On Sat, 07 Apr 2012 07:26:26 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 06/04/2012 22:46, Mafi a écrit :
>>> 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
>>
>> The second possibility looks good. Especially because the lack of
>> @attribute on square disallows @square.
>>
>> Mafi
>
> This is adding code just for the pleasure of adding more code. Why wan't I construct Area directly as attribute ?

See http://forum.dlang.org/post/op.wcct2shqeav7ka@localhost.localdomain

I think you should be able to construct it by @attribute'ing a struct.  But this sub-thread is about changing the name of the function for construction purposes, but keeping the type as the attribute name.

-Steve

On Sat, 07 Apr 2012 10:11:16 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2012-04-06 20:52, Steven Schveighoffer wrote:
>
>> Also, if I see:
>>
>> @square(5) int foo();
>>
>> How do I know that I have to use __traits(getAttribute, foo, Area)?
>
> Isn't "square" the name of the attribute? In that case you would use:
>
> __traits(getAttribute, foo, square)

The argument was to use the name of the type returned as the attribute name instead of the function.  That is not my proposal.  The suggested case is to be able to use a different name to build the same attribute, to be more intuitive.

i.e. both area and square create the Area attribute, but square only takes one parameter because it's a square.  Kind of like saying "the area is square".

So my counter point above is in the context that the type name of the return value becomes the attribute name.

-Steve

On Sat, 07 Apr 2012 12:48:00 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2012-04-07 05:29, Kapps wrote:
>
>> I slightly prefer this function method over the struct method because:
>> 1) No need to generate a custom struct for everything. Plenty of things
>> are just a true or false, or a string. Saves a little bit of TypeInfo
>> generation.
>
> But you still need to create a function.

functions are easier for the linker to deal with.  The main point here is, no TypeInfo needed.

>
>> 2) The more important one: The possibility to eventually include an
>> alias template parameter. This allows things like looking up whether the
>> symbol with the attribute has other attributes applied, or determining
>> type. This allows things like constraints, and can be a nice benefit.
>
> This can't be done for structs?

IFTI.  It possibly can be added to struct ctors (I argue it should be), but is not today.

I think the struct approach is fine for some attributes, and I think it should be doable to @attribute either functions or structs.  I just want the most generic, basic feature possible.  I think Timon has the best idea that any callable CTFE symbol should be able to be an attribute.

At this point it has become a "structs are a good solution, why not also allow functions?" argument.

-Steve

Am Mon, 09 Apr 2012 09:13:51 -0400
schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:

> On Sat, 07 Apr 2012 10:00:19 -0400, Jacob Carlborg <doob@me.com> wrote:
> 
> > On 2012-04-06 19:37, Steven Schveighoffer wrote:
> >> On Fri, 06 Apr 2012 12:53:51 -0400, Piotr Szturmaj
> >>> struct Author { string name = "empty"; }
> >>> // struct Author { string name; } - this works too
> >>
> >> I think the point is, we should disallow:
> >>
> >> @Author int x;
> >>
> >> -Steve
> >
> > Why?
> 
> I misspoke.  The person who implemented the @Author attribute probably wants to disallow specifying an Author attribute without a name.  I don't think we should disallow that on principle, I meant in the context it should be disallowed.
> 
> -Steve

Yes, when libraries start to offer attributes, their authors likely want to add some static checking. Either as an invariant() with the struct solution, or static asserts in the function.

Java and C# also offer attributes for attributes to:
- allow multiple attributes of the same kind on a symbol
- restrict the attribute to certain symbol types (function, struct, ...)
- inherit attributes down a class hierarchy
I thought I'd just mention it all here in one go as "attribute constraints".

-- 
Marco

On 2012-04-09 15:20, Steven Schveighoffer wrote:

> The argument was to use the name of the type returned as the attribute
> name instead of the function. That is not my proposal. The suggested
> case is to be able to use a different name to build the same attribute,
> to be more intuitive.
>
> i.e. both area and square create the Area attribute, but square only
> takes one parameter because it's a square. Kind of like saying "the area
> is square".
>
> So my counter point above is in the context that the type name of the
> return value becomes the attribute name.
>
> -Steve


Aha, I see.

-- 
/Jacob Carlborg

On 2012-04-09 15:29, Steven Schveighoffer wrote:

> I think the struct approach is fine for some attributes, and I think it
> should be doable to @attribute either functions or structs. I just want
> the most generic, basic feature possible. I think Timon has the best
> idea that any callable CTFE symbol should be able to be an attribute.

Using any callable CTFE symbol would make sense.

-- 
/Jacob Carlborg