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
peeking_next(&mut self, accept: impl FnOnce(..) ->bool) can be implemented in terms of peek(&mut self) -> Option<&Item> and next. Conversely, peek can be implemented in terms of peeking_next. So, they are equivalent.
However, peeking_next is a more complicated API. So IMO ideally,
The trait's required method ought to be peek. (This has a name clash with std::iter::Peekable::peek, but I think that's OK because the inherent method will take priority when the type is just Peekable.)
peeking_next ought to be a provioded method.
Probably, then, the name is then wrong. Peek seems like it would be right.
These would be breaking changes, but I think implementations of PeekingNext are going to be tolerably rare, and the fix will be obvious. The key thing will be to avoid breaking all trait bounds. I suggest, in a maor revision,
Abolish PeekingNext and replace it with Peek, with peek as required method and peeking_next as provided.
Additionally export Peek as PeekingNext with a #[deprecated].
Put appropriate notes in the docs about the migration.
I think the effect is that:
Downstreams that don't impl PeekingNext will see no actual break, although they'll see a new deprecation warning.
Downstreams that impl PeekingNext will get an error saying "you need to implement the required method peek". Turning an implementation of peeking_next into an implementation of peek will almost always be easy, just deleting code. Alternatively, the downstream could just add fn peek(&mut self) -> ... { itertools::impl_peek_via_peeking_next..., if we chose to provide it.
This should probably be done at the same time as #678, which becomes impl Peek for &mut Peek.
The text was updated successfully, but these errors were encountered:
peeking_next(&mut self, accept: impl FnOnce(..) ->bool)
can be implemented in terms ofpeek(&mut self) -> Option<&Item>
andnext
. Conversely,peek
can be implemented in terms ofpeeking_next
. So, they are equivalent.However,
peeking_next
is a more complicated API. So IMO ideally,peek
. (This has a name clash withstd::iter::Peekable::peek
, but I think that's OK because the inherent method will take priority when the type is justPeekable
.)peeking_next
ought to be a provioded method.Peek
seems like it would be right.These would be breaking changes, but I think implementations of
PeekingNext
are going to be tolerably rare, and the fix will be obvious. The key thing will be to avoid breaking all trait bounds. I suggest, in a maor revision,PeekingNext
and replace it withPeek
, withpeek
as required method andpeeking_next
as provided.Peek
asPeekingNext
with a#[deprecated]
.#[deprecated] pub fn impl_peek_via_peeking_next(self_: &mut impl Peek, accept: ...) -> ...
I think the effect is that:
impl PeekingNext
will see no actual break, although they'll see a new deprecation warning.impl PeekingNext
will get an error saying "you need to implement the required methodpeek
". Turning an implementation ofpeeking_next
into an implementation ofpeek
will almost always be easy, just deleting code. Alternatively, the downstream could just addfn peek(&mut self) -> ... { itertools::impl_peek_via_peeking_next...
, if we chose to provide it.This should probably be done at the same time as #678, which becomes
impl Peek for &mut Peek
.The text was updated successfully, but these errors were encountered: