Pointers to non-static member functions!

[Steven Schveighoffer]

On Wed, 08 Jun 2011 14:13:46 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2011-06-08 13:29:27 -0400, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> On Wed, 08 Jun 2011 13:07:50 -0400, Michel Fortin   
>> <michel.fortin at michelf.com> wrote:
>>
>>> On 2011-06-08 10:54:54 -0400, "Steven Schveighoffer"   
>>> <schveiguy at yahoo.com> said:
>>>
>>>> On Wed, 08 Jun 2011 10:40:48 -0400, Daniel Murphy    
>>>> <yebblies at nospamgmail.com> wrote:
>>>>   I almost would prefer that hacking delegates would be illegal.   
>>>> Yes,  you  can get the function pointer and data pointer out of a  
>>>> delegate,  but  cannot set them.  I can't think of any good use cases  
>>>> for them.
>>>  I was "hacking delegates" a lot in the D/Objective-C bridge (before  
>>> I  decided to bring things directly in the compiler). To make it  
>>> short, I  needed to do that to call the appropriate D function from  
>>> Objective-C  stub method implementation.
>>  The issue with hacking delegates I have is that almost certainly you  
>> know  what the type of the function pointer is, which means you almost  
>> certainly  have access to the member function for that type directly,  
>> it seems a very  strange use case to be able to dynamically address the  
>> member functions of  a class without knowing the type.  When I first  
>> wrote the above reason, I  tried to think of a compelling real example,  
>> I couldn't.
>>  Now, you are implementing a bridge to another language that supports  
>> a  feature, which means you have to implement it.  But how often is  
>> that  feature used in that other language?
>
> This is not at all a feature of Objective-C. This was a workaround. Tell  
> me, if inside a template you have an alias to a member function, how can  
> I call that member function? This won't work:
>
> 	void callMe(alias memberFunc)(Object o) {
> 		o.memberFunc(); // won't work, Object has no member called  
> "memberFunc".
> 	}

In this case, the alias points at A.func or something like that, no?  So  
you have enough information to figure out that the member function is from  
A?  That is my point, you almost never *don't know* where the member  
function comes from.  And even if you don't, it's dangerous to simply  
assume this.

In my proposal, I'd guess that &memberFunc would give you a  
'delegate-function' pointer, which you could then cast o to the right type  
(assuming it is that type) and pass it into the function.

i.e.:

auto fptr = &memberFunc;
fptr(cast(thisType!(fptr))o); // thisType gets the type of the 'this'  
argument from the delegate-function pointer

> Although even there it won't work very well if your member is a virtual  
> function. I needed to use an ever stranger workaround for that. Here's  
> the actual code from the Objective-C bridge (it's a template which be  
> mixed in the class):

This is an entirely different thing, a delegate removes the virtual-ness  
of the call.  &A.func points to A's function, not to the virtual version  
(it can't possibly know that without an instance).  Having a way to say  
"call vtable entry for A.func" for a specific object would be nice, but is  
not a delegate.

>> All this is dependent on the idea that a delegate cannot be constructed  
>>  unless you have the original method (or a type-safe  
>> 'delegate-function'  such as int function(A this)).  I really think  
>> that makes sense.
>
> I won't disagree with anything you say, because I do agree. I know my  
> use case is a fringe one, and I don't need it anymore so I don't care  
> much. And it'd only need one small thing for it to work without all that  
> cumbersome hack:
>
> 	o.memberFunc() // where methodFunc is an alias to a member of o

I'd much prefer memberFunc(o);  This is of course for a delegate-function  
pointer, not for an alias.  I'm not sure how an alias would work.

-Steve