Document iterator protocol better #8276
Conversation
| /// Resets the fuse such that the next call to .next() or .next_back() will | ||
| /// call the underlying iterator again even if it prevously returned None. | ||
| #[inline] | ||
| fn resetFuse(&mut self) { |
There was a problem hiding this comment.
the should be reset_fuse per the naming conventions
|
I've sent a proposal to the list about this: https://mail.mozilla.org/pipermail/rust-dev/2013-August/005113.html |
|
@kballard , @thestinger - what's the status of this PR? Can it move forward? |
|
I'm still in favor of this approach. I don't know if @thestinger has changed his position at all. It would be nice if other developers would weigh in. |
|
This change is about defining the guarantees and non-guarantees of the iterator protocol, or conversely, the expectations we place on implementations of |
|
Yes. The mail message I linked in my first comment gives an overview of the 3 proposed approaches, and this PR implements the third approach (or more accurately, standardizes it; the current iterators already basically implement approach 3 in an ad-hoc fashion). |
it seems rather controversial to me. Even if the side effects question is not resolved, at the very least the Iterator protocol should expect each iterator to return None indefinitely. |
|
@blake2-ppc Have you read the mail message I linked? This is covered there. But the short version is, I believe that if we guarantee |
|
of course, I don't agree with you on the 2nd case. I share Armin R.'s concerns. |
|
As I said in my reply to Armin R., most clients aren't ever going to touch an iterator after it returns |
|
It does add a certain complexity for iterator uses outside plain for-loops. You'll have to judge each iterator if you know it is "sane" (for example VecIterator) or if you have to use |
|
I feel like we're just re-hashing the ML convo here. Anyway, I just feel it's subtly dangerous to say that an iterator must return Also, declaring this as the behavior all iterators must follow rules out a class of interesting iterators. I posted one to the ML during the conversation, one that allows you to push an element back onto the front of the iterator (but only one). This iterator would allow you to decide that you don't want to handle a particular value yet, push it back, break out of your inner loop, and let the outer loop handle it. Basically equivalent to the |
|
The case of that kind of Peekable is not under this umbrella. If you modify an iterator like that, the iterator protocol guarantees don't apply. Some iterators might even have a I do read the ML, you don't have to repeat it if you don't want to. I did read it and I still didn't/don't agree that there is consensus or that the chosen guarantee is the best, |
Document the fact that the iterator protocol only defines behavior up until the first None is returned. After this point, iterators are free to behave how they wish. Add a new iterator adaptor Fuse<T> that modifies iterators to return None forever if they returned None once.
Python's zip() short-circuits by not even querying its right-hand iterator if the left-hand one is done. Match that behavior here by not calling .next() on the right iterator if the left one returns None.
|
Fixed the test failure. |
Add `msrv` config for `map_clone` Just a small PR to have some fun with Clippy and to clear my head a bit 😅 --- changelog: [`map_clone`]: The suggestion takes `msrv` into account changelog: Track `msrv` attribute for `manual_bits` and `borrow_as_prt` fixes: rust-lang#8276
r? @thestinger