[swift-evolution] [Pitch] Remove destructive consumption from Sequence
dabrahams at apple.com
Wed Jun 22 15:57:07 CDT 2016
on Wed Jun 22 2016, David Waite <swift-evolution at swift.org> wrote:
> Today, a Sequence differs from a Collection in that:
> - A sequence can be infinitely or indefinitely sized, or could require
> an O(n) operation to count the values in the sequence.
The latter being no different from Collection.
> A collection has a finite number of elements, and the fixed size is
> exposed as an O(1) or O(n) operation via ‘count’
I don't believe we've actually nailed down that Collection is finite.
Oh, gee, Nate's documentation edits do
Nate, did we discuss this explicitly or did it slip in unnoticed?
The one crucial distinction in Collection is that you can make multiple
passes over the same elements.
> - A collection is indexable, with those indices being usable for
> various operations including forming subsets, comparisons, and manual
> - A sequence may or may not be destructive, where a destructive
> sequence consumes elements during traversal, making them unavailable
> on subsequent traversals. Collection operations are required to be
> I would like to Pitch removing this third differentiation, the option
> for destructive sequences.
I have been strongly considering this direction myself, and it's
something we need to decide about for Swift 3.
> 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.
I don't think the names are really the worst potential cause of
confusion here. There's also the fact that you can conform to Sequence
with a destructively-traversed “value type” that has no mutating
> It would still be possible to have Generators which operate
<Ahem> “Iterators,” please.
> destructively, but such Generators would not conform to the needs of
> Sequence. As such, the most significant impact would be the inability
> to use such Generators in a for..in loop,
Trying to evaluate this statement, it's clear we're missing lots of
* Would you remove Sequence?
* If so, what Protocol would embody “for...in-able?”
* If not, would you remove Collection?
* What role would Iterator play?
More information about the swift-evolution