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

[Brent Royal-Gordon]

> 	* 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