Mitigating the attribute proliferation - attribute inference for functions

[Dicebot via Digitalmars-d]

On Monday, 13 April 2015 at 14:09:22 UTC, Steven Schveighoffer 
wrote:
> On 4/11/15 5:46 PM, Martin Nowak wrote:
>> Sorry to open yet another topic.
>>
>> I'm repeatedly finding myself in situations where I write 
>> functions like
>> this.
>>
>>     private @property bool empty() const @safe pure nothrow 
>> @nogc
>>     {
>>         return impl is null || !impl.count;
>>     }
>>
>> This is obviously a joke, because the compiler very well knows 
>> the
>> attributes and I don't need to guarantee them as part of an 
>> API.
>> The situation is getting somewhat out of hands and we need to 
>> find a way
>> to make attribute inference for functions feasible.
>
> Have you considered the evolution of code?
>
> For example, what if a @nogc-inferred function changes 
> implementation and then uses the GC? The author of said 
> function didn't care if it was @nogc or not, but the compiler 
> helpfully makes it @nogc.

This is exactly what "explicit API" thing is about. If symbol is 
`export` it must have explicit attributes. If it isn't, inferring 
is fine because no promises are actually made.