Tracking Issue for ptr::fn_addr_eq

[Urgau]

Feature gate: #![feature(ptr_fn_addr_eq)]

This is a tracking issue for std::ptr::fn_addr_eq

Compares the addresses of the two function pointers for equality.

Public API

// core::ptr

/// Compares the *addresses* of the two function pointers for equality.
///
/// Function pointers comparisons can have surprising results since
/// they are never guaranteed to be unique and could vary between different
/// code generation units. Furthermore, different functions could have the
/// same address after being merged together.
///
/// This is the same as `f == g` but using this function makes clear
/// that you are aware of these potentially surprising semantics.
pub fn fn_addr_eq<T: FnPtr, U: FnPtr>(f: T, g: U) -> bool {
    f.addr() == g.addr()
}

Steps / History

• ACP: Add ptr::fn_addr_eq to compare functions pointers. libs-team#323
• Implementation: Implement ptr::fn_addr_eq #129323 and Expand ptr::fn_addr_eq() documentation. #131457
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[Urgau]

T-lang as started an FCP for adding a lint against function pointer comparisons and would like to use this method ptr::fn_addr_eq as recommendation to suppress the lint and hang documentation about caveats.

Stabilization Report

Implementation History

• Implement ptr::fn_addr_eq #129323
• Expand ptr::fn_addr_eq() documentation. #131457 (waiting on review, but doesn't prevent FCP)

API Summary

// core::ptr

/// Compares the *addresses* of the two function pointers for equality.
///
/// Function pointers comparisons can have surprising results since
/// they are never guaranteed to be unique and could vary between different
/// code generation units. Furthermore, different functions could have the
/// same address after being merged together.
///
/// This is the same as `f == g` but using this function makes clear
/// that you are aware of these potentially surprising semantics.
pub fn fn_addr_eq<T: FnPtr, U: FnPtr>(f: T, g: U) -> bool {
    f.addr() == g.addr()
}

The std::marker::FnPtr bound

The FnPtr marker trait is not stable and would be not stabilized by this FCP, but this commits us to having such trait (even in this unstable form).

---

cc @rust-lang/lang (regarding the FnPtr bound)
cc @rust-lang/libs-api

[dtolnay]

@rfcbot fcp merge

[rfcbot]

Team member @dtolnay 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
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

@rfcbot reviewed

[nikomatsakis]

@rfcbot reviewed

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this in triage today. We've now unanimously checked off on the lang side. We appreciate @rust-lang/libs-api for moving this forward in support of the pending lang work.

[rfcbot]

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