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 ?

On 7 April 2012 06:29, Kapps <opantm2+spam@gmail.com> wrote:

> On Friday, 6 April 2012 at 13:23:03 UTC, Steven Schveighoffer wrote:
>
>> OK, so I woke up this morning to find a huge discussion on attributes, and I'd like to once again propose the idea of how to define and use an attribute.
>>
>> I do not like the idea of:
>>
>> @attr(identifier)
>>
>> Why?  Because what the hell did we create that "@" syntax for?  I though it was to avoid misinterpreting such things as normal symbols, and avoid creating new keywords.  Why should the compiler be the only one able to use such symbols?
>>
>> Another thing I don't like is some idea that only a certain type of construct can be the identifier.  An attribute should have one requirement -- that it can be created/determined at compile time.
>>
>
> Either this or the one that's the same just with structs is the way to go. The original proposal by Walter is good, it's just a little verbose.
>
> 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.
> 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.
>
> On the topic of type vs storage, it is useful to be able to apply attributes to a type, but this should /not/ change the type itself. It must be transparent to the user what attributes a type has unless they're actually accessing attributes.
>

Generating a struct for an attribute is fine. It's not like you go on
a custom attribute frenzy attributing everything with different stuff. You
may have a few useful attributes, and those given by libs that you just use.
Why can't you use alias template parameters in a struct definition in just
the same way?

Structs are definitely preferable in my opinion, for the fact that they can
have methods and properties and stuff. If you get an attribute of
something, being about to use methods on it, or access calculated data via
properties will be useful.
I see no reason to name an attribute differently than the thing that
happens to define it.

On Saturday, 7 April 2012 at 11:13:54 UTC, deadalnix wrote:
> Le 07/04/2012 05:29, Kapps a écrit :
>> 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.
>
> If the type isn't used at runtime, the compiler should be able to remove that dead part of the code. If it doesn't, it is an implementation issue, and shouldn't be solved by language design decision.

This is not possible currently. The TypeInfo is required at runtime whether or not the type is used at compile-time, for reasons such as Object.factory.

On Saturday, 7 April 2012 at 11:25:15 UTC, Manu wrote:
>
> Generating a struct for an attribute is fine. It's not like you go on
> a custom attribute frenzy attributing everything with different stuff. You
> may have a few useful attributes, and those given by libs that you just use.
> Why can't you use alias template parameters in a struct definition in just
> the same way?
>
> Structs are definitely preferable in my opinion, for the fact that they can
> have methods and properties and stuff. If you get an attribute of
> something, being about to use methods on it, or access calculated data via
> properties will be useful.
> I see no reason to name an attribute differently than the thing that
> happens to define it.

The calling methods is a valid point, however the method can return a struct as well.

Ultimately, I don't think it makes a large difference at all which is used. I'm just leaning towards methods because there's less bloat, no issues with this() like with a struct, and can be slightly simpler in certain situations.

Again, it's mostly minor things. I'd be quite happy with either approach.

On 7 April 2012 14:35, Kapps <opantm2+spam@gmail.com> wrote:

> On Saturday, 7 April 2012 at 11:25:15 UTC, Manu wrote:
>
>>
>> Generating a struct for an attribute is fine. It's not like you go on
>> a custom attribute frenzy attributing everything with different stuff. You
>> may have a few useful attributes, and those given by libs that you just
>> use.
>> Why can't you use alias template parameters in a struct definition in just
>> the same way?
>>
>> Structs are definitely preferable in my opinion, for the fact that they
>> can
>> have methods and properties and stuff. If you get an attribute of
>> something, being about to use methods on it, or access calculated data via
>> properties will be useful.
>> I see no reason to name an attribute differently than the thing that
>> happens to define it.
>>
>
> The calling methods is a valid point, however the method can return a struct as well.
>
> Ultimately, I don't think it makes a large difference at all which is used. I'm just leaning towards methods because there's less bloat, no issues with this() like with a struct, and can be slightly simpler in certain situations.
>
> Again, it's mostly minor things. I'd be quite happy with either approach.
>

Yeah I'm happy either way. At the end of the day, I guess whoever actually implements the feature will just follow their preference ;)

On 2012-04-06 19:36, Steven Schveighoffer wrote:
> 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.

If we want to be able to pass a key-value list to the attribute, I think a struct is needed.

@attribute struct Author
{
    string name;
    string email;
}

@Author(name = "John Doe", email = "john@doe.com") struct Foo {}

BTW, could both structs and functions be allowed?

-- 
/Jacob Carlborg

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?

-- 
/Jacob Carlborg

On 2012-04-06 19:51, bls wrote:

> Why not being more flexible .. Likewise
>
> struct Annotation //Throw in all your annotations
> {
>
> Variant[] [string] map;
>
> Variant[] opDispatch(string key)()
> {
> return map[key];
> }
>
> // Single value
> Variant[] opDispatch(string key, T) (T t )
> if ( !isArray!T && !isTuple!T )
> {
> index ~= key;
> map[key] ~= to!Variant(t);
> return map[key];
> }
> ....Array, Tuple
> }
> well.. I am not sure about CTFE

Variant yet again. What with this Variant all the time.

-- 
/Jacob Carlborg

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)

-- 
/Jacob Carlborg

On 2012-04-07 00:40, Piotr Szturmaj wrote:

> Ok, but it needs more work in the compiler, comparing to identifier
> search and remembering expression tuple of a symbol. Also, I just found
> a major drawback of this approach: consider parameterless attributes
> like @NotNull. What would you return from function named NotNull()?

void ?

-- 
/Jacob Carlborg