[swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee
brent at architechies.com
Fri Apr 29 07:40:24 CDT 2016
> * 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?
> * 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.
More information about the swift-evolution