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

[Russ Bishop]

> On Jun 22, 2016, at 6:12 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> E.g., the current Iterator could gain a
>> class constraint and become the only representation of single-pass
>> sequences.
> 
> Hmm.  I would have to give this more thought.  Do we really want to require all conformances of `Iterator` to be reference types?  What would be the performance impact of that?

I wouldn’t think so.


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

IEnumerable<> does not guarantee the ability to repeatedly enumerate, generally around I/O which is the same place I use a destructively iterating sequence in Swift - lazily enumerating rows from a database query.

Russ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160626/df97c7c4/attachment.html>