<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Can’t a Sequence be potentially infinite, whereas a collection has a defined count/endIndex? &nbsp;Other than that, I agree with your statement.</div><div class=""><br class=""></div><div class="">Here is what I see as the appropriate structure:</div><div class=""><br class=""></div><div class=""><b class="">Iterator</b>: Single destructive pass, potentially infinite, (should be for-in able)</div><div class=""><b class="">Sequence</b>: Guaranteed non-destructive multi-pass (vends Iterators), potentially infinite, (should be subscript-able, gain most of collection, but lose anything that relies on it ending)</div><div class=""><b class="">Collection</b>: Multi-pass, guaranteed finite, (no changes from current form, except extra inits from Iterator/Sequence with end conditions)</div><div class=""><br class=""></div><div class="">Right now we are allowed to have an infinite sequence, but calling dropLast or non-lazy map will cause an infinite loop. &nbsp;These cases could be made much safer by considering the potentially infinite and finite cases separately...</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">on Wed Jun 22 2016, David Waite &lt;<a href="http://david-at-alkaline-solutions.com" class="">david-AT-alkaline-solutions.com</a>&gt; wrote:

&gt;&gt;<i class=""> On Jun 22, 2016, at 2:57 PM, Dave Abrahams via swift-evolution &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">swift-evolution at swift.org</a>&gt; wrote:
</i>&gt;&gt;<i class=""> 
</i>&gt;&gt;<i class=""> &lt;Ahem&gt; “Iterators,” please.
</i>&gt;<i class="">
</i>&gt;<i class=""> That makes me happy - for some reason I thought it was still GeneratorProtocol
</i>&gt;<i class="">
</i>&gt;&gt;&gt;<i class=""> destructively, but such Generators would not conform to the needs of
</i>&gt;&gt;&gt;<i class=""> Sequence. As such, the most significant impact would be the inability
</i>&gt;&gt;&gt;<i class=""> to use such Generators in a for..in loop, 
</i>&gt;&gt;<i class=""> 
</i>&gt;&gt;<i class=""> Trying to evaluate this statement, it's clear we're missing lots of
</i>&gt;&gt;<i class=""> detail here:
</i>&gt;&gt;<i class=""> 
</i>&gt;&gt;<i class=""> * Would you remove Sequence?
</i>&gt;&gt;<i class=""> * If so, what Protocol would embody “for...in-able?”
</i>&gt;<i class=""> No, I would just remove the allowance in the documentation and API
</i>&gt;<i class=""> design for a destructive/consuming iteration. Sequence would be the
</i>&gt;<i class=""> interface to getting access to repeatable iteration, without the need
</i>&gt;<i class=""> for meeting the other requirements for Collection.
</i>
That would be wrong unless there exist substantial examples of a
multipass Sequence that *can't* meet the other requirements of
Collection without loss of efficiency.  And since I can write an adaptor
that turns any multipass sequence into a Collection, I think it's
trivial to prove that no such examples exist.

-- 
-Dave</pre></blockquote><div class=""><br class=""></div></div></body></html>