I find that many cases where self-conformance is needed, can be solved by using subtyping relation instead of protocol conformance.
Original thread - Existential subtyping as generic constraint
MR - [Generics Manifesto] Existential subtyping as generic constraint by nickolas-pohilets · Pull Request #33552 · apple/swift · GitHub
I’m suggesting syntax f<T: P> for protocol conformance requirement and f<T: any P> for existential subtyping.
First one allows T to be any concrete type confirming to P, and allows usage of static requirements and associated types.
Second one allows T to be any concrete type conforming to P, but also existential type for P or any derived protocol. But static requirements and associated types are not available inside f.
Witness table for the existential subtyping can have single entry - a function that returns an existential container for P given a value of T.