custom attribute proposal (yeah, another one)

[Steven Schveighoffer]

On Fri, 06 Apr 2012 14:23:45 -0400, Mafi <mafi at example.org> wrote:

> Am 06.04.2012 17:17, schrieb Adam D. Ruppe:
>> On Friday, 6 April 2012 at 15:07:04 UTC, Manu wrote:
>>> But maybe the function approach has an
>>> effect on the simplicity of the expression for a simple attribute,
>>> like a single bool?
>>
>> Meh, it is pretty similar:
>>
>> struct Serializable { bool yes; }
>> bool Serializable(bool yes) { return yes; }
>>
>
> There's one difference I think.
> struct approach:
> struct Area { int x, y; }
> Area sqare(int a) { return Area(x, y); }
> //foo and bar are attributed the same
> @Area(5, 5) int foo();
> @square(5) int bar();
>
> whereas with the function approach:
> @area(5, 5) int foo();
> @square(5) int bar();
> foo and bar have different attributes.
>
> The problem is you can't define forwarding functions because the symbol  
> is the attribute type. This seems to be a major problem to me.

I acknowledge this limitation.  But we can also overload functions:

@attribute Area area(int w, int h) { return Area(w, h);}
@attribute Area area(int w) { return Area(w, w);}

Granted, area is not as obvious as square (it's actually a bad name, it  
should be something like dimensions), but being able to have more than one  
attribute of the same type I think is essential.

Also, if I see:

@square(5) int foo();

How do I know that I have to use __traits(getAttribute, foo, Area)?

Another possibility:

@attribute Area area(int w, int h) { return Area(w, h);}
@attribute Area area(Area a) { return a;}

Area square(int a) { return Area(a, a);}

@area(5, 5) int foo();
@area(square(5)) int bar();

-Steve