]> git.lizzy.rs Git - rust.git/commit
Rollup merge of #61457 - timvermeulen:double_ended_iters, r=scottmcm
authorMazdak Farrokhzad <twingoow@gmail.com>
Tue, 6 Aug 2019 06:17:31 +0000 (08:17 +0200)
committerGitHub <noreply@github.com>
Tue, 6 Aug 2019 06:17:31 +0000 (08:17 +0200)
commitfe998dbfe496d05dc1536820ab9611bd3281a7f2
tree283463b03e3ba369e849e40423e70db5a9b42cd3
parentc4715198b50d1cdaad44b6e250844362b77dcdd7
parent56ebfb185b2e144d5404eda1fc40b0070a3122f3
Rollup merge of #61457 - timvermeulen:double_ended_iters, r=scottmcm

Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take}

Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it.

I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early.

I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation.

The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
src/libcore/iter/adapters/mod.rs
src/libcore/tests/iter.rs