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:

• feature(ptr_sub_ptr)
  • pointer::sub_ptr
• feature(ptr_mask)
  • pointer::mask
• feature(pointer_is_aligned)
  • pointer::is_aligned
  • pointer::is_aligned_to
• feature(ptr_alignment_type)
  • core::ptr::Alignment
• feature(strict_provenance)
  • pointer::addr
  • pointer::with_addr
  • pointer::map_addr
  • core::ptr::invalid
  • core::ptr::invalid_mut
• feature(exposed_addr)
  • pointer::expose_addr
  • core::ptr::from_exposed_addr
  • core::ptr::from_exposed_addr_mut

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