custom attribute proposal (yeah, another one)

[deadalnix]

Le 06/04/2012 15:23, Steven Schveighoffer a écrit :
> OK, so I woke up this morning to find a huge discussion on attributes,
> and I'd like to once again propose the idea of how to define and use an
> attribute.
>
> I do not like the idea of:
>
> @attr(identifier)
>
> Why? Because what the hell did we create that "@" syntax for? I though
> it was to avoid misinterpreting such things as normal symbols, and avoid
> creating new keywords. Why should the compiler be the only one able to
> use such symbols?
>
> Another thing I don't like is some idea that only a certain type of
> construct can be the identifier. An attribute should have one
> requirement -- that it can be created/determined at compile time.
>
> So here is my proposal:
>
> 1. Introduce a new compiler-defined attribute @attribute (or @attr or
> something better, the name isn't important).
> 2. This attribute can *only* be used on a module-level function.
> 3. @attribute functions *must* be CTFE-able.
> 4. An @attribute function can be used as a user-defined attribute on any
> declaration using the syntax @identifier where identifier is the name of
> the attribute function (subject to normal function lookup rules). If the
> attribute can be called without parameters, the parentheses are optional.
> 5. When used on a declaration, that CTFE function is called during
> compile-time, and the result of that function is stored as metadata on
> that symbol. It does not affect the type of the symbol or transfer to
> any other symbols that are assigned to the value of that declaration (in
> other words, it *cannot* be used as a type constructor).
> 6. The metadata is stored in a key-value pair, with the key being the
> symbol of the @attribute function, and the value being the result of the
> CTFE function.
> 7. One can lookup whether an attribute exists on a symbol using
> __traits(hasAttribute, symbol).
> 8. One can retrieve the value of the CTFE result using
> __traits(getAttribute, symbol). If the CTFE function returns void, this
> is a compiler error.
>
> And that's it. We can extend this eventually to storing something in
> TypeInfo, but I'm not sure we need that. However, I want to stress that
> having runtime type metadata is not a requirement for this proposal.
>
> Example usage:
>
> @attribute bool serializable(bool yesorno = true) { return yesorno; }
>
> unittest {
> // serializable is a normal function also
> assert(serializable() == true);
> assert(serializable(true) == true);
> assert(serializable(false) == false);
> }
>
> @serializable struct MyType
> {
> int x;
> int y;
> @serializable(false) int z;
> }
>
> string serialize(T)(const ref T t) if (__traits(hasAttribute,
> serializable) && __traits(getAttribute, serializable))
> {
> // serialize each field. Skip any fields that are marked as serializable
> == false
> }
>
> -Steve

The struct proposal from previous thread was superior because it provide 
similar capability without as much language change.