[swift-evolution] [Pitch/plea] Recursive protocol constraints

[Austin Zheng]

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 <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 <austinzheng at gmail.com> 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 <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> 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 <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
> 
> 
> Sent from my iPhone
> 
> On Nov 13, 2016, at 4:03 PM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161230/80103b4c/attachment.html>