I think I really don't know what exactly do the UDAs do at the moment, judging from your reply.The only documentation was the original D.anounce post of yours. Is there a way I can get a reliable documentation on this?
Use cases: 1. I have a declaration with a UDA struct. I introspect the types I need and add their names to an array in that struct. read that struct in a static constructor and do necessary stuff with all those types. Is this possible currently? 2. I have some code, which must be run on any type, marked with a special UDA. Can I have that code executed without explicitly having to mix stuff in every module? I guess the way UDAs were originally designed, they have absolutely nothing to do with what I envisioned. On Tue, Nov 27, 2012 at 3:11 PM, Walter Bright <[email protected]>wrote: > On 11/27/2012 6:42 PM, Gor Gyolchanyan wrote: > >> AFAIK, currently UDAs are set at declaration site, are immutable and the >> declaration cannot get additional UDAs externally. Moreover, only global >> declarations can have UDAs, which removes some very useful possible uses >> of UDAs. >> > > What very useful thing could be done with UDAs on local variables? > > > > 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. >> > > I don't understand this. It is perfectly possible to create compile time > tuple of (int, long, float, int*, S). > > > > 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. >> > > I don't understand the difficulty here. UDAs are additive, so you could > mixin your template in one space at the top, and it will apply to all the > declarations nested under it, exactly like other attributes do now. > > > > 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. >> > > That can be done now. Loop over the declarations, checking to see if each > has a particular attribute. > > > 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. >> > > That could cause ugly forward reference issues, and also recall that a UDA > can be applied to many declarations at once. > > -- Bye, Gor Gyolchanyan.
