Fully generalize cmp instances

With cmp/ops reform, all of the comparison traits allow the types of the two sides to differ. However, the traits provide a default type for the right-hand size that is the same as the left-hand side. Thus, an impl like:

impl<T: PartialEq> PartialEq for Rc<T> { ... }

is more limited than it needs to be; it could instead be

impl<U, T: PartialEq<U>> PartialEq<Rc<U>> for Rc<T> { ... }

(Of course, you could imagine being even more general than that, allowing Rc values to be compared to other values.)

The various impls in the standard library should probably be generalized along these lines; currently a few are but most aren't.

@japaric

cc @japaric @alexcrichton

I don't think we need to do this prior to stabilization, since we can always safely generalize in the future. I'd also like to put some thought into how general we want to make things, but the example above seems like a good minimum.

A bit of follow up: I'm seeing some cases where e.g. the PartialEq implementation has been generalized like the above, but the Eq hasn't.

rollup merge of rust-lang#20065: aturon/stab-2-cmp

What's the status of this with #20065 merged?

I am guessing the status is that it's done, so I'm giving it a close. Let me know if there's anything specific still missing.

@steveklabnik

@steveklabnik No, this hasn't been done yet. Basically it would require a sweep through all existing impls to generalize them.

I'm not sure where you want to track tickets like this. It's generally backwards compatible to make these changes, and not exactly high priority, but something nice for expressiveness and consistency (and definitely does not require an RFC).

Yeah, it's hard because it's not directly actionable, it's more like 'double check all these things.' It'd be nice if we had an actual list.

@rust-lang/lang How realistic would it be to for a solution for the problem here to be designed and accepted any time soon? Ideally we'd make Some("1".to_string()) == Some("1") work, but right now we can't do that without breaking Some(1) == None and None == Some(1).

Note that it wouldn't need to have T = U and U = T defaults on the PartialEq impl. Default of T = ! and U = ! (or some other dummy type) would also work, as long as ! implements PartialEq<T> for all T, and all T implement PartialEq<!> (which overlap, but that should be fine for !).

Some languages are able to do point-to-point vectorial comparisons:

[1, 2, 3, 4, 5] <= [5, 4, 3, 2, 1] will give [true, true, true, false, false]

Such overloading would be possible, for example, if trait PartialOrd had associated output type, as (this is only a sketchy suggestion):

pub trait PartialOrd<Rhs = Self>: PartialEq<Rhs>
where
    Rhs: ?Sized,
{
    type Ordering;
    type Bool;
    
    fn partial_cmp(&self, other: &Rhs) -> Option<Self::Ordering>;

    fn lt(&self, other: &Rhs) -> Self::Bool { ... }
    fn le(&self, other: &Rhs) -> Self::Bool { ... }
    fn gt(&self, other: &Rhs) -> Self::Bool { ... }
    fn ge(&self, other: &Rhs) -> Self::Bool { ... }
}

In whatever case, is there an RFC aimed at enabling point-to-point vector comparisons (or even more general comparisons such as functional point-to-point comparisons, etc.)?

@fdecode

@fdecode That's https://doc.rust-lang.org/std/simd/cmp/trait.SimdPartialOrd.html#tymethod.simd_le

Merge pull request rust-lang#20063 from lnicola/sync-from-rust

Navigation Menu

Repository navigation

Fully generalize cmp instances #20063

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Fully generalize cmp instances #20063

Description

Activity

aturon commented on Dec 20, 2014

aturon commented on Dec 20, 2014

steveklabnik commented on Jan 21, 2015

steveklabnik commented on Feb 15, 2015

aturon commented on Feb 16, 2015

steveklabnik commented on Feb 16, 2015

10 remaining items

m-ou-se commented on Jan 5, 2022

m-ou-se commented on Jan 5, 2022

fdecode commented on Nov 22, 2024

scottmcm commented on Nov 24, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions