Pointers to non-static member functions!

[Steven Schveighoffer]

On Wed, 08 Jun 2011 11:19:12 -0400, Daniel Murphy  
<yebblies at nospamgmail.com> wrote:

> I can see the theoretical appeal of having member function pointers or  
> being
> able to call member functions as if they were globals, but I don't think  
> the
> practical uses really justify introducing new syntax or types or changing
> the ABI.  I also don't think any option which does any of those things  
> has a
> chance of getting incorporated into dmd.

The issue becomes, what is the type of dg.funcptr?  And is it useable?  I  
don't know if returning void * is the right answer, one of the main things  
I think would be required is:

if(dg.funcptr is &A.func) {}

Which is really all you can do with a void *, so it does satisfy most  
requirements.  But I don't like that it can be passed into functions that  
for example, take a void *.  It just seems odd that you don't get any type  
information.

What I'd prefer is to have dg.funcptr return a new type like:

int function(void this)

which means, it cannot be called, because you don't know what type this  
is.  However, accessing the function pointer from the originating type  
would return:

int function(A this);

I don't think we need to change the ABI.  Calling the function with the  
given instance type would be the same as constructing the delegate and  
calling that delegate.

As far as "new" syntax, you may have a point.  I'll point out however that  
this is a seldom used "feature", and changing syntax would likely not  
affect very much code.

> If I can get some kind of consensus I'll try and patch dmd.
> I think the following covers most of your points, given that you can  
> still
> do the unsafe thing by casting:
>
> Make delegate.funcptr read only and return void*
> Make &ClassType.nonstaticmemberfunction return void*

Again, I think the read-only for funcptr is good, but void * seems too  
lax.  But it's an acceptable update, better than nothing.

-Steve