The main change is that @always_emit_into_client is now not considered a
versioned attribute: either you use it up front and the entity is not part
of your ABI, or you don't and it is. Everything else falls out from that.
Describe a new attribute, @always_emit_into_client, which covers the
behavior of helpers for inlineable functions: any client that makes use
of the body of an inlineable function should use that implementation,
including any helper functions, local functions, or closures referenced
therein. This is also a tool a library developer can use.
This is a nice change because it formalizes several things that were
previously special-cased; however, there are still some open questions.
It's not totally clear whether we want separate @inlineable and
@always_emit_into_client annotations; we could attempt to get away with
just the latter. However, as noted in the diff, there are some entities
that can't really be completely eliminated from the ABI, so marking them
@always_emit_into_client would be disingenuous.
...from JoeG, Dmitri, and David Owens.
- Add an explicit section on default arguments.
- Replace the phrase "permitted but discouraged" with a new and stronger
term "binary-compatible source-breaking change". This may need more
work but it is an improvement.
- Mark that we could make converting get-only 'var' to 'let' safe.
- Adding a required convenience init is safe with certain restrictions.
- Add some more related proposals.
- Add a todo list for more substantive changes and ongoing discussion.
- Assorted clarifications and typo fixes.
...by giving all the types silly magic-themed names, rather than just
'Base' or 'SomeProto'. That makes a (mostly) consistent theme throughout
the document, and hopefully makes it easier to have a mental model
about what various changes mean.
I realized "members are mostly the same as their top-level equivalents" is worth
calling out explicitly, especially for subscripts and initializers without top-level
equivalents. There's still a hole here for members of protocol extensions, which can
have pretty drastic effects on conforming types.
"Proposal" refers to something going through the Swift Evolution Process,
which this won't as such. (Although it does have many pieces affected by
proposals, as described at the end of the document.)
Basically, elaborate on why it's not important right now. Also, drop the
section on limiting the addition of new vtable-dispatched methods. That's
not something we're really interested in.
The Default Behavior Should Be Safe
Also, remove the line about "providing tools to check changes", because
it no longer fits in the prologue flow and isn't core to the model.
The section on it is good enough.
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.
