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