Stabilize the partition_point feature

[VillSnow]

Stabilize the partition_point feature.
Tracking Issue: #73831
First PR: #73577

[rust-highfive]

r? @dtolnay

(rust-highfive has picked a reviewer for you, use r? to override)

[dtolnay]

@rust-lang/libs
@rfcbot fcp merge

This method finds the start of the range of elements where pred=false, assuming all elements for which pred=true come before all elements for which pred=false, via binary search.

impl<T> [T] {
    pub fn partition_point<P>(&self, pred: P) -> usize
    where
        P: FnMut(&T) -> bool;
}

This is a special case of binary_search_by, but reasonably common and not all that clear expressed using binary_search_by.

slice.partition_point(pred)

// equivalent to
slice.binary_search_by(|x| if pred(x) { Less } else { Greater }).unwrap_err()

The polarity choice for whether false or true elements go first is consistent with the stable Iterator::partition (https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.partition), with STL's std::partition_point in C++ (https://en.cppreference.com/w/cpp/algorithm/partition_point), and with the unstable Iterator::is_partitioned (#62544, https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.is_partitioned).

[m-ou-se]

We recently decided to do FCPs on the tracking issue instead of a stabilization PR if possible, to avoid splitting the discussion to two places. (Our new library tracking issue template reflects this.) There's valuable information in the discussion on the tracking issue, and it'd be good to keep that together with any discussion that follows now we're going for stabilization. So I'm moving the FCP to that issue, and close this for now. Please feel free to re-open this PR once stabilization is decided upon in the tracking issue. Thanks!

@rfcbot cancel

[rfcbot]

@m-ou-se proposal cancelled.

[m-ou-se]

@VillSnow Sorry for the confusion about the library stabilization process. The new info is in the new tracking issue template, but we should really fix the documentation too. ^^'

[matklad]

Yay, FCP on the tracking issue completed, this can be reopened. I think we also want to change 1.51 to 1.52 here, as the next release is almost here.

[m-ou-se]

Yay, FCP on the tracking issue completed, this can be reopened. I think we also want to change 1.51 to 1.52 here, as the next release is almost here.

Yup, the version bump to 1.52 already happened last week: https://github.com/rust-lang/rust/blob/master/src/version

[m-ou-se]

@VillSnow Can you rebase/squash the commits? We generally try to avoid merge commits on branches/PRs.

[VillSnow]

@VillSnow Can you rebase/squash the commits? We generally try to avoid merge commits on branches/PRs.

Can I push --force? I made a new branch after rebase and pushed it. I'll feel easy if someone review it before push --force.

[m-ou-se]

Yes, git push --force is fine :)

Can you also squash the commits?

[VillSnow]

Can you also squash the commits?

Is it means six commits 'stabilize partition_points' to 'update feature gate' into single commit like 'stabilize partition_points' ?
or two commits 'update documents' and 'stabilize partition_points' ?

[m-ou-se]

Both are fine. Whatever you prefer :)

[matklad]

based on #73831 (comment)

@bors r+

[bors]

📌 Commit afdc8c7 has been approved by matklad