accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

> 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.