News for hackers. Stuff that matters.
Re:Swift 5.0 release process by IshKebab on Thursday September 27, 2018 @03:57PM (#18088007)
I'm not confusing it. We weren't talking about API stability at all. The issue isn't Swift's API stability.

This is all about ABI - can binaries compiled with one version of the compiler interoperate with binaries compiled with a different version.

API stability is easy - C++ has an extremely stable API. Swift is pretty stable apparently.

Re:Swift 5.0 release process by olliej on Thursday September 27, 2018 @09:44PM (#18090353)
Ok, here's an example API:

SomeLibrary.h:

class Foo {

   virtual void bar(); 

   virtual ~Foo();
};

The library is compiled into SomeLibrary.dll,dylib,so or what have you.

Your program uses this:

void my_cool_function(Foo* foo) {

    foo->bar();
}

Later on the library makes a change, and adds a new virtual method wibble(). The API is stable -- they haven't removed Foo::bar, and they haven't changed its parameters or return type. But this API change can break the library ABI if it declared the new virtual method in the wrong part of the class, because vtable ordering is defined as being order of declaration.

So there are two aspects of ABI compatibility. First, does a given API result in the same ABI irrespective of what compiler version it uses. The second is, given that your language is ABI stable, are your changes to the API also ABI stable. C++ is notoriously bad at this, because of foot guns like vtable ordering, changes to binary layout of superclasses, etc.

Swift is at least in existing versions even less stable, where you're not necessarily guaranteed that a single API will get the same ABI depending on what things it is compiled with, and certainly not through even minor compiler version changes - let alone actual language version changes.