Another small problem is that not immediately dropping the first element of a
on the last call to .next()
would make a small but observable change to the behavior of Zip
.
A bigger problem is the DoubleEndedIterator
implementation. Currently if you zip two DoubleEndedIterator + ExactSizeIterator
iterators then the resulting Zip
also supports DoubleEndedIterator
operation such as next_back()
. For this, the implementation does—on the first call to next_back
—first trim the longer iterator so that they both have the same length, with the goal that the iterators are still, logically, being “zipped from the front” (i.e. you really get the same list of values, just backwards [as well as reversed side-effects]). The problem is: An iterator does (in general) not allow you to just “leave” the last n
elements alone and save them for later. The only way in which the rest/remainder of Zip
could be kept after a call to next_back
is by storing them in a new Vec
or something; while caching a single element is reasonable, doing a whole potentially large allocation “just-in-case-it’s-needed” for an uncommon use-case seems very unreasonable.
Possible solutions include panicking or otherwise failing on calling a potential rest
/remainder
method in case next_back
was called. Maybe the more reasonable approach is to just introduce an alternative to zip
that offers such a rest
method (and doesn’t implement DoubleEndedIterator
) and maybe do this only in a third-party-crate.