SE-0364: Warning for Retroactive Conformances of External Types

[Jumhyn (Frederick Kellison-Linn)]

@xwu

In this case, to my understanding, the “original” x cannot be a witness for the protocol requirement without recompilation and this would not be meaningfully different to v2.0 of the library vending a non-protocol requirement extension method of the same name, which is a supported feature albeit with its own complications (as all shadowing has)—but the runtime behavior is not undefin(ed|able).

Hm—perhaps I'm exposing a gap in my understanding here but I don't see how that can be the case (I'm also not entirely clear which x you're referring to as the "original" since they were both added in the same version; I'm assuming x in the extension?). If the client code looks like:

import SomeLibrary

extension S: P {}

then with v1.0 of the library you've simply declared a retroactive conformance of S to P—no issue, strictly. But since adding a (defaulted) protocol requirement is a resilient change, SomeLibrary could have updated in the following manner:

// SomeLibrary v1.5
public struct S {}
public protocol P {
  var x: Int { get }
}
public extension P {
  var x: Int { 1 }
}

How would this be a resilient change if the definition of x in the extension isn't witnessing P.x within the client module? Otherwise, there would be no witness for P.x in the conformance S: P.

ETA:

@xwu

We can decide many things by fiat, but I am struggling to see why we should prohibit anew in Swift Next something that currently works without a demonstration of active harm.

Yeah I take your point, and if there's really no soundness issue in the requirement-less case then I don't feel super strongly. I just think that there's some value in having a simple rule here ("module-qualify retroactive conformances") that covers the general case rather than trying to subset out narrow cases that are okay.