> On Jun 22, 2016, at 6:12 PM, Matthew Johnson via swift-evolution > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
