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

Austin Zheng austinzheng at gmail.com
Mon Nov 21 20:42:51 CST 2016


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> 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> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Nov 13, 2016, at 4:03 PM, Austin Zheng <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> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161121/45e0c85d/attachment.html>


More information about the swift-evolution mailing list