I went through the list of attributes and declaration modifiers and
made sure they were all accounted for. Anything not on the list
should be assumed restricted, as mentioned at the top of the
"Supported Evolution" section.
...most of which don't exist yet. These are things that need to go
through the Swift Evolution Process and ultimately be accepted or
rejected before we have final answers on some parts of the document.
Specifically, public members (and nested types) within a versioned type are
assumed to be present on the outer type since its introduction unless otherwise
specified. (This saves boilerplate for a type's initial API.)
This drops the requirement that a fixed-layout struct only contain fixed-size
things (which wasn't specified correctly anyway). Slava and Dmitri both
pointed out that the previous definition had several flaws, including not
really scaling to generics. This reduced version only promises that stored
instance properties won't be added, removed, or modified, which is still
enough to do useful optimizations. And in most cases, we'll be able to
infer the full "fixed-size" property of a type from this attribute anyway.
The name "fixed-contents" was chosen to force us to pick a better name later.
The next commit will bring back the "fixed-size" property as a performance
assertion.
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.
