[swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

[Dave Abrahams]

This post describes the standard library team's analysis of the
finite/infinite sequence issue raised by Matthew Johnson and others in
http://news.gmane.org/find-root.php?message_id=1976B8AE%2dFDD1%2d4257%2dA24F%2d2AFF84115445%40anandabits.com.

[Dmitri is going to write a separate post detailing our proposed
direction with respect to the original topic raised by David Waite in
http://thread.gmane.org/gmane.comp.lang.swift.evolution/21295, the
confusion resulting from the refinement relationship between Sequence
and Collection that introduces non-destructive consumption.  As you
will see below, the resolution of this post's issue will depend
somewhat on that].

It seems to us that there are four possible approaches here:

1. Do nothing.  Infinite loops are not usually security problems and
   might not be worth complicating APIs for.

2. Formally lift the constraint on Collection that forces it to be
   finite.  That would allow us to model multi-pass traversal over
   (portions of) infinite sequences.

3. #2, plus add to Collection an `isKnownToBeInfinite` property,
   defaulting to `false`, that can be used to trigger a trap when a call
   would otherwise loop infinitely.

4. Go all the way to separate protocols for finite and infinite
   Collections as detailed in
   http://article.gmane.org/gmane.comp.lang.swift.evolution/22471

As far as we can tell, the only real point in distinguishing finiteness
is to prevent infinite loops.  Since inifinite loops are equally
(non-)problematic for both single- and multi-pass sequences, we can find
little justification for treating single-pass and multi-pass sequences
differently where finiteness is concerned.  Therefore, whatever we end
up with for Collection should apply to single-pass sequences as well.

Lastly, it looks like nobody on the standard library team is going to
have the time to drive this forward for Swift 3.  While the standard
library team can provide some guidance, if it is to happen, someone else
needs to take the reins.  That's not supposed to be discouraging:
several smart and capable people have expressed their interest in this
topic.  That said, if you care about it, you'll need to do as much work
as possible independently.  That includes putting the proposal through
evolution and creating a pull request containing the implementation.

Thanks, everybody!

-- 
Dave