Proposal

Problem statement

Working with raw pointers to create raw slices currently requires going through ptr::slice_from_raw_parts{_mut} which currently enforces the style of a free function call. This leads to verbose code that mixes programming styles, or raw pointer manipulation coming off as "hard to work with".

The current approach breaks the method chaining flow and requires importing or fully qualifying free functions, making raw pointer manipulation less fluent than it could be.

If a user library decides to implement a trait to accomplish this task, it breaks in const contexts because const trait implementations are not stabilized yet, while ptr::slice_from_raw_parts{_mut} is const stable.

Motivating examples or use cases

There are approximately 30 calls to ptr::slice_from_raw_parts{_mut} in the Rust standard library rust/library/* itself. Here is a real example from impl Drop for Vec:

// today
ptr::drop_in_place(ptr::slice_from_raw_parts_mut(self.as_mut_ptr(), self.len))

// with proposal
ptr::drop_in_place(self.as_mut_ptr().with_len(self.len))

// or, fully using method chaining
self.as_mut_ptr().with_len(self.len).drop_in_place()

Solution sketch

Implement an inherent method for raw pointers that calls into the respective function that creates the slice:

impl<T> *const T {
    const fn with_len(self, len: usize) -> *const [T] {
        core::ptr::slice_from_raw_parts(self, len)
    }
}

impl<T> *mut T {
    const fn with_len(self, len: usize) -> *mut [T] {
        core::ptr::slice_from_raw_parts_mut(self, len)
    }
}

impl<T> NonNull<T> {
    pub const fn with_len(self, len: usize) -> NonNull<[T]> {
        NonNull::slice_from_raw_parts(self, len)
    }
}

The method name with_len was chosen because:

1. It clearly indicates that we're adding length information to create a slice pointer.
2. It can be uniformly spelled across *const T, *mut T and NonNull<T> types.
3. It follows existing naming patterns in Rust (similar to with_capacity etc.)

Alternatives

1. Status quo: Continue using the free functions ptr::slice_from_raw_parts and ptr::slice_from_raw_parts_mut. This works but is more verbose and breaks method chaining, and forces users to go back and forth while writing raw pointer code.

2. Alternative Names:

   • set_len was suggested but with_len better indicates that it returns a new value rather than mutating
   • with_len_{const|mut} to be strict over the resulting mutability, but it is unclear whether we should allow calling with_len_mut on a const pointer, or what we should do with NonNull.

3. Import free functions as methods (hypothetical): A language feature like use ptr::slice_from_raw_parts_mut as <*mut T>::with_len was mentioned but doesn't exist in Rust.

Links and related work

Original Zulip discussion: #t-libs > method for `*const T` that calls `ptr::slice_from_raw_parts`
ptr::slice_from_raw_parts: https://doc.rust-lang.org/core/ptr/fn.slice_from_raw_parts.html
ptr::slice_from_raw_parts_mut: https://doc.rust-lang.org/core/ptr/fn.slice_from_raw_parts_mut.html
NonNull::slice_from_raw_parts (associated function): https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.slice_from_raw_parts

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.