@safe function causes attribute inference since 2.072

[RazvanN]

On Thursday, 16 April 2020 at 03:33:35 UTC, Timon Gehr wrote:
> On 15.04.20 04:07, Walter Bright wrote:
>> On 4/14/2020 2:08 PM, Steven Schveighoffer wrote:
>>> Is there any reason why @safe functions are also affected? Is 
>>> there any reason we shouldn't extend this to other attributed 
>>> functions, or just all things inside a function context?
>> 
>> I think the rationale was that @system-by-default didn't make 
>> sense for nested functions inside @safe functions when source 
>> was available. So being in @safe turned on attribute inference 
>> for them.
>> 
>> It probably does make sense to turn on attribute inference for 
>> everything defined within a function.
>
> Yes, absolutely. Also, any kind of attribute "inheritance" is 
> misguided and should be turned off. There is no reason why 
> functions nested in @nogc functions should be implicitly @nogc, 
> for example. If they are inferred to possibly use the GC, @nogc 
> already checks that the enclosing function only calls it in a 
> context where that is okay (for example, in CTFE).

+1. Currently, dmd is completely inconsistent with regards to 
qualifier inference. You have different behaviors depending on 
the attribute (for example: @safe is inherited for nested 
functions, while pure is not; and this depends on the use case, 
see [1]). I think it would be much more intuitive to infer 
attributes for functions where the body is certainly known 
(delegates, nested functions, generated functions - think about 
member functions of nested structs), but enforce those only when 
the function is called in a specific context.

[1] https://github.com/dlang/dmd/pull/8607