Attributes on Enum Members: Call for use cases.

Steven Schveighoffer schveiguy at yahoo.com
Thu Nov 30 14:25:25 UTC 2017


On 11/30/17 3:34 AM, Timon Gehr wrote:
> On 29.11.2017 20:49, Steven Schveighoffer wrote:
>>
>> I would say:
>>
>>>
>>> struct attribute1{}
>>> struct attribute2{}
>>>
>>> int foo(@attribute1 int x){ return x; }
>>> int bar(@attribute2 int y){ return y; }
>>>
>>> pragma(msg, typeof(&foo)); // int function(@attribute1 int x)?
>>
>> int function(int)
>> ...
> 
> Your suggestion is missing the parameter name.

Yes, I didn't actually test this code, my version was just looking at 
what happened when attributes were assigned to a function. So I didn't 
bother putting in parameters, and assumed just the type would come 
through :)

>>  ...
>>>
>>> auto weird(){
>>>      int x;
>>>      void foo(@x int y){}
>>>      return &foo;
>>> }
>>>
>>> pragma(msg, typeof(weird())); // ?
>>
>> void delegate(int)
> 
> Just noticed this:
> 
> auto weird(){
>       int x=3;
>       int foo(int y=x){ return y; }
>       return &foo;
> }
> pragma(msg, typeof(weird)); // int delegate(int y = x)
> 
> I.e., we have "Voldemort initializers".

IMO, whatever mechanism is doing this, it's not really part of the type, 
but it is part of the type. I think we should consider reworking how 
this works in the compiler, I don't like the way it's done. It's too 
fragile and inconsistent.

-Steve


More information about the Digitalmars-d mailing list