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.)

[Pointerbender]

Hello everyone. Thank you for working on this feature! I understand that currently #73987 is a blocker for slice_ptr_len. As an end-user of this API, is there any feedback I could provide that would help decide on the method signature? FWIW, I've not seen any risky situations in my usage due to its current method signature (I tend to check to which method it resolves to using my IDE in case there are multiple potential matches, so this might be more thorough than the average end-user). In an attempt to spark new ideas, an alternative I see is to turn the method signature pub const fn len(self) -> usize into an associated function like pub const fn len(ptr: Self) -> usize if this is really blocking, then it would be impossible to get confused (but at the cost of ergonomics). But as an end-user, I would also be satisfied for how the signature is currently available already, I do not find it confusing as it is. I'd like to help out more if I can, please let me know if I can contribute somehow :-) Thank you!

[Pointerbender]

A second idea for a suggestion that came to me today. Currently this tracking issues is for all of <*const T>::len, <*mut T>::len and NonNull::<T>::len. If I understand correctly, #73987 is only related to <*const T>::len and <*mut T>::len, but does not affect NonNull::<T>::len(), because creating a reference &NonNull<T> through len() would merely be a reference to the pointer to T, not to the actual T. If I'm not mistaken, the internals of NonNull::<T>::len() are still allowed to call the non-stabilized pointer methods, even when NonNull::<T>::len() would already be stable (I think remember seeing this approach before when browsing through the core library source code). Is there a possibility that NonNull::<T>::len() could get stabilized already before the other methods?

[RalfJung]

#73987 indeed does not affect NonNull::len.

[Amanieu]

Is there a particular reason why there is no NonNull::<[T]>::is_empty?

That's a good point. It should be added as well for consistency with raw pointers.

[zachs18]

As per #122800 (comment), #122800 currently uses this issue as the tracking issue for NonNull::<[T]>::is_empty

[RalfJung]

Adding something to FCP after the boxes were already checked is rather unconventional (I expected a new tracking issue for a new function) -- @rust-lang/libs-api I hope you're okay with it (a team member proposed to do this after all).

[Amanieu]

I've added NonNull::is_empty to the tracking issue.

I'll restart the FCP to make sure everyone is aware of the change.

@rfcbot fcp cancel

[rfcbot]

@Amanieu proposal cancelled.

[Amanieu]

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

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!

See this document for info about what commands tagged team members can give me.

[rfcbot]

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

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.