custom attribute proposal (yeah, another one)

Manu turkeyman at gmail.com
Sat Apr 7 04:25:04 PDT 2012


On 7 April 2012 06:29, Kapps <opantm2+spam at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120407/2dd3b082/attachment.html>


More information about the Digitalmars-d mailing list