[swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

[Gwendal Roué]

> The review of "SE-0052: Change IteratorType post-nil guarantee" begins now and runs through May 3. The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md


• What is your evaluation of the proposal?

I'm -1.

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.

I agree as well that the precondition that when calling next(), no preceding call to next() should have returned nil is not observed enough.

I agree that algorithms need guarantees and API contracts.

Yet I have three arguments against the proposal:

1. Obscurity argument: 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.

2. Social argument: 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.

3. Iterator autonomy argument : 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.

I'd thus remove the existing precondition, and support the following alternatives:

- the FuseIterator Patrick's proposal (and we could discuss its name).
- a new StoppingIterator protocol which does explicitly provide the post-nil guarantee. Algorithms could then use this guarantee.


• Is the problem being addressed significant enough to warrant a change to Swift?

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.


• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

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.


• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

The best I could to expose my points :-)

Gwendal Roué

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160429/c0a31720/attachment.html>