Jarrett Billingsley wrote:
On Thu, Sep 3, 2009 at 6:48 PM, Edward
Diener<eddielee_no_spam_h...@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?
