Tracking Issue for [*const T|*mut T]::with_metadata_of

[oliver-giersch]

Feature gate: #![feature(set_ptr_value)]

Public API

impl<T: ?Sized> *mut T {
    pub fn with_metadata_of<U: ?Sized>(self, val: *const U) -> *mut U;
}

impl<T: ?Sized> *const T {
    pub fn with_metadata_of<U: ?Sized>(self, val: *const U) -> *const U;
}

Steps / History

• Implementation: adds [*mut|*const] ptr::set_ptr_value #74774
• Change type and add #[must_use]: Requested changes to [*mut T|*const T]::set_ptr_value #75407
• Reverse argument order and rename to with_metadata_of: Refactor set_ptr_value as with_metadata_of #95249
• Const argument for mutable with_metadata_of: Adjust argument type for mutable with_metadata_of (#75091) #103346
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• Correct argument type -- *mut ()? *mut u8? *mut Opaque?
• Is this even needed/useful given that there now also is Tracking Issue for pointer metadata APIs #81513?

[SimonSapin]

As discussed on Zulip this could be replaced with ptr::from_raw_parts(val, ptr::metadata(self)), tracked in #81513

[ChayimFriedman2]

Even if we want to keep these methods I think it's better to write them in terms of the metadata API as it's easy to reason about and less error prone than the current implementation.

[WaffleLapkin]

This needs a better motivational example. From current docs:

This function is primarily useful for allowing byte-wise pointer
arithmetic on potentially fat pointers:

#![feature(set_ptr_value)]
use core::fmt::Debug;
let mut arr: [i32; 3] = [1, 2, 3];
let mut ptr = arr.as_mut_ptr() as *mut dyn Debug;
let thin = ptr as *mut u8;
unsafe {
    ptr = thin.add(8).with_metadata_of(ptr);
    assert_eq!(*(ptr as *mut i32), 3);
    println!("{:?}", &*ptr); // will print "3"
}

This is superceeded by byte_add and co (#96283)

[dtolnay]

dyn-clone perhaps? dtolnay/dyn-clone#8

[HeroicKatora]

flexible-io is the implementation of the solution devised a while ago to the problem and another instance which originally got me invested in this PR. It relies on with_metadata_of. The full metadata API might be an optimization for later, but is way more complex than necessary here.

[bjorn3]

That will use the provenance of from rather than the provenance of onto, which will cause UB if you dereference the resulting pointer, but the provenance of from doesn't allow accessing this address. Miri is entirely correct in rejecting this. With rustc it may work by accident or you may get a miscompilation.