Why `Box<T>` does not implement `PartialEq<Box<U>>` where `T: PartialEq<U>`?

libs
1

Currently, the PartialEq implementation is defined like this:

impl<T: ?Sized + PartialEq> PartialEq for Box<T> {
    fn eq(&self, other: &Box<T>) -> bool {
        PartialEq::eq(&**self, &**other)
    }
    fn ne(&self, other: &Box<T>) -> bool {
        PartialEq::ne(&**self, &**other)
    }
}

Why is it not implemented for PartialEq<U> like this?

impl<T: ?Sized, U: ?Sized> PartialEq<Box<U>> for Box<T>
where
    T: PartialEq<U>,
{
    default fn eq(&self, other: &Box<U>) -> bool {
        PartialEq::eq(&**self, &**other)
    }
    default fn ne(&self, other: &Box<U>) -> bool {
        PartialEq::ne(&**self, &**other)
    }
}

Same applies to PartialOrd

EDIT: I updated the code to use specialization to prevent a semver-breaking change.

2

For the non-generic case, autoderef should handle it, which may be why it is less likely to be noticed.

In the generic case, I agree that this generalization is correct, and is a non-semver-breaking change (well, except for the fact that Box is #[fundamental] which has some special rules I don’t quite understand) but probably could easily lead to inference problems.

1 Like
3

AIUI, this means Box<Foo> has the same locality as Foo for the purpose of coherence, so adding a new blanket impl on Box<U> is a breaking change.

For example, I could have impl PartialEq<Box<Bar>> for Box<Foo> already.

2 Likes
4

With specialization, this could be solved, right?

5

Yes, specialization would solve that semver problem.

6

I updated the first post to cover this case. Thank you!

7

As for why we don’t have that default impl: the stdlib is very careful not to do anything that requires specialization yet, as it’s not stabilized yet (and still isn’t fully designed, there’s some really scary corners left).

Once specialization is stable, it might make sense to add this impl to the stdlib.

1 Like
8

internals.rust-lang is missing the solved-button like in users.rust-lang :wink:

9

the stdlib is very careful not to do anything that requires specialization yet, as it’s not stabilized yet

That's not true of liballoc, which does use specialization, and is what contains the Box type.

10

I’m pretty sure that nothing’s stabily exposed that’s impossible without specialization. (If there is, I’m wrong and I admit it, but I’ve seen potential specialization-requiring impls blocked on stabilized specialization.)

Of course, it’s being used for optimization. But only in the sense that the general impl works for all cases, and a subset is explicitly specialized to a more efficient path.

3 Likes
11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.