Dynamic closure vs static closure

[Jarrett Billingsley]

On Sat, Oct 25, 2008 at 5:08 PM, Yigal Chripun <yigal100 at gmail.com> wrote:
> Jarrett Billingsley wrote:
>> On Sat, Oct 25, 2008 at 9:30 AM, Yigal Chripun <yigal100 at gmail.com> wrote:
>>> anyway, I think you got my intention by now.
>>> I really don't want to have 3 kinds of function types. I think the
>>> already existing separation between function pointers and delegates
>>> could be handled better by adding an implicit cast.
>>
>> It would start to become untenable, but I would imagine closures would
>> be implicitly convertible to scope delegates, since in effect they are
>> a subtype, and anywhere a scope delegate could be used, a closure
>> could be used as well.  Add to that implicit conversion from functions
>> to delegates using thunks and bam, you could have a function take one
>> type and it could accept all three.
>
> OK, But my question is why do you need that separation in the first
> place? to me it seems an unnecessary distinction between scope delegates
> and "regular" delegates.

Did you see the thread on performance?

D1's nested functions are great because they're very efficient.  D2's
"allocate everything on the heap just in case" is, in most cases,
completely unnecessary, and performancewise it's terrible too.  Yes,
with a perfect compiler, it would be able to statically ensure that a
delegate doesn't need to be allocated on the heap; but since we have
separate compilation and use ancient object formats and linkers that
don't understand such analysis, it can't be done.

> regarding functions and delegates - I must be missing something but why
> do you need a thunk? just allocate a delegate, assign its function
> pointer to the function and leave the "context" pointer null. isn't that
> enough?

No.  Functions and delegates have similar, but slightly different
calling conventions.  Translation from one to the other requires a bit
of register/stack shuffling.  Implicit conversion from function to
delegate only requires a single statically allocated thunk for each
set of parameter types; the delegate would have the thunk as the
funcptr and the original function as the ptr.  The thunk would then be
able to shift the params around and call the real function.