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