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
