@safe function causes attribute inference since 2.072

[jeckel]

On Monday, 13 April 2020 at 19:45:54 UTC, Steven Schveighoffer 
wrote:
> On 4/13/20 3:11 PM, jeckel wrote:
>
>> 
>> I'd say it's a feature. And I'd honestly prefer it to be 
>> expanded to regular functions as well. Rather than having to 
>> deal with the change all the defaults DIPs. I usually come 
>> across a function in phobos that is @nogc and pure, someone 
>> just forgot to annotate it with those attributes. If it was 
>> auto inferred this wouldn't be a problem, it knows whether it 
>> is @nogc and pure, it should just add those attributes itself.
>
> I kind of agree, more inference = better code, especially for 
> things that are in functions which cannot be prototyped in a 
> .di file. I'd just as soon see ALL inner functions and types be 
> fully inferred.

I'd say even to functions that appear in header files. Header 
files are auto generated, they would add the attributes as 
required. Yes this has the problem that you may unintentionally 
change the attributes by changing the implementation. If you need 
to ensure a certain attribute is followed you can just add it to 
the function.

> But there are two sticking points:
>
> 1. If I WANT to mark something as @gc, throw, or impure, I 
> can't. So there are some cases (unittests are one of them) that 
> are difficult to construct.
>
> For example, the now-merged PR that I made had to put this in 
> the constructor:
>
>         this(scope ref return const A other)
>         {
>             import std.stdio;
>             x = other.x;
>             // note, struct functions inside @safe functions 
> infer ALL
>             // attributes, so the following 3 lines are meant 
> to prevent this.
>             new int; // prevent @nogc inference
>             writeln("impure"); // prevent pure inference
>             throw new Exception(""); // prevent nothrow 
> inference
>         }
>
> 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.

> 2. I can't figure out why @safe should be the only place where 
> this happens. Which is why I'm not sure if it was intentional 
> or not.
>
> Regardless of how helpful it is, if it's a bug, we should look 
> to see why it was "added" and that would help figure out 
> whether we should revert that without breaking the reason it 
> happened.
>
> Or make it official, and expand the places it is useful.
>
> -Steve

That I feel is probably a bug. I tried to narrow down which 
commit it was, not sure why there's such a huge commit but it's 
somewhere in here: 
https://github.com/dlang/dmd/commit/7713ec376d446245ac60a0e3d0ad101d28fea5ba
Really hate merges like this instead of a rebase.