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

[Patrick Pijnappel]

Thanks for the feedback! Some comments:

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.


To some degree true, but I'd argue the current guarantee is significantly
more obscure than the proposed alternative:
- All standard library iterators return nil indefinitely.
- Iterators return nil if they're exhausted, i.e. no next element exists.
If I call next() again, it is still exhausted, still no next element
exists, so you'd probably expect it to return nil again.

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.


IteratorProtocol does explicitly describe itself as iterating over a
sequence though:
/// A type that supplies the values of a sequence one at a time.
I'm not sure IteratorProtocol 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.

On Fri, Apr 29, 2016 at 2:40 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> >       * What is your evaluation of the proposal?
>
> I think it's a good idea.
>
> 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.
>
> 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.
>
> 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.
>
> >       * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> Yes.
>
> >       * Does this proposal fit well with the feel and direction of Swift?
>
> I think so. One of the major themes of Swift 3 is cleaning up the standard
> library.
>
> >       * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> 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.
>
> >       * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> Quick reading this time, but I participated the previous discussion.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160501/fd11452e/attachment.html>