Rewinding iterators
There is no good reason indeed. Worse, there is no way to enforce it on user-generated iterators, so it'd be dangerous for standard iterator consumers to assume such a property.
This mention should probably be removed altogether. Filed ecmascript#2606
Thanks for filing that! Now I also know where to file bugs, so doubly
see ecmascript#2003 which was the original issue that motivated the currently spec'ed behavior.
Thanks Allen! When reading the issue, I can't quite make out what the reasoning is for setting this constraint on the iterator protocol. Locking down the behavior of Map/Set/Array iterators is fine I suppose (although I'd argue against the permanently closed behavior) but I reckon it seems a bit overkill to specify that custom iterators must have the same behavior. It seems arbitrary, but perhaps more importantly I'm not sure how engines should enforce this behavior or why this added complexity is necessary. If engines don't enforce it, then this language doesn't really matter much for the general iterator protocol anyway. I'm also very open to the possibility that I've misunderstood the whole thing.
Much obliged to for your feedback!
No enforcement is required by the specification. If you create an iterator that doesn't fully conform to the iterator interface specification and then get surprising results, its your fault, not the implementation's.
It would be worthwhile to state that iterators returned by 'built-in' functions always have the "no zombies" property (once done, stays done), even though that can't be enforced on user-supplied iterators. "Be generous in what you accept, rigorous in what you emit."
I don't think I'm making my case very clear, my apologies. Hopefully, I'll be able to clarify in this message.
No enforcement is required by the specification. If you create an iterator that doesn't fully conform to the iterator interface specification and then get surprising results, its your fault, not the implementation's.
This is the very point I'm trying to make: the spec uses language such as
"must" when declaring how iterators should behave, yet an implementation
isn't as you say required to enforce such behavior. In this case, I am
getting "surprising results" because the spec seems to say that the way
I've implemented the iterators above is flat out wrong; yet, the code runs
just fine and sugar such as for..of is working just as it would with a
fully conforming iterator. If it quacks like a duck..
I might be reaching, but I do think the language is confusing. If the intent is to convey a practice or precedence set by the built in iterators, then perhaps it's better to make this explicit or use words such as "recommended" instead of "must". Perhaps I'm bike shedding, in which case I apologize. I hope I've made my point clearer any way.
Ps. I like what Scott's saying, which I think is pretty much what I'm trying to say as well, albeit I'm doing a poorer job at it.
There's nothing wrong with authoring conformance requirements using MUST, but if it's unclear that they're for the author, that's a bug to be fixed in the spec language.
But as others have said, I don't see why this is an authoring conformance criteria at all. It's reasonable for the spec to state that all the built-in iterators are well-behaved in this respect, and to recommend that author-defined iterators are well-behaved as well (unless they have some behavior like rewindability), but requiring it as conformance criteria seems incorrect (because of the rewindability thing).
In section 25.1.2 of the spec it says:
Are there any practical reasons why the Iterator interface explicitly disallows this?
It means that, if you care for conformity, you couldn't do something like have iterators be rewindable gist.github.com/mstade/10012898 or auto-rewinding iterators gist.github.com/mstade/10012933, or any other kind of iterator that might want to change its state after running it's course once. This also means, again if you care for conformity, that you have to keep making new iterator instances. Unless engines start to actively enforce this, it seems a bit pointless to be that strict.