Now that we've decided to allow using versioned internal types in
fixed-layout structs, this isn't just about inlineable functions anymore.
No content change.
...as Slava pointed out, many times it means "versioned". I chose to
leave several things as "non-public, non-versioned" even though "non-
versioned" is sufficient (a versioned library may not have unversioned
public API) because "non-public" is something people instinctively
understand.
Also provide several possible syntaxes for marking an entity as versioned.
None of the syntax in this document is set in stone. (Even these three
options are just examples of three different approaches.)
(but not all of it)
- Add a note about throwing functions becoming non-throwing.
- Clarify that let-properties may not be turned into read-only vars.
- Permit new static stored properties on fixed_layout structs.
- Drop note about "fixed_layout-since-first-available".
- Add note disparaging the utility of @fixed.
- Add note about adding defaulted associated types to protcols.
- Clarify which members can and cannot be added to a class.
- Add some class-specific permitted changes.
- Note that adding/removing 'dynamic' is /not/ permitted.
- Split up protocol and non-protocol extensions.
- Explain why the 'no_payload' performance assertion isn't needed.
Saving the rest of the feedback for the next major content addition.
Update the Library Evolution ("Resilience") doc with a listing for every
top-level declaration kind (...except operators and imports, TODO) that
describes what should be an ABI-compatible change between releases of a
binary library shipped independently of a client app (say, because it's
part of the OS). Restructure the existing discussion of "fragility
attributes" to describe how each of those capabilities is affected when,
say, marking a struct as "fixed-layout".
Still a work in progress, and if something unexpected catches your eye
I'd like to hear about it. Note also that this does /not/ describe how
Swift behaves today; we still make many assumptions about types that
will not be valid in a "resilient" world.
There's still quite a bit of work to go here. In particular, it's not really
ready for review, but John and I think it's pointed in the right direction,
and with Slava and Joe already working in this area it's important that we
have something to anchor to. Hoping to get back to this soon.
