Basically the most important thing I miss is mutable compile-time variables. That's it. Everything else can be worked around.
On Tue, Nov 27, 2012 at 3:16 PM, Manu <[email protected]> wrote: > On 27 November 2012 09:42, Gor Gyolchanyan <[email protected]>wrote: > >> Hi, fellow D programmers. >> >> I'd like to know (and I think I'm not alone with this) the future plans >> about UDAs, the features they're planned to have and the features they're >> planned not to have. >> I have a curious project, which would be vastly easier and cleaner with >> proper UDAs, so naturally I'd like to know what to expect, because if what >> I need is planned to be available, I'll postpone my project, instead of >> rushing into an ugly solution. >> >> AFAIK, currently UDAs are set at declaration site, are immutable and the >> declaration cannot get additional UDAs externally. >> > > This is true, and variable UDA's would be nice. Attributed variable > declarations it should be trivial, but I guess the problem is if you > attribute members of a struct, or any type its self for that matter, then > each instance of that type would have to have respective UDA instances, > that's not so simple. Where do they allocate? Are they part of the struct > or not? > > Moreover, only global declarations can have UDAs, which removes some very >> useful possible uses of UDAs. >> > > This is just not true. You can attribute basically anything. I attribute > shit loads of stuff in my project. > > Lack of mutable compile-time variables sometimes cripples the >> metaprogramming in D. For instance all classes, derived from a certain type >> must be dealt with in a special way, which requires a tuple of those types. >> Gathering a tuple of unrelated types is currently impossible, because that >> would require mutable compile-time variables. >> >> Mutable compile-time variables would also be extremely useful for >> implementing a very powerful compile-time reflection library without the >> need for compiler magic. All you'd have to do is mix in a template in your >> class or your module and voila. The mixin would then add the introspected >> declarations to the central compile-time declaration repository. >> >> There are also many cases when some actions need to happen in case a >> declaration gets a UDA of a specific type. For instance, a powerful RTTI >> library, which (when a type gets a dedicated RTTI-typed UDA) adds the >> run-time information about the class to the central registry at load-time. >> This kind of stuff could be easily achieved using the constructors and >> destructors of the structures, being added to the UDAs of a declaration (in >> this case a class). The only missing thing for this to work is the ability >> for the constructor to see the declaration it's being put on. I'd >> personally expect there to be some sort of a >> __traits(getAttributeDeclaration), which would evaluate to the symbol on >> which the enclosing type (a structure, a union or whatever) is being placed >> on as an attribute. >> >> The point is, that with a tiny little boost, the UDAs could make D's >> meta-programming a tool so powerful, it would be very difficult to predict >> the limit of possibilities.. >> >> Note, that this thread isn't about the syntax, but about the expected and >> planned functionality of UDAs and their use cases. >> >> Please share your thoughts about this. >> > > I guess I'm curious too to hear peoples theoretical limits on the subject. > But what's there now handles about 80% of my use cases, and is a huge bonus! > -- Bye, Gor Gyolchanyan.
