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

[Dave Abrahams]

on Fri Dec 30 2016, Austin Zheng <swift-evolution at swift.org> 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 <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:
>> 
>> 
>> 
>> 
>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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>
>>> 
>>> 
>> 
>> 
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave