On Wednesday, 21 March 2012 at 15:02:15 UTC, Jacob Carlborg wrote:
Here's my proposal:
Ah yes, I think I did read that before.
I'm not in love with the key=value or the explicit
@attribute on the classes, which is the two biggest
differences we have.
The key=value is nice, but it isn't in the language today,
so it'd be a bunch of special code in the @attribute parser
in the compiler.
If we were to have key=value syntax, I say we should do it
generically (like C style struct initializers?) so it can
work in regular code too, then pick it up naturally here.
I'd prefer to use the existing language syntax in there
so the implementation can literally be as simple as:
if(token == TOKnote) {
token.next();
annotations ~= parseExpression();
}
D's existing struct syntax can handle arguments easily
enough with the StructName("member", "member"); style.
Reusing that here keeps the implementation simple,
and it might be more flexible:
enum MyNote = Something("with args", 2);
@note(MyNote) int foo;
@note(MyNote) bool bar;
this would work too with the simple setup, since the
enum is already handled by the compiler's regular code.
Ditto with ctfe, which is an open hook for some potentially
cool stuff down the line without any extra implementation.
The other thing is @attribute struct {} rather than just
struct {}. I don't any benefit to that. If I want to
reuse a regular, runtime struct to store info at compile
time, why shouldn't I be able to do that?
I'm thinking of @note(X) as meaning simply:
enum tmp = X; // evaluate ctfe, etc
decl.annotations ~= tmp; // store it for later
