Skip to content

Tracking Issue for comparing values in const items #92391

Closed

Description

@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

Unresolved Questions

  • None yet.

Activity

  1. added
    T-libs-api[DEPRECATED; DO NOT USE]
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Dec 29, 2021
  2. slightlyoutofphase commented on Dec 29, 2021

    @slightlyoutofphase
    Contributor

    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).

  3. raldone01 commented on Sep 14, 2022

    @raldone01
    Contributor

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

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

  4. fee1-dead commented on Sep 14, 2022

    @fee1-dead
    MemberAuthor

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

  5. added a commit that references this issue on Sep 15, 2022
  6. raldone01 commented on Sep 15, 2022

    @raldone01
  7. added a commit that references this issue on Sep 25, 2022
  8. tgross35 commented on Mar 31, 2023

    @tgross35
    Member

    @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

  9. fee1-dead commented on Mar 31, 2023

    @fee1-dead
    MemberAuthor

    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.

  10. zeroflaw commented on Apr 20, 2023

    @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?

  11. Thomasdezeeuw commented on Apr 21, 2023

    @Thomasdezeeuw
    Contributor

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

  12. RalfJung commented on Sep 8, 2024

    @RalfJung
    Member

    This has been removed by #110393.

  13. added a commit that references this issue on Sep 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCF-const_trait_impl`#![feature(const_trait_impl)]`T-libs-api[DEPRECATED; DO NOT USE]

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions