Trait objects are not the only kind of unsized type; slices are the other.
Using slices it's trivial to get two fat pointers that have the same address, but different metadata. And comparing the metadata does make sense for slices, because it's just the length. Two pointers that point to different sections of the same array, even if they start at the same location, can be said to point to different things.
So that's one justification for defining
ptr::eq that way. That doesn't apply to
Rc, because two
Rc<[T]>s don't overlap unless they overlap entirely. And you could say the same for trait objects... unless you're using a transparent newtype with a different trait implementation, I guess? It's arguable. So I think you can make an argument that
Rc::ptr_eq should just ignore fat pointer metadata.
But it doesn't work that way today. Can it be fixed? Well, to change the behavior of
ptr_eq, you'd need to argue that the previous behavior was a bug, and any code that relies on it is incorrect. I think this is most likely true, actually, but the change would also break the symmetry between
ptr::eq, so there's an argument to be had there.
The other option would be to introduce a new method
Rc::thin_ptr_eq and deprecate
ptr_eq in favor of it.
(Incidentally: One of my annoyances with
Rc is that you can't
Rc with a
Weak unless you first
Weak. If we're talking about possible improvements to
Rc::ptr_eq, maybe this is something that could be taken into consideration.)