www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - simple ABI change to enable implicit conversion of functions to

reply ag0aep6g <anonymous example.com> writes:
TL;DR: Changing the ABI of delegates so that the context pointer is 
passed last would make functions implicitly convertible to delegates, no?

In the discussion of issue 17156 [1], Eyal asks why functions (function 
pointers?) don't convert implicitly to delegates. Walter's answer is 
that their ABIs differ and that a wrapper would have to be generated to 
treat a function transparently as a delegate.

As far as I understand, the problem is that the hidden context pointer 
of a delegate takes the first register, pushing the other parameters 
back. That means the visible arguments are passed in different registers 
than when calling a function.

Some code to show this:

----
void delegate(int a, int b) dg;
void f(int a, int b) { import std.stdio; writeln(a, " ", b); }

void main()
{
     dg.funcptr = &f; /* This line should probably not compile, but that's
         another story. */
     dg.ptr = cast(void*) 13;
     f(1, 2); /* prints "1 2" - no surprise */
     dg(1, 2); /* prints "2 13" */
}
----

Arguments are put into registers in reverse order. I.e., in a sense, the 
call `f(1, 2)` passes (2, 1) to f. And the call `dg(1, 2)` passes (13, 
2, 1), because a delegate has a hidden last parameter: the context 
pointer. But `f` isn't compiled with such a hidden parameter, so it sees 
13 in `b` and 2 in `a`. The register that holds 1 is simply ignored 
because there's no corresponding parameter.

Now, what if we changed the ABI of delegates so that the context pointer 
is passed after the explicit arguments? That is, `dg(1, 2)` would pass 
(2, 1, 13). Then `f` would see 2 in b and 1 in a. It would ignore 13. 
Seems everything would just work then.

This seems quite simple. But I'm most probably just too ignorant to see 
the problems. Why wouldn't this work? Maybe there's a reason why the 
context pointer has to be passed first?



[1] https://issues.dlang.org/show_bug.cgi?id=17156
May 15
next sibling parent reply kinke <kinke gmx.net> writes:
On Monday, 15 May 2017 at 10:41:55 UTC, ag0aep6g wrote:
 TL;DR: Changing the ABI of delegates so that the context 
 pointer is passed last would make functions implicitly 
 convertible to delegates, no?

 In the discussion of issue 17156 [1], Eyal asks why functions 
 (function pointers?) don't convert implicitly to delegates. 
 Walter's answer is that their ABIs differ and that a wrapper 
 would have to be generated to treat a function transparently as 
 a delegate.

 As far as I understand, the problem is that the hidden context 
 pointer of a delegate takes the first register, pushing the 
 other parameters back. That means the visible arguments are 
 passed in different registers than when calling a function.

 Some code to show this:

 ----
 void delegate(int a, int b) dg;
 void f(int a, int b) { import std.stdio; writeln(a, " ", b); }

 void main()
 {
     dg.funcptr = &f; /* This line should probably not compile, 
 but that's
         another story. */
     dg.ptr = cast(void*) 13;
     f(1, 2); /* prints "1 2" - no surprise */
     dg(1, 2); /* prints "2 13" */
 }
 ----

 Arguments are put into registers in reverse order. I.e., in a 
 sense, the call `f(1, 2)` passes (2, 1) to f. And the call 
 `dg(1, 2)` passes (13, 2, 1), because a delegate has a hidden 
 last parameter: the context pointer. But `f` isn't compiled 
 with such a hidden parameter, so it sees 13 in `b` and 2 in 
 `a`. The register that holds 1 is simply ignored because 
 there's no corresponding parameter.

 Now, what if we changed the ABI of delegates so that the 
 context pointer is passed after the explicit arguments? That 
 is, `dg(1, 2)` would pass (2, 1, 13). Then `f` would see 2 in b 
 and 1 in a. It would ignore 13. Seems everything would just 
 work then.

 This seems quite simple. But I'm most probably just too 
 ignorant to see the problems. Why wouldn't this work? Maybe 
 there's a reason why the context pointer has to be passed first?



 [1] https://issues.dlang.org/show_bug.cgi?id=17156
First of all, please don't forget that we're not only targeting X86, and that the args, according to the docs, shouldn't actually be reversed (incl. extern(D) - just on Win32, everywhere else the C ABI is to be followed). Then some ABIs, like Microsoft's, treat ` this` in a special way, not just like any other argument (in combination with struct-return), which would apply to method calls via a delegate with context = object reference. Some additional context: https://github.com/dlang/dmd/pull/5232
May 15
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 15 May 2017 at 12:27:10 UTC, kinke wrote:
 On Monday, 15 May 2017 at 10:41:55 UTC, ag0aep6g wrote:
 TL;DR: Changing the ABI of delegates so that the context 
 pointer is passed last would make functions implicitly 
 convertible to delegates, no?

 In the discussion of issue 17156 [1], Eyal asks why functions 
 (function pointers?) don't convert implicitly to delegates. 
 Walter's answer is that their ABIs differ and that a wrapper 
 would have to be generated to treat a function transparently 
 as a delegate.

 As far as I understand, the problem is that the hidden context 
 pointer of a delegate takes the first register, pushing the 
 other parameters back. That means the visible arguments are 
 passed in different registers than when calling a function.

 Some code to show this:

 ----
 void delegate(int a, int b) dg;
 void f(int a, int b) { import std.stdio; writeln(a, " ", b); }

 void main()
 {
     dg.funcptr = &f; /* This line should probably not compile, 
 but that's
         another story. */
     dg.ptr = cast(void*) 13;
     f(1, 2); /* prints "1 2" - no surprise */
     dg(1, 2); /* prints "2 13" */
 }
 ----

 Arguments are put into registers in reverse order. I.e., in a 
 sense, the call `f(1, 2)` passes (2, 1) to f. And the call 
 `dg(1, 2)` passes (13, 2, 1), because a delegate has a hidden 
 last parameter: the context pointer. But `f` isn't compiled 
 with such a hidden parameter, so it sees 13 in `b` and 2 in 
 `a`. The register that holds 1 is simply ignored because 
 there's no corresponding parameter.

 Now, what if we changed the ABI of delegates so that the 
 context pointer is passed after the explicit arguments? That 
 is, `dg(1, 2)` would pass (2, 1, 13). Then `f` would see 2 in 
 b and 1 in a. It would ignore 13. Seems everything would just 
 work then.

 This seems quite simple. But I'm most probably just too 
 ignorant to see the problems. Why wouldn't this work? Maybe 
 there's a reason why the context pointer has to be passed 
 first?



 [1] https://issues.dlang.org/show_bug.cgi?id=17156
First of all, please don't forget that we're not only targeting X86, and that the args, according to the docs, shouldn't actually be reversed (incl. extern(D) - just on Win32, everywhere else the C ABI is to be followed). Then some ABIs, like Microsoft's, treat ` this` in a special way, not just like any other argument (in combination with struct-return), which would apply to method calls via a delegate with context = object reference. Some additional context: https://github.com/dlang/dmd/pull/5232
Not sure if members in this conversation were aware of my DIP to address this issue: https://github.com/dlang/DIPs/pull/61 The DIP uses a different approach to solve this same problem. It adds new semantics to specify whether a function should use the same ABI as a delegate, called a "delegateable function". The solution you have proposed would remove the need for my DIP by reconciling the difference between the function ABI and delegate ABI. You have two ways to go about this, either modify the delegate ABI to match the function ABI, or the reverse. The specific change could be stated as: Modify the function/delegate ABI so that the first parameter of every function is passed in the same way as the context pointer of a delegate. The questions is whether or not this restriction is reasonable. Currently I don't believe the language restricts any target machine to use a particular ABI. The only real restriction would be that functions with the same signature use the same ABI, but functions that add a parameter or use a different width on one of them can drastically change the ABI however they want. This restriction could circumvent optimizations in the ABI since every function would HAVE TO be compatible with delegates. Take the following example. Say you had a 32-bit machine with one 8-bit register and two 32-bit registers. Since it's a 32-bit machine, the obvious ABI for delegates would be to use one of the 32-bit registers for the context pointer. Now say you had a function like this: void foo(byte a, int b, int c) { } The obviously optimized ABI would be to pass the three parameters in the 3 registers, however, if you require that the first parameter of every function must use the same ABI as delegates then you would have to pass the 8-bit argument "a" in the 32-bit register. This means you could not longer pass all the parameters in the registers so either "b" or "c" would need to be passed in some other way, maybe on the stack. If the application never intends on passing foo to a delegate, you've just removed an optimization for no benefit.
May 15
parent reply ag0aep6g <anonymous example.com> writes:
On 05/15/2017 05:44 PM, Jonathan Marler wrote:
 Not sure if members in this conversation were aware of my DIP to address
 this issue:

 https://github.com/dlang/DIPs/pull/61

 The DIP uses a different approach to solve this same problem. It adds
 new semantics to specify whether a function should use the same ABI as a
 delegate, called a "delegateable function".

 The solution you have proposed would remove the need for my DIP by
 reconciling the difference between the function ABI and delegate ABI.
I was aware of your DIP. I think they're related, but don't really overlap that much. You want to add a special kind of parameter that is taken as the context pointer when making a delegate of the function. You also add syntax to combine such a function with a matching `this` into a delegate. I'd like the context pointer to be passed differently, so that a normal function doesn't mistake it for one of its parameters. I don't think my thing would make your thing obsolete.
 You have two ways to go about this, either modify the delegate ABI to
 match the function ABI, or the reverse.  The specific change could be
 stated as:

 Modify the function/delegate ABI so that the first parameter of every
 function is passed in the same way as the context pointer of a delegate.
If I'm reading it right, with that rule this would be valid: ---- struct Foo { int x; } void baz(Foo* foo, int y) { import std.stdio; writeln(foo.x, " ", y); } void main() { void delegate(int y) dg; dg.funcptr = &baz; /* parameter `foo` is taken as context pointer */ dg.ptr = new Foo(1); dg(2); /* would print "1 2" */ } ---- That's not what I'm after. With my (crude) idea, that code would be just as invalid as it is now. A function's parameters would have to match the (visible) parameters of the delegate type. Any context pointer would be passed in a spot where the function doesn't look. The point is to allow using functions as delegates that don't use the context pointer.
May 15
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 15 May 2017 at 17:06:34 UTC, ag0aep6g wrote:
 On 05/15/2017 05:44 PM, Jonathan Marler wrote:
 Not sure if members in this conversation were aware of my DIP 
 to address
 this issue:

 https://github.com/dlang/DIPs/pull/61

 The DIP uses a different approach to solve this same problem. 
 It adds
 new semantics to specify whether a function should use the 
 same ABI as a
 delegate, called a "delegateable function".

 The solution you have proposed would remove the need for my 
 DIP by
 reconciling the difference between the function ABI and 
 delegate ABI.
I was aware of your DIP. I think they're related, but don't really overlap that much. You want to add a special kind of parameter that is taken as the context pointer when making a delegate of the function. You also add syntax to combine such a function with a matching `this` into a delegate. I'd like the context pointer to be passed differently, so that a normal function doesn't mistake it for one of its parameters. I don't think my thing would make your thing obsolete.
 You have two ways to go about this, either modify the delegate 
 ABI to
 match the function ABI, or the reverse.  The specific change 
 could be
 stated as:

 Modify the function/delegate ABI so that the first parameter 
 of every
 function is passed in the same way as the context pointer of a 
 delegate.
If I'm reading it right, with that rule this would be valid: ---- struct Foo { int x; } void baz(Foo* foo, int y) { import std.stdio; writeln(foo.x, " ", y); } void main() { void delegate(int y) dg; dg.funcptr = &baz; /* parameter `foo` is taken as context pointer */ dg.ptr = new Foo(1); dg(2); /* would print "1 2" */ } ---- That's not what I'm after. With my (crude) idea, that code would be just as invalid as it is now. A function's parameters would have to match the (visible) parameters of the delegate type. Any context pointer would be passed in a spot where the function doesn't look. The point is to allow using functions as delegates that don't use the context pointer.
Ah ok, you're proposing that the language guarantees that functions with the same "visible" parameters as delegates use the same ABI for those parameters. So in this example, foo and bar would use the same ABI to pass in x: void foo(int x) { } struct Bar { void bar(int x) { } } The drawback I can see is that it restricts the ABI that functions can use. Say that our x86 ABI passes all context pointers using the EAX register (no matter what the other parameters are). That would imply that function's couldn't use the EAX register to accept arguments. Note that this would apply to ALL functions, not just the ones that are going to be called through delegates, which is a small subset of ALL functions. An interesting idea but IMO it seems like an odd restriction to put on all functions. I do understand wanting a solution to this use case though (passing a function pointer to a delegate). That is why I created my DIP after all. However, one could argue that even if the context pointer is ignored, it might be worth it to explicitly put it in your function which makes it clear that you want your function to be ABI compatible with a delegate: void foo(void* this, int x) { // the function doesn't really need the 'this' parameter. That's // kind of passing a function to a delegate anyway. } struct Bar { void bar(int x) { } } The only drawback here is that you have a 'this' parameter that you should ignore, but I would actually prefer the more verbose syntax of adding a "void* this" parameter than forcing all functions to not use whatever mechanism the equivalent delegate would use to pass in context pointer.
May 15
parent reply ag0aep6g <anonymous example.com> writes:
On 05/15/2017 09:34 PM, Jonathan Marler wrote:
 Ah ok, you're proposing that the language guarantees that functions with
 the same "visible" parameters as delegates use the same ABI for those
 parameters.
Yup. [...]
 The drawback I can see is that it restricts the ABI that functions can
 use.  Say that our x86 ABI passes all context pointers using the EAX
 register (no matter what the other parameters are).  That would imply
 that function's couldn't use the EAX register to accept arguments.  Note
 that this would apply to ALL functions, not just the ones that are going
 to be called through delegates, which is a small subset of ALL
 functions.  An interesting idea but IMO it seems like an odd restriction
 to put on all functions.
What's "our ABI" here? The one we come up with, or one that we have to follow for some reason? If we have to follow an ABI where all context pointers or `this`s are passed in a specific register, then that's a problem, yes. As far as the spec goes, it says that D follows the C conventions of the system. As C doesn't have method/delegate functionality, I think we're free to put our hidden parameters wherever we want. `extern(C++)` and such is different story. I'd just not allow implicit conversion for those functions. If "our ABI" is the one we come up with, then using a fixed register for the context pointer is not what I'm going for. My approach is to assign the visible arguments first, then pass the context pointer in whatever spot is left. Say, the function ABI uses EAX, EBX, and ECX for the first three arguments (in that order). For a function call `f(1, 2)` that means: EAX: 1 EBX: 2 ECX: not used For a delegate call `dg(1, 2)` I'd also put 1 and 2 into EAX and EBX. Additionally, the context pointer would be passed in ECX. Calls to normal functions are supposed to stay as they are. Only method/delegate calls should be affected.
May 15
parent reply kinke <noone nowhere.com> writes:
On Monday, 15 May 2017 at 20:14:49 UTC, ag0aep6g wrote:
 Say, the function ABI uses EAX, EBX, and ECX for the first 
 three arguments (in that order). For a function call `f(1, 2)` 
 that means:

     EAX: 1
     EBX: 2
     ECX: not used

 For a delegate call `dg(1, 2)` I'd also put 1 and 2 into EAX 
 and EBX. Additionally, the context pointer would be passed in 
 ECX.

 Calls to normal functions are supposed to stay as they are. 
 Only method/delegate calls should be affected.
If you just want to append an extra context arg by passing it as last actual arg, it'll end up in the stack sooner or later, and that, I guess, is where bad things may happen by just pushing an additional arg, not matching the function signature.
May 15
parent reply ag0aep6g <anonymous example.com> writes:
On 05/15/2017 10:34 PM, kinke wrote:
 If you just want to append an extra context arg by passing it as last
 actual arg, it'll end up in the stack sooner or later, and that, I
 guess, is where bad things may happen by just pushing an additional arg,
 not matching the function signature.
I'm certainly reaching the boundaries of my limited knowledge here, but wouldn't it work when we push the context arg first, before any other arguments, and pop it in the caller?
May 15
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 15 May 2017 at 21:06:57 UTC, ag0aep6g wrote:
 On 05/15/2017 10:34 PM, kinke wrote:
 If you just want to append an extra context arg by passing it 
 as last
 actual arg, it'll end up in the stack sooner or later, and 
 that, I
 guess, is where bad things may happen by just pushing an 
 additional arg,
 not matching the function signature.
I'm certainly reaching the boundaries of my limited knowledge here, but wouldn't it work when we push the context arg first, before any other arguments, and pop it in the caller?
It really depends on the target platform. There may be ways to optimize it for particular systems with particular argument sets, but in the long run if you want to support this in the general case on all functions, your proposal would require every function to use the same ABI as it's delegate counterpart, which includes the code to unwind the stack if the context pointer was passed in there or any extra setup code in the caller. If this proposal was integrated I could also imagine applications wanting to create functions that are not delegate compatible so they don't have to incur the delegate ABI overhead, i.e. extern(NoContextPointer) void foo(int x) { } Of course I suppose extern(C) would already do this. In short, this proposal modifies existing the function ABI to use the delegate ABI which will have a runtime cost in the general case (even though some cases may have zero cost). It's sacrificing performance for ALL functions when in practice applications will only need this for a small subset of their functions. I like the concept but I wouldn't want it to be the default for all functions, I think it should be an "opt-in" feature for every function. My DIP is one way you could cover this use case (a bit differently) or you could introduce a new extern like 'extern(delegate)' to say that the function should use the same ABI as it's delegate counterpart. extern(delegate) void foo(int x) { } void delegate(int) x = &foo; x(); I'd definitely be ok with this. It doesn't handle the use cases where you actually want the function to use the context pointer, but it handles your situation well.
May 15
parent reply ag0aep6g <anonymous example.com> writes:
On 05/15/2017 11:56 PM, Jonathan Marler wrote:
 your proposal would require every function to use the same ABI as it's
 delegate counterpart, which includes the code to unwind the stack if the
 context pointer was passed in there or any extra setup code in the caller.
I don't see how that's true. Stack cleanup of the context pointer would be done in the caller, not the callee. And no extra setup (or cleanup) is needed in the caller when the callee is a non-delegate function. And that's the point. The goal is to keep normal, non-delegate function calls exactly as they are. That's why the context pointer is passed in a spot where it doesn't affect the rest of the call (i.e. in a free register or before the other args on the stack).
 If this proposal was integrated I could also imagine applications
 wanting to create functions that are not delegate compatible so they
 don't have to incur the delegate ABI overhead, i.e.
There should be zero overhead. [...]
 In short, this proposal modifies existing the function ABI to use the
 delegate ABI which will have a runtime cost in the general case (even
 though some cases may have zero cost).
No. At least, that's not how it's supposed to work. The idea is to modify the delegate ABI to be compatible with the function ABI. I wouldn't touch the function ABI. Every call to a delegate would contain code that's exactly the same as a call to a non-delegate function with the same visible parameters. That piece of code would look the same as it does today. For example, if `f(1, 2);` results in machine code `foo` today, then `void delegate(int, int) dg = &f; dg(1, 2);` would be made to result in mov parameter_register_not_used_in_foo, context_pointer; foo; or if `foo` already uses all registers push context_pointer; foo; pop; If this doesn't work for some specific `foo`, I'd appreciate an example where it falls apart. It doesn't work with `extern(C++)` methods, because we have to follow established calling conventions and put the `this` pointer somewhere else. So, implicit conversion wouldn't work here. That's ok. I suspect that variadic functions might also be problematic. But I haven't checked, because I don't care much about them. Worst case, you can't implicitly convert a variadic function to a variadic delegate. Not a big issue.
May 15
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 15 May 2017 at 23:10:00 UTC, ag0aep6g wrote:
 On 05/15/2017 11:56 PM, Jonathan Marler wrote:
 your proposal would require every function to use the same ABI 
 as it's
 delegate counterpart, which includes the code to unwind the 
 stack if the
 context pointer was passed in there or any extra setup code in 
 the caller.
I don't see how that's true. Stack cleanup of the context pointer would be done in the caller, not the callee. And no extra setup (or cleanup) is needed in the caller when the callee is a non-delegate function. And that's the point. The goal is to keep normal, non-delegate function calls exactly as they are. That's why the context pointer is passed in a spot where it doesn't affect the rest of the call (i.e. in a free register or before the other args on the stack).
 If this proposal was integrated I could also imagine 
 applications
 wanting to create functions that are not delegate compatible 
 so they
 don't have to incur the delegate ABI overhead, i.e.
There should be zero overhead. [...]
 In short, this proposal modifies existing the function ABI to 
 use the
 delegate ABI which will have a runtime cost in the general 
 case (even
 though some cases may have zero cost).
No. At least, that's not how it's supposed to work. The idea is to modify the delegate ABI to be compatible with the function ABI. I wouldn't touch the function ABI. Every call to a delegate would contain code that's exactly the same as a call to a non-delegate function with the same visible parameters. That piece of code would look the same as it does today. For example, if `f(1, 2);` results in machine code `foo` today, then `void delegate(int, int) dg = &f; dg(1, 2);` would be made to result in mov parameter_register_not_used_in_foo, context_pointer; foo; or if `foo` already uses all registers push context_pointer; foo; pop; If this doesn't work for some specific `foo`, I'd appreciate an example where it falls apart. It doesn't work with `extern(C++)` methods, because we have to follow established calling conventions and put the `this` pointer somewhere else. So, implicit conversion wouldn't work here. That's ok. I suspect that variadic functions might also be problematic. But I haven't checked, because I don't care much about them. Worst case, you can't implicitly convert a variadic function to a variadic delegate. Not a big issue.
Ok I got your proposal backwards. Now that I understand I think it's worth looking into. The obvious questions would be the practical performance implications of changing how the context pointer is passed in, and also how close the current delegate ABI is to working with this. I'm not alot of help here so I hope others respond. It adds some restriction to the delegate ABI that didn't exist before so the next question would be is the decrease in ABI flexibility going to be an issue? Some platforms may have very fast ways of passing the context pointer that aren't compatible with these restrictions in which case D delegates/member-functions would have to use an inferior ABI by default. That could be addressed by adding something like "extern(optimized)" that allows the ABI to be flexible at the cost of being incompatible with a function pointer. An interesting idea, it's sort of the reverse of my proposal hence why I was making the bad assumptions. Will wait to hear others thoughts.
May 15
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
On 05/15/2017 02:27 PM, kinke wrote:
 First of all, please don't forget that we're not only targeting X86, and
 that the args, according to the docs, shouldn't actually be reversed
 (incl. extern(D) - just on Win32, everywhere else the C ABI is to be
 followed).
As far as I see, it doesn't matter if the arguments are reversed or not. The idea is to pass the context pointer in a way that doesn't affect the other arguments. Put it in a spot that would otherwise be unused. I.e., if the arguments are not reversed, add the context pointer as a new last parameter, and if the arguments are reversed, make it a new first parameter.
 Then some ABIs, like Microsoft's, treat ` this` in a special way, not
 just like any other argument (in combination with struct-return), which
 would apply to method calls via a delegate with context = object reference.
This __thiscall thing, right? https://msdn.microsoft.com/en-us/library/ek8tkfbw.aspx So, `this` always goes in ECX in that case. Yeah, that's a problem, I guess. But __thiscall is for C++, and we don't have to adhere to it in D, do we? I mean, I know that D is supposed to (mostly) follow the C calling convention of the system, but matching C++ is not a goal, or is it? `extern(C++)` functions/delegates have to follow it, obviously. But then we can just say that implicit conversion doesn't work with those.
 Some additional context: https://github.com/dlang/dmd/pull/5232
What I take from that is that changing the way arguments are passed (particularly if they're reversed or not) is going to break a ton of stuff.
May 15
parent kinke <noone nowhere.com> writes:
On Monday, 15 May 2017 at 17:03:20 UTC, ag0aep6g wrote:
 On 05/15/2017 02:27 PM, kinke wrote:
 Some additional context: https://github.com/dlang/dmd/pull/5232
What I take from that is that changing the way arguments are passed (particularly if they're reversed or not) is going to break a ton of stuff.
Well, when I experimentally didn't reverse the args for extern(D) back then for LDC (after patching druntime/Phobos inline asm accordingly...), that single issue prevented a fully green testsuite. The problem is that druntime there goes the other way and invokes a method via a function pointer, so in essence the inverse of what you're after. The problem there is that this/context may be passed differently on Win64; I checked, and LDC only does it for `extern(C++)` for Visual C++ compatibility, not for extern(D), so OTOH the (absolutely unintuitive) resulting arguments order for Win64 should currently be: extern(C++) BigStruct freeFunC(Object this, int b, int c) => __sret, this, b, c extern(D) BigStruct freeFunD(Object this, int b, int c) => __sret, c, b, this extern(C++) BigStruct Object.funC(int b, int c) => __this, __sret, b, c extern(D) BigStruct Object.funD(int b, int c) => __sret, __this, c, b And yes, for Win32 there's the __thiscall convention, but also only for extern(C++).
 `extern(C++)` functions/delegates have to follow it, obviously. 
 But then we can just say that implicit conversion doesn't work 
 with those.
Doesn't sound that bad as long as the front-end enforces it.
May 15
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 15 May 2017 at 10:41:55 UTC, ag0aep6g wrote:
 Now, what if we changed the ABI of delegates so that the 
 context pointer is passed after the explicit arguments? That 
 is, `dg(1, 2)` would pass (2, 1, 13). Then `f` would see 2 in b 
 and 1 in a. It would ignore 13. Seems everything would just 
 work then.
You can't pass 3 arguments to a function that takes 2 arguments. It's a violation of ABI and it won't work.
May 16
parent ag0aep6g <anonymous example.com> writes:
On 05/16/2017 11:35 AM, Kagamin wrote:
 On Monday, 15 May 2017 at 10:41:55 UTC, ag0aep6g wrote:
 Now, what if we changed the ABI of delegates so that the context
 pointer is passed after the explicit arguments? That is, `dg(1, 2)`
 would pass (2, 1, 13). Then `f` would see 2 in b and 1 in a. It would
 ignore 13. Seems everything would just work then.
You can't pass 3 arguments to a function that takes 2 arguments. It's a violation of ABI and it won't work.
Can you give an example where it doesn't work? Are there requirements for registers which have no corresponding argument? Note that the additional argument is not supposed to be used by the function. There's also no requirement that the argument survives the call. That is, if the context pointer is passed in a register, the called function may use that register for its own purposes, stomping over the context pointer.
May 16
prev sibling parent reply Jerry <Kickupx gmail.com> writes:
My understanding is that we want to pass functions to functions 
which takes delegates transparently, or is it something more 
involved here?

Anyway if that is everything, then why not add a template to the 
D runtime which casts the function to a delegate?

And if that wrapper function is only called by the compiler it 
does not even have to be a template. Templetation just provides 
type safety in this case.
May 16
parent ag0aep6g <anonymous example.com> writes:
On 05/16/2017 02:57 PM, Jerry wrote:
 My understanding is that we want to pass functions to functions which
 takes delegates transparently, or is it something more involved here?
That's about it. It's not a big thing. Would just be nice to have.
 Anyway if that is everything, then why not add a template to the D
 runtime which casts the function to a delegate?
You can't currently cast a function (pointer) to a delegate. You have to create a wrapper delegate that calls the function. std.functional.toDelegate does this.
 And if that wrapper function is only called by the compiler it does not
 even have to be a template. Templetation just provides type safety in
 this case.
Walter doesn't like the idea of doing toDelegate automatically. He says it has "negative performance implications that users could find very surprising" [1]. [1] https://issues.dlang.org/show_bug.cgi?id=17156
May 16