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

Tracking Issue for const str::split_at* #131518

Open
1 of 4 tasks
zachs18 opened this issue Oct 10, 2024 · 0 comments
Open
1 of 4 tasks

Tracking Issue for const str::split_at* #131518

zachs18 opened this issue Oct 10, 2024 · 0 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@zachs18
Copy link
Contributor

zachs18 commented Oct 10, 2024

Feature gate: #![feature(const_str_split_at)]

This is a tracking issue for using str::split_at, str::split_at_mut, str::split_at_checked, str::split_at_mut_checked in const, which allows dividing one (mutable) string slice into two (fallibly) at an index during const-eval.

Public API

// core::str
impl str {
    pub const fn split_at(&self, mid: usize) -> (&str, &str);
    pub const fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str);
    pub const fn split_at_checked(&self, mid: usize) -> Option<(&str, &str)>;
    pub const fn split_at_mut_checked(&mut self, mid: usize) -> Option<(&mut str, &mut str)>;
}

Steps / History

Unresolved Questions

  • None yet.

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

@zachs18 zachs18 added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Oct 10, 2024
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Oct 29, 2024
Mark `str::is_char_boundary` and `str::split_at*` unstably `const`.

Tracking issues: rust-lang#131516, rust-lang#131518

First commit implements `const_is_char_boundary`, second commit implements `const_str_split_at` (which depends on `const_is_char_boundary`)

~~I used `const_eval_select` for `is_char_boundary` since there is a comment about optimizations that would theoretically not happen with the simple `const`-compatible version (since `slice::get` is not `const`ifiable) cc rust-lang#84751. I have not checked if this code difference is still required for the optimization, so it might not be worth the code complication, but 🤷.~~

This changes `str::split_at_checked` to use a new private helper function `split_at_unchecked` (copied from `split_at_mut_unchecked`) that does pointer stuff instead of `get_unchecked`, since that is not currently `const`ifiable due to using the `SliceIndex` trait.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 29, 2024
Rollup merge of rust-lang#131520 - zachs18:const-str-split, r=Noratrieb

Mark `str::is_char_boundary` and `str::split_at*` unstably `const`.

Tracking issues: rust-lang#131516, rust-lang#131518

First commit implements `const_is_char_boundary`, second commit implements `const_str_split_at` (which depends on `const_is_char_boundary`)

~~I used `const_eval_select` for `is_char_boundary` since there is a comment about optimizations that would theoretically not happen with the simple `const`-compatible version (since `slice::get` is not `const`ifiable) cc rust-lang#84751. I have not checked if this code difference is still required for the optimization, so it might not be worth the code complication, but 🤷.~~

This changes `str::split_at_checked` to use a new private helper function `split_at_unchecked` (copied from `split_at_mut_unchecked`) that does pointer stuff instead of `get_unchecked`, since that is not currently `const`ifiable due to using the `SliceIndex` trait.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

1 participant