Last updated: 12 Dec 2018
One of the top priorities for Swift right now is compatibility across future Swift versions. One major component of this is ABI stability, which enables binary compatibility between applications and libraries compiled with different versions of Swift. The Swift ABI Manifesto describes the engineering and design tasks that need to be complete before declaring the ABI stable. These tasks include a mix of expected changes, investigations that may or may not result in changes, and documentation tasks. The following dashboard tracks the progress of these tasks*:
- For more detail on the status of each task, please see the tracking issues.
|Optimize layout of partially opaque aggregates||SR-3722||No change required (1)|
|Support a fixed layout attribute with availability information||SR-3911||No change required (2)|
|Revise layout algorithm for structs||SR-7809||Done in Swift 5.0|
|Revise layout algorithm for tuples||SR-3726||No change required|
|Revise layout algorithm for payloaded enums||SR-3727||Done in Swift 5.0|
|Use word-size field in native object header for reference counting||SR-4353||Done in Swift 4.1|
|Explore using spare bits in references for ARC optimizations||SR-3728||No change required (3)|
|Re-evaluate buffer size for existential containers||SR-3340||No change required (4)|
|Use reference-counted copy-on-write existential buffers||SR-4330||Done in Swift 4.0|
|Evaluate converting from an existential parameter into a protocol-constrained generic parameter||SR-4331||No change required (5)|
|Create technical specification of the layout algorithms||SR-3730|
(1) This optimization would only benefit non-resilient generic structs, and it can be implemented later with a layout versioning scheme.
(2) This is not needed until some future release when an opaque type changes to have a fixed layout.
(3) The complexity and code size overhead of this proposal were decided to outweigh the potential performance gains, especially because function signature optimization provides the same benefit for calls within a module.
(4) There was no consensus on whether to shrink the inline buffer to 2 words, so we decided to keep the status quo with a 3 word buffer.
(5) This would be a huge change and is out of scope for Swift 5.
|Plan for the evolution of type metadata (including carving out space for future functionality and freezing performance critical areas)||SR-3923||Done in Swift 4.2|
|Clean-up historical artifacts in the metadata representation||SR-3924||Done in Swift 4.2|
|Augment type metadata with more semantic information for future features (e.g., reflection)||SR-3925||No change required (6)|
|Technical specification for the fixed part of the metadata layout of all language constructs||SR-3731|
|Decide the mangling of names stored in named value type metadata||SR-3926||Done in Swift 4.2|
|Review the efficiency of interacting with the enum discriminator through the witness table||SR-4332||Done in Swift 4.1|
|Lock down the layout of value witness tables||SR-3927||Done in Swift 4.1|
|Document what class metadata is opaque for library evolution||SR-4343||Done in Swift 5.0|
|Lock down the layout of vtables or decide to use thunks||SR-3928||Done in Swift 5.0|
|Lock down the layout of a protocol witness table||SR-3732||Done in Swift 4.2|
|Decide the layout of existential type metadata, including protocol descriptors||SR-4341||Done in Swift 4.1|
|Consider updating the existing tuple-design for function parameters||SR-4333||Done in Swift 4.2|
(6) Complete reflection support is not a goal prior to ABI stability. We can add more semantic information later (SR-3923).
|Define canonicalization of generic and protocol requirements for order-agnostic mangling||SR-3733||Done in Swift 4.1|
|Review mangling variadicity of function parameters||SR-3734||Done in Swift 4.0|
|Consider dropping the distinction between structs and enums in mangled symbols||SR-3930||No change required (7)|
|Remove any unnecessary internal witness table symbols||SR-3931||No change required|
|Overhaul of word substitution to reduce redundancy in names||SR-4344||Done in Swift 4.0|
|Investigate mangling based on known overload set for non-resilient functions||SR-3933||No change required (8)|
|Redesign type/conformance info manglings to maximize common prefixes||SR-3932||Done in Swift 4.0|
(7) This would be hard to implement and would not produce a more compact mangling.
(8) This would be a disruptive change, and after the mangling changes in Swift 4.0, the symbol names are short enough that we do not plan to pursue this.
|Adopt the new Swift calling convention||SR-4346||Done in Swift 4.0|
|Document the function signature lowering scheme||SR-4349|
|Determine number of registers to hold return values||SR-3946||Done in Swift 4.0|
|Investigate whether to split values with partially opaque layout||SR-3947||No change required (9)|
(9) This would be very complicated and would probably improve performance only slightly. We can consider doing it later for non-public functions.
|Audit every runtime function for desirability and behavior||SR-3735||Done in Swift 4.1|
||SR-4354||Done in Swift 4.2|
|Protocol-oriented integers||SR-3196||Done in Swift 4.0|
|Enforce appropriate constraints on Sequences and Collections||SR-3453||Done in Swift 4.1|
|Collapse various collection wrappers using conditional conformance||SR-3458||Done in Swift 4.1|
|Change the convention for passing parameters to "guaranteed" by default||SR-7100||Done in Swift 4.2|
|Implement coroutines so that they can be used for robust inout modifications||SR-7134||Done in Swift 5.0|
|Implement generalized accessors and adopt them in the standard library||SR-7135||Done in Swift 5.0|
|Support enforcement of exclusive memory accesses in Release builds||SR-7139||Done in Swift 5.0|
|Implement generators and adopt them in the standard library||SR-7140||No change required (10)|
|Implement proof-of-concept for move-only types to make sure the standard library can support move-only data||SR-7141||No change required (10)|
(10) Generators and move-only types are out of scope for Swift 5. These features could be added later in an ABI-compatible way, although library support is likely to introduce extra complexity.
* Note: Tasks may be added as more progress is made.