-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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_cstr_methods
#101719
Comments
…r=oli-obk Make `CStr::from_ptr` `const`. Should be included in rust-lang#101719. cc `@WaffleLapkin`
…r=oli-obk Make `CStr::from_ptr` `const`. Should be included in rust-lang#101719. cc ``@WaffleLapkin``
…r=oli-obk Make `CStr::from_ptr` `const`. Should be included in rust-lang#101719. cc `@WaffleLapkin`
…r=oli-obk Make `CStr::from_ptr` `const`. Should be included in rust-lang#101719. cc ``@WaffleLapkin``
@WaffleLapkin are any of these uncontroversial enough that you'd be comfortable const stabilizing them? For #107429 I had to mark some of the memchr functions const stable, and the methods here largely have the same const dependencies. So, at least a subset of these could probably go const stable in the same release. |
@tgross35 I personally think that all of these are uncontroversial and I'd be very comfortable stabilizing them, however I do not posses the power to do so. Stabilizing library APIs is a prerogative of |
Rightieo, I just was wondering if you had any bad feeling that any of them would be unmaintainable as const. I think the FCP could take place on the PR since this is quite small, similarly to #107429. Would you like to make the stabilization PR? If not, I don't mind doing it tomorrow. (in either case, using my commit 877e9f5 as a base is likely a good idea to avoid a smidge of rebasing once #107429 is in) |
I'll live the PR to you :) |
Alright, I've opened #107624 |
Make `CStr::from_ptr` `const`. Should be included in rust-lang/rust#101719. cc ``@WaffleLapkin``
…lnay Stabilize `const_cstr_methods` This PR seeks to stabilize `const_cstr_methods`. Fixes most of rust-lang#101719 ## New const stable API ```rust impl CStr { // depends: memchr pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, FromBytesWithNulError> {...} // depends: const_slice_index pub const fn to_bytes(&self) -> &[u8] {} // depends: pointer casts pub const fn to_bytes_with_nul(&self) -> &[u8] {} // depends: str::from_utf8 pub const fn to_str(&self) -> Result<&str, str::Utf8Error> {} } ``` I don't think any of these methods will have any issue when `CStr` becomes a thin pointer as long as `memchr` is const (which also allows for const `strlen`) . ## Notes - `from_bytes_until_nul` relies on `const_slice_index`, which relies on `const_trait_impls`, and generally this should be avoided. After talking with Oli, it should be OK in this case because we could replace the ranges with pointer tricks if needed (worst case being those feature gates disappear). rust-lang#107624 (comment) - Making `from_ptr` const is deferred because it depends on `const_eval_select`. I have moved this under the new flag `const_cstr_from_ptr` rust-lang#107624 (comment) cc `@oli-obk` I think you're the const expert `@rustbot` modify labels: +T-libs-api +needs-fcp
…lnay Stabilize `const_cstr_methods` This PR seeks to stabilize `const_cstr_methods`. Fixes most of rust-lang#101719 ## New const stable API ```rust impl CStr { // depends: memchr pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, FromBytesWithNulError> {...} // depends: const_slice_index pub const fn to_bytes(&self) -> &[u8] {} // depends: pointer casts pub const fn to_bytes_with_nul(&self) -> &[u8] {} // depends: str::from_utf8 pub const fn to_str(&self) -> Result<&str, str::Utf8Error> {} } ``` I don't think any of these methods will have any issue when `CStr` becomes a thin pointer as long as `memchr` is const (which also allows for const `strlen`) . ## Notes - `from_bytes_until_nul` relies on `const_slice_index`, which relies on `const_trait_impls`, and generally this should be avoided. After talking with Oli, it should be OK in this case because we could replace the ranges with pointer tricks if needed (worst case being those feature gates disappear). rust-lang#107624 (comment) - Making `from_ptr` const is deferred because it depends on `const_eval_select`. I have moved this under the new flag `const_cstr_from_ptr` rust-lang#107624 (comment) cc ``@oli-obk`` I think you're the const expert ``@rustbot`` modify labels: +T-libs-api +needs-fcp
@WaffleLapkin I think you can close this tracking issue if you would like, since #107624 merged. |
Tracking issue rust-lang#101719 was for `const_cstr_methods`, rust-lang#113219 is a new issue specific for `const_cstr_from_ptr`.
…ing-issue, r=ChrisDenton Update the tracking issue for `const_cstr_from_ptr` Tracking issue rust-lang#101719 was for `const_cstr_methods`, rust-lang#113219 is a new issue specific for `const_cstr_from_ptr`. (I believe rust-lang#101719 could also be closed) `@rustbot` label +T-libs-api +A-docs
…ing-issue, r=ChrisDenton Update the tracking issue for `const_cstr_from_ptr` Tracking issue rust-lang#101719 was for `const_cstr_methods`, rust-lang#113219 is a new issue specific for `const_cstr_from_ptr`. (I believe rust-lang#101719 could also be closed) ``@rustbot`` label +T-libs-api +A-docs
…ing-issue, r=ChrisDenton Update the tracking issue for `const_cstr_from_ptr` Tracking issue rust-lang#101719 was for `const_cstr_methods`, rust-lang#113219 is a new issue specific for `const_cstr_from_ptr`. (I believe rust-lang#101719 could also be closed) ```@rustbot``` label +T-libs-api +A-docs
Feature gate:
#![feature(const_cstr_methods)]
This is a tracking issue for
CStr
methods asconst
functions.Public API
Steps / History
CStr
methods #100291const_cstr_methods
#107624Unresolved Questions
Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: