Tracking issue for ptr::slice_from_raw_parts[_mut]

[arielb1]

In stable Rust, the only way to get a *const [T] with an arbitrary length is through slice::from_raw_parts. Unfortunately, that function returns a &[T], which makes it very dubious to use with arbitrary raw pointers.

[Thiez]

Given that Index isn't defined for *const [T], what would be the value of being able to create *const [T]?

[durka]

Why would you want one, but also, this seems like it depends on (yet to be decided?) details of the memory model. Is the fleeting moment where a reference exists in unsafe { slice::from_raw_parts(0xDEADBEEF, 42) as *const [T] } enough to invoke UB if the pointer is invalid?

[arielb1]

@durka

If the reference is null, then this is insta-UB for sure.

[CAD97]

Is there anything holding slice_from_raw_parts[_mut] from stabilizing? If not, I'd like to propose stabilization of these functions, as they are rather simple in concept and allow avoiding manifesting references during (slice) pointer manipulation.

cc @RalfJung #63880 #63851 @rust-lang/wg-unsafe-code-guidelines

If I'm reading the various issue threads correctly, the validity invariant of pointer metadata is at max that of the metadata type. For slice pointers, the metadata is typed at usize.

Context: I happen to currently be writing a library that cannot use the reference-based functions, because though the pointers are known to be non-null (and valid), it is not (and cannot be, with the current abstraction) known whether the pointer has unique or shared provenance (thus should use slice::from_raw_parts or slice::from_raw_parts_mut to be sound). (Specifically, I'm now adding the bits required to handle erasing slice types. I can bifurcate my unerase function into unerase_const and unerase_mut, but so far, it works fine with one unerase operating over ptr::NonNull, and it'd be sad to have the _const/_mut split hanging around even after these functions stabilize (assuming they can)).

[nikomatsakis]

I don't recall any reason that slice_from_raw_parts cannot be stabilized.

[SimonSapin]

The implementation PR #60667 used this feature requested as a tracking issue, but this wasn’t labelled properly. Doing so now.

[SimonSapin]

By the way, rust-lang/rfcs#2580 would also cover this :)