How Nested Functions Work, part 1

[Jarrett Billingsley]

On Thu, Sep 3, 2009 at 7:10 PM, grauzone<none at example.net> wrote:
>
> Probably the same type as .ptr?

void*? That's just silly. Let's just throw all static typing out the window. :P

> And by the way, I find it really strange, that .funcptr results into an
> incorrectly typed function pointer, that basically has the wrong calling
> convention for the destination code, which usually is a method. It'd be
> different if signature of the .funcptr included an explicit argument for the
> hidden pointers. So that you could write: dg.funcptr(dg.ptr, arguments);

Yeah. There probably needs to be an extern(this) or so for functions
that take a context pointer, like __thiscall in VC++. The way it works
now is rather unsafe.

> And that's about the only reason to keep them.
>
> But wouldn't it be possible for the compiler to allow assignment of a
> function pointer to a delegate? All the compiler had to do is to generate a
> hidden dispatch method to "translate" the different calling conventions. The
> delegate's .funcptr points to that dispatch function, and the dispatch
> function call the actual function. If the assigned function pointer is not a
> statically known function (but from a variable), the function address could
> be stored in the delegate's .ptr. Would this work?

Of course it'd work. And D APIs would take delegates and everyone
would be happy. But it still doesn't really justify getting rid of raw
function pointers.