-
Notifications
You must be signed in to change notification settings - Fork 309
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
Peekable
Adapters: peeking_take_while
, peek_map
, peeking_fold_while
and try_
#979
Comments
After playing around with a However, there are a handful of issues with the current
|
I would like to add My use case: finding the last item smaller then x and the first item larger then x such that I can generate an interpolated item. With data.iter()
.peekable()
.peeking_skip_while(|(x, _)| *x < pos)
.next_tuple() // yields x1, x2 where x1 < x > x2
.ok_or(TooInaccurate)
.inspect(|v| eprintln!("v: {v:?}, pos: {pos}"))
.map(|((a, ay), (b, by))| if pos - a < b - pos { (a, ay) } else { (b, by) })
.and_then(|(x, y)| {
if (pos - x).abs() <= max_deviation {
Ok(*y)
} else {
Err(TooInaccurate)
}
}) |
Note: I am primarily seeking feedback rather than proposing at this stage.
Peekable
As I see it
peekable
(Existing in std) facilitates two concepts, the ability to preview an item in an iterator and to optionally consume said item. Though it's not a limitation, consumption typically occurs after and/or with some information from a previewed item (&Self::Item
). It is also notable that these only hold true at the point of thePeekable
adapter, that is to say, at the point of a previous adapter, at least one of thepeek
ed forPeekable
and more forPeekingNext
(Existing Trait) items will have been consumed.Existing Extensions
The
peeking_take_while
(Existing in itertools) and similartake_while_ref
(Existing in itertools) consume depending on a predicate with the information from the previewed item (&Self::Item
), thoughtake_while_ref
isn't technically peeking. For the output of these adapters, they output the owned item (Self::Item
) when it has beenaccept
ed via the predicate otherwise none. Generally, the iterator will continue not to output items, as the predicate is fixed at the creation of the iterator, unless interior mutability is used.Remaining Problem Space
As I see it, the problem space doesn't have good solutions for the following (conceptually accumulating) examples.
map
ing with information from or computed with the previewed item (&Self::Item
).accept
ed items remain, liketry_for_each
but withPeekable
.peeking_take_while
adapter can only be reused when you don't need any of the unaccept
ed items.peekable
once for thepeeking_take_while
adapter and again for the following.peek()
.Potential Peekable Adapters
With this in mind, the most general solution for the entire problem space might look something like the following:
with the above examples then looking like this:
and the
peeking_take_while
could then be emulated by this:Related sources
peekable
(Existing in std)PeekingNext
(Existing Trait)peek_map
peeking_fold_while
peeking_take_while
(Existing in itertools)take_while_ref
(Existing in itertools)hacked together compile only implimentation
The text was updated successfully, but these errors were encountered: