Skip to content

Tracking Issue for PeekableIterator #132973

@bluebear94

Description

@bluebear94

Feature gate: #![feature(peekable_iterator)]

This is a tracking issue for the PeekableIterator trait, which extends Iterator with peek_with and related methods that inspect the next element without consuming it.

Public API

// core::iter

pub trait PeekableIterator: Iterator {
  // required method
  fn peek_with<T>(&mut self, func: impl for<'a> FnOnce(Option<&'a Self::Item>) -> T) -> T;

  // provided methods
  fn peek_map<T>(&mut self, func: impl for<'a> FnOnce(&'a Self::Item) -> T) -> Option<T>;
  fn next_if(&mut self, func: impl FnOnce(&Self::Item) -> bool) -> Option<Self::Item>;
  fn next_if_eq<T>(&mut self, expected: &T) -> Option<Self::Item>
  where
    Self::Item: PartialEq<T>,
    T: ?Sized;
}

Steps / History

Unresolved Questions

  • Should peek take &mut self or &self? &self makes sense for iterators such as core::slice::iter but precludes implementing the trait on Peekable.
  • What about the return type of peek? We could always make it return Self::Item like itertools’s PeekingNext, but that would prevent this trait from being implemented for consuming iterators such as vec::IntoIter, as well as Peekable itself. Resolved by having the method take a callback.
    • If we use an associated type, then what should be the bound for it: Borrow, AsRef, or something else?

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions