-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Some total ordering relations can only be expressed as partial orders #2511
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
Comments
The |
@varkor Indeed. I don't think we can make these more generic without breaking backwards compatibility, but we could add a pub trait Ord<RHS>: Eq<RHS> + PartialOrd<RHS> {
fn cmp(&self, other: &Self) -> Ordering;
// continue to work like they do now:
fn max(self, other: RHS) -> Self where Self: Sized, RHS=Self {
if other >= self { other } else { self }
}
fn min(self, other: RHS) -> Self where Self: Sized, RHS=Self {
if self <= other { self } else { other }
}
} A radically different alternative might be to just add a new trait enum Either<L, R>(L, R);
trait Ord2<RHS>: Eq<RHS> + PartialOrd<RHS> {
fn cmp(&self, other: &Self) -> Ordering;
fn max(self, other: RHS) -> Either<Self, RHS> where Self: Sized;
fn min(self, other: RHS) -> Either<Self, RHS> where Self: Sized;
}
impl<T: Ord> Ord2<T> for T { ...specializable default impls... } An open question is whether we can make such a trait as ergonomic as |
I think the question is, why are |
I do think
or more likely have conversions that provide symmetry
And replace In this case though, isn't this version fully compatible?
|
@burdges that seems reasonable |
I don't know, but I don't think this is something that we are allowed to change. |
I suppose big num types contain allocations like
|
Uh oh!
There was an error while loading. Please reload this page.
TL;DR: one cannot
impl Ord<Foo> for Bar
.Currently, we can stablish strict and non-strict partial ordering relations between types:
but there is no way to state that such a relation is a total order because
Ord
andEq
are not generic over theRHS
likePartialOrd
andPartialEq
are.Is this an oversight?
I would find this useful when implementing ordering relations for wrapper types for which it makes no sense to implement
Deref
. For example:To solve this we would probably need to change
Eq
andOrd
from:to
Would this be a breaking change? (if so, could it be fixed automatically by rustfix?)
The text was updated successfully, but these errors were encountered: