Proposal: user defined attributes

[Kapps]

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. 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. 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.