Minor updates for LibraryEvolution.rst #20135
Conversation
|
@swift-ci Please smoke test |
| - Removing a non-public case is not applicable. | ||
| - Adding a raw type is still permitted. |
There was a problem hiding this comment.
Are you sure about this?
There was a problem hiding this comment.
Perhaps @DougGregor or @jckarter knows if adding a raw type has any effects in addition to what you'd get if you wrote the conformance manually?
There was a problem hiding this comment.
I feel like I remember some from SE-0192 but perhaps I didn't actually implement them. (I know at one point we tossed around the idea of raw type = trivial one-word or 64-bit representation.)
There was a problem hiding this comment.
A raw type is just sugar for implementing a RawRepresentable conformance. It doesn't change the representation.
| @@ -827,6 +839,7 @@ There are very few safe changes to make to protocols and their members: | |||
|
|
|||
| - A new non-type requirement may be added to a protocol, as long as it has an | |||
| unconstrained default implementation. | |||
| - A new associated type requirement may be added as long as it has a default. | |||
There was a problem hiding this comment.
I'm not sure about this until we have a generalized existential story.
There was a problem hiding this comment.
Good point. This is true for adding new requirements with non-covariant Self, too. I'll add a separate bullet explaining that making something not usable as an existential is binary-compatible but not source-compatible.
There was a problem hiding this comment.
Yeah. Even if you already had associated types, I think we should be able to support the "existential of fully-constrained subprotocol" possibly before we get the full generalized existentials. It's a much easier change to reason about, and this would break that too.
There was a problem hiding this comment.
I have a radar on me for that :) One day...
There was a problem hiding this comment.
Amusing thing about binary compatibility: as? P casts written before P gained an associated type will continue to work fine, but the source code, if recompiled, would result in a compiler error.
docs/LibraryEvolution.rst
Outdated
| - Removing any non-public, non-versioned member. | ||
| - Changing the body of any methods, initializers, or accessors. | ||
|
|
||
| Additionally, non-protocol extensions have a handful of additional rules: |
There was a problem hiding this comment.
"allow a few additional changes"? (since the items are all positive noun phrases)
slavapestov
force-pushed
the
update-evolution-doc
branch
from
d38f20d to
6c609f2
Compare
|
@swift-ci Please smoke test |
1 similar comment
|
@swift-ci Please smoke test |
docs/LibraryEvolution.rst
Outdated
| @@ -840,9 +853,18 @@ There are very few safe changes to make to protocols and their members: | |||
| be added to a function requirement without any additional versioning | |||
| information. | |||
|
|
|||
| Note that clients can use a protocol as an existential type as long as it does | |||
| not have any associated types or requirements containing ``Self`` in | |||
| non-contravariant position. Therefore adding such a requirement becomes a | |||
There was a problem hiding this comment.
You double-negated this, yeah? "non-covariant" or "contravariant".
|
|
||
| Adding such requirements to protocols that already contain such requirements and | ||
| cannot be used as existential types, on the other hand, is always | ||
| source-compatible. |
There was a problem hiding this comment.
This is the thing I don't want to promise, because of fully-constrained sub-protocols.
| All other changes to the protocol itself are forbidden, including: | ||
|
|
||
| - Adding a new associated type. | ||
| - Adding or removing refined protocols. |
- We don't allow local typealiases in inlinable code either. - Explicitly document the places where adding or removing 'lazy' is allowed and not allowed (it's effectively like going between stored and computed). - Adding associated types with defaults is now allowed. - Adding associated types or Self requirements to a protocol that did not already have them is a *binary-compatible source-breaking change*. - For non-@objc enums, adding a raw type is OK -- it's just a compiler-synthesized RawRepresentable conformance and is not used for layout. - Adding/removing/re-ordering extension members does _not_ follow the rules of the type itself.
slavapestov
force-pushed
the
update-evolution-doc
branch
from
6c609f2 to
4959c33
Compare
|
@swift-ci Please smoke test |
1 similar comment
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test macOS |
|
@swift-ci Please smoke test |
is allowed and not allowed (it's effectively like going between
stored and computed).
compiler-synthesized RawRepresentable conformance and is not
used for layout.
follow the rules of the type itself.