<div dir="ltr">Thank you for the kind comments and the review, Dave! I will be working to address the points you brought up throughout the week. This will include re-auditing the stdlib types based on both manual investigation and Doug's branch.<div><br></div><div>Anyone who wants to help, by the way, is more than welcome to; I'm happy to take PRs or just even a message describing what needs to change, and I'd of course add you to the authors list...<br><div><br></div><div>Regarding "valid" recursive constraints breaking the compiler: it was a reference to something Doug said in his original email:</div><div><br></div><div>> <span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Best,</span></div><div><span style="font-size:12.8px">Austin</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 31, 2016 at 11:29 AM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
on Sat Dec 31 2016, Dave Abrahams <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> on Fri Dec 30 2016, Austin Zheng <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> After overpromising and underdelivering, I finally managed to sit down<br>
>> and draft a proposal. Sorry it took so long.<br>
><br>
> All your help is deeply appreciated, Austin!<br>
><br>
>> You can find it here:<br>
>><br>
>><br>
> <a href="https://github.com/austinzheng/swift-evolution/blob/recursive-constraints/proposals/XXXX-recursive-protocol-constraints.md" rel="noreferrer" target="_blank">https://github.com/<wbr>austinzheng/swift-evolution/<wbr>blob/recursive-constraints/<wbr>proposals/XXXX-recursive-<wbr>protocol-constraints.md</a><br>
>><br>
> <<a href="https://github.com/austinzheng/swift-evolution/blob/recursive-constraints/proposals/XXXX-recursive-protocol-constraints.md" rel="noreferrer" target="_blank">https://github.com/<wbr>austinzheng/swift-evolution/<wbr>blob/recursive-constraints/<wbr>proposals/XXXX-recursive-<wbr>protocol-constraints.md</a>><br>
>><br>
>> It contains both a description of the change itself, as well as a list<br>
>> of stdlib changes that need to be made. I used the “FIXME(ABI)”<br>
>> comments in the codebase to compile that list of changes. I also went<br>
>> over parts of the stdlib myself to see if there was anything else I<br>
>> could find, but didn’t notice anything in particular. (I was hoping<br>
>> protocols like `_Integer` could go away, but I’m not sure the issue<br>
>> they’re working around is related to recursive constraints.)<br>
><br>
> It is.<br>
><br>
>> One thing that needs to be done before this can enter formal review is<br>
>> thinking through cases where “valid” recursive constraints might break<br>
>> the compiler.<br>
><br>
> I haven't read it yet; does the document explain what you mean by that?<br>
> Because it's not obvious from this message<br>
<br>
</span>...or from the document.<br>
<br>
I left some commentary in<br>
<a href="https://github.com/austinzheng/swift-evolution/commit/ad1d28b3b74bb12cfd07c277322ea4eb2b78b8cd#diff-6b60459047bfe1c675c50d5ca66cfe91R57" rel="noreferrer" target="_blank">https://github.com/<wbr>austinzheng/swift-evolution/<wbr>commit/<wbr>ad1d28b3b74bb12cfd07c277322ea4<wbr>eb2b78b8cd#diff-<wbr>6b60459047bfe1c675c50d5ca66cfe<wbr>91R57</a><br>
<br>
in addition, I notice that many of the likely stdlib changes are<br>
missing... but it may be more efficient for you to watch the branch<br>
Doug's working on and see what changes are made there, and then propose<br>
those, than to try to anticipate what will change.<br>
<div class="HOEnZb"><div class="h5"><br>
>> Help on that (or any other feedback, really) would be greatly<br>
>> appreciated.<br>
>><br>
>> Best,<br>
>> Austin<br>
>><br>
>>> On Nov 21, 2016, at 6:42 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Never mind, I just saw SE-0142. I need to go back and read all the proposals again!<br>
>>><br>
>>> On Mon, Nov 21, 2016 at 6:32 PM, Austin Zheng<br>
>>> <<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a><br>
>>> <mailto:<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>><wbr>> wrote:<br>
>>> I'm still working on this. When you mention where clauses on<br>
>>> associated types, how should I handle that in the context of the<br>
>>> proposal?<br>
>>><br>
>>> * Consider where clauses part of the proposal (so that the proposal<br>
>>> becomes "recursive associated type constraints + where clauses on<br>
>>> associated types")<br>
>>> * Assume that where clauses will definitely be accepted, and write the stdlib changes assuming that<br>
>>> * Assume that where clauses might not be accepted, and write the<br>
>>> stdlib changes assuming that, but also have a section containing<br>
>>> further stdlib changes conditional on where clauses being accepted<br>
>>><br>
>>> Best,<br>
>>> Austin<br>
>>><br>
>>> On Sun, Nov 13, 2016 at 7:55 PM, Douglas Gregor<br>
>>> <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a><br>
>>> <mailto:<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Nov 13, 2016, at 4:03 PM, Austin Zheng<br>
>>> <<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a><br>
>>> <mailto:<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>><wbr>> wrote:<br>
>>><br>
>>>> I'd be happy to put something together, unless someone else wants to take it on.<br>
>>><br>
>>> Great, thanks!<br>
>>><br>
>>>><br>
>>>> Doug, I also owe you a PR adding a minor amendment to one of the<br>
>>>> accepted proposals. I'll get to that this week.<br>
>>><br>
>>> Sounds great.<br>
>>><br>
>>> - Doug<br>
>>><br>
>>>> Austin<br>
>>>><br>
>>>> On Sun, Nov 13, 2016 at 10:13 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
>>>> Recursive protocol constraints is one small-looking feature that could greatly improve the standard library. The generics manifesto describes it this way:<br>
>>>><br>
>>>> "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:<br>
>>>><br>
>>>> protocol Sequence { associatedtype Iterator : IteratorProtocol ... associatedtype SubSequence : Sequence // currently ill-formed, but should be possible }<br>
>>>> 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."<br>
>>>><br>
>>>> <<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics" rel="noreferrer" target="_blank">https://github.com/apple/<wbr>swift/blob/master/docs/<wbr>GenericsManifesto.md#nested-<wbr>generics</a>>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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> For reference, we've already been implementing this feature. Some information about the compiler internal issues is captured at:<br>
>>>><br>
>>>> <a href="https://gist.github.com/DougGregor/e7c4e7bb4465d6f5fa2b59be72dbdba6" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>DougGregor/<wbr>e7c4e7bb4465d6f5fa2b59be72dbdb<wbr>a6</a> <<a href="https://gist.github.com/DougGregor/e7c4e7bb4465d6f5fa2b59be72dbdba6" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>DougGregor/<wbr>e7c4e7bb4465d6f5fa2b59be72dbdb<wbr>a6</a>><br>
>>>><br>
>>>> - Doug<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> swift-evolution mailing list<br>
>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <mailto:<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.<wbr>org</a>><br>
>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
>> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a>><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
>><br>
<br>
--<br>
-Dave<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>