Add a range argument to vec.extract_if

[the8472]

tracking issue: #43244

This adds the range argument requested in #43244 (comment)

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

Maybe change one of the first few 0s to 1 to indicate they don't get extracted (out of range)?

[the8472]

Hrm, I wanted to show the "I have a prefix that I know doesn't contain those things, so I can skip them" use.

[cuviper]

LGTM.

The FCP finished -- do you want to go ahead and add the stabilization too?

[tgross35]

r? @cuviper (sorry, I didn't realize this was assigned to me)

The FCP finished -- do you want to go ahead and add the stabilization too?

Since this is a pretty significant API and implementation change, maybe it would be good to hold off for a couple of weeks? In case anyone using this API unstably has feedback after the change (I doubt it, but doesn't hurt).

[the8472]

Changing and stabilizing in the same PR doesn't seem ideal to me either, especially when the change happened parallel to the FCP. I think it should bake a few days at least.

[cuviper]

@bors r+

[bors]

📌 Commit 414acda has been approved by cuviper

It is now in the queue for this repository.

[the8472]

Indeed, fixed.

@bors r=cuviper

[bors]

📌 Commit 44790c4 has been approved by cuviper

It is now in the queue for this repository.

[nk9]

I hope this is the right place to raise this question about the sample code in this PR.

[nk9]

Apologies for the late comment, but I wanted to point out that this sample code doesn't behave the same way as the real extract_if(). 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. Proposed change to the sample code:

    let some_predicate = |x: &mut i32| { *x == 2 || *x == 3 || *x == 5 };
    let mut vec = vec![0, 1, 2, 3, 4, 5, 6];
    let range = 1..5;
    let mut i = range.start;
    let mut end = range.end;
    while i < min(vec.len(), end) {
        if some_predicate(&mut vec[i]) {
            let _val = vec.remove(i);
            end -= 1;
            // your code here
        } else {
            i += 1;
        }
    }

    assert_eq!(vec, vec![0, 1, 4, 5, 6]);

[the8472]

If you want to propose a documentation improvement you can just open a PR.