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.