Library Evolution for Stable ABIs #1025
Conversation
Co-Authored-By: airspeedswift <[email protected]>
Co-Authored-By: airspeedswift <[email protected]>
Co-Authored-By: airspeedswift <[email protected]>
proposals/NNNN-library-evolution.md
Outdated
|
|
||
| - The struct is *ABI-public* (see [SE-0193][]), i.e. `public` or marked `@usableFromInline`. | ||
| - Every class, enum, struct, protocol, or typealias mentioned in the types of the struct's fields is ABI-public. | ||
| - No fields have observing accessors (`willSet` or `didSet`). |
There was a problem hiding this comment.
Maybe the forum is the best place to discuss this but I feel like this restriction is somewhat arbitrary and doesn’t buy us much.
proposals/NNNN-library-evolution.md
Outdated
|
|
||
| When a library is compiled with library evolution mode enabled, it is not an ABI-breaking change to modify the fields in a struct (to add, remove, or reorder them), and to add new enum cases (including with associated values). This implies that clients must manipulate fields and enum cases indirectly, via non-inlinable function calls. Information such as the size of the type, and the layout of its fields, becomes something that can only be determined at runtime. Types that reserve this flexibility are referred to as "resilient types". | ||
|
|
||
| A new `@frozen` keyword will be introduced to allow library authors to opt out of this flexibility on a per-type basis. This keyword promises that stored instance properties within the struct will not be *added,* *removed,* or *reordered*, and that an enum will never *add,* *remove,* or *reorder* its cases (note removing, and sometimes reordering, cases can already be source breaking, not just ABI breaking). The compiler will use this for optimization purposes when compiling clients of the type. The precise set of allowed changes is defined below. |
There was a problem hiding this comment.
@frozen an attribute, not a keyword, correct?
There was a problem hiding this comment.
Okay, as an implicit contrast with the column to the left?
Yes. There are some things that affect the ABI even without frozen, which aren't bolded.
I think it might be better to be stronger about this than "Affects".
Yeah, I guess "Not Allowed". The question would be, not allowed by whom, given the compiler isn't going to stop you. @jrose-apple do you have an opinion?
There was a problem hiding this comment.
(Somehow this ended up attached to the wrong comment)
"Not allowed" works for me. "Allowed" has the same actorship problem. :)
proposals/NNNN-library-evolution.md
Outdated
| | Changing a computed instance property to stored | Allowed | **Affects ABI** | ||
| | Changing the access of a non-ABI-public field | Allowed | Allowed | ||
| | Marking an `internal` field as `@usableFromInline` | Allowed | Allowed | ||
| | Changing an `internal` ABI-public field to be `public` | Allowed | Allowed |
There was a problem hiding this comment.
What's with the inconsistent bolding?
There was a problem hiding this comment.
Bold indicates inconsistency between frozen and unfrozen.
There was a problem hiding this comment.
Okay, as an implicit contrast with the column to the left?
I think it might be better to be stronger about this than "Affects".
proposals/NNNN-library-evolution.md
Outdated
|
|
||
| ## Naming | ||
|
|
||
| `@frozen` was used here, as originally used in [SE-0192][], for both fixed-layout structs and enums. |
There was a problem hiding this comment.
Please fill in these links and make any other editorial changes you intend to make before this goes up.
There was a problem hiding this comment.
The link's there, it's (implicit) reference style markdown link. Renders correctly in GitHub.
proposals/NNNN-library-evolution.md
Outdated
| * Authors: [Jordan Rose](https://github.com/jrose-apple), [Ben Cohen](https://github.com/airspeedswift) | ||
| * Review Manager: TBD | ||
| * Status: **Awaiting review** | ||
| * Implementation: Implemented in Swift 5 for standard library use |
There was a problem hiding this comment.
Could you whip up an implementation PR that actually uses the command-line and attribute spelling you're proposing?
There was a problem hiding this comment.
PR here, but it's far easier to use the shipping toolchain to try it out with the underscores than one generated from that PR.
No description provided.