-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Closed
Labels
B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.
Description
Implemented in #35992 as #[unstable(feature = "ptr_eq")]
.
std::ptr::eq
is rust-lang/rfcs#1155.
vadixidav and ruudapmarcelll, bluss, lifthrasiir and coreh
Metadata
Metadata
Assignees
Labels
B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
pub fn ptr_eq(this: &Self, other: &Self) -> bool
to Rc and Arc #35992vadixidav commentedon Nov 25, 2016
I needed Rc::ptr_eq to avoid a double borrow in a recursive data structure with Rc<RefCell< T >>. Thanks a lot!
SimonSapin commentedon Nov 25, 2016
@vadixidav It can be implemented outside of
std
by tweaking it a bit. Copy-pasting this into your code can unblock you untilRc::prt_eq
is stabilized:alexcrichton commentedon Feb 14, 2017
Seem like good/easy APIs to stabilize!
@rfcbot fcp merge
rfcbot commentedon Feb 14, 2017
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams:
No concerns currently listed.
Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
federicomenaquintero commentedon Feb 17, 2017
FWIW, I just found a good use for this in librsvg's port to Rust.
Librsvg has a Node structure for the tree of SVG objects. The C code keeps around
RsvgNode*
values all over the place, including multiple references to the same value.Sometimes there is code like
if (current_node == tree_root)
for special-casing... and you see where this is going.The things I expose to the C code are pointers that come from
Box<Rc<Node>>
I also exposenode_ref()
andnode_unref()
functions so that C can get new references to existing nodes and discard them as needed.This means that
is invalid now. What I want is to
and that can be implemented as
For now I'm using @SimonSapin's code (it's missing double asterisks in
&**this
and&**other
), but it would indeed be nice to have an Rc::ptr_eq() in stable!SimonSapin commentedon Feb 17, 2017
I sometimes find convenient to make it less generic (when it’s only used with one
T
type):This looks the same as
==
, but since it expects raw pointer they can be coerced implicitly from references. (And, by the way,(*const T)::as_ref()
can be more convenient thanis_null
)(Of course,
Rc::eq
is nicer still.)alexcrichton commentedon Feb 28, 2017
ping @BurntSushi (checkbox)
rfcbot commentedon Feb 28, 2017
🔔 This is now entering its final comment period, as per the review above. 🔔
rfcbot commentedon Mar 10, 2017
The final comment period is now complete.
Stabilize ptr_eq feature, closes rust-lang#36497
matklad commentedon Dec 31, 2020
For future GitHub travelers, investigating
clippy::vtable_address_comparisons
:Looks like the methods were stabilized with the
?Sized
bound, while the current impl doesn't quite handle them. Specifically,ptr_eq
can spuriously returnfalse
for identical trait objects. This is being tracked in #69757.SimonSapin commentedon Dec 31, 2020
This is not unique to these
ptr_eq
methods. Wide pointers to trait objects have been comparable with the==
operator forever, with the same spurious results.