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
