Add custom nth_back for Chain

[acrrd]

Implementation of nth_back for Chain.
Part of #54054

[rust-highfive]

r? @withoutboats

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

[acrrd]

r? @scottmcm

[koalatux]

Nice! Is it possible with the current state of default impl to also have a more specific implementation, where B also implements ExactSizeIterator?

[acrrd]

What is the best way to test both implementations?

[Dylan-DPC-zz]

ping from triage @scottmcm waiting for your review on this

[timvermeulen]

You're not mutating self.b in any way when n >= self.b.len() in the specialized version, so if the state is ChainState::Back, I don't think calling nth_back with a too large value will actually empty the iterator (even though it will return None). I haven't tested it, but I think this will fail:

let mut iter = std::iter::empty().chain(vec![0, 0]);
iter.next();        // to change the state to ChainState::Back
iter.nth_back(100); // to empty the iterator
assert_eq!(iter.next(), None);

I think you'll need to call self.b.nth_back(n) regardless of the length of b.

[acrrd]

@timvermeulen I added tests for that and fixed the specialization. Thanks!

[jonas-schievink]

Ping from triage, still waiting on your review @scottmcm

(or someone else from @rust-lang/libs)

[scottmcm]

This is introducing a default fn on an Iterator impl that's not there in the analogous forward implementation of the method, so I'd like someone from libs to take this. *rolls dice*

r? @Kimundi

[timvermeulen]

Presumably there could also be a specialized nth when A: ExactSizeIterator?

[acrrd]

What could be the problem in not having nth also be specialized for ExactSizeIterator?

[totsteps]

ping from triage, @Kimundi @Centril any updates on this?

[fmckeogh]

Second ping from wg-triage, pinging random member of T-libs per procedure.

@SimonSapin

[Dylan-DPC-zz]

r? @SimonSapin

[SimonSapin]

Per discussion in #62483 (comment) it’s not clear that we want to use specialization in public trait (as opposed to a private trait that only optimize an implementation detail) while specialization itself is still unstable, or at least while it has significant design issue still open.

CC @alexcrichton

[alexcrichton]

I'm personally not the biggest fan of so aggressively using specialization myself, but at a bare minimum the general convention we've had (or so I think) is that all specialization is done internally in the standard library and no public-facing function is listed as default

[JohnCSimon]

Ping from triage @acrrd @SimonSapin
Hi! This has sat idle for awhile. Is this close to being resolved?

[acrrd]

After the comment of @SimonSapin and @alexcrichton I removed the specialization

[SimonSapin]

@bors r+

[bors]

📌 Commit 7b6ad60 has been approved by SimonSapin