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)
