I don't think this can ever be supported, since it modifies existing protocol hierarchies after the fact. It could change how a canonical generic signature gets computed if we're not careful, which could lead to ABI mismatches. @DougGregor, @slavapestov, further thoughts?

Thanks for picking this up @belkadan. I’ve just filed a PR (#25786) with an implementation which works pretty well. There wasn’t much to do just adding some late phase adding of protocols into the ProtocolConformance table. The only catch was making sure that referenced witness tables get emitted so they are tracked at the same time. Not sure if this affects ABI but I would have thought not. I guess the issue is not can this be done but should it?

Don't forget retroactive conformances…

How do you mean?

There is one limitation in that usage of nominals acquiring the new conformance must be in the same module as an extension of the protocol being extended.

This part is a problem – what happens when there's a protocol in module A, extended in module B, and then module C uses types from both A and B in a generic context? Some of the types will have the new protocol and some won't, but the generic context won't know which.

Looks like I may have to concede defeat on this one. There may be other problems but the one that has me stumped is “which source emits the witness table” for new conformances. When a concrete type is conformed the witness table is emitted in that source but when a protocol is conformed the witness table for a concrete type is emitted on demand if it is used. This works for a single file but if a conformance is used in a different source from the extension there is no opportunity to emit the witness table and you get an undefined symbol when linking. If you do emit the witness table where it is used you can get duplicate symbols if the conformance is used in more than one file and it seems impossible to resolve this problem. I’ll put this on hold until I can think of a solution.

I'm still chipping away at this. I was able to resolve the duplicate witness table symbols by emitting them as private to the file being compiled when they are inferred from an extension. So far so good.

This feature is categorized as "unlikely" in the generics manifesto (see https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions), because there's a lot questions about the discovery of such conformances (particularly at runtime) and the ambiguities that can result from doing this.

OK, Thanks for letting me know it's on the radar however unlikely. I'd really love to see this in the language someday though I can see it's a bit of a loose cannon. Perhaps "Parameterized extensions" will fill the gap.

After a bit of a pause I'm taken a second run at this problem and the results are reasonably encouraging at this stage #29272 While the layout of witness tables does change it seems new conformances are added to the end of the table and they are emitted as private so shouldn't affect resilience. Can someone review the PR and let me know if we're on the right track please?

I've added a post to the S/E pitch to take a bit more feedback https://forums.swift.org/t/protocol-extensions-inheriting-protocols/25491/8