The future of lambda delegates

[kris]

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


Nice, but the problem with that is as follows:

When passing such a delegate as an argument, you don't know whether 
it'll be used in a synchronous or asynchronous manner. So, perhaps you 
choose the safe route and assume worst-case. That's cool, but if you 
choose best case instead (because you 'know' usage is synchronous) then 
you leave yourself open to nasty issues if that callee is ever changed. 
Think about passing a delegate to a third-party lib? The contract is 
weak, and therefore fragile. That's why we'd suggested an extension to 
the type system instead (which also has some problems).

The other thing that Mik noted is that the entire frame should be on the 
heap; not just part of it (for performance reasons), and taking a 
snapshot copy of the scope (or part thereof) does not work at all, since 
there could be self-references, pointers, whatever, in there. It seems 
you have to flip the entire frame into the heap.

Other than that, it is a pretty clean syntax :)