/me scratches head
How is this not a concrete form of SR-12692 , being the exact example there? Furthermore, as it says there, no fix for the problem in SR-12692 exists without language changes, whereas as I have pointed out over and over, that's not the case for SR-12881. That makes SR-12881 just as different from SR-12692 as my example above.
Sheesh, could you have made that example a little more condensed? It's hard to see what you're trying to do here, but IIUC the essence is that you're exploring how the compiler should deal with ambiguous, equally-good, conformances.
As I've said several times in this thread, I'm quite sure it's easy to prove that many such ambiguities can't be detected until run time. ContrivedImpl<Int> doesn't have to appear anywhere in source code where the compiler can forbid the use of doSomething():
func contrive<T>(_ x: T) {
ContrivedImpl<T>().doSomething()
}
As I've also said, one possible strategy is to simply (deterministically) pick one matching conformance when there are ambiguities. Protocol requirements have semantic requirements, and all equally-good candidates should produce reasonable results.
And as I've also also said, there's a cluster of issues here that includes the inability to retroactively add algorithms that are dispatched based on conformances, and the inability to definitively associate different implementations of the same algorithm, that maybe should be addressed together. If there was a different way to write such things, we could avoid changing the semantics of existing code, make the language more expressive, and deal with the ambiguity issues on their own terms, at least giving people finer control over how they are resolved.