On 10 June 2013 22:53, Jacob Carlborg <doob@me.com> wrote:
On 2013-06-10 14:36, Manu wrote:

You supply 'this' at the time of calling. Read my OP.

Yes, exactly. It needs "this". It's the same thing as a delegate. It's just that with the delegate the context pointer and function pointer is combined. A function pointer (member or free) is useless if it's not called.


It's Don's work of art. It's also how I came to find out about D in the
first place ;)

I see.


There's no way to specify to use the 'thiscall' calling convention.
What I propose is a syntax that would describe a member function
pointer, and imply the appropriate calling convention.

Right. I suggested a different syntax, but you want to reserve that syntax for something that match a library implementation, that's not even in the standard.

It's like saying I want int[] to match MyIntArray implemented in C++.

No, I'm not talking about delegates. I'm not talking about FastDelegate (that was an aside when you commented that C++ has no concept of delegate).
I'm just talking about function pointers. Not sure where you get this analogy from?

funcptr pretends to be typed, but the type is just wrong. In your
example, the type is 'void function()', it should be 'void function(Foo
this)'.

"void function()" is part of the complete type. It becomes complete with the context pointer.

The context pointer type is not present in the type. So the function can't be used/called.
It also doesn't know how to call it. What's the calling convention for 'void function()'? cdecl?

So it's actually a lie. You can't call it. I'm not sure why it's typed
at all... just a crash waiting to happen.

You can put a free function in a delegate and call it through the delegate. I guess you don't want that to be possible either.

A free function? Like a static function? You can assign it, but it'll crash. Free functions are cdecl, methods are thiscall.
If you know the ABI and it receives 'this' as the first integer argument, you can fabricate a compatible signature and it won't crash, but it's not portable.
This is my whole point about the type-safety. If we create an expression to describe a method pointer, then we can actually do it safely and portably.

So what I'm suggesting is a syntax to express a member function pointer,
and then it could be properly typed.

I don't think there's anything wrong with supporting C++ member function pointers but I don't think we need to add new syntax for it.

I'm not suggesting supporting 'C++ member function pointers', they are completely bat-shit crazy.
I'm suggesting a distinctly D way. They will be useful when interfacing C++, and also on their own, and unlike C++, they won't be totally mental.