Recursive protocol constraints are a small-looking feature (really, eliminating a limitation that feels arbitrary to users) that can also greatly improve the standard library. However, their implementation will require a number of changes throughout the Swift compiler. This document attempts to catalogue the kinds of changes required in the compiler to implement this feature, to provide some scoping and direction for the work.
The ArchetypeBuilder is responsible for processing the requirements in a protocol, generic function, generic type, or extension of a generic type to determine whether they are consistent. It also plays a central role in producing and canonicalizing generic signatures, as well as producing archetypes for a generic signature in a given generic environment. It is where recursive protocol constraints are detected and diagnosed, and the primary place where we will need to deal with recursion.
Currently, the ArchetypeBuilder expands the nested types of a potential archetype somewhat eagerly, when it sees a protocol constraint. For recursive constraints, this process will not terminate, so it will need to be performed lazily instead. This change shouldn't have any other impact on the system---it just makes something that is currently eager, more lazy.
The protocol conformance checker is likely already suitable for checking recursive constraints. However, it is possible that it will need to be made more lazy to accommodate such checks.