custom attribute proposal (yeah, another one)
Tove
tove at fransson.se
Fri Apr 6 10:33:33 PDT 2012
On Friday, 6 April 2012 at 14:23:51 UTC, Steven Schveighoffer
wrote:
> 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
I think this proposal pretty much covers what I would expect from
'custom attributes'... but what about adding a D twist, getting
"what we annotate" as a template parameter so that one among
other things can make use of Template Constraints?
More information about the Digitalmars-d
mailing list