If we could start from scratch and guarantee that no new
attributes would
ever be introduced, then we could just put @ on none of them
and thus be
fully consistent. But we can't start from scratch, and we can't
guarantee
that there will be no new attributes. And even then, instead of
getting
complaints about being inconsistent with @, then we'd get even
more
complaints about the number of keywords that we have.
There is no way to win here. No matter what we do, there will
be screaming
from someone. And whether the language would be objectively
improved would
be debatable.
I have proposed a way that I think is a win win. Add support for
non-keyword function attributes on the right hand side of a
function signature. This will not break any code since it does
not require removing support for using '@' for function
attributes. Then later we can deprecate support for the '@'
character if we feel like it's worth breaking code.
void foo() safe; // now valid, and safe is not a keyword
safe void foo(); // still not valid, might make the grammar
// ambiguous, if it does not then it could
// be supported later
void foo() @safe; // Still ok (can be deprecated)
It's simple to remember that if you put the function attribute on
the right hand side then no '@' is required. Plus, this will
encourage developers to put their attributes on the right hand
side in the future so they can remove the '@' character.
PLUS, this would be very simple to implement!
There may be set of changes that would ultimately be better
enough that
they'd be worth making - where the pros are generally
considered to outweigh
the cons - but we'll be stuck with the cons regardless, and I
seriously
question that any change to attribute names is enough of an
improvement to
merit the code breakage that it would cause, even if it were
objectively
better.
My proposal will not break any code.
