www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Member function pointers

reply Manu <turkeyman gmail.com> writes:
So from my dconf talk, I detailed a nasty hack to handle member function
pointers in D.
My approach is not portable, so I'd like to see an expression formalised in
D, so this sort of interaction with C++ is possible, and also it may be
useful in D code directly.

I'm thinking something like this... Keen to hear thoughts.

My approach was this:
  void function(T _this, ...args...);

Explicit 'this' pointer; only works with ABI's that pass 'this' as the
first integer argument.

What I suggest is:
  void function(T this, ...args...);

Note, I use keyword 'this' as the first argument. This is the key that
distinguishes the expression as a member-function pointer rather than a
typical function pointer. Calls through this function pointer would know to
use the method calling convention rather than the static function calling
convention.

For 'extern(C++) void function(T this)', that would be to use the C++
'thiscall' convention.

I think this makes good sense, because other than the choice of calling
convention, it really is just a 'function' in every other way.

Now taken this as a declaration syntax, I think calls would be made via
UFCS.

T x;
void function(T this) mp;

mp(x); // I guess this is fine
x.mp(); // but UFCS really makes this concept nice!

So the final detail, is how to capture one of these member function
pointers from within D...
I initially thought about a syntax, but this is so niche, I don't think it
warrants a syntax.
So my current best idea is to introduce 2 properties to delegates, so that
the function pointer (of this type) can be accessed via the delegate syntax.

delegate d = &x.f;
void function(T this) mp = d.funcPtr;

An interesting side effect, is that 'delegate' could actually be understood
as a strongly-typed small struct, whereas currently, it's just a magic
thing:

Given: RT delegate(A x, B y) d = &c.m;

It would look like:
struct delegate(C)
{
  C thisPointer;
  RT function(C this, A x, B, y) funcPointer;
}

Currently, to get the instance or function pointers from a delegate, you
need to do something like:
delegate d;
void** pd = cast(void**)&d;
T instancePointer = cast(T)pd[0];
void function(T this) functionPointer = cast(RT function(T this))pd[1];

Casting through a void array like that is pretty horrible.
Adding 2 properties to delegate to get either of those things can makes
sense once it is possible to express the type of the function pointer,
which would now be possible with the syntax above.

So, I quite like the transparency introduced when a delegate can be
explicitly described in the language. But there is one loose detail...

void f()
{
  void g() {}
  void delegate() d = &g; // delegate 'this' is a closure
}

I don't know a syntax to describe the type of a closure, so when a delegate
is typed with a closure instead of a struct/class, what is 'C' in the
struct template above?


Thoughts?
Is there reason to outright ban this sort of expression?
I think this actually clarifies some details of the language, and reduces a
currently 'magic' thing into a well-defined, strongly-typed concept.

- Manu
Jun 07 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
 Currently, to get the instance or function pointers from a 
 delegate, you need to do something like:

delegates have two members, ptr and funcptr: http://dlang.org/function.html As a fun fact, if you modify druntime's allocator to be malloc(), you can use free(delegate.ptr) to manually manage closures, though this takes a lot of care to know if it actually should be freed or not. Anyway, the ptr member there is always void*, however, so at least one cast is required to actually use it. Perhaps the language could be extended to make this strongly typed, but then you'd have to change the whole visible type as assigning say, a closure to a delegate variable would need to be a different type than a class member; I guess this is what you're talking about though. idk, I've kinda wanted pointer to members before but I also think D's delegates being so versatile and interchangeable is totally boss.
 I don't know a syntax to describe the type of a closure, so 
 when a delegate is typed with a closure instead of a 
 struct/class,
 what is 'C' in the struct template above?

That's a tricky one, perhaps it could be a tuple of the captured variables' type.
Jun 07 2013
parent reply Manu <turkeyman gmail.com> writes:
On 8 June 2013 09:42, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:

 Currently, to get the instance or function pointers from a delegate, you
 need to do something like:

delegates have two members, ptr and funcptr: http://dlang.org/function.html As a fun fact, if you modify druntime's allocator to be malloc(), you can use free(delegate.ptr) to manually manage closures, though this takes a lot of care to know if it actually should be freed or not. Anyway, the ptr member there is always void*, however, so at least one cast is required to actually use it. Perhaps the language could be extended to make this strongly typed, but then you'd have to change the whole visible type as assigning say, a closure to a delegate variable would need to be a different type than a class member; I guess this is what you're talking about though.

Indeed, I apologise for my ignorance! The properties are already there... but they're not properly typed. idk, I've kinda wanted pointer to members before but I also think D's
 delegates being so versatile and interchangeable is totally boss.

I agree, a delegate is almost always what I want. But a delegate is really just a compound concept, and without a way to express it's fundamental parts, which in certain circumstances (like in my case) are useful on their own, then it feels like a bit of magic. I don't know a syntax to describe the type of a closure, so when a
 delegate is typed with a closure instead of a struct/class,
 what is 'C' in the struct template above?

That's a tricky one, perhaps it could be a tuple of the captured variables' type.

Yeah, that was my initial feeling too... and I think it could be quite workable in that way.
Jun 07 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 7 June 2013 at 23:54:55 UTC, Manu wrote:
 The properties are already there...
 but they're not properly typed.

I just don't think they can be unless we change the visible type which isn't always what we want.... but, check this out: // this new type keeps track of the exact type of the pointer // and manages the delegate so we can cast with some sanity... struct PointerToMemberFunction(Class, Ret, T...) if(is(Class : Object)) { private Ret delegate(T) dg; property Class object() { return cast(Class) dg.ptr; } property void object(Class rhs) { dg.ptr = cast(void*) rhs; } Ret opCall(T t) { assert(dg.ptr !is null, "null this"); static if(is(Ret == void)) dg(t); else return dg(t); } } // this helps us construct the above template ptrToMember(alias blargh) { // I'm writing out the function template longhand // because I want to use blargh as a type and // dmd won't let me do it without an intermediate // dmd complains "type expected, not __traits" so we use // this to work around it template workaround(T) { alias workaround = T; } alias ObjectType = workaround!(__traits(parent, blargh)); auto ptrToMember(ObjectType a = null) { import std.traits; PointerToMemberFunction!( ObjectType, ReturnType!blargh, ParameterTypeTuple!blargh ) mem; mem.dg.funcptr = &blargh; mem.dg.ptr = cast(void*) a; return mem; } } actually i just realized maybe this should not be a function at all, so it is easy to use as a class member, without having to write an extra typeof(). That's probably more valuable than the initialiser which as you'll see below is optional anyway. Anyway, then you can use it like this: class A { void foo() {writeln("foo from ", name);} int bar(string s) {writeln("bar ",s," from ", name); return 10; } this(string n) { name = n; } string name; } class B : A { this(string n) { super(n); } override void foo() { writeln("derived foo from ", name); } } void main() { A a = new A("a"); B c = new B("c"); Object ob = a; auto ptr = ptrToMember!(B.foo)(c); // initialize the object here ptr(); ptr.object = a; ptr(); auto ptr2 = ptrToMember!(A.bar); // initialize to null.. ptr2.object = ptr.object; // can assign later ptr2("hey"); } And if you play around with the types there, you'll see the compile will fail if you do something uncool. Though the error messages sometimes suck, what the hell: "test2.d(58): Error: not a property ptr.object"... actually it is, but I was passing it an A when it required a B. That's a type mismatch, not a missing property. But whatever, at least it *did* fail to compile, so we have our type safety. And if I threw in an alias this on a getter property, we could assign these beasties to regular delegates too. Not half bad. But regular delegate assigning to this is prohibited because we can't be sure their context pointer is the right kind of class. This would be true if the compiler automatically did the ptrToMember!() too, so let's say we change &a.foo to return one of these strongly typed things instead of a void* delegate like it does now. auto ptr = &a.foo; // is ptr a void delegate() or a pointer to specifically a void() member of class A? That matters because if the former (current behavior), this compiles: ptr = { writeln("hello!"); }; but if the latter, that will not, it will complain that the this pointers are of mismatching type (or "not a property" lol). Of course, with alias this style behavior, you could explicitly write out void delegate() ptr = &a.foo; // ok, use looser type ptr = {...}; // perfectly fine So I guess we wouldn't be losing much, but since we both agree a delegate is almost always what we want, maybe the library solution of ptrToMember is better to keep auto in a Just Works state. I'm presuming you're already doing something similar for your C++ interop, if not, I'm pretty sure this same idea would work there too, at least to a 'good enough' state, even if not technically portable.
 Yeah, that was my initial feeling too... and I think it could 
 be quite workable in that way.

Aye, and this would require the compiler's help. Can't hit 'good enough' on that with templates.
Jun 07 2013
parent reply Manu <turkeyman gmail.com> writes:
On 8 June 2013 10:24, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Friday, 7 June 2013 at 23:54:55 UTC, Manu wrote:

 The properties are already there...
 but they're not properly typed.

I just don't think they can be unless we change the visible type which isn't always what we want.... but, check this out: // this new type keeps track of the exact type of the pointer // and manages the delegate so we can cast with some sanity... struct PointerToMemberFunction(Class, Ret, T...) if(is(Class : Object)) { private Ret delegate(T) dg; property Class object() { return cast(Class) dg.ptr; } property void object(Class rhs) { dg.ptr = cast(void*) rhs; } Ret opCall(T t) { assert(dg.ptr !is null, "null this"); static if(is(Ret == void)) dg(t); else return dg(t); } } // this helps us construct the above template ptrToMember(alias blargh) { // I'm writing out the function template longhand // because I want to use blargh as a type and // dmd won't let me do it without an intermediate // dmd complains "type expected, not __traits" so we use // this to work around it template workaround(T) { alias workaround = T; } alias ObjectType = workaround!(__traits(parent, blargh)); auto ptrToMember(ObjectType a = null) { import std.traits; PointerToMemberFunction!( ObjectType, ReturnType!blargh, ParameterTypeTuple!blargh ) mem; mem.dg.funcptr = &blargh; mem.dg.ptr = cast(void*) a; return mem; } } actually i just realized maybe this should not be a function at all, so it is easy to use as a class member, without having to write an extra typeof(). That's probably more valuable than the initialiser which as you'll see below is optional anyway. Anyway, then you can use it like this: class A { void foo() {writeln("foo from ", name);} int bar(string s) {writeln("bar ",s," from ", name); return 10; } this(string n) { name = n; } string name; } class B : A { this(string n) { super(n); } override void foo() { writeln("derived foo from ", name); } } void main() { A a = new A("a"); B c = new B("c"); Object ob = a; auto ptr = ptrToMember!(B.foo)(c); // initialize the object here ptr(); ptr.object = a; ptr(); auto ptr2 = ptrToMember!(A.bar); // initialize to null.. ptr2.object = ptr.object; // can assign later ptr2("hey"); } And if you play around with the types there, you'll see the compile will fail if you do something uncool. Though the error messages sometimes suck, what the hell: "test2.d(58): Error: not a property ptr.object"... actually it is, but I was passing it an A when it required a B. That's a type mismatch, not a missing property. But whatever, at least it *did* fail to compile, so we have our type safety. And if I threw in an alias this on a getter property, we could assign these beasties to regular delegates too. Not half bad. But regular delegate assigning to this is prohibited because we can't be sure their context pointer is the right kind of class. This would be true if the compiler automatically did the ptrToMember!() too, so let's say we change &a.foo to return one of these strongly typed things instead of a void* delegate like it does now. auto ptr = &a.foo; // is ptr a void delegate() or a pointer to specifically a void() member of class A? That matters because if the former (current behavior), this compiles: ptr = { writeln("hello!"); }; but if the latter, that will not, it will complain that the this pointers are of mismatching type (or "not a property" lol). Of course, with alias this style behavior, you could explicitly write out void delegate() ptr = &a.foo; // ok, use looser type ptr = {...}; // perfectly fine So I guess we wouldn't be losing much, but since we both agree a delegate is almost always what we want, maybe the library solution of ptrToMember is better to keep auto in a Just Works state. I'm presuming you're already doing something similar for your C++ interop, if not, I'm pretty sure this same idea would work there too, at least to a 'good enough' state, even if not technically portable.

I initially started with something like this. But look how much code it is! I actually deleted it all and went for my non-portable hack. My implementation was different. You've basically wrapped up a delegate, and made something that emulates a delegate (I'm not sure why?). I don't want a delegate, I want a function pointer. So my solution was similar, but wrapped up a function pointer and aliased a delegate to the correct type, then created a local delegate populating with 'this' and the function at the call-site... But it's all crap! It's really just abusing a delegate to get at the concept it embed's which doesn't have a proper expression.
Jun 07 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 8 June 2013 at 01:11:46 UTC, Manu wrote:
 I initially started with something like this. But look how much 
 code it is!

Yeah...
 You've basically wrapped up a delegate, and made something that 
 emulates a delegate
 (I'm not sure why?).

I just wanted to add type safety to a delegate; to get rid of the visible cast(void*) and vice versa, to see what it would look like.
Jun 07 2013
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-07 23:21:53 +0000, Manu <turkeyman gmail.com> said:

 Thoughts?

Reminds me of something similar I implemented a while ago: http://michelf.ca/projects/d-objc/syntax/#selector-literals Not only I think member function pointers are doable, but I think they're solely missing. There have been situations where I'd have used them but instead had to hack my way using a delegate. That was to build a bridge for Objective-C (before I decided to hack the compiler). I'd guess you're doing something of the sort too? -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 07 2013
parent reply Manu <turkeyman gmail.com> writes:
On 8 June 2013 09:48, Michel Fortin <michel.fortin michelf.ca> wrote:

 On 2013-06-07 23:21:53 +0000, Manu <turkeyman gmail.com> said:

  Thoughts?

Reminds me of something similar I implemented a while ago: http://michelf.ca/projects/d-**objc/syntax/#selector-literals<http://michelf.ca/projects/d-objc/syntax/#selector-literals> Not only I think member function pointers are doable, but I think they're solely missing. There have been situations where I'd have used them but instead had to hack my way using a delegate. That was to build a bridge for Objective-C (before I decided to hack the compiler). I'd guess you're doing something of the sort too?

Precisely. The concept is already embedded inside of delegate, but delegate is framed like a piece of magic, rather than a well defined compound of more primitive pieces. Those primitive pieces would be useful in certain cases (like mine, and yours). I think the only missing detail is a way to express a 'thiscall' function pointer, which I believe my suggestion satisfies quite nicely.
Jun 07 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-07 23:57:40 +0000, Manu <turkeyman gmail.com> said:

 Precisely. The concept is already embedded inside of delegate, but delegate
 is framed like a piece of magic, rather than a well defined compound of
 more primitive pieces.

Delegates are not parametrized on the type of "this", which makes them easier to move around. I would not change delegates. But function pointers with a "this" parameter would be useful. You can achieve this using a template struct containing a pointer and a call method: the call method would generate a local delegate variable from the pointer and and call it. What you can't do without compiler support is get such a pointer in a type-safe manner. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 07 2013
parent Manu <turkeyman gmail.com> writes:
On 8 June 2013 12:29, Michel Fortin <michel.fortin michelf.ca> wrote:

 On 2013-06-07 23:57:40 +0000, Manu <turkeyman gmail.com> said:

  Precisely. The concept is already embedded inside of delegate, but
 delegate
 is framed like a piece of magic, rather than a well defined compound of
 more primitive pieces.

Delegates are not parametrized on the type of "this", which makes them easier to move around. I would not change delegates.

Actually, that's very true. Good point, and I think this is almost the key distinction. But function pointers with a "this" parameter would be useful. You can
 achieve this using a template struct containing a pointer and a call
 method: the call method would generate a local delegate variable from the
 pointer and and call it. What you can't do without compiler support is get
 such a pointer in a type-safe manner.

Yup, this is what I originally did. It's big and ugly, I didn't like it, and deleted it. I think the syntax I suggest is simple and obvious, and naturally, typesafe.
Jun 07 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-08 01:21, Manu wrote:
 So from my dconf talk, I detailed a nasty hack to handle member function
 pointers in D.
 My approach is not portable, so I'd like to see an expression formalised
 in D, so this sort of interaction with C++ is possible, and also it may
 be useful in D code directly.

 I'm thinking something like this... Keen to hear thoughts.

 My approach was this:
    void function(T _this, ...args...);

 Explicit 'this' pointer; only works with ABI's that pass 'this' as the
 first integer argument.

 What I suggest is:
    void function(T this, ...args...);

 Note, I use keyword 'this' as the first argument. This is the key that
 distinguishes the expression as a member-function pointer rather than a
 typical function pointer. Calls through this function pointer would know
 to use the method calling convention rather than the static function
 calling convention.

 For 'extern(C++) void function(T this)', that would be to use the C++
 'thiscall' convention.

 I think this makes good sense, because other than the choice of calling
 convention, it really is just a 'function' in every other way.

Can't we just say that a delegate declared as extern(C++) is a member function? Or do you want to use member functions without connecting to C++ as well? -- /Jacob Carlborg
Jun 09 2013
parent reply Manu <turkeyman gmail.com> writes:
On 10 June 2013 16:50, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-08 01:21, Manu wrote:

 So from my dconf talk, I detailed a nasty hack to handle member function
 pointers in D.
 My approach is not portable, so I'd like to see an expression formalised
 in D, so this sort of interaction with C++ is possible, and also it may
 be useful in D code directly.

 I'm thinking something like this... Keen to hear thoughts.

 My approach was this:
    void function(T _this, ...args...);

 Explicit 'this' pointer; only works with ABI's that pass 'this' as the
 first integer argument.

 What I suggest is:
    void function(T this, ...args...);

 Note, I use keyword 'this' as the first argument. This is the key that
 distinguishes the expression as a member-function pointer rather than a
 typical function pointer. Calls through this function pointer would know
 to use the method calling convention rather than the static function
 calling convention.

 For 'extern(C++) void function(T this)', that would be to use the C++
 'thiscall' convention.

 I think this makes good sense, because other than the choice of calling
 convention, it really is just a 'function' in every other way.

Can't we just say that a delegate declared as extern(C++) is a member function?

That seems pretty awkward to me. Basically a hack. A function pointer is not a delegate, so I don't see why that should be used to describe one. Also, extern(C++) delegates are useful too in their own right Or do you want to use member functions without connecting to C++ as well? I haven't needed to yet... but that doesn't mean it might not be useful. It would probably be used in D for tight binding with other systems. AngelScript binds to native code with member function pointers... just off the top of my head.
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-10 09:23, Manu wrote:

 That seems pretty awkward to me. Basically a hack.
 A function pointer is not a delegate, so I don't see why that should be
 used to describe one.

It depends on how you look at it. In D a delegate is a function pointer with a context pointer. In C++ a pointer to a member function is basically the same, the context pointer is just passed separately.
 Also, extern(C++) delegates are useful too in their own right

To do what? As far as I know C++ doesn't have anything corresponding to a D delegate.
 I haven't needed to yet... but that doesn't mean it might not be useful.
 It would probably be used in D for tight binding with other systems.
 AngelScript binds to native code with member function pointers... just
 off the top of my head.

Actually I don't see why you can't use a delegate for this. The only difference is that it won't be virtual. -- /Jacob Carlborg
Jun 10 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 10 June 2013 18:04, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 09:23, Manu wrote:

  That seems pretty awkward to me. Basically a hack.
 A function pointer is not a delegate, so I don't see why that should be
 used to describe one.

It depends on how you look at it. In D a delegate is a function pointer with a context pointer. In C++ a pointer to a member function is basically the same, the context pointer is just passed separately.

A function pointer is a pointer. A delegate is a pointer to a function and a context pointer, ie, 2 pointers. A pointer to a method is just a pointer to a function, but it's a special function which receives a 'this' argument with a special calling convention. It's definitely useful to be able to express a 'thiscall' function pointer. Also, extern(C++) delegates are useful too in their own right

To do what? As far as I know C++ doesn't have anything corresponding to a D delegate.

C++ has FastDelegate, which I use to interact with D delegates all the time! ;) extern(C++) delegate is required to specify the appropriate calling convention, otherwise it's just a delegate like usual. I haven't needed to yet... but that doesn't mean it might not be useful.
 It would probably be used in D for tight binding with other systems.
 AngelScript binds to native code with member function pointers... just
 off the top of my head.

Actually I don't see why you can't use a delegate for this. The only difference is that it won't be virtual.

I'm just trying to show that sometimes you don't want a delegate, you just want a function pointer. delegate's contain the function pointer I'm after, so I can access it indirectly, but it's just not so useful. It's not typed (is void*), and you can't call through it.
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-10 11:45, Manu wrote:

 A function pointer is a pointer. A delegate is a pointer to a function
 and a context pointer, ie, 2 pointers.
 A pointer to a method is just a pointer to a function, but it's a
 special function which receives a 'this' argument with a special calling
 convention.
 It's definitely useful to be able to express a 'thiscall' function pointer.

It's not very useful without the context pointer, i.e. "this".
         Also, extern(C++) delegates are useful too in their own right


     To do what? As far as I know C++ doesn't have anything corresponding
     to a D delegate.


 C++ has FastDelegate, which I use to interact with D delegates all the
 time! ;)

I didn't know about that. Is that something that is in the language or standard library?
 extern(C++) delegate is required to specify the appropriate calling
 convention, otherwise it's just a delegate like usual.

I see.
 I'm just trying to show that sometimes you don't want a delegate, you
 just want a function pointer.

Then use a function pointer.
 delegate's contain the function pointer I'm after, so I can access it
 indirectly, but it's just not so useful. It's not typed (is void*), and
 you can't call through it.

The function pointer of a delegate is typed, it's the context pointer that is void*. Sorry, I'm just trying to understand what you're doing, what problems you have. You can compose and decompose delegates using its built-in properties "ptr" and "funcptr". You can do something like: class Foo { int i; void a () { writeln("Foo.a i=", i); } void b () { writeln("Foo.b i=", i); } } void main () { auto f1 = new Foo; f1.i = 3; auto dg = &f1.a; dg(); auto f2 = new Foo; f2.i = 4; dg.ptr = cast(void*) f2; dg(); dg.funcptr = &Foo.b; dg(); } The only thing that doesn't work with the above is if I change the context pointer to a subclass of Foo which overrides the method I want to call. It will still call the method in Foo unless I change "funcptr". -- /Jacob Carlborg
Jun 10 2013
parent reply Manu <turkeyman gmail.com> writes:
On 10 June 2013 21:35, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 11:45, Manu wrote:

  A function pointer is a pointer. A delegate is a pointer to a function
 and a context pointer, ie, 2 pointers.
 A pointer to a method is just a pointer to a function, but it's a
 special function which receives a 'this' argument with a special calling
 convention.
 It's definitely useful to be able to express a 'thiscall' function
 pointer.

It's not very useful without the context pointer, i.e. "this".

You supply 'this' at the time of calling. Read my OP. Also, extern(C++) delegates are useful too in their own right
     To do what? As far as I know C++ doesn't have anything corresponding
     to a D delegate.


 C++ has FastDelegate, which I use to interact with D delegates all the
 time! ;)

I didn't know about that. Is that something that is in the language or standard library?

It's Don's work of art. It's also how I came to find out about D in the first place ;) extern(C++) delegate is required to specify the appropriate calling
 convention, otherwise it's just a delegate like usual.

I see. I'm just trying to show that sometimes you don't want a delegate, you
 just want a function pointer.

Then use a function pointer.

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. delegate's contain the function pointer I'm after, so I can access it
 indirectly, but it's just not so useful. It's not typed (is void*), and
 you can't call through it.

The function pointer of a delegate is typed, it's the context pointer that is void*. Sorry, I'm just trying to understand what you're doing, what problems you have. You can compose and decompose delegates using its built-in properties "ptr" and "funcptr". You can do something like: class Foo { int i; void a () { writeln("Foo.a i=", i); } void b () { writeln("Foo.b i=", i); } } void main () { auto f1 = new Foo; f1.i = 3; auto dg = &f1.a; dg(); auto f2 = new Foo; f2.i = 4; dg.ptr = cast(void*) f2; dg(); dg.funcptr = &Foo.b; dg(); } The only thing that doesn't work with the above is if I change the context pointer to a subclass of Foo which overrides the method I want to call. It will still call the method in Foo unless I change "funcptr".

I wouldn't say that doesn't work, I'd say that works perfectly. A delegate is just a 'this' and function pair. If you change 'this', there's no reason the function should change. 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)'. 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. So what I'm suggesting is a syntax to express a member function pointer, and then it could be properly typed.
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
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++.
 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.
 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.
 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. -- /Jacob Carlborg
Jun 10 2013
next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 10 June 2013 at 12:53:34 UTC, Jacob Carlborg wrote:
 On 2013-06-10 14:36, Manu wrote:
 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.

I wouldn't say so. The fact that you pass context has nothing to do with determining type. For example, you can pass A class instead of B to B method, but B method would still keep its original type. So yes, there is a type problem in language when function taking some parameter is declared as having no such parameter. This is a serious hole in type system.
Jun 10 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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.
Jun 10 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 10 June 2013 at 13:45:37 UTC, Manu wrote:
 What's the calling convention for
 'void function()'? cdecl?

Walter's very own calling convention. It is supposed to match cdecl everywhere but x86, but has the argument order reversed. On x86, it's a custom one that's similar to stdcall in some ways. David
Jun 10 2013
parent Manu <turkeyman gmail.com> writes:
On 10 June 2013 23:49, David Nadlinger <code klickverbot.at> wrote:

 On Monday, 10 June 2013 at 13:45:37 UTC, Manu wrote:

 What's the calling convention for
 'void function()'? cdecl?

Walter's very own calling convention. It is supposed to match cdecl everywhere but x86, but has the argument order reversed. On x86, it's a custom one that's similar to stdcall in some ways.

Indeed. I presume 'extern(C) void function()' is cdecl though? Likewise 'extern(C++) void function(T this)' would be 'thiscall', and 'void function(T this)' would be whatever D's method calling convention happens to be.
Jun 10 2013
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 10 Jun 2013 14:53:33 +0200, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 14:36, Manu wrote:

 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.

This is utter horseshit. Not that it's part of the complete type, nor even that it becomes complete with the context pointer (though that is highly dubious at best), but the type of funcptr. It's a disgrace, simple as that. It should either be typeless, or it should take a void* as its first argument. void* means 'magic ahead', so it would be kinda ok. -- Simen
Jun 10 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Monday, 10 June 2013 at 20:31:32 UTC, Simen Kjaeraas wrote:
 or it should take a void* as its first
 argument. void* means 'magic ahead', so it would be kinda ok.

This would encourage people to try something like dg.funcptr(dg.ptr, ...), which is not correct ABI-wise. David
Jun 10 2013
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-10 08:04:43 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-06-10 09:23, Manu wrote:
 
 That seems pretty awkward to me. Basically a hack.
 A function pointer is not a delegate, so I don't see why that should be
 used to describe one.

It depends on how you look at it. In D a delegate is a function pointer with a context pointer. In C++ a pointer to a member function is basically the same, the context pointer is just passed separately.

But a true member function pointer is also parametrized on the type of this, unlike a delegate, letting you change the object pointer in a type-safe manner. (And implementation-wise, C++ function pointers can be really complicated beasts in order to support virtual calling and multiple/virtual inheritance. sizeof can even change depending on the type of "this". That's not what you want in D.)
 I haven't needed to yet... but that doesn't mean it might not be useful.
 It would probably be used in D for tight binding with other systems.
 AngelScript binds to native code with member function pointers... just
 off the top of my head.

Actually I don't see why you can't use a delegate for this. The only difference is that it won't be virtual.

Type-safety. I mean, you can do this if you want: auto funcptr = &Object.toString; auto object = new Object; // now call our function using object string delegate() deleg; deleg.ptr = cast(void*)object; deleg.funcptr = funcptr; but this is not type-safe: the funcptr type ("string function()") is actually wrong (it'll only work if called from a delegate) and the object pointer the in the delegate is a void*. All Manu is asking is that funcptr is of a correct type so you can call it directly by supplying "this" as an argument, like this: funcptr(object); The problem is that this "correct type" for the function pointer does not exist currently. Calling a member function uses a different ABI, so the type needs to know somehow its a pointer to a member function (and that its first parameter is "this"), otherwise the generated code at the call site will be all wrong. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-10 14:32, Michel Fortin wrote:

 Type-safety. I mean, you can do this if you want:

      auto funcptr = &Object.toString;
      auto object = new Object;

      // now call our function using object
      string delegate() deleg;
      deleg.ptr = cast(void*)object;
      deleg.funcptr = funcptr;

 but this is not type-safe: the funcptr type ("string function()") is
 actually wrong (it'll only work if called from a delegate) and the
 object pointer the in the delegate is a void*. All Manu is asking is
 that funcptr is of a correct type so you can call it directly by
 supplying "this" as an argument, like this:

      funcptr(object);

 The problem is that this "correct type" for the function pointer does
 not exist currently. Calling a member function uses a different ABI, so
 the type needs to know somehow its a pointer to a member function (and
 that its first parameter is "this"), otherwise the generated code at the
 call site will be all wrong.

Then he's asking for (more) type safe delegates and support for C++ member function pointers. -- /Jacob Carlborg
Jun 10 2013
parent reply Manu <turkeyman gmail.com> writes:
On 10 June 2013 22:56, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 14:32, Michel Fortin wrote:

  Type-safety. I mean, you can do this if you want:
      auto funcptr = &Object.toString;
      auto object = new Object;

      // now call our function using object
      string delegate() deleg;
      deleg.ptr = cast(void*)object;
      deleg.funcptr = funcptr;

 but this is not type-safe: the funcptr type ("string function()") is
 actually wrong (it'll only work if called from a delegate) and the
 object pointer the in the delegate is a void*. All Manu is asking is
 that funcptr is of a correct type so you can call it directly by
 supplying "this" as an argument, like this:

      funcptr(object);

 The problem is that this "correct type" for the function pointer does
 not exist currently. Calling a member function uses a different ABI, so
 the type needs to know somehow its a pointer to a member function (and
 that its first parameter is "this"), otherwise the generated code at the
 call site will be all wrong.

Then he's asking for (more) type safe delegates and support for C++ member function pointers.

I'm really not asking for delegates (although they could become more typesafe given my suggestion), just a member function pointer. And not C++ style as you say, my suggestion is much simpler than that, and would fit nicely in D.
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-10 15:47, Manu wrote:

 I'm really not asking for delegates (although they could become more
 typesafe given my suggestion), just a member function pointer. And not
 C++ style as you say, my suggestion is much simpler than that, and would
 fit nicely in D.

I give up, I don't understand what you want. -- /Jacob Carlborg
Jun 10 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 11 June 2013 00:43, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 15:47, Manu wrote:

  I'm really not asking for delegates (although they could become more
 typesafe given my suggestion), just a member function pointer. And not
 C++ style as you say, my suggestion is much simpler than that, and would
 fit nicely in D.

I give up, I don't understand what you want.

...a member function pointer syntax. It's not that complex. My suggestion is: void function(T this) funcptr; This is a function pointer (not a delegate), but using keyword 'this' gives the critical detail to the compiler that it's a member function pointer, and to use the appropriate calling convention when making calls through this pointer. UFCS makes it awesome.
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-10 17:36, Manu wrote:

 My suggestion is: void function(T this) funcptr;
 This is a function pointer (not a delegate), but using keyword 'this'
 gives the critical detail to the compiler that it's a member function
 pointer, and to use the appropriate calling convention when making calls
 through this pointer.
 UFCS makes it awesome.

What I don't understand is what this give you that a delegate doesn't. You need the "this" pointer to call the function pointer anyway. With a delegate it's bundled. -- /Jacob Carlborg
Jun 10 2013
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 10.06.2013 18:28, schrieb Jacob Carlborg:
 On 2013-06-10 17:36, Manu wrote:

 My suggestion is: void function(T this) funcptr;
 This is a function pointer (not a delegate), but using keyword 'this'
 gives the critical detail to the compiler that it's a member function
 pointer, and to use the appropriate calling convention when making calls
 through this pointer.
 UFCS makes it awesome.

What I don't understand is what this give you that a delegate doesn't. You need the "this" pointer to call the function pointer anyway. With a delegate it's bundled.

maybe he just don't need one to handle the this ptr because he wants to call several/hundrets of member-functions?
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-10 18:38, dennis luehring wrote:

 maybe he just don't need one to handle the this ptr because he wants to
 call several/hundrets of member-functions?

How does he call a pointer to a member function without the "this" pointer? -- /Jacob Carlborg
Jun 10 2013
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 10 Jun 2013 12:45:12 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 18:38, dennis luehring wrote:

 maybe he just don't need one to handle the this ptr because he wants to
 call several/hundrets of member-functions?

How does he call a pointer to a member function without the "this" pointer?

Like this: void callRandomMember(C[] objs, memberPointerToCMethod p) { objs[random(0, objs.length)].p(); } Essentially, you bind at call time to form a delegate. But the member function pointer's 'this' must be strongly typed. -Steve
Jun 10 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
On 11 June 2013 02:28, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 17:36, Manu wrote:

  My suggestion is: void function(T this) funcptr;
 This is a function pointer (not a delegate), but using keyword 'this'
 gives the critical detail to the compiler that it's a member function
 pointer, and to use the appropriate calling convention when making calls
 through this pointer.
 UFCS makes it awesome.

What I don't understand is what this give you that a delegate doesn't. You need the "this" pointer to call the function pointer anyway. With a delegate it's bundled.

It's just a pointer, 'this' is associated at the call site. And it's strongly typed. If you don't want a bundle, why be forced to use a bundled type? Consider this, why would you ever want an int* when you can have an int[]? We could remove the syntax for int*, and make it only accessible via int[].ptr... and make: is(typeof(int[].ptr) == size_t)? :)
Jun 10 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 10 June 2013 at 14:43:50 UTC, Jacob Carlborg wrote:
 On 2013-06-10 15:47, Manu wrote:

 I'm really not asking for delegates (although they could 
 become more
 typesafe given my suggestion), just a member function pointer. 
 And not
 C++ style as you say, my suggestion is much simpler than that, 
 and would
 fit nicely in D.

I give up, I don't understand what you want.

Let me try to summarize it in code: --- class A { void foo(); } auto memberFun = (&A.foo).funcptr; auto a = new A; memberFun(a); --- David
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-10 17:40, David Nadlinger wrote:

 Let me try to summarize it in code:

 ---
 class A { void foo(); }
 auto memberFun = (&A.foo).funcptr;

 auto a = new A;
 memberFun(a);
 ---

Why is this better than a delegate? -- /Jacob Carlborg
Jun 10 2013
parent reply Manu <turkeyman gmail.com> writes:
On 11 June 2013 02:26, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 17:40, David Nadlinger wrote:

  Let me try to summarize it in code:
 ---
 class A { void foo(); }
 auto memberFun = (&A.foo).funcptr;

 auto a = new A;
 memberFun(a);
 ---

Why is this better than a delegate?

It's not 'better', it's different.
Jun 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-10 18:34, Manu wrote:
 On 11 June 2013 02:26, Jacob Carlborg <doob me.com <mailto:doob me.com>>
 wrote:

     On 2013-06-10 17:40, David Nadlinger wrote:

         Let me try to summarize it in code:

         ---
         class A { void foo(); }
         auto memberFun = (&A.foo).funcptr;

         auto a = new A;
         memberFun(a);
         ---


     Why is this better than a delegate?


 It's not 'better', it's different.

class A { void foo(); } auto memberFun = (&A.foo).funcptr; auto a = new A; void delegate () dg; dg.funcptr = memberFun; dg.ptr = cast(void*) a; dg(); The details can be hidden in a function call. Sure, a delegate could be type safe but still don't see the point. -- /Jacob Carlborg
Jun 10 2013
next sibling parent Manu <turkeyman gmail.com> writes:
On 11 June 2013 02:43, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 18:34, Manu wrote:

 On 11 June 2013 02:26, Jacob Carlborg <doob me.com <mailto:doob me.com>>

 wrote:

     On 2013-06-10 17:40, David Nadlinger wrote:

         Let me try to summarize it in code:

         ---
         class A { void foo(); }
         auto memberFun = (&A.foo).funcptr;

         auto a = new A;
         memberFun(a);
         ---


     Why is this better than a delegate?


 It's not 'better', it's different.

class A { void foo(); } auto memberFun = (&A.foo).funcptr; auto a = new A; void delegate () dg; dg.funcptr = memberFun; dg.ptr = cast(void*) a; dg(); The details can be hidden in a function call. Sure, a delegate could be type safe but still don't see the point.

You can see how much work that is right? And it's still not typesafe. It's totally a hack.
Jun 10 2013
prev sibling next sibling parent d coder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, Jun 10, 2013 at 10:13 PM, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-10 18:34, Manu wrote:

 On 11 June 2013 02:26, Jacob Carlborg <doob me.com <mailto:doob me.com>>

 wrote:

     On 2013-06-10 17:40, David Nadlinger wrote:

         Let me try to summarize it in code:

         ---
         class A { void foo(); }
         auto memberFun = (&A.foo).funcptr;

         auto a = new A;
         memberFun(a);
         ---


     Why is this better than a delegate?


 It's not 'better', it's different.

class A { void foo(); } auto memberFun = (&A.foo).funcptr; auto a = new A; void delegate () dg; dg.funcptr = memberFun; dg.ptr = cast(void*) a; dg(); The details can be hidden in a function call. Sure, a delegate could be type safe but still don't see the point. -- /Jacob Carlborg

Greetings Apologies for bringing up this year old thread. With https://github.com/D-Programming-Language/dmd/pull/3181 getting merged, it is no longer feasible to directly assign dg.funcptr (which is not an lvalue now). The problem is that the code suggested by David also does not work. Is there an alternative? Regards - Puneet
May 27 2014
prev sibling parent d coder via Digitalmars-d <digitalmars-d puremagic.com> writes:
https://github.com/D-Programming-Language/dmd/pull/3181

Daniel asked me to use this. And it works.

Use something like:

union U
{
  void delegate(int) dg;
  struct
  {
    void* ptr;
    void function(int) funcptr;
  }
}
U u;
u.dg = dg;
u.funcptr = ...;
u.ptr = ...;

Regards
- Puneet
May 27 2014
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
08-Jun-2013 03:21, Manu пишет:
 So from my dconf talk, I detailed a nasty hack to handle member function
 pointers in D.
 My approach is not portable, so I'd like to see an expression formalised
 in D, so this sort of interaction with C++ is possible, and also it may
 be useful in D code directly.

 I'm thinking something like this... Keen to hear thoughts.

 My approach was this:
    void function(T _this, ...args...);

 Explicit 'this' pointer; only works with ABI's that pass 'this' as the
 first integer argument.

I decided to see how convenient can be a solution to auto-generate a thunk function that has exactly this signutre. In ABIs where this is passed as first parameters that shouldn't be much of overhead. Here is my first try, it needs to handle overload sets but that could be added. Second point is perfect forwarding (there is forward in std.typecons, avoided for now). It may as well depend on compiler bugs but it looks nice and clean :) module mem_fun; import std.traits, std.stdio; template memThunk(string call, T, U...) if(is(T == class)) { auto memThunk(T self, U args) { return mixin("self." ~ call~"(args)"); } } struct memberFunc(T) if(is(T == class)) { static property auto opDispatch(string fn)() { alias FnType = typeof(mixin("T."~fn)); return &memThunk!(fn, T, ParameterTypeTuple!FnType); } } class A{ void foo(int k) { writefln("Quack %d!\n", k); } } unittest { void function (A, int) fun = memberFunc!A.foo; A a = new A(); fun(a, 45); //prints Quack 45! } P.S. Having a way to express this-call calling convention explicitly could be very useful still especially taking into account recent enhancements to the extern(C++) support. -- Dmitry Olshansky
Jun 10 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
 I think this makes good sense, because other than the choice of 
 calling
 convention, it really is just a 'function' in every other way.

Another less intrusive option would be to just add extern(CppThisCall) and extern(DThisCall) or something along the lines, which would be specified to pass the first parameter as if it was a this pointer. David
Jun 10 2013
parent reply Manu <turkeyman gmail.com> writes:
On 10 June 2013 23:46, David Nadlinger <code klickverbot.at> wrote:

 On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:

 I think this makes good sense, because other than the choice of calling
 convention, it really is just a 'function' in every other way.

Another less intrusive option would be to just add extern(CppThisCall) and extern(DThisCall) or something along the lines, which would be specified to pass the first parameter as if it was a this pointer.

That would also do the business. Do you think that's less intrusive? It feels a little hacky though. 'DThisCall' isn't really 'extern' so to speak. I like my suggestion a lot more. Little details like, what would you name the 'this' argument? You'll end up with conventions like 'void function(T _this)', and that's a bit untrue because there isn't an argument named '_this', it's called 'this' inside the method.
Jun 10 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote:
 On 10 June 2013 23:46, David Nadlinger <code klickverbot.at>
 Another less intrusive option would be to just add 
 extern(CppThisCall) and
 extern(DThisCall) or something along the lines, which would be 
 specified to
 pass the first parameter as if it was a this pointer.

That would also do the business. Do you think that's less intrusive?

Less intrusive in the way that it is a minimal addition to the language itself (we already have several calling conventions), whereas your suggestion would require adding a special case to the grammar. That's not to say I don't like your proposal, though. I just wanted to put the option on the table to be sure we are getting somewhere with this, even if some people might be opposed to the grammar change. This issue has been bugging me for quite some time as well.
 It feels a little hacky though. 'DThisCall' isn't really 
 'extern' so to speak.

extern(D) exists today – extern(xyz) should really be called abi(xyz), callingconv(xyz) or something like that instead. David
Jun 10 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-10 14:11:31 +0000, "David Nadlinger" <code klickverbot.at> said:

 On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote:
 On 10 June 2013 23:46, David Nadlinger <code klickverbot.at>
 Another less intrusive option would be to just add extern(CppThisCall) and
 extern(DThisCall) or something along the lines, which would be specified to
 pass the first parameter as if it was a this pointer.

That would also do the business. Do you think that's less intrusive?

Less intrusive in the way that it is a minimal addition to the language itself (we already have several calling conventions), whereas your suggestion would require adding a special case to the grammar. That's not to say I don't like your proposal, though. I just wanted to put the option on the table to be sure we are getting somewhere with this, even if some people might be opposed to the grammar change. This issue has been bugging me for quite some time as well.

It's inelegant, but it could work. I just find it sad that we have to use a different calling convention for member functions. I mean, it'd be much more elegant be if a member function could simply be called from a "void function(Object)" by supplying "this" as the first argument? Wouldn't it be better to adapt the ABI to fit the language rather than adapt the language to fit the ABI? -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jun 10 2013
next sibling parent Manu <turkeyman gmail.com> writes:
On 11 June 2013 00:28, Michel Fortin <michel.fortin michelf.ca> wrote:

 On 2013-06-10 14:11:31 +0000, "David Nadlinger" <code klickverbot.at>
 said:

  On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote:
 On 10 June 2013 23:46, David Nadlinger <code klickverbot.at>

 Another less intrusive option would be to just add extern(CppThisCall)
 and
 extern(DThisCall) or something along the lines, which would be
 specified to
 pass the first parameter as if it was a this pointer.

That would also do the business. Do you think that's less intrusive?

Less intrusive in the way that it is a minimal addition to the language itself (we already have several calling conventions), whereas your suggestion would require adding a special case to the grammar. That's not to say I don't like your proposal, though. I just wanted to put the option on the table to be sure we are getting somewhere with this, even if some people might be opposed to the grammar change. This issue has been bugging me for quite some time as well.

It's inelegant, but it could work. I just find it sad that we have to use a different calling convention for member functions. I mean, it'd be much more elegant be if a member function could simply be called from a "void function(Object)" by supplying "this" as the first argument? Wouldn't it be better to adapt the ABI to fit the language rather than adapt the language to fit the ABI?

The ABI is the better part of half a century old...
Jun 10 2013
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Michel Fortin" <michel.fortin michelf.ca> wrote in message 
news:kp4nr0$q71$1 digitalmars.com...
 I just find it sad that we have to use a different calling convention for 
 member functions. I mean, it'd be much more elegant be if a member 
 function could simply be called from a "void function(Object)" by 
 supplying "this" as the first argument? Wouldn't it be better to adapt the 
 ABI to fit the language rather than adapt the language to fit the ABI?

For D, yes, and it would be awesome. For everything else, never ever ever.
Jun 11 2013