Mitigating the attribute proliferation - attribute inference for functions

[Steven Schveighoffer via Digitalmars-d]

On 4/13/15 10:23 AM, Dicebot wrote:
> 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.

I thought 'export' was for dll/so?

In order for this to work, code that is "external" better not be able to 
call any non-export functions. This is not a change I think we should 
pursue.

-Steve