On Thursday, 25 May 2017 at 15:36:38 UTC, Jason King wrote:
> Yes it is a lot of work, which I strongly suspect is a big reason why C still reigns supreme at the systems level — because it does have a stable ABI which solves a lot of headaches from a systems point of view (obviously momentum and history are also very big reasons).
>
> If that’s the direction D wants to go in, there’s nothing wrong with that,
> but it needs to be setting the correct expectations for users.  Not having
> a stable ABI is perfectly fine for application level stuff, but it can be
> rather (in some cases extremely) problematic for systems level stuff--that
> needs to be understood both by the users and the people working on D (and I
> haven’t really seen much recognition of it).
>
> On May 25, 2017 at 10:25:59 AM, Jack Stouffer via Digitalmars-d (
> digitalmars-d@puremagic.com) wrote:
>
> On Thursday, 25 May 2017 at 15:02:00 UTC, Jason King wrote:
>> That’s a fairly important requirement if it’s supposed to be a systems programming language, less so for application focused stuff. I would hope it’s at least an eventual goal even if it’s not quite the case today.
>
> The reason we don't have ABI compatibility is the same reason neither Rust or Go does, it's a lot of work for a minority of users and it stops the language from progressing.
>
> Maybe D will have it eventually due to pressure from large D using companies, but I highly doubt it.

There was a long thread last month about getting dmd into Debian, that discussed the ABI stability issue among others:

https://forum.dlang.org/thread/hhefnnighbowonxsnbdy@forum.dlang.org

ABI stability is not promised, not now or anytime soon, not just from D but many languages, as Jack said.  It just doesn't make sense.

On Thursday, 25 May 2017 at 16:16:19 UTC, Patrick Schluter wrote:
> On Thursday, 25 May 2017 at 14:36:43 UTC, Jonathan M Davis wrote:
>>[...]
> Could someone please explain why people talk always of ABI compatibilty while what is described would imo better classified as API compatibilty. ABI is the way parameter are passed to functions i.e. which parameters go to which register and is defined by the platform, while the API is the set of signature of a library. I find it a bit disturbing that at each release the ABI would change, while that is generally something which is (should) be extremely stable.
> The only time I have been confronted with an ABI (C) change within a platform was in the transition from Solaris 9 to Solaris 10 where the way structs were returned from functions changed.
> TL;DR is there a confusion between ABI and API or does the calling conventions change at every release?

The calling convention is only one aspect of an ABI:

https://dlang.org/spec/abi.html

For example, David notes in that Debian thread that every time attributes are added to druntime functions, their mangling changes, ie the ABI changes.

And how many of those are claiming to be a systems programming language?

I have no problems with an unstable ABI, what I have a problem is with
claiming to be a systems programming language AND not having a stable ABI.
You realistically cannot have both — it seems like D is trying to have it’s
cake and eat it too and I’m just pointing out that it’s going to lead to
sadness.  If there are no plans to ever have a stable ABI, that’s fine (may
even be good for the long term usage of the language), just drop the whole
systems programming language bit and focus more on application level, but
I’ve not really seen any recognition of that.

On May 25, 2017 at 11:41:52 AM, Joakim via Digitalmars-d (
digitalmars-d@puremagic.com) wrote:

On Thursday, 25 May 2017 at 15:36:38 UTC, Jason King wrote:
> Yes it is a lot of work, which I strongly suspect is a big reason why C still reigns supreme at the systems level — because it does have a stable ABI which solves a lot of headaches from a systems point of view (obviously momentum and history are also very big reasons).
>
> If that’s the direction D wants to go in, there’s nothing wrong
> with that,
> but it needs to be setting the correct expectations for users.
> Not having
> a stable ABI is perfectly fine for application level stuff, but
> it can be
> rather (in some cases extremely) problematic for systems level
> stuff--that
> needs to be understood both by the users and the people working
> on D (and I
> haven’t really seen much recognition of it).
>
> On May 25, 2017 at 10:25:59 AM, Jack Stouffer via Digitalmars-d
> (
> digitalmars-d@puremagic.com) wrote:
>
> On Thursday, 25 May 2017 at 15:02:00 UTC, Jason King wrote:
>> That’s a fairly important requirement if it’s supposed to be a systems programming language, less so for application focused stuff. I would hope it’s at least an eventual goal even if it’s not quite the case today.
>
> The reason we don't have ABI compatibility is the same reason neither Rust or Go does, it's a lot of work for a minority of users and it stops the language from progressing.
>
> Maybe D will have it eventually due to pressure from large D using companies, but I highly doubt it.

There was a long thread last month about getting dmd into Debian, that discussed the ABI stability issue among others:

https://forum.dlang.org/thread/hhefnnighbowonxsnbdy@forum.dlang.org

ABI stability is not promised, not now or anytime soon, not just from D but many languages, as Jack said. It just doesn't make sense.

On Thursday, 25 May 2017 at 17:04:10 UTC, Jason King wrote:
> And how many of those are claiming to be a systems programming language?
>
> I have no problems with an unstable ABI, what I have a problem is with
> claiming to be a systems programming language AND not having a stable ABI.
> You realistically cannot have both — it seems like D is trying to have it’s
> cake and eat it too and I’m just pointing out that it’s going to lead to
> sadness.  If there are no plans to ever have a stable ABI, that’s fine (may
> even be good for the long term usage of the language), just drop the whole
> systems programming language bit and focus more on application level, but
> I’ve not really seen any recognition of that.
>

From that point of view, C++ and Ada aren't system programming languages.

On Thursday, 25 May 2017 at 16:16:19 UTC, Patrick Schluter wrote:
> Could someone please explain why people talk always of ABI compatibilty while what is described would imo better classified as API compatibilty.

Here the function mangle  is involved. Mangles/Names are part of the ABI in D specs: https://dlang.org/spec/abi.html#type_mangling, although you're right, generally speaking the ABI is rather what you described.

What's strange is that with a different mangle, the previous function that stand in the static library could still be linked but with different results. Usually this is not the case when the mangle changes. That's why this breakage is particularly "remarkable" i find.

On Thursday, 25 May 2017 at 17:10:01 UTC, Paulo Pinto wrote:
> On Thursday, 25 May 2017 at 17:04:10 UTC, Jason King wrote:
>> And how many of those are claiming to be a systems programming language?
>>
>> I have no problems with an unstable ABI, what I have a problem is with
>> claiming to be a systems programming language AND not having a stable ABI.
>> You realistically cannot have both — it seems like D is trying to have it’s
>> cake and eat it too and I’m just pointing out that it’s going to lead to
>> sadness.  If there are no plans to ever have a stable ABI, that’s fine (may
>> even be good for the long term usage of the language), just drop the whole
>> systems programming language bit and focus more on application level, but
>> I’ve not really seen any recognition of that.
>>
>
> From that point of view, C++ and Ada aren't system programming languages.

Exactly. Maybe I have holes in my memory, but I can't remember anything on "final C++ ABI standard". In fact I can even recall something like this - "by not doing so(ABI freeze, I mean) we are able to stay in touch with newer hardware"

On 05/25/2017 01:04 PM, Jason King via Digitalmars-d wrote:
> 
> I have no problems with an unstable ABI, what I have a problem is with
> claiming to be a systems programming language AND not having a stable ABI.
> You realistically cannot have both

Why?

On May 26, 2017 at 12:11:09 AM, Nick Sabalausky (Abscissa) via
Digitalmars-d (digitalmars-d@puremagic.com) wrote:

On 05/25/2017 01:04 PM, Jason King via Digitalmars-d wrote:
>
> I have no problems with an unstable ABI, what I have a problem is with claiming to be a systems programming language AND not having a stable ABI.

> You realistically cannot have both

Why?

Unless it’s a completely self contained system, if you are operating at the
systems level, you are going to be providing the foundations for other
people’s code to build on (vs. application level stuff where you’re already
at the top).  Just imagine if every time you applied Windows updates or
applied a security fix to your OS of choice you had to rebuild every piece
of software you have, and if providing it to others, provide corresponding
versions of your code with every update and fix that was released with your
OS — not because anything of yours changed, but because just because you
wanted to fix a problem with the underlying system.   Trying to build
something on top of an unstable ABI is building your foundations on sand.

All I’m saying is if no attention is going to be paid to this (it doesn’t mean you can’t change the ABI, but it needs to be managed it better than ‘whoops!’), just stop claiming the systems bit and stay up stack where this isn’t a problem.

On Friday, 26 May 2017 at 13:23:20 UTC, Jason King wrote:
> wanted to fix a problem with the underlying system.   Trying to build
> something on top of an unstable ABI is building your foundations on sand.
>
> All I’m saying is if no attention is going to be paid to this (it doesn’t mean you can’t change the ABI, but it needs to be managed it better than ‘whoops!’), just stop claiming the systems bit and stay up stack where this isn’t a problem.

There is some truth to this as BeOS used C++, and ABI was a concern, but it really depends on the context. D has a too big runtime and too many runtime dependent features to be classified as a low level language anyway, though...