Clarify that pointers are not always compared by their addresses#157682
Clarify that pointers are not always compared by their addresses#157682asquared31415 wants to merge 1 commit into
Conversation
|
r? @LawnGnome rustbot has assigned @LawnGnome. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Do we need to specify what it means to do an |
|
I think it’s fine to specify that ordering of vtables is arbitrary. What’s more troublesome IMO is that their identity is undefined: separate codegen units can generate vtables independently for the same (trait, type) and give them different addresses: #46139 |
|
This has been previously discussed at length and there is a warn-by-default lint that triggers when comparing pointers to trait objects. |
|
Probably could use a link to https://doc.rust-lang.org/nightly/std/ptr/fn.eq.html somewhere. |
|
0342708 to
94b9382
Compare
There was a problem hiding this comment.
I think this is good for the PartialEq case and think the choice of core::ptr::eq as the reference there to avoid duplication is a good one, but I'm not sure this documentation answers the question a reader would have in the Ord and PartialOrd cases (namely, what is about to happen if I call this).
| /// Pointers to [`Sized`] types are compared by their addresses, as produced by the | ||
| /// [`<*const T>::addr`](pointer::addr) method. | ||
| /// Pointers to [dynamically sized types] additionally have their metadata compared. | ||
| /// See [`core::ptr::eq`] for more information about metadata comparisons. |
There was a problem hiding this comment.
Is there anything we can say here to elaborate on what the actual behaviour for Ord (and PartialOrd, for those cases) would be, even if it's essentially meaningless for DSTs? The referenced core::ptr::eq documentation only really deals with equality comparisons, not ordering.
There was a problem hiding this comment.
The behavior is the same as eq, but with the ordering operator instead of ==. That is, the metadata is treated in the same way (usize if length, pointer if vtable). I'm not sure the best way to explain this, especially because equality is a case of ord, so there's some overlap there too.
This makes the doc comments on pointer types correctly clarify that for fat pointers, their metadata is compared as well for equality and ordering operations. Additionally adds this documentation to the
NonNulltype. This makes the documentation match the referenceFixes #157640
Supersedes #136364 which missed this qualification