Static libraries that are
- compiled with dmd 2.074 (maybe previous versions too)
- call format() in their API

will be responsible for strange errors when used by programs compiled with dmd 2.075. People will see their software raising a FormatException (orphan argument) for no reason. When the static library will be recompiled with dmd 2.075 the errors will disappear.

I haven't investigated much since there's been a non trivial amount of change in std.format() during the this spring. I don't know what to do with this facts except to report them here.

On Thursday, 25 May 2017 at 10:42:44 UTC, Basile B. wrote:
> Static libraries that are
> - compiled with dmd 2.074 (maybe previous versions too)
> - call format() in their API
>
> will be responsible for strange errors when used by programs compiled with dmd 2.075. People will see their software raising a FormatException (orphan argument) for no reason. When the static library will be recompiled with dmd 2.075 the errors will disappear.
>
> I haven't investigated much since there's been a non trivial amount of change in std.format() during the this spring. I don't know what to do with this facts except to report them here.

Why is this unexpected?  D has never committed to ABI stability across compiler versions or the different D compilers.

On Thursday, May 25, 2017 13:23:57 Joakim via Digitalmars-d wrote:
> On Thursday, 25 May 2017 at 10:42:44 UTC, Basile B. wrote:
> > Static libraries that are
> > - compiled with dmd 2.074 (maybe previous versions too)
> > - call format() in their API
> >
> > will be responsible for strange errors when used by programs compiled with dmd 2.075. People will see their software raising a FormatException (orphan argument) for no reason. When the static library will be recompiled with dmd 2.075 the errors will disappear.
> >
> > I haven't investigated much since there's been a non trivial amount of change in std.format() during the this spring. I don't know what to do with this facts except to report them here.
>
> Why is this unexpected?  D has never committed to ABI stability across compiler versions or the different D compilers.

Yeah, if you're relying on ABI compatibility across releases, then you're likely to have some weird problems. It may actually work often enough that you can get away with it a good chunk of the time (I don't know), but we certainly don't promised ABI compatibility, and we do break it some percentage of the time. Heck, we frequently do stuff like templatize a function that wasn't templatized before (generally to make it more generic), which breaks all code that was taking it's address to use as a function pointer (but doesn't break most uses of the function). We do try to avoid superfluous breakage, and _most_ code should be fine from release to release, but corner cases do get broken on a regular basis and that's even when you recompile all your code, not even trying to use newly compiled code with code compiled with an older compiler. The sitation is _far_ better than it once was, but we're definitely not ABI stable, and the nature of D actually makes it pretty hard to be.

- Jonathan M Davis

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.


On May 25, 2017 at 8:26:04 AM, Joakim via Digitalmars-d (
digitalmars-d@puremagic.com) wrote:

On Thursday, 25 May 2017 at 10:42:44 UTC, Basile B. wrote:
> Static libraries that are
> - compiled with dmd 2.074 (maybe previous versions too)
> - call format() in their API
>
> will be responsible for strange errors when used by programs compiled with dmd 2.075. People will see their software raising a FormatException (orphan argument) for no reason. When the static library will be recompiled with dmd 2.075 the errors will disappear.
>
> I haven't investigated much since there's been a non trivial amount of change in std.format() during the this spring. I don't know what to do with this facts except to report them here.

Why is this unexpected? D has never committed to ABI stability across compiler versions or the different D compilers.

On 25/05/2017 4:02 PM, Jason King via Digitalmars-d 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.

You would be fighting the existing companies using D who are all saying "break our stuff". So highly unlikely that its going to happen.

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.

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.

On 5/25/17 11:02 AM, Jason King via Digitalmars-d 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.

Two large reasons why D is not focused on ABI compatibility:

1. Most of Phobos is templates. Template signatures can change easily from one version to the next, even if the template didn't change. C++ has the same issue.
2. D is generally statically compiled, not with shared libs. There is some progress on this front, but really, until the shared library support is mainstream, then having binary compatibility between releases, and therefore ABI compatibility, is not critical -- you have to recompile anyway.

-Steve

On Thursday, 25 May 2017 at 14:36:43 UTC, Jonathan M Davis wrote:
> On Thursday, May 25, 2017 13:23:57 Joakim via Digitalmars-d wrote:
>> On Thursday, 25 May 2017 at 10:42:44 UTC, Basile B. wrote:
>> > Static libraries that are
>> > - compiled with dmd 2.074 (maybe previous versions too)
>> > - call format() in their API
>> >
>> > will be responsible for strange errors when used by programs compiled with dmd 2.075. People will see their software raising a FormatException (orphan argument) for no reason. When the static library will be recompiled with dmd 2.075 the errors will disappear.
>> >
>> > I haven't investigated much since there's been a non trivial amount of change in std.format() during the this spring. I don't know what to do with this facts except to report them here.
>>
>> Why is this unexpected?  D has never committed to ABI stability across compiler versions or the different D compilers.
>
> Yeah, if you're relying on ABI compatibility across releases, then you're likely to have some weird problems. It may actually work often enough that you can get away with it a good chunk of the time (I don't know), but we certainly don't promised ABI compatibility, and we do break it some percentage of the time. Heck, we frequently do stuff like templatize a function that wasn't templatized before (generally to make it more generic), which breaks all code that was taking it's address to use as a function pointer (but doesn't break most uses of the function). We do try to avoid superfluous breakage, and _most_ code should be fine from release to release, but corner cases do get broken on a regular basis and that's even when you recompile all your code, not even trying to use newly compiled code with code compiled with an older compiler. The sitation is _far_ better than it once was, but we're definitely not ABI stable, and the nature of D actually makes it pretty hard to be.
>
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?

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).

That is a common misconception.

C only has a stable ABI on operating systems written in C, because the C ABI is actually the OS ABI.

In operating systems not written in C, like all the mainframe OSes before C got widespread out of UNIX and still in use nowadays (IBM i, z/OS, ClearPath), real time OSes written in Ada and quite a few other examples, the "C ABI" only has a meaning inside the POSIX emulation environment.

In fact, during the 80 and 90's it was common not being able to link object files from different C compilers on home OSes that were actually mostly written in Assembly.


--
Paulo