custom attribute proposal (yeah, another one)

Steven Schveighoffer schveiguy at yahoo.com
Fri Apr 6 07:23:51 PDT 2012


On Fri, 06 Apr 2012 10:11:32 -0400, Manu <turkeyman at gmail.com> wrote:

> On 6 April 2012 16:56, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
>
>> On Fri, 06 Apr 2012 09:53:59 -0400, Timon Gehr <timon.gehr at gmx.ch>  
>> wrote:
>>
>>  I think this proposal should be merged with Johannes' one.
>>>
>>
>> It is very similar.  I think the main distinction is that I focused on  
>> the
>> fact that the compiler already has a mechanism to check and run CTFE
>> functions.
>>
>
> Except you're using a function, which I don't follow. How does that work?
> Where do you actually store the attribute data?
> Just attaching any arbitrary thing, in particular, a struct (as in  
> Johannes
> proposal) is far more useful. It also seems much simpler conceptually to
> me. It's nice when things are intuitive...

You can store a struct, just return it from an attribute function.

e.g.:

@attribute Author author(string name) { return Author(name);}

Why should we be restricted to only structs?  Or any type for that matter?

The benefit to using CTFE functions is that the compiler already knows how  
to deal with them at compile-time.  i.e. less work to make the compiler  
implement this.

I also firmly believe that determining what is allowed as attributes  
should be opt-in.  Just allowing any struct/class/function/etc. would lead  
to bizarre declarations.

-Steve


More information about the Digitalmars-d mailing list