Mitigating the attribute proliferation - attribute inference for functions

[Jonathan M Davis via Digitalmars-d]

On Friday, 17 July 2015 at 12:43:33 UTC, Martin Nowak wrote:
> =================== Attributes are hardly useful 
> ======================

nothrow and pure - pure especially - help with reasoning about 
code. You actually lose out a fair bit with them IMHO when 
they're inferred, since a lot of their value is derived from the 
programmer knowing for sure that a function is nothrow or pure. 
pure then allows for some other nice stuff from the compiler like 
optimizations and implicit casting, but I suspect that the 
compiler really isn't taking advantage of it like it should. For 
nothrow, I'm not sure of how much value the optimization 
opportunities are, though having  the compiler scream at you when 
you mark something as nothrow is definitely useful when it isn't 
actually nothrow.

In principle, @safe is great, though it's going to be worse in 
druntime and Phobos, because we're more likely to interacting 
with the C APIs. However, it has way too many holes in it still, 
because we've blacklisted rather than whitelisted, and it's 
arguably a disaster with templates if you have to do anything 
which is @system, because you have to make sure that you only use 
@trusted on stuff that you've actually verified and not stuff 
being called on template arguments. So, the situation with @safe 
is worse than it should be, but I also think that it would be a 
mistake to get rid of it rather than fix it. It should be 
recognized though that thanks to @trusted, it doesn't really 
guarantee memory safety. It just restricts the number of places 
that you have to look when you screw it up (which is quite 
valuable, but it's not the same at all as guaranteeing memory 
safety).

@nogc is mostly a PR thing IMHO. It has value in that it helps 
you find places where you accidentally used the GC (though if you 
really care, you can always use the profiler as you point out), 
and if @nogc is marked explicitly, it makes it easier to see 
which functions can be used in @nogc code, but ultimately, it 
really seems like it's there simply to appease the folks who 
don't want any GC usage at all.

Overall, I think that we're between a rock and a hard place, 
because in many ways, a lot of the benefit of attributes come 
from the fact that they're marked explicitly on the API, so 
having tons of attribute inference would actually make them worse 
in that regard. Also, adding attributes automatically could 
result in effectively giving guarantees about functions which 
aren't intended - especially if the inferred attributes end up in 
the docs for non-templated functions.

Honestly, what we should do if we don't care about code breakage 
is make pure and @safe the default, since they really should be 
the rule rather than the exception. That would reduce the problem 
considerably. But the problem is that that breaks code, and 
without @safe whitelisting stuff instead of blacklisting it, it 
would probably make the breakage related to fixing @safe holes 
even worse. So, I very much doubt that we can do it at this 
point, much as that's really where we want to be.

- Jonathan M Davis