Swift ABI Stability Manifesto
Michael Ilseman (tweet, Reddit):
ABI is per-platform, as it is a low level concern influenced by both the architecture and the OS. Most platform vendors define a “standard ABI” which is used for C code and built on by C-family languages. Swift, however, is a very different language from C and has its own per-platform ABI. While most of this document is platform-agnostic, platform-specific concerns have influenced details of the design and implementation of Swift’s ABI.
[…]
Decisions about the ABI will have long-term ramifications and may limit the ways in which the language can grow and evolve in the future. Future Swift versions can add new, orthogonal aspects to the ABI, but any inefficiencies or inflexibilities present when stability is declared will (effectively) persist forever for that platform.
[…]
Library evolution introduces resilient layouts of public types by default and provides new annotations that freeze the layout for performance. A resilient layout avoids many of the pitfalls of the fragile binary problem by making the layout opaque. Resilient types have far more freedom to change and evolve without breaking binary compatibility: public data members can be rearranged, added, and even removed (by providing a computed getter/setter instead). The new annotations provide the ability to relinquish these freedoms by making stricter guarantees about their layout in order to be more efficiently compiled and accessed.
[…]
Any standard library API shipped post-ABI-stability must be supported into the future to ensure binary compatibility. The standard library will also be utilizing resilience annotations and inlineable code. Inlineable code is code that is bundled with the client’s code, and is available for inlining to the optimizer if it decides to do so. The standard library faces the following (non-exhaustive) list of challenges for ensuring binary compatibility[…]
Previously: Chris Lattner ATP Interview, ABI Stability Deferred Until After Swift 3.0.
Update (2017-01-27): David Hart:
ABI stability is an important feature which many Swift users are looking forward to. If I understand it correctly, once it’s here, the Standard Library becomes part of that ABI and only additive and backwards-compatible changes can be done. Seeing how we are still heavily modifying the Standard Library this year (Strings), wouldn’t it be wiser to let those changes simmer under the scrutiny of the broader community of Swift users for a year before we make it into the ABI?
See also: Swift 4 String Manifesto.
