Never mind, I just saw SE-0142. I need to go back and read all the proposals again!
On Mon, Nov 21, 2016 at 6:32 PM, Austin Zheng <[email protected]> wrote: > I'm still working on this. When you mention where clauses on associated > types, how should I handle that in the context of the proposal? > > * Consider where clauses part of the proposal (so that the proposal > becomes "recursive associated type constraints + where clauses on > associated types") > * Assume that where clauses will definitely be accepted, and write the > stdlib changes assuming that > * Assume that where clauses might not be accepted, and write the stdlib > changes assuming that, but also have a section containing further stdlib > changes conditional on where clauses being accepted > > Best, > Austin > > On Sun, Nov 13, 2016 at 7:55 PM, Douglas Gregor <[email protected]> wrote: > >> >> >> Sent from my iPhone >> >> On Nov 13, 2016, at 4:03 PM, Austin Zheng <[email protected]> wrote: >> >> I'd be happy to put something together, unless someone else wants to take >> it on. >> >> >> Great, thanks! >> >> >> Doug, I also owe you a PR adding a minor amendment to one of the accepted >> proposals. I'll get to that this week. >> >> >> Sounds great. >> >> - Doug >> >> Austin >> >> On Sun, Nov 13, 2016 at 10:13 PM, Douglas Gregor via swift-evolution < >> [email protected]> wrote: >> >>> 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." >>> >>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics>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 >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
