custom attribute proposal (yeah, another one)

[Kapps]

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.