On Thu, Sep 3, 2009 at 7:10 PM, grauzone<n...@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.