Le 08/11/2012 01:11, Timon Gehr a écrit :
On 11/08/2012 12:18 AM, Walter Bright wrote:
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.
This is a valid point, and I think it does not really make sense to only
exclude built-in types. Any type not intended for use as an attribute
and that is exported to sufficiently many places can have the same
behaviour.
I'd vote no restrictions at all, or for requiring @attribute annotations
on the user-defined type and ban user-defined types from being
annotations that do not have that.
I'd vote for requiring @attribute annotations on the user-defined type
and ban user-defined types from being annotations that do not have that.
That is really important to allow libs not to step on each other's toes.
