The Requirement Machine operates on canonical types internally and erases
sugared types appearing in generic requirements as a result.
For trivial cases like Array<T> vs [T], we can use the existing
TypeBase::reconstituteSugar() utility to produce a more aesthetically-pleasing
generic signature.
If you have a pair of requirements T : P and T == G<U>, the conformance
G : P might be conditional, imposing arbitrary requirements on U.
In particular, these conditional requirements can mention arbitrary
protocols on the right hand side.
Introducing these conformance requirements during property map construction
is totally fine when building a top-level generic signature, but when
building a protocol requirement signature, things get a bit tricky.
Because of the design of the requirement machine, it is better if the set
of protocols appearing on the right hand side of conformance requirements
in another protocol (the "protocol dependencies") are known *before* we
start building the requirement signature, because we build the requirement
signatures of all protocols in a connected component of this graph
simultaneously.
Introducing conformance requirements to hithero-unseen protocols after
the graph of connected components had already been built would require
mutating it in a tricky way, and possibly merging connected components.
I didn't find any examples of protocols that rely on conditional
requirement inference in our test suite, or in the source compatibility
suite.
So for now, I'm going to try to disable this feature inside protocols.
Another argument in favor of not doing conditional requirement
inference in protocols is that we don't do the ordinary kind of requirement
inference there either. That is, the following is an error:
protocol P {
associatedtype T == Set<U>
associatedtype U
}
Unlike with an ordinary top-level generic signature, we don't infer
'U : Hashable' here. So arguably the current behavior of protocols inferring
these requirements in the case of a conditional conformance only is also
rather odd.
