The future of lambda delegates

[Bruno Medeiros]

kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>>> Static escape analysis can yield 3 results:
>>>>
>>>> 1) guaranteed to not escape
>>>> 2) might escape
>>>> 3) does escape
>>>>
>>>> If most of the (1) cases in actual use can be reliably detected as 
>>>> (1), then a reasonable strategy is to do so and allocate on the 
>>>> stack only those proven as (1).
>>>
>>>
>>> Aye, but doesn't that imply a heap-frame when passing a delegate to 
>>> another function, when you explicitly know all callbacks will be 
>>> synchronous only?
>>
>>
>> If the source to that function is not known to the compiler, then yes.
> 
> Aye; that's a tough one.
> 
> On the one hand it's certainly 'safer' to rely on analysis only. On the 
> other, there's a lot of good reason to support a means to disable the 
> analysis (for known cases) thus ensuring a stack-frame instead. The 
> latter could be fraught with issue, though; just like the former.
> 

Hum, taking a clue that this problem is very similar to object(and data) 
allocation, one possibility is for both work the same way:
Outer variables be heap-allocated by default (like new), and 
stack-allocated when escape analysis determines that is safe, or when 
the user explicitly states it with the auto(raii) keyword:

void func() {
   auto int x; // x is not heap-allocated, no matter what.
   int y;      // y is stack-allocated, as it is not an outer var
   doSomething( { return x++; } ); //thus this dg literal is synchronous
}

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D