<div dir="ltr">Thanks for the feedback! Some comments:<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">1. <b>Obscurity argument</b>: Both the existing precondition, and the proposed convention are non-enforceable, non-testable, not well-known enough, and generally too weak to be efficient in any way. People don't write custom iterators often enough, and I don't expect those rules to eventually percolate through Swift culture.</blockquote><div><br></div><div>To some degree true, but I'd argue the current guarantee is significantly more obscure than the proposed alternative: </div><div>- All standard library iterators return nil indefinitely.</div><div>- Iterators return nil if they're exhausted, i.e. no next element exists. If I call <font face="monospace, monospace">next()</font> again, it is still exhausted, still no next element exists, so you'd probably expect it to return nil again.</div><div><br style="font-size:13px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">3. <b>Iterator autonomy argument</b> : Iterator is easily seen as a type that exists to support Sequence. In this case, we'd like Iterator to end for good (finite sequence), or never end (infinite sequence). However, one could argue that Iterator is an autonomous type that happens to support Sequence, but may have other uses, like message queues. In such a context, requiring post-nil guarantees has no meaning.</blockquote></div><div style="font-size:13px"><br></div><div style="font-size:13px"><font face="monospace, monospace">IteratorProtocol</font> does explicitly describe itself as iterating over a sequence though:</div></div><div style="font-size:13px"><span style="color:rgb(150,152,150);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:12px;white-space:pre-wrap">/// A type that supplies the values of a sequence one at a time.</span></div><div style="font-size:13px">I'm not sure <font face="monospace, monospace">IteratorProtocol</font> is intended to be used for such cases (where the sequence changes length underneath). If it is, we could consider changing the guarantee to return nil as long as the underlying sequence is empty (i.e. allowing restarts). It's worth noting too that the current guarantee also doesn't support sequences changing length.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 2:40 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> * What is your evaluation of the proposal?<br>
<br>
</span>I think it's a good idea.<br>
<br>
This is a particularly sharp edge in the standard library: people have a completely reasonable expectation about `next()`'s behavior which is usually, but not always, borne out. And the vast majority of iterators can provide this feature for free. Only a few would pay any price, and that price would be minimal—it could easily be the cheapest statements in the method.<br>
<br>
Nor do I think the FuseIterator solution will actually help. If you know about FuseIterator, you don't really need it, because you know about `next()`'s nil behavior and can code around it. This is an attempt to protect the people who *don't* know about the problem.<br>
<br>
There are languages so averse to trading anything for efficiency that they refuse to provide simple improvements to help with these kinds of issues. I don't think Swift should be one of them.<br>
<span><br>
> * Is the problem being addressed significant enough to warrant a change to Swift?<br>
<br>
</span>Yes.<br>
<span><br>
> * Does this proposal fit well with the feel and direction of Swift?<br>
<br>
</span>I think so. One of the major themes of Swift 3 is cleaning up the standard library.<br>
<span><br>
> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
<br>
</span>I haven't, but some of the previous discussions on this issue have brought up Rust, which uses the FuseIterator solution. It seems like a pretty lousy one to me.<br>
<span><br>
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
</span>Quick reading this time, but I participated the previous discussion.<br>
<span><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div><div><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>