How Nested Functions Work, part 1

[grauzone]

Jarrett Billingsley wrote:
> On Thu, Sep 3, 2009 at 6:48 PM, Edward
> Diener<eddielee_no_spam_here at tropicsoft.com> wrote:
>> What I imagine will happen in D is that when an updated delegate type allows
>> itself to be initialized with a function pointer, the vast majority of D
>> programmers will use delegate for all callables and the function pointer
>> will remain simply an artefact of the language. Then D can eventually get
>> rid of it <g> !
> 
> There's no real reason to get rid of function pointers. What type
> would the .funcptr property of a delegate be, if function pointers

Probably the same type as .ptr?

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);

> didn't exist? You also need them for C compatibility.

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?