custom attribute proposal (yeah, another one)

[Steven Schveighoffer]

On Fri, 06 Apr 2012 10:56:19 -0400, Piotr Szturmaj <bncrbme at jadamspam.pl>  
wrote:

> 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);}
>
> Compare it to:
>
> struct Author { string name; }
>
> @Author("John Doe") int x;

so now I must define a type for every attribute?  I'd rather just define a  
function.

What if I have 20 string attributes, I must define a new attribute type  
for each one?  This seems like unneeded bloat.

BTW, if I wasn't trying to demonstrate that you could store structs, I  
would have written:

@attrubte string author(string name) { return name;}

and save the extra bloat associated with declaring another type.  Maybe we  
could even get this someday:

@attribute author(string name) => name;

I just don't see the need to declare a type that can wrap a string.

You could even add this rule:

if @attribute is placed on a struct, its constructor becomes an @attribute  
qualified function with the name of the struct as the attribute name.

>> Why should we be restricted to only structs? Or any type for that  
>> matter?
>
> When using __traits(getAttributes, ...) you ask for conrete (struct)  
> type and you get it. In case of function you ask for serializable but  
> you get a bool.

It's an example.  you can choose any type you want!  I actually just want  
the name of the author, I don't care whether that's a struct, or a string.

>
>> 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.
>
> Compiler can easily deal with structs too:

I concede this is probably a non-issue.

>> 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.
>
> C# has requirement that attributes are classes that derive from base  
> Attribute class. But without that limitation you can do things like:
>
> @Uuid("...")
> interface MyIntf { }
>
> without explicitly declaring Uuid as attribute. However, I don't see any  
> usage for primitive types:
>
> @5
> @"s"
> @false

I don't understand what you are saying here.

> I think that allowing values of structs, classes and _eventually_ enums  
> should be enough.

Any CTFE computed value should suffice.

-Steve