UDAs - Restrict to User Defined Types?

Walter Bright newshound2 at digitalmars.com
Wed Nov 7 15:18:34 PST 2012


Started a new thread on this.

On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
 > OK, that's another thing. And maybe a reason for listening to people having
 > more experience with UDAs than you.
 >
 > For me the analogy with Exceptions is pretty good. The issues an conveniences
 > of throwing anything or annotating a symbol with anything instead of just
 > type are pretty much the same. I only see functions making sense to be accepted
 > as annotations too (that's what Python do with annotations, @annotation symbol
 > is the same as symbol = annotation(symbol), but is quite a different language).

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. 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?

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.


More information about the Digitalmars-d mailing list