ABI Dashboard

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*:

Data Layout

Task Tracking Issue Status
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.

Type Metadata

Task Tracking Issue Status
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).


Task Tracking Issue Status
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.

Calling Convention

Task Tracking Issue Status
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.


Task Tracking Issue Status
Audit every runtime function for desirability and behavior SR-3735 Done in Swift 4.1

Standard Library

Task Tracking Issue Status
Redesign String 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


Task Tracking Issue Status
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.