Tracking Issue for `cmp_splat` (Variadic `min` and `max`)

Feature gate: #![feature(cmp_splat)]
Zulip: #t-libs-api/api-changes > variadic min/max

This is a tracking issue for variadic cmp::min and cmp::max functions. Currently, these are separate functions named smallest and largest. To allow variadic support, #![feature(splat)] is enabled in core. See rust-lang/rust#153629 for further details.

Public API

// core::cmp

// Private implementation detail
impl(self) const trait TupleReduce: Tuple {
    type Item;
    fn reduce<F: [const] Destruct + [const] FnMut(Self::Item, Self::Item) -> Self::Item>(self, f: F) -> Self::Item;
}

impl<T> TupleReduce for (T, ...) { /* ... */ }

#[must_use]
pub const fn smallest<T: [const] Ord + [const] Destruct>(
    #[rustc_splat] vals: impl [const] TupleReduce<Item = T>,
) -> T;

#[must_use]
pub const fn largest<T: [const] Ord + [const] Destruct>(
    #[rustc_splat] vals: impl [const] TupleReduce<Item = T>,
) -> T;

Note that with #[rustc_splat], the signature of smallest and largest is any of fn(T) -> T through to fn(T, T, ..) -> T (up to twelve arguments). Twelve has been chosen as an arbitrary limit and can be changed.

Steps / History

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

• ACP: rust-lang/libs-team#848
• Implementation: #160687
• Final comment period (FCP)^1
• Stabilization PR

Unresolved Questions

• Should we replace min and max (and their _by(_key) alternatives), or offer these new functions under a separate name?

Start with the core::cmp public API and the checked implementation entry in #160687, then review the linked Zulip discussion and the unresolved naming question. Done means resolving the API choice, completing the final comment period, and opening a stabilization PR.