Add PeekableIterator
trait by bluebear94 · Pull Request #132976 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Adds the PeekableIterator
trait (tracking issue: #132973) and implementations for slice::Iter
and ops::Range
.
I tried to implement it for Cloned
, but I couldn’t get the types and lifetimes to line up, so the unit test at library/core/tests/iter/traits/peekable.rs
is not yet compilable.
r? @scottmcm
rustbot has assigned @scottmcm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r?
to explicitly pick a reviewer
rustbot added S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
scottmcm added S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Since you said this isn't compilable, I've marked it waiting on author. Please flip it back once it's ready for a review.
Note that if you're having trouble with any particular impl
, I'd suggest just skipping it for now. Additional impls can always come later in future PRs; they don't need to be in the first one.
Do you think it would be better to remove the trait bound from the PeekedItem
associated type altogether?
Looks like this needs some conflicts resolved, at least?
Once this is ready for review, please use @rustbot ready
so the bot will update the labels appropriately to bring it back to my radar.
Sorry, I haven’t had the motivation to work on this for a long time. I think this needs more thinking on design.
Labels
Status: This is awaiting some action (such as code changes or more information) from the author.
Relevant to the library team, which will review and decide on the PR/issue.