<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>Thanks for a review Kevin!</div><div><br class=""><blockquote type="cite" class="">At the moment AnyCollection does not delegate calls to SequenceType protocol methods to the underlying base sequence<br class=""></blockquote><blockquote type="cite" class=""><div class=""><div class=""> </div>
<div class="">Presumably that should say AnySequence instead of AnyCollection, since the rest of the proposal talks about AnySequence?<br class=""></div></div></blockquote>Good catch. Although applicable to AnyCollection as well, this should mention AnySequence in this case. đź‘Ť</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
<div class=""> </div>
<div class="">2. One of the added constraints looks like<br class=""></div>
<div class=""> </div>
<pre class="">S<span class="colour" style="color:rgb(167, 29, 93)">.</span>SubSequence<span class="colour" style="color:rgb(167, 29, 93)">.</span>SubSequence <span class="colour" style="color:rgb(167, 29, 93)">==</span> S<span class="colour" style="color:rgb(167, 29, 93)">.</span>SubSequence<br class=""></pre><div class=""> </div>
<div class="">with a comment saying that ideally the set of constraints would apply to the SequenceType protocol but that's not currently possible. This makes sense for the other constraints (that SubSequence conforms to SequenceType and has the same element), but this particular constraint, that the subsequence type must have itself as its own subsequence, surprises me a little. I can see why it's needed here (because that's the only way you can guarantee that recursing through SubSequences always finds SequenceTypes with the right element), but ideally we wouldn't actually require it to be the _same_ sequence, just that it is some sequence with the same element type. If we ever change Swift such that these constraints can be expressed on the SequenceType definition itself, then presumably we'll be able to drop this == constraint entirely as the SequenceType protocol itself will ensure that its subsequence is a sequence of the same element type (which will satisfy the need to have it be true after arbitrary levels of recursion).<br class=""></div></div></div></blockquote><div><br class=""></div><div>You’re totally right again. I will make these changes to the proposal.</div><div><br class=""></div><div>max</div><div><br class=""></div>[a bunch of text removed]</div></body></html>