Proposal: user defined attributes

[Johannes Pfau]

Am Fri, 16 Mar 2012 16:21:41 +0100
schrieb Piotr Szturmaj <bncrbme at jadamspam.pl>:

> > @note(Serializable.yes) int a;
> 
> This is just enum. If you use struct or class attributes (like in C#) 
> then direct @Struct(constructor args..) might be better.
> 
> 
+1

> > The expression inside is appended to a list on
> > the declaration.
> >
> > This would be valid on variables, functions,
> > function parameters, struct members, etc.
> >
> > 2) __traits(getNotes, decl). This returns a tuple
> > of all the note expressions.
> >
> > foreach(i, exp; __traits(getNotes, a)) {
> > static assert(is(typeof(exp) == Serializable);
> > static assert(exp == Serializable.yes);
> > }
> 
> This is nice. Also it's base for library functions like hasNotes or 
> getNotes!(Symbol, MyAttribute).
+1

> > 1) how do you define what is and is not a valid attribute?
> >
> 
> It should be any user-defined type that may be used at compile-time.
> For example @UUID("...") should be available out of the box.

Or we could add a @attribute attribute:

@attribute struct Test
{
    this(int a) {}...
}

@Test(99)
string someTestVal;

> > 2) OK, how do you namespace things so different libraries don't
> > get different results?
> >
> > That's where the beauty of the expression type comes in: D
> > already has namespaces. foo.Serializable != bar.Serializable,
> > so there's no conflict.
> >
> > We simply declare types. The enum X {yes, no} pattern is already
> > common in Phobos, and is also the best way to express a bool
> > condition here. (Technically, @note(true) would compile, but it'd
> > be much less useful than declaring a name for the note too, with an
> > enum.)
> >
> > Name conflicts is a problem already solved by the language.
> 
> Yes, it should be possible to write @std.UUID("").
> 
And all normal import rules should work for user defined attributes as
well (renamed imports, static imports, ...).