rust_ptr_api_2024_stabilizations.md

i would like to get the ball rolling on stabilizing as many of the pointer APIs that were introduced in the last year

APIs:

Initial Discussion:

feature(ptr_sub_ptr)
- ✅ minor name bikeshedding, the name is fine
- 📝 should add byte_sub_ptr as feature(pointer_bytes_offset) is stable now
  - impl: rust-lang/rust#121919
feature(ptr_mask)
- ✅ seems free to stabilize as-is, although its docs refer to a strict_provenance API
feature(pointer_is_aligned)
- ✅ is_aligned uncontroversial/good
- ⚠️ is_aligned_to more controversial because it has to handle non-power of twos
  - proposed deprecate as insufficient motivation
    - impl: rust-lang/rust#121920
  - waffle proposes unspecified behaviour (i agree this is reasonable)
  - mara proposes is_aligned_for::<T>() as more egnomic for most practical cases (also agree)
  - scott proposes core::ptr::Alignment (see next ptr_alignment_type below)
feature(ptr_alignment_type)
- ✅ people are apparently hungering for this, so we should just stabilize it
- ⚠️ "blocked" on it being weird that nothing in std actually uses it
  - Layout "should" use it
  - some version of pointer::is_aligned_to "should" use it
feature(strict_provenance)
- ⚠️ addr, with_addr, and map_addr all seem very good and inoffensive in a vacuum, but i strongly believe they shouldn't be stabilized without their exposing partners to form a fully consistent system to follow for strict provenance
- 🛑 invalid and invalid_mut are in a more dubious place
  - does not appropriately address the needs of hardcoded memory addresses or "from FFI"
feature(exposed_addr)
- ⚠️ expose_addr, from_exposed_addr, and from_exposed_addr_mut all form a consistent system but people are cagey about them
  - i personally think they can just be stabilized with caveats that the semantics are opt-in and you're not "fucking up" if you fail to uphold them

Gankra/rust_ptr_api_2024_stabilizations.md