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

[Kevin Ballard]

On Thu, Apr 28, 2016, at 11:12 AM, Chris Lattner via swift-evolution wrote:
> Hello Swift community,
> 
> 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
> 
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
> 
> 	https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
> 
> 	* What is your evaluation of the proposal?

I was originally strongly -1 on this (as can be seen from my previous messages on this ML about this topic), both for the reasons that Gwendal Roué wrote as well as my belief that the vast majority of users never even write code that hits this case at all and my own experience in that it's actually more common for me as an author of a custom Iterator to have to worry about meeting this guarantee than it is for anyone using my Iterator to rely on the behavior.

However, if there really is a 25% speedup on UTF-8 decoding for ASCII input, that's a pretty significant point in favor of the change. I saw the gist that was used to come up with this 25% number. But I do have to ask, does the 25% increase still hold when talking about String.UTF8View, or is that significant speedup only shown when using the UTF8 type to transcode? And similarly, what's the effect on performance for non-ASCII input?

Similarly, do we have any numbers for the effect on performance for a custom Iterator that now has to track state which it otherwise wouldn't? TakeWhileIterator would be a good candidate for testing, except it hasn't been implemented yet (though it shouldn't be hard to whip up a sample implementation for that).

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

Yes. The current defined behavior is pretty much the worst of all options since it encourages library authors to deliberately crash, and yet no stdlib type actually does crash, so it makes it easy to write code that works for stdlib iterators but will fail when given a third-party iterator.

> 	* Does this proposal fit well with the feel and direction of Swift?

Yes.

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

Rust's equivalent Iterator type is defined such that after a previous call to next() has returned None, Iterators are allowed to return either None or Some(Item) from subsequent calls to next() (but shouldn't crash). And Rust has a FuseIterator (and a corresponding .fuse() method). This matches the first alternative in the proposal. And with this approach, it's true that it's extremely rare for people to call .fuse() (but this just demonstrates that very few people write code where post-nil behavior matters), but it does simplify many Iterator implementations, and AFAIK nobody's complained about this behavior.

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

An in-depth study.

-Kevin Ballard