The future of lambda delegates

[Walter Bright]

Mikola Lysenko wrote:
> Such a translation is possible for any of these examples, albeit quite 
> tedious.  From what I gather C# applies a similar technique with its lambda 
> delegates and inner classes.  For a machine code compiler, such a rewrite is 
> not even necessary, since it could simply overwrite the frame pointer at the 
> start of the function with a GC allocated block.  This would preserve 
> frame-based addressing for arguments and variables, requiring no change in 
> any of the internally generated machine code.  The run time overhead is 
> fairly low, only on the order of one extra memory allocation per function 
> call.  Practically, such an implementation would be extremely simple.
> 
> Any thoughts or comments?

Yes, I'm aware of this, and want to fix it for D 2.0. The way to fix it 
is, as you suggest, allocating the frame on the heap rather than on the 
stack. The drawback with that is that heap allocation is far, far more 
expensive than stack allocation.

An ideal solution would be if the compiler could statically detect if a 
nested class reference can 'escape' the stack frame, and only then 
allocate on the heap. Otherwise, the current (very efficient) method of 
just passing a frame pointer would be employed.

Of course, then there's the problem of nested functions within nested 
functions, that then escape and try to reference multiple nesting levels 
back on the stack.