On Tuesday, November 27, 2012 11:42:17 Gor Gyolchanyan wrote:
> I'd like to know (and I think I'm not alone with this) the future plans
> about UDAs

Ah, the wonders of acronyms. I spent half this post trying to figure out what on earth UDAs were (User Defined Attributes, I guess). Clearly, I need to update the set of D-related acronyms in my head.

- Jonathan M Davis

Yes, this is about User Defined Attributes. I'd like to hear the opinions of the D community and the DMD development team in particular.


On Tue, Nov 27, 2012 at 2:01 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Tuesday, November 27, 2012 11:42:17 Gor Gyolchanyan wrote:
> > I'd like to know (and I think I'm not alone with this) the future plans
> > about UDAs
>
> Ah, the wonders of acronyms. I spent half this post trying to figure out
> what
> on earth UDAs were (User Defined Attributes, I guess). Clearly, I need to
> update the set of D-related acronyms in my head.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

On 27 November 2012 09:42, Gor Gyolchanyan <gor.f.gyolchanyan@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!

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

> On 27 November 2012 09:42, Gor Gyolchanyan <gor.f.gyolchanyan@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.

On Tuesday, November 27, 2012 15:28:10 Gor Gyolchanyan wrote:
> Basically the most important thing I miss is mutable compile-time variables. That's it. Everything else can be worked around.

Having them would break the compilation model, so we're never going to get them. D quite specifically avoids them because it solves all kinds of problems to not have them (e.g. issues with the order of initialization of variables). If a mutable variable, than use a local variable inside of a template or function with CTFE. That's as close as you're going to get.

- Jonathan M Davis

On Tuesday, 27 November 2012 at 11:28:21 UTC, Gor Gyolchanyan wrote:
> Basically the most important thing I miss is mutable compile-time
> variables. That's it. Everything else can be worked around.

I like the fact that you don't need to worry about the order in which things are compiled.

On 27 November 2012 11:16, Manu <turkeyman@gmail.com> wrote:
> On 27 November 2012 09:42, Gor Gyolchanyan <gor.f.gyolchanyan@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?
>

As far as I can tell, it's all just metadata known at compile-time only.  Nothing is written in the resultant binaries or object files produced.



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Yeah, current D's compile-time model makes it impossible. And I agree, that D's compile-time model isn't going to change any time soon (if ever). That's depressing. Having a complete compile-time reflection without this will require heavy duty compiler magic.


On Tue, Nov 27, 2012 at 3:34 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Tuesday, November 27, 2012 15:28:10 Gor Gyolchanyan wrote:
> > Basically the most important thing I miss is mutable compile-time variables. That's it. Everything else can be worked around.
>
> Having them would break the compilation model, so we're never going to get
> them. D quite specifically avoids them because it solves all kinds of
> problems
> to not have them (e.g. issues with the order of initialization of
> variables).
> If a mutable variable, than use a local variable inside of a template or
> function with CTFE. That's as close as you're going to get.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

Knowing that my only hope is that new std.reflection (and all compiler magic that comes with it) will remedy all big problems that I wanted to solve using compile-time mutable variables.


On Tue, Nov 27, 2012 at 3:34 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Tuesday, November 27, 2012 15:28:10 Gor Gyolchanyan wrote:
> > Basically the most important thing I miss is mutable compile-time variables. That's it. Everything else can be worked around.
>
> Having them would break the compilation model, so we're never going to get
> them. D quite specifically avoids them because it solves all kinds of
> problems
> to not have them (e.g. issues with the order of initialization of
> variables).
> If a mutable variable, than use a local variable inside of a template or
> function with CTFE. That's as close as you're going to get.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

It'll always be true for anything that IS immutable. If (theoretically) we had mutable compile-time variables, the ones marked as immutable would behave exactly like the current compile-time values. Otherwise, yes, we'd have to give up the freedom of evaluation for the mutable ones.

But Jonathan is right, that's not going to happen.


On Tue, Nov 27, 2012 at 3:36 PM, jerro <a@a.com> wrote:

> On Tuesday, 27 November 2012 at 11:28:21 UTC, Gor Gyolchanyan wrote:
>
>> Basically the most important thing I miss is mutable compile-time variables. That's it. Everything else can be worked around.
>>
>
> I like the fact that you don't need to worry about the order in which things are compiled.
>



-- 
Bye,
Gor Gyolchanyan.