Open bluebear94 opened 1 year ago
One method I think would be really nice to have in the standard library is something like peeking_take_while
- a version of take_while
that doesn't consume the first element that doesn't match. Could live on this trait.
I think another motivation is that Peekable
requires stack memory overhead and may not be as performant as impl PeekingIterator for slice::Iter
Sorry if I missed this in prior discussions, but itertools
does have PeekingNext
and peeking_take_while
.
Proposal
Problem statement
Some iterator types can support peeking à la
Peekable
. Sometimes, peeking is required for such an iterator, but methods specific to the original iterator’s type must be called as well. In these cases, creating aPeekable
does not allow doing the latter.Motivation, use-cases
The following code for ps9 is meant to parse a ‘decoration’ object at the start of a word, returning the parsed object as well as the remainder of the string.
Solution sketches
We could add a
Peek: Iterator
trait that would provide the same methods asPeekable
. This trait would be implemented byPeekable
as well as any other iterator that can support peeking operations, such asstd::str::Chars
,std::slice::Iter
, andstd::ops::Range
.This trait could be added to all types that are
Iterator + Clone
, but this would incur unnecessary overhead for types such asstd::vec::IntoIter
which can peek at O(1) time but needs O(n) time to clone.Links and related work
What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.