Rust: 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 https://github.com/rust-lang/rust/pull/60667 used this feature requested as a tracking issue, but this wasn’t labelled properly. Doing so now.

[SimonSapin]

By the way, https://github.com/rust-lang/rfcs/pull/2580 would also cover this :)