On 2012-11-08 00:18, 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. 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.
I think we should only allow user defined types marked with @attribute, i.e.
@attribute struct foo {}
@attribute class foo {}
@attribute interface foo {}
@attribute enum foo {}
And so on.
--
/Jacob Carlborg
