On Monday, 10 April 2017 at 23:27:35 UTC, Walter Bright wrote:
On 4/10/2017 5:59 AM, Matthias Klumpp wrote:
You need to see here that D is not the center of the world and
we will need to
make it work nicely with the rest of the system. The technical
policies work for
everything else, so there is nothing that really justifies an
exception for D
here (if 10% of Debian's code was written in D and the Debian
D team was really
large we could maybe get one, but not the way it is now).
And tbh, I think finding a good solution here is entirely
possible.
I think it is possible, too, and thank you for your efforts
helping us do this.
The ABI differences between the compilers is unfortunate, and
is largely the result of historical accident.
The first problem is that my idea originally was for D to have
its own function calling convention, which would free us to
innovate to have a more efficient calling convention than the C
one. This hasn't panned out in practice, and ldc/gdc decided to
sensibly stick with the C ABI. At some point, we should just
crowbar dmd to generate the C ABI, but this has its own
problems - it'll break code that uses the inline assembler. No
obvious solution there.
The next problem is that dmd occasionally changes the interface
to the D runtime. Or more accurately, with about every release.
This has not been an issue historically for us, as the two have
always been a matched set. I'm a lot less sure how to deal with
this. I also do not know how the gdc/lds druntime interfaces
differ.
Thank you very much for this context! It's really good to know
why things are the way they are to properly understand the
problem (I am no compiler developer and ABIs are not my expertise
- as outsider to this I see pages like
https://dlang.org/spec/abi.html though and wonder whether the
incompatibilities are seen as an issue in the D community and
whether there is a chance to address them before putting work
into setting up infrastructure to rebuild the world on compiler
updates).
