[swift-evolution] [Pitch] Remove destructive consumption from Sequence

[David Waite]

> On Jun 22, 2016, at 2:57 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> <Ahem> “Iterators,” please.

That makes me happy - for some reason I thought it was still GeneratorProtocol

>> 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
> detail here:
> 
> * Would you remove Sequence?
> * If so, what Protocol would embody “for...in-able?”
No, I would just remove the allowance in the documentation and API design for a destructive/consuming iteration. Sequence would be the interface to getting access to repeatable iteration, without the need for meeting the other requirements for Collection.

Sequence would be what java would refer to as Iterable, C# refers to as IEnumerable<>, but perhaps it is closest to the Enumerable mixin module in Ruby in terms of default utility methods supplied based on an implementation of ‘each’ (forEach() in Swift). Sequence is for…in-able because Sequence defined makeIterator(). The only difference is that subsequent calls to makeIterator() are expected to return conceptually equivalent elements in the same order.

> * If not, would you remove Collection?

I see value in the other differentiating factors between Collection (not needing to be indexable, not needing to return a definitive count, and possibly not needing to be finite - although it sounds like collections may be effectively infinite to the extent that the integer type returned from count allows.

A Fibonacci-providing sequence can be written as a rather small closure, while my understanding of Collection would require either more code (that I likely don’t need), rather funky indexes that preserve state internally, and/or a switch to a non-iterative algorithm.

> * What role would Iterator play?


So far I haven’t considered whether IteratorProtocol would be destructive, since my motivation was primarily around consistent Sequence behavior. By that light, an Iterator returned by a method other than Sequence.makeIterator() could still consume data. However, I wonder if supporting such Iterators provides enough value to be worthwhile - there aren’t that many methods that consume an IteratorProtocol (the AnyIterator<> initializer is the only one I know of) and without applicability to a Sequence such an iterator has less value.

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/5d8c0afe/attachment.html>