<div dir="ltr"><div>1. Do nothing with finiteness, because huge sequences are mostly like infinite ones, plus because infinite loops are useful</div><div>2. Allow collections to be infinite</div><div>3. Do not add new fields to collections, because infinite loops are useful</div><div>4, Do not separate protocols</div><div>Current model of IteratorProtocol + Sequence is a very simple and clean way to define one's own iterables. Let's not break it.</div><div><br></div><div>Now to single-pass-ness.</div><div>I would suggest the following model:</div><div>1. Iterable protocol is base of everything that can be used in for loop. Contains all single-pass-able operations.</div><div>2. IteratorProtocol is what Iterable returns. IteratorProtocol conforms to Iterable, returns itself. Single-pass sequences should conform to IteratorProtocol.</div><div>3. Sequence protocol conforms to Iterable. Sequences are multi-pass.</div><div><br></div><div>Also, we should leave both Sequence and Collection trees, because correctly conforming to Collection is a hard work, and correctly conforming to Sequence must be easy as pie.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-06 4:56 GMT+03:00 Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
This post describes the standard library team's analysis of the<br>
finite/infinite sequence issue raised by Matthew Johnson and others in<br>
<a href="http://news.gmane.org/find-root.php?message_id=1976B8AE%2dFDD1%2d4257%2dA24F%2d2AFF84115445%40anandabits.com" rel="noreferrer" target="_blank">http://news.gmane.org/find-root.php?message_id=1976B8AE%2dFDD1%2d4257%2dA24F%2d2AFF84115445%40anandabits.com</a>.<br>
<br>
[Dmitri is going to write a separate post detailing our proposed<br>
direction with respect to the original topic raised by David Waite in<br>
<a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/21295" rel="noreferrer" target="_blank">http://thread.gmane.org/gmane.comp.lang.swift.evolution/21295</a>, the<br>
confusion resulting from the refinement relationship between Sequence<br>
and Collection that introduces non-destructive consumption. As you<br>
will see below, the resolution of this post's issue will depend<br>
somewhat on that].<br>
<br>
It seems to us that there are four possible approaches here:<br>
<br>
1. Do nothing. Infinite loops are not usually security problems and<br>
might not be worth complicating APIs for.<br>
<br>
2. Formally lift the constraint on Collection that forces it to be<br>
finite. That would allow us to model multi-pass traversal over<br>
(portions of) infinite sequences.<br>
<br>
3. #2, plus add to Collection an `isKnownToBeInfinite` property,<br>
defaulting to `false`, that can be used to trigger a trap when a call<br>
would otherwise loop infinitely.<br>
<br>
4. Go all the way to separate protocols for finite and infinite<br>
Collections as detailed in<br>
<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/22471" rel="noreferrer" target="_blank">http://article.gmane.org/gmane.comp.lang.swift.evolution/22471</a><br>
<br>
As far as we can tell, the only real point in distinguishing finiteness<br>
is to prevent infinite loops. Since inifinite loops are equally<br>
(non-)problematic for both single- and multi-pass sequences, we can find<br>
little justification for treating single-pass and multi-pass sequences<br>
differently where finiteness is concerned. Therefore, whatever we end<br>
up with for Collection should apply to single-pass sequences as well.<br>
<br>
Lastly, it looks like nobody on the standard library team is going to<br>
have the time to drive this forward for Swift 3. While the standard<br>
library team can provide some guidance, if it is to happen, someone else<br>
needs to take the reins. That's not supposed to be discouraging:<br>
several smart and capable people have expressed their interest in this<br>
topic. That said, if you care about it, you'll need to do as much work<br>
as possible independently. That includes putting the proposal through<br>
evolution and creating a pull request containing the implementation.<br>
<br>
Thanks, everybody!<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave<br>
<br>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</font></span></blockquote></div><br></div>