Tracking Issue for clamp_min and clamp_max

[Kyuuhachi]

Feature gate: #![feature(clamp_min_max)]

This is a tracking issue for rust-lang/libs-team#665, which adds less confusable alternatives for x.min(y) and x.max(y).

Public API

pub trait Ord: PartialOrd {
    ...
    fn clamp_min(self, other: Self) -> Self { self.max(other) }
    fn clamp_max(self, other: Self) -> Self { self.min(other) }
}

// and likewise in f16, f32, f64, and f128

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: ACP: Intuitive alternative for .min() and .max() libs-team#665
• Implementation: Implement clamp_min and clamp_max #147786
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Is having these functions, where clamp_min == max, actually less confusing than the status quo?
• Should there be a lint that suggests replacing x.max(y) with x.clamp_min(y), and T::clamp_max(x, y) with T::min(x, y)?
• What semantics should the float versions have regarding NaN? NAN.max(0.0) is 0, while NAN.clamp(0.0, 0.0) is NaN.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Kyuuhachi]

I'm adding NaN semantics to unresolved questions. Current implementation has same as .max(), but it would also make sense to have the same semantics as .clamp().

[ChrisDenton]

On the original zulip thread, simulacrum suggested naming these at_most and at_least, which would avoid the slightly confusing naming where clamp_max does the opposite to max.