stabilize ptr_cast_slice

[malezjaa]

Stabilization report

Closes #149103

This feature adds method calls on raw pointers that call into the respective ptr::slice_from_raw_parts{_mut} method for the types *const T, *mut T and NonNull<T> to make using raw pointers more ergonomic in Rust by supporting postfix method chain syntax while creating slices.

Implementation

1. Implementation PR: Implement cast_slice for raw pointer types #149110
2. Migrated std to use ptr.cast_slice: Migrate libraries from ptr::slice_from_raw_parts to .cast_slice #156109

Public API

// core::ptr::const_ptr
impl<T> *const T {
    pub const fn cast_slice(self, len: usize) -> *const [T];
}

// core::ptr::mut_ptr
impl<T> *mut T {
    pub const fn cast_slice(self, len: usize) -> *mut [T];
}

// core::ptr::non_null
impl<T> NonNull<T> {
    pub const fn cast_slice(self, len: usize) -> NonNull<[T]>;
}

r? @nia-e

@rustbot modify labels: +T-libs

[rustbot]

nia-e is currently at their maximum review capacity.
They may take a while to respond.

[nia-e]

seems fine. i think it's small enough that we can const-stabilise it too yeah.

@rfcbot merge libs

[rust-rfcbot]

@nia-e has proposed to merge this. The next step is review by the rest of the tagged team members:

• @ChrisDenton
• @Mark-Simulacrum
• @cuviper
• @dtolnay
• @joshtriplett
• @nia-e
• @the8472
• @thomcc

Concerns:

• naming (stabilize ptr_cast_slice #162927 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/libs-ping: FCP proposed for libs, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[Paladynee]

i'd like to change the documentation to point to ptr::slice_from_raw_parts instead of inlining it before we stabilize, like ptr.copy_from_nonoverlapping pointing to ptr::copy_nonoverlapping

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[malezjaa]

Sorry, forgot I cant use github for resolving merge conflicts :\

[Mark-Simulacrum]

I think it's critical we keep the "safety" aspect present here. I'm OK indirecting but this makes it too easy to skip over information that is pretty important for the reader.

View changes since the review

[malezjaa]

So something like this,

/// This function is safe, but actually using the return value is unsafe.
/// See [`ptr::slice_from_raw_parts`] for more information.
///
/// [`ptr::slice_from_raw_parts`]: crate::ptr::slice_from_raw_parts

or should I just revert to the original version?

[Mark-Simulacrum]

Commenting on a random file to start a thread.

I'm not a huge fan of the name cast_slice. I think all of our existing stable cast functions (and unstable, with the exception of cast_array, which I would rename too) don't take any parameters -- just like as casts, they may be lossy, but they're not adding any information into the result.

I'm checking my box since I don't have a great alternative (e.g., to_slice, maybe?) but wanted to raise that point in case others share it and have ideas on alternative names.

View changes since the review

[Paladynee]

this feature was initially proposed in the ACP as with_len, but explicitly accepted as cast_slice as consistency with cast_array.

here's the relevant libs-api meeting: https://hackmd.io/@rust-libs/SkVJ_fcgbe#new-change-proposal-rusttflibs693-Add-a-method-for-raw-pointers-that-calls-ptrslice_from_raw_parts_mut

here's the libs-api meeting for cast_array, which doesn't touch upon the naming too much: https://hackmd.io/@rust-libs/Bk0IDObHxx#new-change-proposal-rusttflibs602-ACP-add-arrayfrom_raw_parts

[Mark-Simulacrum]

IMO, that consistency argument doesn’t hold much value until we actually stabilize cast_array (or this one). I think having slice/array in the name is important, it’s only the cast part that I have some qualms about.

[clarfonthey]

to_slice_with_len or cast_slice_with_len are the only ones I can think of that might be reasonable, besides the proposal.

[tgross35]

Quick survey of our pointer API (mostly ignoring mut versions):

Stable as_*

• as_array *const [T], N -> Option<*const [T; N]> 🟰

Stable cast_*

• cast for *const T -> *const U
• cast_mut for *const T -> *mut T
• cast_const for *mut T -> *const T

Unstable as_*

• as_slice for *const [T; N] -> *mut [T] 🟰
• as_ptr for *const [T] -> *const T 🟰
• as_ptr for *const [T; N] -> *const T 🟰
• as_uninit_ref for *const T -> Option<&MaybeUninit<T>
• as_uninit_slice for *const [T] -> Option<&[MaybeUninit<T>]>

Unstable cast_*

• cast_init for *const MaybeUninit<T> -> *const T ❓ MaybeUninit::as_ptr
• cast_uninit for *const T -> *const MaybeUninit<T>
• cast_array for *const T, N -> *const [T; N]
• cast_slice (this API) for *const T -> *const [T]

Unstable to_*

• to_raw_parts for *const T -> (*const (), <T as Pointee>::Metadata)

The difference between cast_ and as_ feels a bit inconsistent. I've added an 🟰 to the places where the API is equivalent to a non-raw-pointer T/[T]/[T; N] method's name, all of those seem fine.

The remaining unstable cast_ methods are less certain. All of those feel more similar to the as_ methods in the sense that they add/remove length information or add/remove a transparent wrapper. The stable cast_ OTOH are more fundamental changes to reinterpret as an unrelated type or change allowed accesses - not the most descriptive rule, but I think it works well enough here?

All of that to say, I think cast_array and cast_slice should be as_array and as_bikeshed rather than cast_bikeshed.

Fon's proposal to use with_len seems nice, so perhaps as_slice_with_len? Or go a completely different route and call it fn slice_from_raw_parts to echo the &[T] API.

---

Since this naming could use discussion, nominating for the naming things meeting:

@rustbot label +I-libs-nominated

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tgross35]

From the meeting:

Nia: This is sound for any usize. I'm sympathetic to the naming argument that it looks weird, but cast_array is a precedent.

cast_array is unstable, I don't think that should be taken as precedent. We could just as easily change cast_array to as_array, which I do think we should do (above).

There is a stable as_array method

Fon: We have a week to figure out. I'll unnominate.

What week, it's in FCP 😱

[cuviper]

@rfcbot concern naming

[clarfonthey]

Fon: We have a week to figure out. I'll unnominate.

What week, it's in FCP 😱

That was exactly my point. Any concerns would have to be formally registered before the meeting to avoid it just passing FCP.

(It was a long meeting. Just woke up from a post-libs-meeting-recovery nap, and now will re-nominate for next week.)