UDAs - Restrict to User Defined Types?

[Timon Gehr]

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.