You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the Peekable adapter, that is to say, at the point of a previous adapter, at least one of the peeked for Peekable and more for PeekingNext (Existing Trait) items will have been consumed.
Existing Extensions
The peeking_take_while (Existing in itertools) and similar take_while_ref (Existing in itertools) consume depending on a predicate with the information from the previewed item (&Self::Item), though take_while_ref isn't technically peeking. For the output of these adapters, they output the owned item (Self::Item) when it has been accepted 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.
maping with information from or computed with the previewed item (&Self::Item).
After playing around with a peeking_map() with subsequent adapters, I found that subsequent adapters would require the burden of maintaining the knowledge of whether a value was taken or not, which may vary depending on Output. It could probably be made nicer with a try_next() but that would introduce branches for all the subsequent adapters.
The only real way to manage actual short-circuiting that I can see would be within a single code block. So regarding iterators that would be the try_fold.
However, there are a handful of issues with the current peeking_fold_while:
It doesn't use the experimental std::ops::Try which would allow for non-eronious short-circuiting, though this is just for readability.
It restricts the implementation for PutBack<I> by unnecessarily constraining it to an immutable reference, where the owned value could be necessary for some.
With only a reference, a fold may not be able to be completed only validated, It could need the owned value and the implementation for Peekable<I> currently discards this.
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: