Tracking Issue for `inherent_str_constructors` #131114

robertbastian · 2024-10-01T19:59:17Z

Feature gate: #![feature(inherent_str_constructors)]

This is a tracking issue for inherent str constructors.

Public API

str::from_utf8
str::from_utf8_mut
str::from_utf8_unchecked
str::from_utf8_unchecked_mut

Steps / History

ACP: Make core::str::from_utf8* methods available on the str type libs-team#398
Implementation: implement inherent str constructors #136517
Final comment period (FCP)¹
Stabilization PR

Unresolved Questions

None yet.

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

The text was updated successfully, but these errors were encountered:

…rs, r=jhpratt implement inherent str constructors implement rust-lang#131114 this implements - str::from_utf8 - str::from_utf8_mut - str::from_utf8_unchecked - str::from_utf8_unchecked_mut i left `std::str::from_raw_parts` and `std::str::from_raw_parts_mut` out of this as those are unstable and were not mentioned by the tracking issue or the original pull request, but i can add those here as well. i was also unsure of what to do with the `rustc_const_(un)stable` attributes: i removed the `#[rustc_const_stable]` attribute from `str::from_utf8`, `str::from_utf8_unchecked` and `str::from_utf8_unchecked_mut`, and left the`#[rust_const_unstable]` in `str::from_utf8_mut` (btw why is that one not const stable yet with rust-lang#57349 merged?). is there a way to redirect users to the stable `std::str::from_utf8` instead of only saying "hey this is unstable"? for now i just removed the check for `str::from_utf8` in the test in `tests/ui/suggestions/suggest-std-when-using-type.rs`.

Rollup merge of rust-lang#136517 - m4rch3n1ng:inherent-str-constructors, r=jhpratt implement inherent str constructors implement rust-lang#131114 this implements - str::from_utf8 - str::from_utf8_mut - str::from_utf8_unchecked - str::from_utf8_unchecked_mut i left `std::str::from_raw_parts` and `std::str::from_raw_parts_mut` out of this as those are unstable and were not mentioned by the tracking issue or the original pull request, but i can add those here as well. i was also unsure of what to do with the `rustc_const_(un)stable` attributes: i removed the `#[rustc_const_stable]` attribute from `str::from_utf8`, `str::from_utf8_unchecked` and `str::from_utf8_unchecked_mut`, and left the`#[rust_const_unstable]` in `str::from_utf8_mut` (btw why is that one not const stable yet with rust-lang#57349 merged?). is there a way to redirect users to the stable `std::str::from_utf8` instead of only saying "hey this is unstable"? for now i just removed the check for `str::from_utf8` in the test in `tests/ui/suggestions/suggest-std-when-using-type.rs`.

hanna-kruppe · 2025-02-09T13:14:58Z

I would like to request stabilization of these constructors. Yes, they only landed in nightly a few days ago, but there shouldn't be any need to gather more experience with them since they're identical in every way to existing APIs that have been stable forever, except not requiring an import of the str module. On the contrary, them existing unstably currently degrades compiler diagnostics, so stabilizing them ASAP would be helpful.

Implementation history

API change proposal: Make core::str::from_utf8* methods available on the str type libs-team#398
Implementation: implement inherent str constructors #136517
The first PR trying to implement it got bogged down in trying to migrate existing in-tree uses to the new API and raised the question of deprecating the non-inherent functions in a future version. As @tgross35 said there, none of that seems necessary or advisable before the inherent constructors are stabilized.

API summary

impl str {
    pub const fn from_utf8(v: &[u8]) -> Result<&str, Utf8Error>;
    pub fn from_utf8_mut(v: &mut [u8]) -> Result<&mut str, Utf8Error>;
    pub const unsafe fn from_utf8_unchecked(v: &[u8]) -> &str;
    pub const unsafe fn from_utf8_unchecked_mut(v: &mut [u8]) -> &mut str;
}

~~The stable *_mut constructors~~ The stable core::str::from_utf8_mut is not stably const yet, so the inherent equivalent should not be const-stabilized either at this point (but see #136668). The other three constructors are stably const, including from_utf8_unchecked_mut since 1.83.

Experience report

As @joshtriplett wrote on the ACP:

The reaction in today's @rust-lang/libs-api meeting was "why didn't we do this years ago".

I just tried it on a personal project, removing four imports of {std,core}::str and adding #![feature(inherent_str_constructors)] to the respective crate roots instead. Worked as expected. But I'm not going to commit those changes because having to add the feature flag wouldn't be worth it even if that project already required nightly.

joshtriplett · 2025-02-09T13:21:35Z

@rfcbot merge

rfcbot · 2025-02-09T13:21:36Z

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot · 2025-02-09T14:41:53Z

🔔 This is now entering its final comment period, as per the review above. 🔔

tgross35 · 2025-02-09T23:58:02Z

One concern: these new methods bypass the deny-by-default invalid_from_utf8_unchecked lint https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d83927cfe3a10a45e8ce6684396396f5. Updating to cover both is pretty trivial, I think this should be done before stabilization.

There are also a few clippy lints that use the same diagnostic items, somebody should at least open an issue there so they can update.

Lint source: https://github.com/rust-lang/rust/blob/124cc92199ffa924f6b4c7cc819a85b65e0c3984/compiler/rustc_lint/src/invalid_from_utf8.rs

Edit: Thanks GrigorenkoPV for handling rustc, opened rust-lang/rust-clippy#14254 for clippy.

…Urgau `invalid_from_utf8[_unchecked]`: also lint inherent methods Addressing rust-lang#131114 (comment) Also corrected a typo: "_an_ invalid literal", not "_a_ invalid literal".

Rollup merge of rust-lang#137101 - GrigorenkoPV:str-inherent-lint, r=Urgau `invalid_from_utf8[_unchecked]`: also lint inherent methods Addressing rust-lang#131114 (comment) Also corrected a typo: "_an_ invalid literal", not "_a_ invalid literal".

`invalid_from_utf8[_unchecked]`: also lint inherent methods Addressing rust-lang/rust#131114 (comment) Also corrected a typo: "_an_ invalid literal", not "_a_ invalid literal".

…r=Amanieu fix docs for inherent str constructors related to rust-lang#131114 when implementing inherent str constructors in rust-lang#136517, i forgot to change the docs, so the code examples still imported the `std::str` module and used the constructor from there, instead of using "itself" (the inherent constructor).

Rollup merge of rust-lang#137126 - m4rch3n1ng:fix-inherent-str-docs, r=Amanieu fix docs for inherent str constructors related to rust-lang#131114 when implementing inherent str constructors in rust-lang#136517, i forgot to change the docs, so the code examples still imported the `std::str` module and used the constructor from there, instead of using "itself" (the inherent constructor).

rfcbot · 2025-02-19T14:43:22Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

Rollup merge of rust-lang#137277 - m4rch3n1ng:stabilize-inherent-str-constructors, r=tgross35 stabilize `inherent_str_constructors` fcp done in rust-lang#131114 (comment). tracking issue: rust-lang#131114 closes: rust-lang#131114

`invalid_from_utf8[_unchecked]`: also lint inherent methods Addressing rust-lang/rust#131114 (comment) Also corrected a typo: "_an_ invalid literal", not "_a_ invalid literal".

…ors, r=tgross35 stabilize `inherent_str_constructors` fcp done in rust-lang/rust#131114 (comment). tracking issue: #131114 closes: #131114

`invalid_from_utf8[_unchecked]`: also lint inherent methods Addressing rust-lang/rust#131114 (comment) Also corrected a typo: "_an_ invalid literal", not "_a_ invalid literal".

robertbastian 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 1, 2024

robertbastian mentioned this issue Oct 1, 2024

Add inherent constructors on str #131118

Closed

m4rch3n1ng mentioned this issue Feb 3, 2025

implement inherent str constructors #136517

Merged

wmstack mentioned this issue Feb 8, 2025

Rust Analyzer passive or doesn't locate available methods and macros rust-lang/rust-analyzer#19116

Open

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Feb 9, 2025

GrigorenkoPV mentioned this issue Feb 15, 2025

invalid_from_utf8[_unchecked]: also lint inherent methods #137101

Merged

m4rch3n1ng mentioned this issue Feb 16, 2025

fix docs for inherent str constructors #137126

Merged

rustbot mentioned this issue Feb 19, 2025

Tracking issue for release notes of #131114: Tracking Issue for inherent_str_constructors #137276

Open

3 tasks

m4rch3n1ng mentioned this issue Feb 19, 2025

stabilize inherent_str_constructors #137277

Merged

tgross35 changed the title ~~Tracking Issue for inherent_str_constructors~~ Tracking Issue for inherent_str_constructors Feb 19, 2025

tgross35 mentioned this issue Feb 19, 2025

Update existing std::str::* lints to also check inherent_str_constructors rust-lang/rust-clippy#14254

Closed

bors closed this as completed in be73ea8 Feb 20, 2025

apiraino removed the to-announce Announce this issue on triage meeting label Feb 21, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for `inherent_str_constructors` #131114

Tracking Issue for `inherent_str_constructors` #131114

robertbastian commented Oct 1, 2024 •

edited by lukas-code

Loading

hanna-kruppe commented Feb 9, 2025 •

edited

Loading

joshtriplett commented Feb 9, 2025

rfcbot commented Feb 9, 2025 •

edited by Amanieu

Loading

rfcbot commented Feb 9, 2025

tgross35 commented Feb 9, 2025 •

edited

Loading

rfcbot commented Feb 19, 2025

Tracking Issue for inherent_str_constructors #131114

Tracking Issue for inherent_str_constructors #131114

Comments

robertbastian commented Oct 1, 2024 • edited by lukas-code Loading

Public API

Steps / History

Unresolved Questions

Footnotes

hanna-kruppe commented Feb 9, 2025 • edited Loading

Implementation history

API summary

Experience report

joshtriplett commented Feb 9, 2025

rfcbot commented Feb 9, 2025 • edited by Amanieu Loading

rfcbot commented Feb 9, 2025

tgross35 commented Feb 9, 2025 • edited Loading

rfcbot commented Feb 19, 2025

Tracking Issue for `inherent_str_constructors` #131114

Tracking Issue for `inherent_str_constructors` #131114

robertbastian commented Oct 1, 2024 •

edited by lukas-code

Loading

hanna-kruppe commented Feb 9, 2025 •

edited

Loading

rfcbot commented Feb 9, 2025 •

edited by Amanieu

Loading

tgross35 commented Feb 9, 2025 •

edited

Loading