The future of UDAs.

[Gor Gyolchanyan]

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 <turkeyman at gmail.com> wrote:

> On 27 November 2012 09:42, Gor Gyolchanyan <gor.f.gyolchanyan at gmail.com>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121127/e0648655/attachment.html>