Custom attributes (again)

Timon Gehr timon.gehr at gmx.ch
Fri Apr 6 03:43:27 PDT 2012


On 04/06/2012 12:28 PM, Walter Bright wrote:
> On 4/6/2012 3:23 AM, Manu wrote:
>> What about:
>>
>> struct editor
>> {
>> this(string name, EditType, Colour = Colour.Default, string
>> description = null)
>> {
>> //...
>> }
>>
>> blah blah blah
>> }
>>
>> @attr(editor("thing",...blah...))
>
> Are you really changing the arguments for every declaration? Or is it
> one set that is repeated everywhere?
>

Yes, allowing the arguments to be different is a crucial feature.

Custom attributes are not a boolean thing, that is just the case for 
built-in ones. They are arbitrary data that is attached to a declaration 
and can then be used to build powerful semantics using compile time 
reflection.

>
>> I don't see the advantage over:
>> @editor(...)
>>
>> ?
>
> Name collisions with other @ attributes.
>

Which other attributes? Built-in ones? Otherwise, the D module system 
will be great at disambiguating the collisions as soon as inaccessible 
private symbols do not participate in symbol name collisions any more.

Maybe we could just keep all the lower case @attributes reserved in 
order to be future proof.


More information about the Digitalmars-d mailing list