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.
