Implement advance_by, advance_back_by for slice::{Iter, IterMut}

[timvermeulen]

Part of #77404.

Would be nice if we can get away with getting rid of nth[_back] altogether, but if not, we can keep nth and advance_by alongside each other.

Also see #76909 (comment).

cc @ecstatic-morse @scottmcm

[rust-highfive]

r? @withoutboats

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

[ecstatic-morse]

@bors try
@rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 3f22d0d with merge e64db831273cd38b9834dbdc2be0b6dd02f22f70...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: e64db831273cd38b9834dbdc2be0b6dd02f22f70 (e64db831273cd38b9834dbdc2be0b6dd02f22f70)

[rust-timer]

Queued e64db831273cd38b9834dbdc2be0b6dd02f22f70 with parent 98edd1f, future comparison URL.

[scottmcm]

We'll see what perf says, but honestly I'd recommend leaving the specific nth -- on normal user iterators it would be fine to just have advance_by, but slice iterators tend to implement all of them rather leaving it to the optimizer (to fold the checks between advance_by+next, for example) because they're used so pervasively that making LLVM's life easier helps compile times.

[rust-timer]

Finished benchmarking try commit (e64db831273cd38b9834dbdc2be0b6dd02f22f70): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[timvermeulen]

@scottmcm I'm totally happy to have it either way, I know how picky slice::Iter can be. Right now I don't really have a reason to assume that advance_by followed by a next is less efficient in any way than the current nth implementation, which kind of does both? I could try adding some benchmarks to see if I can get them to perform differently.

[crlf0710]

Triage: What's the status on this?

[JohnCSimon]

@timvermeulen Ping from Triage: What's the status on this?

[Dylan-DPC-zz]

r? @KodrAus

[Dylan-DPC-zz]

r? @m-ou-se

[m-ou-se]

I'm totally happy to have it either way, I know how picky slice::Iter can be. Right now I don't really have a reason to assume that advance_by followed by a next is less efficient in any way than the current nth implementation, which kind of does both? I could try adding some benchmarks to see if I can get them to perform differently.

Adding an implementation for advance_by is fine, but removing the nth implementation to use the default advance_by + next needs a bit more convincing, since this is a very important iterator. Does it result in the same assembly? Is the performance the same as before?

(Or if you change the PR to only add advance_[back_]_by: r=me.)

[JohnCSimon]

@timvermeulen Ping again from Triage: Can you please post the status on this?

[JohnCSimon]

I'm closing this as inactive. If you like, you can reopen this MR and continue.