3 ms·

Neither of those languages launched out of the gate with a stable ABI. Prior to Rust 1.0 it was much the same, with regular breaking changes. C++ famously took

Neither of those languages launched out of the gate with a stable ABI. Prior to Rust 1.0 it was much the same, with regular breaking changes. C++ famously took many years to have a stable ABI. Swift 5 represents a stable ABI. That means from this point forward all binaries built with Swift 5 or later will run against a newer Swift stdlib. The ABI is entirely separate from source compatibility. Swift is already source compatible and the bar for a source-breaking change is extremely high.

slavapestov 8y ago
Rust does not have a stable ABI.
coder543 8y ago
The Swift 5 release process document specifically implies that some Swift 4 code will not compile on Swift 5. This discussion is about source compatibility, not binary compatibility, which neither Rust nor Go offer AFAIK. The number 5 _also_ implies significant breaking changes. Otherwise, why wouldn't it be Swift 4.3? Removing Swift 3 compatibility mode (which was part of Swift 4) is itself a major source-compatibility breaking change, even if nothing else.
- slavapestov 8y ago
  So far there are only a handful of small breaking changes between -swift-version 4 and -swift-version 5 on the master branch. The only ones I can think of are a type safety hole getting plugged and some warnings for corner cases around access control that got promoted to errors.
  - coder543 8y ago
    If that's the case, that's encouraging to hear.
- saagarjha 8y ago
  "Source compatibility" for Swift means that the compiler provides a flag with that will allow it to compiler earlier versions of Swift.
paulddraper 8y ago
Java has and has always had a very high ABI compatibility. But that's an unfair comparison since its "binary" format is non-native.
aw1621107 8y ago
> C++ famously took many years to have a stable ABI. I'm pretty sure C++ doesn't prescribe any particular ABI for implementations to adhere to. There was even a paper in 2014 about defining a portable ABI, and I don't believe it was adopted [0]. In particular, MSVC uses a different ABI than the *nixes, and MSVC's ABI isn't guaranteed to be stable across major compiler releases. In addition, libstdc++ 5.1 had a significant break for C++11 std::string and std::list [1]. [0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf [1]: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
helge5 8y ago
C++ has a stable ABI? Do you have pointers on that?
- olliej 8y ago
  There are basically two parts to ABI stability. Memory layout, and calling convention. C++ defines the memory layout ABI exactly - two c++ compilers will (theoretically) produce identical struct layouts irrespective of inheritance, virtual vs non virtual classes, etc C++ implementations generally use a calling convention that is stable ABI on each platform, but different platforms may have a different ABI. In the past the MSVC ABI was different from most posix platforms, I’m not sure if that carries through to win64. The easiest way to explain why C++ the language doesn’t prescribe the calling convention ABI is that you may want to compile code on different cpu architectures. There’s no way you could (sensibly) have the same calling convention :)
  - IshKebab 8y ago
    There's way more to a stable ABI than that. All of the standard library for example. Try making a binary library that uses `std::string`. It can't really be done - you have to take `const char*` and convert to `std::string` internally. Huge pain for closed-source libraries.
    - olliej 8y ago
      I think you're confusing maintaining ABI stability with at an API level, vs. ABI compatibility at the language level. ABI stability at a language level is for code (replace syntax with your language of choice): class Foo { virtual void bar(); int _i; float _f; bool b; int bitfield : 5; } Should be stable across multiple compilers and versions. This is what swift currently does not have. This is vs. source defined ABI, e.g. class Foo { virtual void bar(); virtual void wibble(); int i; float f; } vs. class Foo { virtual void wibble(); virtual void bar(); float f; int i; } In this example Foo is API stable, and the language ABI means either definition is ABI stable, but as a publicly exposed API it is not ABI stable. C++ defines vtable layout in terms of order of definition (so changing the order of virtual methods is not stable). And you have the source compatible reordering of i and f, which is just as ABI breaking in C++ as it is in a C struct.

slavapestov 8y ago

Rust does not have a stable ABI.

coder543 8y ago

The Swift 5 release process document specifically implies that some Swift 4 code will not compile on Swift 5. This discussion is about source compatibility, not binary compatibility, which neither Rust nor Go offer AFAIK. The number 5 _also_ implies significant breaking changes. Otherwise, why wouldn't it be Swift 4.3? Removing Swift 3 compatibility mode (which was part of Swift 4) is itself a major source-compatibility breaking change, even if nothing else.

slavapestov 8y ago
So far there are only a handful of small breaking changes between -swift-version 4 and -swift-version 5 on the master branch. The only ones I can think of are a type safety hole getting plugged and some warnings for corner cases around access control that got promoted to errors.
- coder543 8y ago
  If that's the case, that's encouraging to hear.
saagarjha 8y ago
"Source compatibility" for Swift means that the compiler provides a flag with that will allow it to compiler earlier versions of Swift.

paulddraper 8y ago

Java has and has always had a very high ABI compatibility. But that's an unfair comparison since its "binary" format is non-native.

aw1621107 8y ago

> C++ famously took many years to have a stable ABI. I'm pretty sure C++ doesn't prescribe any particular ABI for implementations to adhere to. There was even a paper in 2014 about defining a portable ABI, and I don't believe it was adopted [0]. In particular, MSVC uses a different ABI than the *nixes, and MSVC's ABI isn't guaranteed to be stable across major compiler releases. In addition, libstdc++ 5.1 had a significant break for C++11 std::string and std::list [1]. [0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf [1]: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

helge5 8y ago

C++ has a stable ABI? Do you have pointers on that?

olliej 8y ago
There are basically two parts to ABI stability. Memory layout, and calling convention. C++ defines the memory layout ABI exactly - two c++ compilers will (theoretically) produce identical struct layouts irrespective of inheritance, virtual vs non virtual classes, etc C++ implementations generally use a calling convention that is stable ABI on each platform, but different platforms may have a different ABI. In the past the MSVC ABI was different from most posix platforms, I’m not sure if that carries through to win64. The easiest way to explain why C++ the language doesn’t prescribe the calling convention ABI is that you may want to compile code on different cpu architectures. There’s no way you could (sensibly) have the same calling convention :)
- IshKebab 8y ago
  There's way more to a stable ABI than that. All of the standard library for example. Try making a binary library that uses `std::string`. It can't really be done - you have to take `const char*` and convert to `std::string` internally. Huge pain for closed-source libraries.
  - olliej 8y ago
    I think you're confusing maintaining ABI stability with at an API level, vs. ABI compatibility at the language level. ABI stability at a language level is for code (replace syntax with your language of choice): class Foo { virtual void bar(); int _i; float _f; bool b; int bitfield : 5; } Should be stable across multiple compilers and versions. This is what swift currently does not have. This is vs. source defined ABI, e.g. class Foo { virtual void bar(); virtual void wibble(); int i; float f; } vs. class Foo { virtual void wibble(); virtual void bar(); float f; int i; } In this example Foo is API stable, and the language ABI means either definition is ABI stable, but as a publicly exposed API it is not ABI stable. C++ defines vtable layout in terms of order of definition (so changing the order of virtual methods is not stable). And you have the source compatible reordering of i and f, which is just as ABI breaking in C++ as it is in a C struct.