Backwards-deployable Conformances

[xwu (Xiaodi Wu)]

@jrose

Now ShoemakingElf conforms to Summonable in two different ways, which may be incompatible (especially if Summonable had associated types or requirements involving Self ).

Additionally, the client can't even remove ShoemakingElf 's conformance to Summonable , because it may itself be a library with other code depending on it. We could fix that with an annotation to explicitly inherent the conformance of Summonable from the base class, but even that may not be possible if there are incompatible associated types involved (because changing a member typealias is not a safe change).

One solution is to disallow adding a conformance for an existing protocol to an open class. I don't think people will be happy with this.

This all stems from the original decision to have subclasses inherit the protocol conformances of their superclasses, if I understand correctly. I do recall that at least one core team member was mentioning that this is something that they regret.

Is it now baked into the ABI? Or is there room to evolve the design so that protocol conformances are implicitly inherited unless explicitly overridden? Then, we could say that explicit conformances to a protocol in a subclass disables (for itself and any of its subclasses in turn) any inheritance of such a conformance (retroactive or otherwise) from a superclass.