Tracking Issue for raw slice len() method (slice_ptr_len, const_slice_ptr_len)

[neocturne]

This is a tracking issue for the len() method on raw slice pointers, which allows to get the length of a raw slice pointer when conversion to a slice reference would be UB (because the pointer is null or unaligned).

It covers the feature gates #![feature(slice_ptr_len)] and #![feature(const_slice_ptr_len)] (for const fn).

Public API

impl<T> *mut [T] {
    pub const fn len(self) -> usize;
    pub const fn is_empty(self) -> bool;
}

impl<T> *const [T] {
    pub const fn len(self) -> usize;
    pub const fn is_empty(self) -> bool;
}

impl<T> NonNull<[T]> {
    pub const fn len(self) -> usize; // Already stable
    pub const fn is_empty(self) -> bool;
}

History / Steps

• ptr: introduce len() method on raw slices #71082
• Add len and slice_from_raw_parts to NonNull<[T]> #71940
• Additional *mut [T] methods #95594
• also add is_empty to const raw slices #118231
• Add NonNull::<[T]>::is_empty. #122800
• Final commenting period (FCP)
• Stabilization PR

Open questions

• Potential blocker: rustc performs auto-ref when a raw pointer would be enough #73987

[SimonSapin]

PR #71940 adds NonNull<[T]>::len, reusing this as its tracking issue.

[RalfJung]

#73987 is a potential blocker for stabilization of these methods.

[SimonSapin]

Is it really? I feel that a DST struct with a slice field is not a common case, and certainly not the only one.

[RalfJung]

That issue shows a general problem with methods where self is a raw pointer: if a method with the same name as self being a reference exists, it is very easy to accidentally call the reference method. Isn't that a problem for stabilizing any of those raw pointer methods?

[SimonSapin]

This does look like a footgun, but I think the core of that issue is not at all the len methods. Instead it’s that you can’t get a raw pointer to a struct field from a raw pointer to that struct without something like rust-lang/rfcs#2582. The example code in #73987 never involved a *const [u8] value at all. I’ve commented some more there.

Once you do have a *const [u8] value, calling len on it is perfectly fine.

[RalfJung]

(Responded there. What you describe is buggy behavior, IMO -- the source code didn't involve a &[u8] either, the compiler added that, and that is exactly the problem.)