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
