accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Monday, 26 January 2015 at 23:41:07 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler 
> wrote:
>> The lexer would recognize these attributes as normal ID tokens.
>> The grammar could be amended to allow a function to be 
>> decorated with keywords and generic id tokens.  Then the 
>> meaning of those tokens would be handled by semantic analysis.
>
> How do you tell the difference between a return type and a user 
> attribute on the left side?
>
> nogc myUda1 myUda2 returnType funcName() { return 
> returnType(a); }
>
> They are UDAs only because they are not the second-to-last id 
> (the return type) or the last id (the function name). How do 
> you do 'auto' inferred return types in this context, when the 
> compiler thinks your UDA is also your return type? Also, why 
> burden the *programmer* with having to sort this out? It's too 
> ambiguous to read, for my taste. If I just switch the names the 
> entire signature changes:
>
> nogc returnType myUda1 myUda2 funcName() { return 
> returnType(a); }
>
> Now it's supposed to return a myUda2, just because you switched 
> the ordering? I can see why this idea would be rejected.

I wasn't proposing UDA's to omit the '@', only LDA's (Language 
defined attributes).  Also, again, your example is assuming that 
we allow identifiers before the function signature, which is on 
optional part of what I proposed.  The bigger problem with that 
proposal would be that if a function can start with a list of 
general id tokens, it's very likely to create ambiguity in the 
grammar.  However, if they can only appear after the function 
signature, I'm almost certain no ambiguity is created.  There are 
different ways to get around this, one is to require the '@' only 
if the attribute appears before the function signature.  The 
other is to disallow function attributes before the signature (or 
at least certain ones).  There's different solutions, but that's 
not the point of the proposal.  The point of the proposal is to

   Allow a function to be decorated with id tokens (so long as it 
doesn't create ambiguity) in order to specify attribute like 
"safe"/"nogc"/etc

There are different ways to implement this and I see people 
arguing about specific implementations, but no one is addressing 
the main concept of the proposal (except Walter who just says 
that he doesn't like "context-sensitive" tokens but I fail to see 
how this creates tokens that are more "context-sensitive" then 
other tokens)