Skip to content
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

make ParseIntError, ParseFloatError and ParseBoolError reusable (public) #1143

Open
genodeftest opened this issue Jun 2, 2015 · 5 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@genodeftest
Copy link

I'd like to reuse ParseIntError to write a wrapper for the as keyword to make sure the new value matches the old one. It could look like this:

fn convert_usize_to_isize(from: usize) -> Result<isize, ParseIntError> {
    let to = from as isize;
    match (to as usize) == from {
        true => Ok(to),
        false => Err(ParseIntError { kind: IntErrorKind::Overflow }),
    }
}

Furthermore, ParseIntError and ParseFloatError would be useful if one decides to create his own integer or float data type.

To make this work, ParseIntError's kind field, ParseFloatError's kind field and both enums IntErrorKind and FloatErrorKind have to be public.
Whether this should affect ParseBoolError should be discussed.

@genodeftest genodeftest changed the title make ParseIntError and ParseFloatError reusable (public) make ParseIntError, ParseFloatError and ParseBoolError reusable (public) Jun 2, 2015
@andylamp
Copy link

bump, since making it public would allow to do a matching on the Error kind which would really help on situations like this.

@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 29, 2016
@FauxFaux
Copy link

FauxFaux commented Sep 9, 2017

I was hoping to match on whether there was an overflow, so I can handle the numbers differently. I was writing a comparator like this, which might not be the best way, but felt clear to me. Untested, as it doesn't compile.

use std::cmp::Ordering;

pub fn compare_big_numbers(left: &str, right: &str) -> Ordering {
    match left.parse::<u64>() {
        Ok(left) => match right.parse::<u64>() {
            Ok(right) => {
                // both parsed; can use normal comparator (common case)
                return left.cmp(&right)
            },
            Err(e) if e.kind() == ParseIntError::Overflow => {
                // left fits, but right doesn't -> it must be bigger
                return Ordering::Greater;
            },
            _ => panic!("unexpected parse error"),
        },
        Err(e) if e.kind() == ParseIntError::Overflow => {
            // left overflowed, let's see if right does too
            match right.parse::<u64>() {
                Ok(_) => {
                    // it didn't, we're bigger
                    return Ordering::Less;
                },
                Err(e) if e.kind == Overflow => {
...

@cmpute
Copy link

cmpute commented Nov 1, 2022

Vote for this. Is there any reason that the interior of ParseXXXError structs are not public?

@conqp
Copy link

conqp commented Jun 21, 2023

Any news on this? I just stumbled over this when writing a doctest:

assert_eq!(num, Err(StrParseError::<i8, i8>::InvalidRealPart(ParseIntError{ kind: IntErrorKind::InvalidDigit })));

I worked around this via a match statement, but I don't find it particularly idiomatic.

@Stargateur
Copy link

Stargateur commented Jun 21, 2023

You could write this:

use core::num::{IntErrorKind, ParseIntError};

enum StrParseError {
    InvalidRealPart(ParseIntError),
    Foo,
}

fn main() {
    let num = i32::from_str_radix("a12", 10).map_err(|e| StrParseError::InvalidRealPart(e));
    let e = num.map_err(|e| match e {
        StrParseError::InvalidRealPart(e) => e.kind() == &IntErrorKind::InvalidDigit,
        _ => false,
    });

    assert_eq!(Err(true), e);
}

However it would probably be more simple to have IntErrorKind directly instead of ParseIntError or to use your own error type. More on my SO answer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

7 participants