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

[Dave Abrahams]

on Wed Jul 06 2016, Anton Zhilin <antonyzhilin-AT-gmail.com> wrote:

> 1. Do nothing with finiteness, because huge sequences are mostly like
> infinite ones, plus because infinite loops are useful
> 2. Allow collections to be infinite
> 3. Do not add new fields to collections, because infinite loops are
> useful

No argument so far, but...

> 4, Do not separate protocols
> Current model of IteratorProtocol + Sequence is a very simple and clean way
> to define one's own iterables. Let's not break it.

It's already broken.  When you call non-mutating methods such as map,
filter, or reduce on a Sequence, the sequence can be modified.  That
provblem was outlined very nicely by David Waite in
http://thread.gmane.org/gmane.comp.lang.swift.evolution/21295/focus=21872:

  My main motivation for proposing this is the potential for developer
  confusion. As stated during one of the previous threads on the naming
  of map, flatMap, filter, etc. methods on Sequence, Sequence has a
  naming requirement not typical of the rest of the Swift standard
  library in that many methods on Sequence may or may not be
  destructive. As such, naming methods for any extensions on Sequence is
  challenging as the names need to not imply immutability.

> Now to single-pass-ness.
> I would suggest the following model:
> 1. Iterable protocol is base of everything that can be used in for loop.
> Contains all single-pass-able operations.
> 2. IteratorProtocol is what Iterable returns. IteratorProtocol conforms to
> Iterable, returns itself. Single-pass sequences should conform to
> IteratorProtocol.
> 3. Sequence protocol conforms to Iterable. Sequences are multi-pass.

That solves no problems AFAICT and introduces a new protocol.  What's
the point?

> 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.

That goal should not take precedence over logical coherence and
simplicity of the standard library.

Also, conforming to collection isn't really hard.

Finally, as mentioned earlier we could easily supply a protocol that
makes it no harder than conforming to IteratorProtocol is.  You don't
even need to make your iteration state equatable because we can compare
counters stored in the indices.  I'll post a gist illustrating this
today.

-- 
Dave