Update LibraryEvolution.rst for new attribute names

Author: slavapestov

docs/LibraryEvolution.rst

@@ -324,7 +324,7 @@ are a few common reasons for this:
   save the overhead of a cross-library function call and allow further
   optimization of callers.
 
-- The function accesses a fixed-contents struct with non-public members; this
+- The function accesses a frozen struct with non-public members; this
   allows the library author to preserve invariants while still allowing
   efficient access to the struct.
 
@@ -345,11 +345,12 @@ Clients are not required to inline a function marked ``@inlinable``.
     understanding that it will not affect existing clients. This is the
     standard example of a `binary-compatible source-breaking change`.
 
-Any local functions or closures within an inlinable function are themselves
-treated as ``@inlinable``, and a client that inlines the containing function
-must emit its own copy of the local functions or closures. This is important in
-case it is necessary to change the inlinable function later; existing clients
-should not be depending on internal details of the previous implementation.
+Any local functions or closures within an inlinable function are treated as
+``@_alwaysEmitIntoClient`` (see below). A client that inlines the containing
+function must emit its own copy of the local functions or closures. This is
+important in case it is necessary to change the inlinable function later;
+existing clients should not be depending on internal details of the previous
+implementation.
 
 Removing the ``@inlinable`` attribute completely---say, to reference private
 implementation details that should not be `versioned <versioned entity>`---is a
@@ -408,12 +409,28 @@ bodies of inlinable functions have the following restrictions:
   guards.
 
 
+Always Emit Into Client
+-----------------------
+
+A function, computed property or subscript annotated as ``@_alwaysEmitIntoClient``
+is similar to an ``@inlinable`` declaration, except the declaration is
+not part of the module's ABI, meaning that the client must always emit
+their own copy.
+
+As a result, removing a declaration annotated as ``@_alwaysEmitIntoClient``
+is a binary-compatible source-breaking change.
+
+.. admonition:: TODO
+
+    The implementation of ``@_alwaysEmitIntoClient`` is incomplete and
+    should probably graduate to having its own evolution proposal.
+
 Default Argument Expressions
 ----------------------------
 
 Default argument expressions for functions that are public, versioned, or
-inlinable are implemented very similar to inlinable functions and thus are
-subject to similar restrictions:
+inlinable are implicitly ``@_alwaysEmitIntoClient``. They are subject to
+similar restrictions:
 
 - They may not define any local types.
 
@@ -642,14 +659,18 @@ extension; unlike access control, entities within the extension may freely
 declare themselves to be either more or less available than what the extension
 provides.
 
+We could also implement a ``@_alwaysEmitIntoClient``  attribute for conformances.
+This introduces its own challenges with runtime uniquing of witness tables now
+necessary for conformances.
 
-Fixed-Contents Structs
-----------------------
 
-To opt out of this flexibility, a struct may be marked ``@fixedContents``.
+Frozen Structs
+--------------
+
+To opt out of this flexibility, a struct may be marked ``@frozen``.
 This promises that no stored properties will be added to or removed from the
 struct, even non-public ones. Additionally, all versioned instance stored
-properties in a ``@fixedContents`` struct are implicitly declared
+properties in a ``@frozen`` struct are implicitly declared
 ``@inlinable`` (as described above for top-level variables). In effect:
 
 - Reordering stored instance properties (public or non-public) is not permitted.
@@ -680,14 +701,9 @@ generic parameters and members of tuples.
 .. note::
 
     The above restrictions do not apply to ``static`` properties of
-    ``@fixedContents`` structs. Static members effectively behave as top-level
+    ``@frozen`` structs. Static members effectively behave as top-level
     functions and variables.
 
-.. note::
-
-    The name ``@fixedContents`` is intentionally awful to encourage us to come
-    up with a better one.
-
 While adding or removing stored properties is forbidden, existing properties may
 still be modified in limited ways:
 
@@ -698,13 +714,13 @@ still be modified in limited ways:
 - A versioned ``internal`` property may be made ``public`` (without changing
   its version).
 
-An initializer of a fixed-contents struct may be declared ``@inlinable`` even
+An initializer of a frozen struct may be declared ``@inlinable`` even
 if it does not delegate to another initializer, as long as the ``@inlinable``
 attribute, or the initializer itself, is not introduced earlier than the
-``@fixedContents`` attribute and the struct has no non-versioned stored
+``@frozen`` attribute and the struct has no non-versioned stored
 properties.
 
-A ``@fixedContents`` struct is *not* guaranteed to use the same layout as a C
+A ``@frozen`` struct is *not* guaranteed to use the same layout as a C
 struct with a similar "shape". If such a struct is necessary, it should be
 defined in a C header and imported into Swift.
 
@@ -717,7 +733,7 @@ defined in a C header and imported into Swift.
 
 .. note::
 
-    Hypothetically, we could use a different model where a ``@fixedContents``
+    Hypothetically, we could use a different model where a ``@frozen``
     struct only guarantees the "shape" of the struct, so to speak, while
     leaving all property accesses to go through function calls. This would
     allow stored properties to change their accessors, or (with the Behaviors
@@ -726,17 +742,17 @@ defined in a C header and imported into Swift.
     a simple C-like struct that groups together simple values, with only public
     stored properties and no observing accessors, and having to opt into direct
     access to those properties seems unnecessarily burdensome. The struct is
-    being declared ``@fixedContents`` for a reason, after all: it's been
+    being declared ``@frozen`` for a reason, after all: it's been
     discovered that its use is causing performance issues.
 
     Consequently, as a first pass we may just require all stored properties in
-    a ``@fixedContents`` struct, public or non-public, to have trivial
+    a ``@frozen`` struct, public or non-public, to have trivial
     accessors, i.e. no observing accessors and no behaviors.
 
-``@fixedContents`` is a `versioned attribute`. This is so that clients can
+``@frozen`` is a `versioned attribute`. This is so that clients can
 deploy against older versions of the library, which may have a different layout
 for the struct. (In this case the client must manipulate the struct as if the
-``@fixedContents`` attribute were absent.)
+``@frozen`` attribute were absent.)
 
 
 Enums
@@ -1171,19 +1187,14 @@ A Unifying Theme
 ~~~~~~~~~~~~~~~~
 
 So far this document has talked about ways to give up flexibility for several
-different kinds of declarations: ``@inlinable`` for functions,
-``@fixedContents`` for structs, etc. Each of these has a different set of
+different kinds of declarations: namely ``@inlinable`` for functions, and
+``@frozen`` for enums and structs. Each of these has a different set of
 constraints it enforces on the library author and promises it makes to clients.
-However, they all follow a common theme of giving up the flexibility of future
+However, they follow a common theme of giving up the flexibility of future
 changes in exchange for improved performance and perhaps some semantic
-guarantees. Therefore, all of these attributes are informally referred to as
+guarantees. Therefore, these attributes are informally referred to as
 "fragility attributes".
 
-Given that these attributes share several characteristics, we could consider
-converging on a single common attribute, say ``@fixed``, ``@inline``, or
-``@fragile``. However, this may be problematic if the same declaration has
-multiple kinds of flexibility.
-
 
 Versioning Internal Declarations
 ================================
@@ -1233,7 +1244,7 @@ at run time if the source code is reorganized, which is unacceptable.
     keep things simple we'll stick with the basics.
 
 We could do away with the entire feature if we restricted inlinable functions
-and fixed-contents structs to only refer to public entities. However, this
+and frozen structs to only refer to public entities. However, this
 removes one of the primary reasons to make something inlinable: to allow
 efficient access to a type while still protecting its invariants.
 
@@ -1244,7 +1255,7 @@ efficient access to a type while still protecting its invariants.
 *Backdating* refers to releasing a new version of a library that contains
 changes, but pretending those changes were made in a previous version of the
 library. For example, you might want to release version 1.2 of the "Magician"
-library, but pretend that the "SpellIncantation" struct was fixed-contents
+library, but pretend that the "SpellIncantation" struct was frozen
 since its introduction in version 1.0.
 
 **This is not safe.**
@@ -1253,9 +1264,8 @@ Backdating the availability a versioned entity that was previously non-public
 is clearly not safe: older versions of the library will not expose the entity
 as part of their ABI. What may be less obvious is that the fragility attributes
 likewise are not safe to backdate, even if you know the attributes could have
-been added in the past. To give one example, the presence of ``@closed`` or
-``@fixedContents`` may affect the layout and calling conventions for an enum
-or struct.
+been added in the past. To give one example, the presence of ``@frozen`` may
+affect the layout and calling conventions for an enum or struct.
 
 .. note::
 
@@ -1470,7 +1480,7 @@ for verification. Important cases include but are not limited to:
 - Unsafe `backdating <#backdating>`_.
 
 - Unsafe modifications to entities marked with fragility attributes, such as
-  adding a stored property to a ``@fixedContents`` struct.
+  adding a stored property to a ``@frozen`` struct.
 
 Wherever possible, this tool should also check for `binary-compatible
 source-breaking changes <binary-compatible source-breaking change>`, such as
@@ -1627,19 +1637,22 @@ The following proposals (some currently in the process, some planned) will
 affect the model described in this document, or concern the parts of this
 document that affect language semantics:
 
+- Non-exhaustive enums (`SE-0192 <SE0192>`_)
+- Inlineable functions (`SE-0193 <SE0193>`_)
+- Frozen structs and enums (`SE-0260 <SE0260>`_)
 - (draft) `Overridable methods in extensions`_
 - (planned) Restricting retroactive modeling (protocol conformances for types you don't own)
 - (planned) `Generalized existentials (values of protocol type) <Generics>`_
-- (planned) Frozen enums (building on `SE-0192 <SE0192>`_)
 - (planned) Removing the "constant" guarantee for 'let' across module boundaries
-- (planned) Syntax for declaring fixed-contents structs
 - (future) Performance annotations for types
 - (future) Attributes for stored property accessors
 - (future) Stored properties in extensions
 
 .. _Overridable methods in extensions: https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md
 .. _Generics: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials
 .. _SE0192: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
+.. _SE0193: https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
+.. _SE0260: https://github.com/apple/swift-evolution/blob/master/proposals/0260-library-evolution.md
 
 This does not mean all of these proposals need to be accepted, only that their
 acceptance or rejection will affect this document.