Tracking Issue for ptr::addr_eq

[scottmcm]

Feature gate: #![feature(ptr_addr_eq)]

This is a tracking issue for ...

Public API

// core::ptr

pub fn addr_eq<T: ?Sized, U: ?Sized>(p: *const T, q: *const U) -> bool;

Steps / History

• ACP: Add ptr::addr_eq for use with pointers-to-DSTs libs-team#274
• Implementation: Add ptr::addr_eq #116325
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[asquared31415]

While ptr.addr() (or maybe expose_addr) is gated under strict_provenance, I think that it should be noted here because it would allow for writing this code to compare the addresses. However, since addr is a method on pointer types, it cannot be used with &(mut) without a cast and some parentheses first, which is less convenient.

I think that in the quest to replace as with better methods, a function with some semantics that involve getting the address will be stabilized and for the purposes of implementing this method it doesn't matter what other semantics w.r.t. provenance might exist.

[asquared31415]

To clarify, today you can write

#![feature(strict_provenance)]
fn addr_eq<T: ?Sized, U: ?Sized>(p: *const T, q: *const U) -> bool {
    p.addr() == q.addr()
}

(or just inline that code directly, if you can cast to raw pointers first instead of relying on coercion)

[scottmcm]

Note that I implemented this via casting to *const (), not via .addr() (nor .expose_addr()). I wanted to avoid any ptr2int in the codegen, since even with .addr() in LLVM we still end up exposing the address.

You can copy exactly what the PR does if you want; it works on stable.

[joshtriplett]

Lang would like to recommend addr_eq in a lint (#117758), so I'd like to propose stabilizing this function.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.