[swift-evolution] [Pitch/plea] Recursive protocol constraints
Douglas Gregor
dgregor at apple.com
Sun Nov 13 16:13:54 CST 2016
Recursive protocol constraints is one small-looking feature that could greatly improve the standard library. The generics manifesto describes it this way:
"Currently, an associated type cannot be required to conform to its enclosing protocol (or any protocol that inherits that protocol). For example, in the standard library SubSequence type of a Sequence should itself be a Sequence:
protocol Sequence { associatedtype Iterator : IteratorProtocol ... associatedtype SubSequence : Sequence // currently ill-formed, but should be possible }
The compiler currently rejects this protocol, which is unfortunate: it effectively pushes the SubSequence-must-be-a-Sequence requirement into every consumer of SubSequence, and does not communicate the intent of this abstraction well."
It's actually slightly worse than the above implies: the standard library has a pile of underscore-prefixed protocols (e.g., _Sequence) specifically to dodge this restriction. They are ugly, and we want them to go away. Many of these places are marked with an ABI FIXME in the standard library sources.
Would someone like to write up a proposal for this feature? The syntax and basic semantics are pretty direct, but a proposal should also capture the expected effects on the standard library, particularly when combined with where clauses on associated types.
I also have a nagging feeling that we will need some form of restrictions on this feature for implementation reasons, e.g., because some recursive constraints will form unsolvable systems.
For reference, we've already been implementing this feature. Some information about the compiler internal issues is captured at:
https://gist.github.com/DougGregor/e7c4e7bb4465d6f5fa2b59be72dbdba6
- Doug
Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161113/15f22921/attachment.html>
More information about the swift-evolution
mailing list