Skip to content

Tracking Issue for int_from_ascii #134821

Description

@niklasf

View all comments

Feature gate: #![feature(int_from_ascii)]

This is a tracking issue for int_from_ascii, providing equivalent methods to {usize,u8,u16,u32,u64,u128,isize,i8,i16,i32,i64,i128}::from_str() and from_str_radix() that allow working directly on byte slices, in order to skip UTF-8 validation.

Public API

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

// core::num

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

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

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

    pub const fn from_ascii_bytes_radix<T>(src: T, radix: u32) -> Result<Self, ParseIntError>
    where
        T: [const] AsRef<[u8]> + [const] core::marker::Destruct;
}
Originally with src: &[u8]
// core::num

impl X {
    pub const fn from_ascii(src: &[u8]) -> Result<X, ParseIntError>;
    pub const fn from_ascii_radix(src: &[u8], radix: u32) -> Result<X, ParseIntError>;
}

impl NonZero<X> {
    pub const fn from_ascii(src: &[u8]) -> Result<Self, ParseIntError>;
    pub const fn from_ascii_radix(src: &[u8], radix: u32) -> Result<Self, ParseIntError>;
}

Steps / History

Unresolved Questions

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    T-libs-api[DEPRECATED; DO NOT USE]
    on Dec 27, 2024
  2. niklasf commented on Dec 27, 2024

    @niklasf
    ContributorAuthor

    Opened PR #134824 with an implementation.

  3. added a commit that references this issue on Jan 16, 2025
  4. added 2 commits that reference this issue on Jan 30, 2025
  5. 91 remaining items

  6. sorairolake commented on Feb 7, 2026

    @sorairolake
    Contributor

    @niklasf Could you please update #134821 (comment) after #152267 is merged?

    The current version only mentions primitive integer types, so I think the beginning description, the Public API section, and the Steps / History section should be updated.

    Examples:

    // core::num
    
    impl NonZero<T> {
        pub const fn from_ascii(src: &[u8]) -> Result<Self, ParseIntError>;
        pub const fn from_ascii_radix(src: &[u8], radix: u32) -> Result<Self, ParseIntError>;
    }
  7. niklasf commented on Feb 7, 2026

    @niklasf
    ContributorAuthor

    Thanks. I think that means #152193 should be stabilized first, so we don't end up with NonZero<T>::from_ascii_radix() without a matching NonZero<T>::from_str_radix().

  8. added a commit that references this issue on Feb 7, 2026
  9. added a commit that references this issue on Feb 7, 2026
  10. dimpolo commented on Jun 24, 2026

    @dimpolo
    Contributor

    nonzero_from_str_radix was stabilized.
    Is it time to FCP this?

  11. ajtribick commented on Jul 20, 2026

    @ajtribick
    Contributor

    Well I raised this one on Zulip and the discussion there suggested changing the API to:

    impl X {
        pub const fn from_ascii_bytes<T>(src: T) -> Result<X, ParseIntError>
        where
            T: [const] AsRef<[u8]> + [const] core::marker::Destruct;
    
        pub const fn from_ascii_bytes_radix<T>(src: T, radix: u32) -> Result<X, ParseIntError>
        where
            T: [const] AsRef<[u8]> + [const] core::marker::Destruct;
    }

    So have raised #159554 to implement that.

  12. added 3 commits that reference this issue on Jul 27, 2026
  13. added a commit that references this issue on Jul 27, 2026
  14. added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
  15. sorairolake commented on Sep 3, 2026

    @sorairolake
    Contributor

    If this feature is stabilized, I think it would be good to add a lint check for cases where &str is passed as a parameter corresponding to these methods in Clippy.


    let x = u8::from_ascii_bytes("+10");
    let y = NonZero::<i32>::from_ascii_bytes_radix("A", 16);

    Could be written as:

    let x = u8::from_str("+10");
    let y = NonZero::<i32>::from_str_radix("A", 16);
  16. ajtribick commented on Sep 22, 2026

    @ajtribick
    Contributor

    I don't know how much evidence is needed for the "experience" part of the stabilisation report, but I can verify that it works for the parser application I want to use it for. Minimal example: https://github.com/ajtribick/int_from_ascii_test

    I would actually also need floating point versions of these functions ("float_from_ascii") but I don't think it makes sense to start work on those before stabilising this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions