Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for comparing values in const items #92391

Open
1 of 3 tasks
fee1-dead opened this issue Dec 29, 2021 · 8 comments
Open
1 of 3 tasks

Tracking Issue for comparing values in const items #92391

fee1-dead opened this issue Dec 29, 2021 · 8 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-const_trait_impl `#![feature(const_trait_impl)]` T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@fee1-dead
Copy link
Member

fee1-dead commented Dec 29, 2021

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.
@fee1-dead fee1-dead added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Dec 29, 2021
@slightlyoutofphase
Copy link
Contributor

slightlyoutofphase commented Dec 29, 2021

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
Copy link
Contributor

raldone01 commented Sep 14, 2022

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
Copy link
Member Author

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

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 15, 2022
…dering, r=fee1-dead

Constify `PartialEq` for `Ordering`

Adds `impl const PartialEq for Ordering {}` to rust-lang#92391.
@raldone01

This comment was marked as resolved.

fee1-dead added a commit to fee1-dead-contrib/rust that referenced this issue Sep 25, 2022
…e1-dead

Constify cmp_min_max_by.

Constifies `core::cmp::{min, max}_by[_key]` behind the `const_cmp` rust-lang#92391 feature gate, using `const_closure`.
@fee1-dead fee1-dead added the F-const_trait_impl `#![feature(const_trait_impl)]` label Mar 24, 2023
@tgross35
Copy link
Contributor

@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
Copy link
Member Author

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
Copy link

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-const_trait_impl `#![feature(const_trait_impl)]` T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants