on Fri Dec 30 2016, Austin Zheng <[email protected]> wrote: > After overpromising and underdelivering, I finally managed to sit down > and draft a proposal. Sorry it took so long.
All your help is deeply appreciated, Austin! > You can find it here: > > https://github.com/austinzheng/swift-evolution/blob/recursive-constraints/proposals/XXXX-recursive-protocol-constraints.md > <https://github.com/austinzheng/swift-evolution/blob/recursive-constraints/proposals/XXXX-recursive-protocol-constraints.md> > > It contains both a description of the change itself, as well as a list > of stdlib changes that need to be made. I used the “FIXME(ABI)” > comments in the codebase to compile that list of changes. I also went > over parts of the stdlib myself to see if there was anything else I > could find, but didn’t notice anything in particular. (I was hoping > protocols like `_Integer` could go away, but I’m not sure the issue > they’re working around is related to recursive constraints.) It is. > One thing that needs to be done before this can enter formal review is > thinking through cases where “valid” recursive constraints might break > the compiler. I haven't read it yet; does the document explain what you mean by that? Because it's not obvious from this message > Help on that (or any other feedback, really) would be greatly > appreciated. > > Best, > Austin > >> On Nov 21, 2016, at 6:42 PM, Austin Zheng <[email protected]> > wrote: >> >> 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] >> <mailto:[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] >> <mailto:[email protected]>> wrote: >> >> >> >> >> On Nov 13, 2016, at 4:03 PM, Austin Zheng >> <[email protected] >> <mailto:[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] <mailto:[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 >>> <https://gist.github.com/DougGregor/e7c4e7bb4465d6f5fa2b59be72dbdba6> >>> >>> - Doug >>> >>> >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] > <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
