https://doc.rust-lang.org/src/alloc/slice.rs.html#268-270
https://doc.rust-lang.org/src/core/cmp.rs.html#1034
pub fn sort(&mut self)
where
T: Ord,
{
merge_sort(self, |a, b| a.lt(b));
}
fn lt(&self, other: &Rhs) -> bool {
matches!(self.partial_cmp(other), Some(Less))
}
It uses lt() inside the merge_sort(). If partial_cmp() returns None then lt() returns Less.
So, it seems like PartialOrd is enough for sort().
Both historical and logical reasons.
Back in the days, before impl<T> [T], sort first used cmp() instead of lt(). That changed about 5 years ago for optimization reasons. At that point, the constraint could have been changed from Ord to PartialOrd. And truly, it sparked another discussion about PartialOrd and Ord.
However, there's a logical reason too: for any two indices i and j within [0..values.len()] and i <= j, you expect the following to hold if values has been sorted:
assert!(values[i] <= values[j]);
Note that I said any indices where i <= j. However, with PartialOrd, we can have some value x that's uncompareable to any other value, for example f64::NAN. It's completely unclear where x should be sorted in this case, as both f64::NAN < y and y < f64::NAN yield false for any y, and your expectations have been mislead and your day ruined. To really sort all values, we need all of them to be compareable to the whole domain. But that's exactly Ord.
Now, an implementation could place all incomparable values at the end of the collection, but that would be an arbitrary decision which might yield surprising results. But instead of using some seemingly random approach in sort, the Rust standard library provides sort_by to enable you to decide:
values.sort_by(|a, b| a.partial_cmp(b).unwrap());
This is now an explicit choice. And as the Python Zen says: "Explicit is better than implicit."