Proposal Accepted with Amendment — Naming question
Thank you for everyone's patience on waiting for the Core Team to circle back on this proposal.
This proposal, as well as SE-0192, generated some questions in the Core Team about the general future of library evolution and resilience and the tactical concerns in the near term and the strategic concerns in the long term.
One key discussion point — both on the review thread and in the Core Team — was around library versioning, and how it should inform the design of these attributes. Library versioning is a core piece of the library evolution story, but this proposal specifically calls that out as a future design concern to be revisited. Library versioning is a bigger design topic — and one that probably extends beyond the current Swift 4.2 (and possibly Swift 5) release cycle. The question then is whether to hold these attributes back and wait for a more general scheme that combines library versioning with a broader design for these attributes — and other attributes related to library evolution — or if in their current form they warranted going out as is.
The Core Team felt that:
-
Attributes like
@inlinableand@abiPublic(pending spelling revision, see below) will be used widely enough and be useful without versioning information that even if a more generalized scheme comes along for library-related attributes at worst case the spelling of these attributes could be deprecated in the future or just used as a convenient short-hand syntax. Further, many libraries also won't care about library versioning at all, and just want these attributes available to expose performance opportunities for their clients. -
These attributes would be particularly useful for Swift Package Manager packages, where currently the compilation model provides artificial boundaries to optimization between packages. In the fullness of time the tools should eventually punch through these optimization barriers automatically (when possible) but in the meantime
@inlinableis a useful attribute for performance-sensitive cases.
Concern for Abuse of these Attributes
There was some concern (some voiced privately to me as the review manager) that these attributes could be abused. Many library authors may not realize the full implications of marking an API as @inlinable in that in can create interesting scenarios where (a) a client has a copy of a called API inlined but then (b) upgrades to using a newer binary version of a library without rebuilding. In this scenario, it is possible for multiple implementations of the called API (the one in the binary library and the one inlined into the client code) to co-exist. This is a subtle point, and raises the bar for library designers to think the invariants of their exposed APIs.
In the end, these attributes are power tools. Like all power tools they have the potential to be abused and cause injury. Weighing the tradeoffs, the Core Team still felt these were important tools to add to the language.
Next Steps: Naming Revision - @abiPublic
This proposal will essentially be accepted as is — except for the name for @abiPublic. Many people voiced concern for this name. While it technically is accurate, it exposes the term "abi" which will be foreign to many. It also doesn't connote the full implications and value of adding the attribute.
I've heard a few suggested alternate spellings from various people:
@inlineAvailable@availableFromInlinable@usableFromInlinable@inlinableCanAccess@inlineAccessibile
All of these have tradeoffs.
Review Extended to March 18, 2018
The proposed spelling for @abiPublic is now @inlineAvailable — but we are officially extending the review a week — to March 15, 2018 — to discuss the spelling of that particular attribute. The rest of the proposal is accepted as specified.
Thank you everyone who participated in this review!
Ted Kremenek
Review Manager