<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">The review of "SE-0052: Change IteratorType post-nil guarantee" begins now and runs through May 3. The proposal is available here:<br class=""><br class=""></blockquote><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md</a></blockquote></div><div class=""><br class=""></div><div class=""><b class="">• What is your evaluation of the proposal?</b><br class=""></div><div class=""><br class=""></div><div class="">I'm -1.</div><div class=""><br class=""></div><div class="">I agree with Patrick Pijnappel that it is too easy to write code that assumes that iterators end with nil for good, and breaks when this assumption happens to be false.</div><div class=""><br class=""></div><div class="">I agree as well that the precondition that when calling next(), no preceding call to next() should have returned nil is not observed enough.</div><div class=""><br class=""></div><div class="">I agree that algorithms need guarantees and API contracts.</div><div class=""><br class=""></div><div class="">Yet I have three arguments against the proposal:</div><div class=""><br class=""></div><div class="">1. <b class="">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.</div><div class=""><br class=""></div>2. <b class="">Social argument</b>: when a user complains that my library crashes when fed with a third-party iterator that does not behave, I, as a library author, have better make my code robust and accept non-conforming iterators than whining about the third-party. It's just faster and more efficient.<br class=""><br class=""><div class="">3. <b class="">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.</div><div class=""><br class=""></div><div class="">I'd thus remove the existing precondition, and support the following alternatives:</div><div class=""><br class="">- the FuseIterator Patrick's proposal (and we could discuss its name).<br class="">- a new StoppingIterator protocol which does explicitly provide the post-nil guarantee. Algorithms could then use this guarantee.<br class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">• Is the problem being addressed significant enough to warrant a change to Swift?</b><br class=""></div><div class=""><br class=""></div><div class="">Yes, because algorithms need guarantees and API contracts. I'm totally with the proposal author here. But I don't think the proposed changes are the right solution.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</b><br class=""></div><div class=""><br class=""></div><div class="">This proposal has opened my eyes on a subtle problem with iterators that had not yet bitten me in any language I have used before. Or if it had, I guess just made my code more robust without much second thought.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b><br class=""></div><div class=""><br class=""></div><div class="">The best I could to expose my points :-)</div><div class=""><br class=""></div><div class="">Gwendal Roué</div><div class=""><br class=""></div></body></html>