User Defined Attributes

[Timon Gehr]

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; }})));