Skip to content

Another round of updates for LibaryEvolution.rst #20158

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

slavapestov
Copy link
Contributor

Adding new protocol requirements is now a "binary compatible
source breaking change" without explicit guarantees about
source compatibility.

Removing a default from an associated type is not binary
compatible because the associated type may itself have been
added resiliently, in which case clients that predate the
associated type will not be able to instantiate a witness
table for the protocol.

Adding new protocol requirements is now a "binary compatible
source breaking change" without explicit guarantees about
source compatibility.

Removing a default from an associated type is not binary
compatible because the associated type may itself have been
added resiliently, in which case clients that predate the
associated type will not be able to instantiate a witness
table for the protocol.
@slavapestov slavapestov force-pushed the library-evolution-fixes-part-2 branch from b3e0fa0 to 28c90ab Compare October 30, 2018 18:53
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test macOS

@slavapestov slavapestov merged commit 6a29428 into swiftlang:master Oct 30, 2018
source-compatible.
- A new non-type requirement may be added to a protocol, as long as it has an
unconstrained default implementation in a protocol extension of the
protocol itself or some other protocol it refines.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I liked it better with the old organization, but I guess this is fine.

A protocol's associated types are used in computing the "generic signature"
that uniquely identifies a generic function. Adding an associated type
could perturb the generic signature and thus change the identity of a
function, breaking binary compatibility.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad to be wrong about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants