Add str pointer methods

[WaffleLapkin]

This PR adds the following functions for pointers to str, similar to already existing functions for pointers to [T].

impl *const str {
    pub const fn len(self) -> usize;
    pub const fn as_ptr(self) -> *const u8;
    pub unsafe fn get_unchecked<I>(self, index: I) -> *const I::Output
    where
        I: SliceIndex<str>;
}

impl *mut str {
    pub const fn len(self) -> usize;
    pub const fn as_mut_ptr(self) -> *mut u8;
    pub unsafe fn get_unchecked_mut<I>(self, index: I) -> *mut I::Output
    where
        I: SliceIndex<str>;
}

// mod ptr
pub const fn str_from_raw_parts(data: *const u8, len: usize) -> *const str;
pub const fn str_from_raw_parts_mut(data: *mut u8, len: usize) -> *mut str;

impl NonNull<str> {
    pub const fn str_from_raw_parts(data: NonNull<u8>, len: usize) -> Self;
    pub const fn len(self) -> usize;
    pub const fn as_non_null_ptr(self) -> NonNull<u8>;
    pub const fn as_mut_ptr(self) -> *mut u8;
    pub unsafe fn get_unchecked_mut<I>(self, index: I) -> NonNull<I::Output>
    where
        I: SliceIndex<str>;
}

---

I wasn't sure about feature gates and how to group them, so the advice is very appreciated.

---

This PR also adds const_str_ptr and mut_str_ptr lang items (they are required for *const str and *mut str impls).

---

See also:

• len for raw slices -- Tracking Issue for raw slice len() method (slice_ptr_len, const_slice_ptr_len) #71146
• as{,_mut,_non_null}_ptr, get_unchecked[_mut] -- Tracking Issue for raw slice getters (slice_ptr_get) #74265
• ptr::slice_from_raw_parts[_mut] -- Tracking issue for ptr::slice_from_raw_parts[_mut] #36925

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[jfrimmel]

I'm unsure about ptr.as_ptr(), as we already have a pointer. Maybe use as_bytes() instead?

[WaffleLapkin]

@jfager I would expect that as_bytes returns some sort of byte slice, e.g. it's *const str -> *const [u8], I don't think it's a good name for a *const str -> *const u8 function. Maybe as_ptr isn't a great name either, but it's consistent with <*const [T]>::as_ptr.

[jfager]

@WaffleLapkin looks like you tagged the wrong person!

[WaffleLapkin]

Oops, right. I've meant to tag @jfrimmel 😅

[m-ou-se]

The len functions look fine to me. For those, you can just use the same tracking issue as for [T]: #71146

The as_[mut_]ptr and get_unchecked ones also look fine. Feel free to just re-use #74265.

But I'm not sure about the str_from_raw_parts, because we don't have a &str variant (yet?). Right now, you'd have to use slice::from_raw_parts and str::from_utf8_unchecked to make a &str from raw parts. If we have a str_from_raw_parts for *const str, I'm worried that might be confusing, since users searching for a &str will only find the *const str version. Is this ptr::str_from_raw_parts that useful? Should we leave it out? Or maybe we need one for &str too? (Part of the reason it's good it needs two steps, is that it makes it clear there's two unsafe assumptions: One about the pointer+len being valid, and one about the UTF-8 encoding being valid.)

[WaffleLapkin]

@m-ou-se my original motivation for ptr::str_from_raw_parts was that it seemed weird to have methods on *const str without a convenient way to create such pointers. &str on the other hand can be easily created, e.g. str::from_utf8(slice::from_raw_parts(ptr, len))?. Though for symmetry and convenience str::from_raw_parts seems nice.

Part of the reason it's good it needs two steps, is that it makes it clear there's two unsafe assumptions: One about the pointer+len being valid, and one about the UTF-8 encoding being valid.

Then maybe instead of ptr::str_from_raw_parts we could have str::from_raw_utf8(*const [u8]) -> *const str.

---

Not sure which way is better.

[crlf0710]

@WaffleLapkin Ping from triage, what's next steps here?

[m-ou-se]

Then maybe instead of ptr::str_from_raw_parts we could have str::from_raw_utf8(*const [u8]) -> *const str.

Yeah maybe. I'd still put that in ptr:: instead of str:: though. Most users of str aren't interested in raw pointers, so it's probably good to keep all the raw pointer functions inside the ptr module.

cc @rust-lang/libs-api Any thoughts on these functions?

[dtolnay]

I don't see why the safety requirement of get_unchecked involves utf8 boundaries. I would expect only the same safety requirements as https://doc.rust-lang.org/std/primitive.pointer.html#method.add.

Please document safety requirements in a # Safety section.

Can we have safe indexing that works like https://doc.rust-lang.org/std/primitive.pointer.html#method.wrapping_add ?

[WaffleLapkin]

I don't see why the safety requirement of get_unchecked involves utf8 boundaries. I would expect only the same safety requirements as https://doc.rust-lang.org/std/primitive.pointer.html#method.add.

Hm. So *const str doesn't have utf8 guarantees, and it's only unsafe to create non-utf8 &str?

[WaffleLapkin]

So, to summarize the state of this PR. ​

1. len, as_ptr, as_mut_ptr, as_non_null_ptr and get_unchecked are considered ok, I just need to fill tracking issues.
   • I also need to fix safety comments (add # Safety, remove mentions of utf8 boundaries)
   • There is an open question if get_unchecked could be safe if it used wrapping_add, but it equally applies to <[T]>::get_unchecked so IMO it's out of scope of this PR.
2. str_from_raw_parts{_mut} is more controversial, since it may be confusing to have a function *const u8, usize -> *const str, but not the -> &str. There are a couple ways to 'fix' this, e.g.:
   • Add a ptr::str_from_utf8(*const [u8]) -> *const str function instead. This way we reuse slice ptr functions (like ptr::slice_from_raw_parts) and split safety into 2 parts: ptr validity and utf8 validity.
   • Add a -> &str counterpart too, like str::from_raw_parts (similar to slice::from_raw_parts)

I'm waiting for the decision on str_from_raw_parts{_mut} to fix everything and one go.

[bors]

☔ The latest upstream changes (presumably #85769) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

Triage: Still has conflicts

[bors]

☔ The latest upstream changes (presumably #86808) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #87875) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #91203) made this pull request unmergeable. Please resolve the merge conflicts.

[WaffleLapkin]

Closing in favour of #91216 and #91218