UDAs - Restrict to User Defined Types?

deadalnix deadalnix at gmail.com
Sat Nov 10 07:32:56 PST 2012


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.


More information about the Digitalmars-d mailing list