Specialize StepBy::nth

[oberien]

This allows optimizations of implementations of the inner iterator's .nth method.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Kimundi (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[scottmcm]

Good change! ❤️

I think that this needs to handle overflow in the multiplication, though, since I could write (0u64..).step_by(0x10000).nth(0x10000) on a 32-bit machine, for example.

Also, tests?

[oberien]

Tests are a good call, I found 2 off-by-ones while implementing them.

I added overflow behaviour, but it is pretty weighty. While I think that it shouldn't influence normal execution due to intrinsics::likely and branch prediction, I do think that it is pretty complicated code, which doesn't really add too much value. Anyway, now that it exists, I don't mind keeping it :)

[varkor]

Nit: space before }.

[shepmaster]

Thanks @oberien ! We'll make sure to get you a first-class review from @Kimundi or another team member soon!

[kennytm]

Review ping for you @Kimundi!

[kennytm]

Since @Kimundi haven't left any comment here, reassigning to another @rust-lang/libs team member.

r? @dtolnay

[dtolnay]

Thanks!

[dtolnay]

@bors r+

[bors]

📌 Commit 4a0da4c has been approved by dtolnay

[bvinc]

I know I'm late. But does anyone else think that this function is rather large to be marked inline?

[scottmcm]

@bvinc Well, it's on a generic impl, so it'll be an inlining candidate regardless. And that's good in general, since you really want .step_by(2).nth(4) to inline and const fold.

That said, it might be interesting to split out the overflow handling into a separate function, to make it easier for LLVM to inline the short easy normal path without the hard part.