[ajtribick]

This is my first time raising a stabilization PR, hopefully I'm not messing up the process here. I had noticed this Zulip thread where it is mentioned that the stabilization guide is outdated and the FCP is done on the stabilization PR now. Thanks to @niklasf for keeping the tracking issue up-to-date, the Implementation history and API description are taken striaght from there.

Stabilization report

Closes #134821

See also Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/327149-t-libs.2Fapi-changes/topic/How.20to.20proceed.20with.20int_from_ascii

Implementation history

• Abandoned implementation: Implement int_from_ascii_radix #105206
• API change proposal: Add from_bytes_radix function libs-team#469
• Implementation for T: Implement int_from_ascii (#134821) #134824
• Implementation for NonZero<T>: feat: Implement int_from_ascii for NonZero<T> #152267
• Update method signature after Zulip discussion: feat: Update method signature of int_from_ascii #159554

API being stabilized

For each integer type X (usize, u8, u16, u32, u64, u128, isize, i8, i16, i32, i64, i128):

// core::num

impl X {
    pub fn from_ascii_bytes<T>(src: T) -> Result<X, ParseIntError>
    where
        T: AsRef<[u8]>;

    pub fn from_ascii_bytes_radix<T>(src: T, radix: u32) -> Result<X, ParseIntError>
    where
        T: AsRef<[u8]>;
}

impl NonZero<X> {
    pub fn from_ascii_bytes<T>(src: T) -> Result<Self, ParseIntError>
    where
        T: AsRef<[u8]>;

    pub fn from_ascii_bytes_radix<T>(src: T, radix: u32) -> Result<Self, ParseIntError>
    where
        T: AsRef<[u8]>;
}

Experience report

The tracking issue has received a number of emoji reactions, including 7 thumbs up when it was suggested to FCP this on Jun 24 #134821 (comment)

The atoi crate which provides this functionality with a different API, has over 200 million downloads, indicating that there is a need for the ability to do this.

To validate the design, I have built a reduced version of a parser that makes use of this feature at https://github.com/ajtribick/int_from_ascii_test

Potential issues / questions

• Should there be a lint against use of this API with &str, as suggested in Tracking Issue for int_from_ascii #134821 (comment)

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey

[pthariensflame]

Seems like you're not actually stabilizing the const aspects of these. We have no opinion on whether or not you should, to be clear: we just noticed the discrepancy between the PR description and the actual commit.

[ajtribick]

Thanks, good point, updated the description.

[Mark-Simulacrum]

@rfcbot fcp merge libs

[rust-rfcbot]

@Mark-Simulacrum has proposed to merge this. The next step is review by the rest of the tagged team members:

• @ChrisDenton
• @Mark-Simulacrum
• @cuviper
• @dtolnay
• @joshtriplett
• @nia-e
• @the8472
• @thomcc

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!

cc @rust-lang/libs-ping: FCP proposed for libs, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[clarfonthey]

Note that this relies on AsRef<[u8]> while the string API accepts &str. This would allow passing in both string and byte slices, as well as ByteStr, but could eat entire vectors for example if passed by value.

[Scripter17]

Note that this relies on AsRef<[u8]> while the string API accepts &str. This would allow passing in both string and byte slices, as well as ByteStr, but could eat entire vectors for example if passed by value.

I think if someone is passing in entire vectors that's more a them problem than anything. Maybe worth a Clippy lint but it would be weird if a function called from_ascii couldn't take a &[ascii::Char] without a manual conversion.