The future of lambda delegates

[xs0]

Bruno Medeiros wrote:
> xs0 wrote:
>> Mikola Lysenko wrote:
>>> [snip]
>>> Any thoughts or comments?
>>
>> Well, to me it seems that anything the compiler will try to do 
>> automatically will be wrong (or at least needlessly slow) in many 
>> cases. And a lot of the problem seems to be simply that one can't 
>> attach storage to a delegate without creating a whole class/struct, 
>> and doing that is too verbose to be used easily/often.
>>
>> So, why not simply have some syntax sugar for that?
>>
>> int delegate() fibs()
>> {
>>     int a=0, b=1;
>>     return delegate with(a,b) { // it takes a and b with it
>>         ...
>>     }
>> }
>>
>> Which would become exactly what you proposed.
>>
>>
>> xs0
> 
> Would the instances of a & b of the fibs function be the same as the 
> ones in the delegate? In other words, does the "with(a,b)" create a heap 
> copy of a & b, for the delegate to use, or does it cause the original 
> "int a=0, b=1;" to be heap allocated?

A heap copy is created at the point in code where the delegate is 
"evaluated". For example, the above case would function exactly the same 
as the following:

int delegate() fibs()
{
     int a=0, b=1;
     auto result = delegate with(a,b) {
         ...
     }
     a = 5000;
     b = -1;
     return result;
}

because it would become this behind the scenes:

class _anonymousclass123 // more probably struct
{
     int a, b;
     this(int a, int b) {
         this.a=a; this.b=b;
     }

     int _anonymousfunc() {
         ...
     }
}

int delegate() fibs()
{
     int a=0, b=1;
     auto result = &((new _anonymousclass123(a, b))._anonymousfunc);
     a = 5000;
     b = -1;
     return result;
}

Of course, the compiler is free to allocate the fibs()'s a and b on the 
heap, if it determines the result is the same (it's potentially better 
because less stack is used), though I don't think it would actually 
matter in any realistic case..


xs0