@safe function causes attribute inference since 2.072

[Steven Schveighoffer]

On 4/13/20 8:44 PM, jeckel wrote:
>> I would hope there is a better way to do this.
> 
> Why would you want to do this? If something is @nogc, why would you want 
> to mark it not as @nogc? What use case is there? This hasn't been an 
> issue for templates, at least I've never heard someone mention and it 
> being an issue for them.

Here is the issue I was fixing:

https://issues.dlang.org/show_bug.cgi?id=20732

What I wanted for a test was a struct with a non-pure, non- at nogc, 
throwing copy constructor to test my fix. I figured this should do it:

@safe unittest
{
    static struct A
    {
       this(scope ref return const A other) {}
    }
    A a1, a2;
    swap(a1, a2);
}

And I added that test before fixing the problem. And it passed!

But doing similar things on run.dlang.io didn't work. Indeed, if you 
just copy that exact struct definition as a global definition, and then 
try to use it, it fails. It took me a while to figure out what was going on.

So not a common use case. But I would hope one that has a better 
solution than a) define a unittest-only struct outside unittests, or b) 
do what I did and add things to prevent inference.

I suppose I could have called an extern(C) prototype inside the 
constructor that was without attributes. I don't really like that 
either, but probably not as verbose.

The bottom line is -- there are no opposites for some of these 
attributes, so it's awkward to force the inference that way. It's a 
weird thing to enforce only on @safe functions anyway.

-Steve