<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>Fair enough. I was thinking that it's better to err on the side of allowing flexibility, but there is something to be said for having slices of slices still be slices. My vague thought was that there might be some desire to have a slice be a type that wraps the thing being sliced, but I admit that I can't think offhand of any reason why a FooSlice<FooSlice<FooSlice<Foo>>> would be useful.<br></div>
<div> </div>
<div>-Kevin</div>
<div> </div>
<div>On Fri, Dec 18, 2015, at 08:51 PM, Dmitri Gribenko wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><div>Hi Kevin,<br></div>
<div> </div>
<div>Thank you for your feedback!<br></div>
<div> </div>
<div><div>On Fri, Dec 18, 2015 at 3:13 PM, Kevin Ballard via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;"><div><div>2. One of the added constraints looks like<br></div>
<div> </div>
<pre>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></pre><div> </div>
<div>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></div>
</div>
</blockquote><div> </div>
<div>The idea behind putting this constraint into the protocol was to make it possible to write code that repeatedly slices a collection without getting a ton of different types along the way:<br></div>
<div> </div>
<div>var myCollectionSlice = myCollection[myCollection.indices]<br></div>
<div>myCollectionSlice = myCollectionSlice.dropFirst()<br></div>
<div> </div>
<div>Also, we couldn't come up with an example of a sequence or a collection that needs to have different SubSequence types on different depth levels for efficiency or type safety reasons. Given that we think we aren't limiting expressivity with this constraint, having a simpler model (the operation of slicing slices is closed in the set of types) is better.<br></div>
<div> </div>
<div>I'd be happy to hear if you know some sequence or collection types that would benefit from not having this constraint.<br></div>
<div> </div>
<div>Dmitri<br></div>
<div> </div>
</div>
<div>-- <br></div>
<div><div>main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br></div>
<div>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/<br></div>
</div>
</div>
</div>
</blockquote><div> </div>
</body>
</html>