Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add str pointer methods (take 2) #91218

Closed

Conversation

WaffleLapkin
Copy link
Member

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>;
}

impl NonNull<str> {
    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>;
}

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


This was previously proposed in #85816. This PR includes changes proposed by the review and was created to split these changes from the addition of pointer-to-str-construction methods (#91216).


r? @m-ou-se

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 25, 2021
@rust-log-analyzer

This comment has been minimized.

@WaffleLapkin WaffleLapkin force-pushed the str_ptr_len_get_take2 branch 2 times, most recently from 7bb8644 to fdf5382 Compare November 25, 2021 17:08
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Dec 1, 2021
@bors
Copy link
Contributor

bors commented Dec 7, 2021

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

These items allow to make inherent impls for `*const str` and `*mut str`.
@m-ou-se m-ou-se added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 16, 2021
Copy link
Member

@m-ou-se m-ou-se left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for splitting that PR!

This looks great. I only have some small comments on the documentation:

library/core/src/ptr/non_null.rs Outdated Show resolved Hide resolved
library/core/src/ptr/const_ptr.rs Outdated Show resolved Hide resolved
library/core/src/lib.rs Outdated Show resolved Hide resolved
This patch adds the following methods to `*const str` and `*mut str`:
- `len`
- `as_ptr` (`as_mut_ptr`)
- `get_unchecked` (`get_unchecked_mut`)

Similar methods have already existed for raw slices.
This patch adds the following methods to `NonNull<str>`:
- `len`
- `as_non_null_ptr`
- `as_mut_ptr`
- `get_unchecked_mut`

Similar methods have already existed for raw slices, raw strings and nonnull
raw slices.
This commit changes documentation of the following methods as proposed
by the PR review
- `<*const [T]>::len`
- `<*mut [T]>::len`
- `<*const str>::len`
- `<*mut str>::len`
- `<*const str>::get_unchecked`
- `<*mut str>::get_unchecked_mut`
- `NonNull::<str>::get_unchecked_mut`
@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Dec 17, 2021
@WaffleLapkin
Copy link
Member Author

@m-ou-se I've edited the documentation as you suggested

@WaffleLapkin
Copy link
Member Author

Actually... I now dought that these APIs are useful.

While &str and &[u8] are different in that &str guarantees more about the data, *const str and *const [u8] are not different at all! As discussed while editing safety comments, it's totally fine for *const str to point to non-utf8 bytes, for example.

So I'm not sure that using and operating on *const str actually gives us any advantages over using *const [u8].

@WaffleLapkin
Copy link
Member Author

I'm going to close this PR per the reasoning above. Feel free to ping me, if you disagree and think that these APIs are useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants