+1k.9 Sent from my iPhone
> On Dec 30, 2016, at 18:44, Austin Zheng via swift-evolution > <[email protected]> wrote: > > After overpromising and underdelivering, I finally managed to sit down and > draft a proposal. Sorry it took so long. You can find it here: > > 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.) > > 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. 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]> 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." >>>>>> >>>>>> >>>>>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
