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.
