Correct extract_if sample equivalent.

[nk9]

Tracking issue: #43244

Original PR: #133265

The sample code marked as equivalent in the doc comment isn't currently equivalent. Given the same predicate and range, if your vector were [1, 2, 3, 3, 3, 3, 3, 3, 4, 5, 6], then all of the 3s would be removed. i is only incremented when an element is dropped, but range.end is unchanged, so the items shift down. I got very confused when reading the docs and trying to square this sample code with the explanation of how the function works.

Fortunately, the real extract_if() does not have this problem. I've added an end variable to align the behavior. I've also taken the opportunity to simplify the predicate, which now just matches odd numbers, and to pad out the vec of numbers to line up the zero-indexed range with the integers in the vec.

r? the8472

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @the8472 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue