User Defined Attributes

Jacob Carlborg doob at me.com
Wed Nov 7 23:35:29 PST 2012


On 2012-11-07 23:20, Walter Bright wrote:

> There's another aspect to this.
>
> D's UDAs are a purely compile time system, attaching arbitrary metadata
> to specific symbols. The other UDA systems I'm aware of appear to be
> runtime systems.
>
> This implies the use cases will be different - how, I don't really know.
> But I don't know of any other compile time UDA system. Experience with
> runtime systems may not be as applicable.
>
> Another interesting data point is CTFE. C++11 has CTFE, but it was
> deliberately crippled and burdened with "constexpr". From what I read,
> this was out of fear that it would turn out to be an overused and
> overabused feature. Of course, this turned out to be a large error.
>
> One last thing. Sure, string attributes can (and surely would be) used
> for different purposes in different libraries. The presumption is that
> this would cause a conflict. But would it? There are two aspects to a
> UDA - the attribute itself, and the symbol it is attached to. In order
> to get the UDA for a symbol, one has to look up the symbol.

This is what I start to like less and less about the current 
implementation of UDA. There is no actual attribute. There is the symbol 
with a bunch of random attached values.

I want to be able to do something like this:

module bar;

@attribute struct foo
{
     string name;
}

@foo int a;

alias Tuple!(__traits(getAttributes, foo)) TP;

enum bool yes = hasAttribute!(bar.foo);

static if (yes)
     enum foo attr = getAttribute!(bar.foo);

The last two could actually be library functions.

> There isn't
> a global repository of symbols in D. You'd have to say "I want to look
> in module X for symbols." Why would you look in module X for an
> attribute that you have no reason to believe applies to symbols from X?
> How would an attribute for module X's symbols leak out of X on their own?

Have you ever heard of libraries. You can pass a symbol as an alias 
parameter to a function of a completely different library.

> It's not quite analogous to exceptions, because arbitrary exceptions
> thrown from module X can flow through your code even though you have no
> idea module X even exists.
>


-- 
/Jacob Carlborg


More information about the Digitalmars-d-announce mailing list