The future of lambda delegates

[Bruno Medeiros]

Walter Bright wrote:
> kris wrote:
>> C# gets around all this by (it's claimed) *always* using a heap-based 
>> frame for delegates.
> 

Note: C# doesn't allocate the *whole* (outer) frame on the stack or on 
the heap. It will allocate on the heap only those variables that are 
accessed by a delegate literal, which are called outer variables (and 
are said to be "captured" or "lifted"). The delegate's (own) frame, is 
normal I believe, unless it also has delegate literals.

> That's the copout solution. I find more and more nifty uses for 
> (synchronous) delegates, and having to allocate the frames on the heap 
> is too high a price to pay. Paying that price would preclude D from 
> having a viable alternative to C++ expression templates, for example.
> 
> 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).

Also, such analysis would also be useful for object (and data) 
allocation, as the concept (and the compiler checking method too, I 
think) is pretty much the same. (A new'ed object
can be allocated on the stack, if it is determined that it does not escape).

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