Dynamic closure vs static closure

[Yigal Chripun]

Jarrett Billingsley wrote:
> 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?
> 

I've read that thread and understand the benefits of D1 style delegates,
performance wise. What I meant to say was Why do we need two separate
*types* for that?
both styles can be used with one type and with a scope modifier as I
replied to Kenny.

> 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.

I see. Thanks for explaining this.