-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
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
This was referenced 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.
jhpratt
added a commit
to jhpratt/rust
that referenced
this issue
Feb 14, 2025
… r=Amanieu Stabilize `const_is_char_boundary` and `const_str_split_at`. Tracking issues: rust-lang#131516, rust-lang#131518 Stabilized const API: ```rs // in `core` impl str { // const_is_char_boundary feature const fn is_char_boundary(&self, index: usize) -> bool; // const_str_split_at feature, depends on const_is_char_boundary const fn split_at(&self, mid: usize) -> (&str, &str); const fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str); const fn split_at_checked(&self, mid: usize) -> Option<(&str, &str)>; const fn split_at_mut_checked(&mut self, mid: usize) -> Option<(&mut str, &mut str)>; } ``` This will allow safely splitting string slices during const-eval. Closes rust-lang#131516, Closes rust-lang#131518 This will need FCP. r? libs-api IIUC these do not use any new const language features (i.e. they are implementable manually on stable 1.83.0 using `unsafe`: [playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3679632cd1041084796241b7ac8edfbd)). Cc `@rust-lang/wg-const-eval` (I don't know if I have the permissions for this ping; if not, someone else please ping wg-const-eval if it is necessary)
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 15, 2025
Rollup merge of rust-lang#134016 - zachs18:stable-const-str-split_at, r=Amanieu Stabilize `const_is_char_boundary` and `const_str_split_at`. Tracking issues: rust-lang#131516, rust-lang#131518 Stabilized const API: ```rs // in `core` impl str { // const_is_char_boundary feature const fn is_char_boundary(&self, index: usize) -> bool; // const_str_split_at feature, depends on const_is_char_boundary const fn split_at(&self, mid: usize) -> (&str, &str); const fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str); const fn split_at_checked(&self, mid: usize) -> Option<(&str, &str)>; const fn split_at_mut_checked(&mut self, mid: usize) -> Option<(&mut str, &mut str)>; } ``` This will allow safely splitting string slices during const-eval. Closes rust-lang#131516, Closes rust-lang#131518 This will need FCP. r? libs-api IIUC these do not use any new const language features (i.e. they are implementable manually on stable 1.83.0 using `unsafe`: [playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3679632cd1041084796241b7ac8edfbd)). Cc ``@rust-lang/wg-const-eval`` (I don't know if I have the permissions for this ping; if not, someone else please ping wg-const-eval if it is necessary)
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.
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
inconst
, which allows dividing one (mutable) string slice into two (fallibly) at an index during const-eval.Public API
Steps / History
str::is_char_boundary
andstr::split_at*
unstablyconst
. #131520const_is_char_boundary
#131516Unresolved Questions
Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: