User Defined Attributes

[deadalnix]

Le 07/11/2012 10:13, Timon Gehr a écrit :
> On 11/07/2012 08:08 AM, Daniel Murphy wrote:
>> "Walter Bright" <newshound2 at digitalmars.com> wrote in message
>> news:k7cko9$hes$1 at digitalmars.com...
>>> On 11/6/2012 6:10 PM, Daniel Murphy wrote:
>>>> My thoughts exactly. It reminds me of the horror of C++ exceptions. I
>>>> think it would be reasonable to require every annotation is a struct or
>>>> class.
>>>
>>>
>>> Good analogy. But I'm not sure at this point if that is the right
>>> thing to
>>> do.
>>
>> I don't know if it will turn out to be useful either. But if it's left in
>> there, right or wrong, people will use it and it will be impossible to
>> remove later.
>>
>> If two libraries both use string literal annotations for metadata (and
>> they
>> will) you can no longer use both on the same declaration at once. This
>> leads back to C/C++'s global namespace.
>>
>> As an example:
>> [3] class Blah {}
>> What on earth is 3? Why would you want to attach 3 to a class
>> declaration?
>> How many different ways are there for libraries to interpret this?
>>
>> Most importantly, if users still want to experiment with anonymous
>> annotations, they still can:
>> [tuple(3)] class Blah {}
>
> Then what does this particular restriction buy?
>
>> Adding speculative features with no use case in mind is a recipe for
>> disaster.
>>
>> Much like how you can use extern(C) to force global visibility, you can
>> still get the less hygienic behaviour, if you explicitly ask for it.
>>
>> We lose nothing. If it turns out this was the wrong call, built-in types
>> can be restored without breaking a single line of code.
>>
>
> That is never a given in D.
>
> static assert(!is(typeof({struct S{ [2] int x; }})));
>

I'd argue that is expression is the problem here, not really the annotation.