Proposal: user defined attributes

[Andrei Alexandrescu]

On 3/20/12 12:50 AM, Kapps wrote:
> On Monday, 19 March 2012 at 21:00:32 UTC, Andrei Alexandrescu wrote:
>> On 3/19/12 3:55 PM, F i L wrote:
>>> I think this could get tricky for the compiler to confidently use given
>>> that the mixed in enums can collide with existing members (although not
>>> likely). Also, if objects are not identified as being unique marked (in
>>> the compilers eyes), what specific attribute post-fixes will it be
>>> searching for on enums members?
>>
>> Not a big issue, the name could always contain a uuid which makes
>> collision practically impossibile.
>>
>> Andrei
>
> And with parameters? Or how about run-time reflection, which is
> something that should be added eventually for attributes as well (that
> is, typeid(Blah).getCustomAttributes())? We can't manually add things
> into the TypeInfo.

Perhaps we should add a field of type Variant[string].

> This is an already ridiculously hackish approach, and
> it *does not* work for anything besides trivial applications. It is
> completly unreasonable to expect everything to be done in a library; the
> compiler exists for a reason and at some point you have to draw the
> line.

I'm afraid I disagree. A targeted language feature definitely makes a 
library approach inferior, by definition. But adding features is 
cheating, like printing money is for a government: very tempting, with 
apparently good short-term benefits, but with devastating cumulative 
effects.

Also, as I mentioned, the availability of the easy escape hatch of 
adding a language feature thwarts creativity. Nobody will care to think 
about and come with idioms that use the language to do great things, if 
they know a language feature could be always added that makes things 
"nicer".

I'm not saying this particular feature should or should not be in the 
language, but I wish our community exercised considerably more restraint 
when it comes about adding new language features.

> Why even bother having an auto keyword? Instead of 'auto a = b +
> c' you could simply use 'Auto!(b + c) a = b + c'. It is a more extreme
> example for now, but won't be too much different once more complicated
> things arise; after all, auto!2 a = 2 is not much different from auto a
> = 2. Just like it's not too much different for parameterless attributes
> (even if it is uglier and much more hackish), but once you get into
> parameters and runtime stuff it becomes just as ugly as the above example.

I don't think your example with auto is relevant.


Andrei