Tracking Issue for comparing values in const items

[fee1-dead]

Feature gate: #![feature(const_cmp)]

This is a tracking issue for various const PartialEq, PartialOrd, Ord impls in the standard library

Public API

// core::cmp

impl<T: ~const PartialOrd> const PartialOrd for Reverse<T> {}
impl const Ord for Ordering {}
impl const PartialOrd for Ordering {}
impl const PartialEq for Ordering {}
pub const fn min<T: ~const Ord + ~const Drop>(v1: T, v2: T) -> T;
pub const fn max<T: ~const Ord + ~const Drop>(v1: T, v2: T) -> T;
impl const PartialEq for {bool char usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 f32 f64 () !}
impl const PartialOrd for {bool char usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 f32 f64 () !}
impl const Ord for {bool char usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 () !}


pub const fn min_by<T, F: ~const FnOnce(&T, &T) -> Ordering>(v1: T, v2: T, compare: F) -> T
where
    T: ~const Destruct,
    F: ~const Destruct;

pub const fn min_by_key<T, F: ~const FnMut(&T) -> K, K: ~const Ord>(v1: T, v2: T, mut f: F) -> T
where
    T: ~const Destruct,
    F: ~const Destruct,
    K: ~const Destruct;

pub const fn max_by<T, F: ~const FnOnce(&T, &T) -> Ordering>(v1: T, v2: T, compare: F) -> T
where
    T: ~const Destruct,
    F: ~const Destruct;

pub const fn max_by_key<T, F: ~const FnMut(&T) -> K, K: ~const Ord>(v1: T, v2: T, mut f: F) -> T
where
    T: ~const Destruct,
    F: ~const Destruct,
    K: ~const Destruct;

Steps / History

• Implementation: Constify a few (Partial)Ord impls #92390 Constify PartialEq for Ordering #101810 Constify cmp_min_max_by. #102245
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[slightlyoutofphase]

One interesting thing to note is that you can currently use all of those primitive types as fields inside structs, implement const PartialOrd / const PartialEq / etc for the structs, and then have const fns defined with the appropriate ~const bounds work completely fine with them.

However, const "free" functions attempting to operate directly on the primitive types just do not work regardless of what bounds are provided (except if they're entirely non-generic functions), as I inquired about and demonstrated here a bit earlier today.

I'm assuming this probably has something to do with the compiler likely just "special casing" primitive types in various scenarios without actually taking the trait system directly into account at all (which it seems as though it'd have to have done historically in order to avoid all sorts of runtime performance isssues popping up).

[raldone01]

Any reason why impl const PartialEq for Ordering {} is not added by this feature?

I used matches!(ordering, Ordering::Less) as a workaround.

[fee1-dead]

@raldone01 No reason. Feel free to add that yourself :)

[tgross35]

@fee1-dead could this, or at least a subset, be moved to const stable at this point? I'm not sure if it's blocked on const traits, but the functions seem fairly uncontroversial

[fee1-dead]

No we are currently planning temporary removal of all things related to const traits in the standard library to allow a clean redesign of compiler implementation of const traits. Unless there's a way to make sure that it would remain stable even if we remove const traits entirely we can't stabilize anything that uses const traits. Also do note that const traits don't have an accepted RFC yet and is still experimental.

[zeroflaw]

As of 2023-04-20, rust version 1.71.0-nightly (39c6804 2023-04-19), I've just found that this has been removed. Is there an alternative way of doing const cmp?

[Thomasdezeeuw]

For people following this tracking issue, it seems to be removed in #110393, the removal is tracked in #110395.

[RalfJung]

This has been removed by #110393.