-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better documentation for Iter::zip behavior #52279
Comments
In this case, I would even day that the documentation is misleading. |
This was addressed in #50719, which will hit stable Rust on August 2nd. https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.zip https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip |
That's close, but I'd propose a further change, to emphasize that zip always does |
Opened a pull request for this: #52477 |
…xcrichton Clarify short-circuiting behvaior of Iterator::zip. Fixes rust-lang#52279.
…ntee, r=dtolnay Weaken guarantee around advancing underlying iterators in zip The current guarantee (introduced in rust-lang#52279) is too strong as it prevents adapters from exploiting knowledge about the iterator length and using counted loops for example because they would stop calling `next()` before it ever returned `None`. Additionally several nested zip iterators already fail to uphold this. This does not yet remove any of the specialization code that tries (and sometimes fails) to uphold the guarantee for `next()` because removing it would also affect `next_back()` in more surprising ways. The intent is to be able to remove for example this branch https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/src/iter/adapters/zip.rs#L234-L243 or this test https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/tests/iter/adapters/zip.rs#L177-L188 Solves rust-lang#82303 by declaring it a non-issue.
…ntee, r=dtolnay Weaken guarantee around advancing underlying iterators in zip The current guarantee (introduced in rust-lang#52279) is too strong as it prevents adapters from exploiting knowledge about the iterator length and using counted loops for example because they would stop calling `next()` before it ever returned `None`. Additionally several nested zip iterators already fail to uphold this. This does not yet remove any of the specialization code that tries (and sometimes fails) to uphold the guarantee for `next()` because removing it would also affect `next_back()` in more surprising ways. The intent is to be able to remove for example this branch https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/src/iter/adapters/zip.rs#L234-L243 or this test https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/tests/iter/adapters/zip.rs#L177-L188 Solves rust-lang#82303 by declaring it a non-issue.
In particular, we should specify and document what exactly zip does when its first child terminates. Currently, as soon as
self.a.next()
returns None, it short-circuits execution without callingself.b.next()
. This could lead to some potential surprising behavior:To be clear, I'm not saying this behavior is bad; just that it should be more explicitly documented. This will allow developers to more confidently build abstractions on top of Zip, knowing exactly what it does with the underlying iterator.
The text was updated successfully, but these errors were encountered: