Custom attributes (again)

[Timon Gehr]

On 04/06/2012 09:15 PM, Andrei Alexandrescu wrote:
> On 4/6/12 10:09 AM, Timon Gehr wrote:
>>> Speaking of the distinction, it would be great if we arranged things
>>> such that attributes are a lowering to existing D (i.e. the compiler
>>> rewrites a nice attribute syntax into clunky D code you wouldn't want to
>>> write by hand).
>>>
>>
>> What would that look like?
>
> Essentially we want to associate with any symbol (be it a type,
> function, method, or whatnot) some extra information in the form of a
> tuple of key/value pairs. The value can be anything CTFE. How would one
> do that "by hand", albeit ugly and verbose? Once we get the desired
> functionality, we work back on a syntax for it. And we're done.
>

There is no existing in-language solution whose only bad property is its 
ugliness, because it cannot be allowed to introduce additional symbols.

>>> Lowerings have worked miracles for us in terms of keeping language
>>> semantics simple and reducing implementation bugs.
>>
>> What do you have in mind here?
>
> 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 think they have been applied where they were appropriate. What other 
existing language features would you rather have specified as a lowering?

>> All lowerings I am aware of are trivial ones and their implementation
>> resulted in sloppy error handling (eg: foreach) for no clear benefit.
>
> Defining foreach as a lowering clarifies to both the library author and
> the user what the expectations are.
>

Agreed, using lowering custom overloading of language constructs is 
good. These usages have slipped my mind because they are so different 
from what we are discussing here.

I was thinking about foreach over built in arrays. For example:

foreach(double i,x; (int[]).init){}
Error: cannot implicitly convert expression (i) of type double to ulong

i.e. using lowering for implementation without any additional checks is 
not a good thing.

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.