Custom attributes (again)

[Andrei Alexandrescu]

On 4/6/12 2:47 PM, Timon Gehr wrote:
> There is no existing in-language solution whose only bad property is its
> ugliness, because it cannot be allowed to introduce additional symbols.

You can always assume fresh variables even though indeed there's no 
support for them. Just use __ as prefix and then combine with a cookie 
and the existing symbol name. There will be no clashes.

>> All: foreach, scope, operator overloading - wherever we used lowerings
>> it's been an unqualified success. I am only sorry we didn't use them
>> more often and more systematically.

I forgot the new lambda syntax ("=>") was defined as a lowering and as a 
consequence is came virtually bug free.

> I think they have been applied where they were appropriate. What other
> existing language features would you rather have specified as a lowering?

Some array and associative array literals and operations. All object 
copying.

> Anyway, how does the argument apply to the custom attribute case? The
> specification of how custom attributes work is certainly simpler and
> more clear than the specification of how the 'code that is too ugly to
> be written by hand' is generated and getting it right should be
> comparably difficult for both. The solution that uses a lowering would
> need additional compiler support for hiding additionally generated
> symbols. This makes the lowering even harder to follow for someone who
> wants to get started on custom attributes. It just seems kludgy to me.

Expressing attributes in terms of what they do within attribute-less D 
is crucial to keeping both definition and implementation simple. Hidden 
symbols are a non-issue.


Andrei