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

[timvermeulen]

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?

[rust-highfive]

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:05e0c770:start=1559476913973595770,finish=1559476915977649711,duration=2004053941
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:04:42] tidy error: /checkout/src/libcore/tests/iter.rs:903: trailing whitespace
[00:04:47] some tidy checks failed
[00:04:47] 
[00:04:47] 
[00:04:47] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:47] 
[00:04:47] 
[00:04:47] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:47] Build completed unsuccessfully in 0:01:14
---
travis_time:end:0015c48c:start=1559477216064562327,finish=1559477216069687930,duration=5125603
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:36606ce6
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:007a8730
travis_time:start:007a8730
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:02421694
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[kennytm]

An impl is unfortunately insta-stable.

[kennytm]

r? @scottmcm

[scottmcm]

If Peekable is going to be DEI, then should it have a peek_back() too? But that has space cost, which might be why it wasn't already double-ended?

[timvermeulen]

Yeah, that may be why this implementation was missing, but I don't think it needs to have a peek_back() method for it to be useful as a DEI. If anyone needs to be able to peek from both sides, a separate type would probably make more sense because of the memory implications you mentioned.

The only surprising thing about it being a DEI would perhaps be that nth_back can't be implemented efficiently.

[scottmcm]

Is there anything in particular that I should probably also test?

Your tryfolds look pretty good, but because I've seen so many with short-circuiting issues, could you add some very blatant short-circuit-every-step tests? For example,

    let mut it = (2..20).take(3);
    assert_eq!(it.try_for_each(Err), Err(2));
    assert_eq!(it.try_for_each(Err), Err(3));
    assert_eq!(it.try_for_each(Err), Err(4));
    assert_eq!(it.try_for_each(Err), Ok(()));

    let mut it = (2..20).take(3).rev();
    assert_eq!(it.try_for_each(Err), Err(4));
    assert_eq!(it.try_for_each(Err), Err(3));
    assert_eq!(it.try_for_each(Err), Err(2));
    assert_eq!(it.try_for_each(Err), Ok(()));

(Basically the same as the .next()-repeatedly tests, just spelling .next() as .try_for_each(Err).err() and .next_back() as .try_rfold((), |_, x| Err(x)).err() 🙂)

[timvermeulen]

@scottmcm Good idea, something like this?

[ollie27]

Couldn't this multiplication and addition overflow?

[timvermeulen]

Ah, I naively assumed that n would be in-bounds here. Thanks!

[scottmcm]

Nominating to see if libs in interested in these.

[alexcrichton]

Sorry for the delay on the libs side of things, but the libs team discussed this today and is ok adding these impls, so feel free to r+ when ready @scottmcm!

[scottmcm]

@alexcrichton Doesn't this need an FCP because it's adding insta-stable impls?

[alexcrichton]

Sure, can go through that as well!

@rfcbot fcp merge

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @Kimundi
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Centril]

ping @withoutboats @SimonSapin @Kimundi

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

(r=me when the FCP completes in a week)

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[Centril]

@bors r=scottmcm rollup

[bors]

📌 Commit 56ebfb1 has been approved by scottmcm