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

Is there a way to parse a number from string? #412

Closed
iddm opened this issue Feb 15, 2018 · 7 comments
Closed

Is there a way to parse a number from string? #412

iddm opened this issue Feb 15, 2018 · 7 comments
Labels

Comments

@iddm
Copy link

iddm commented Feb 15, 2018

Let's say we have an example:

{
    "user": {
        "id": "78358783457112"
    }
}

Is there a way to parse it into this:

#[derive(Deserialize)]
struct UserId(pub u64)

#[derive(Deserialize)]
struct User {
    user_id: UserId
}

At this moment it works perfectly and does not parse this because of types: the u64 type is expected rather than String. However, I'd like to have an option to parse numbers from string too. What about doing it like this?

#[derive(Deserialize)]
struct User {
    #[serde(from_string)]
    user_id: UserId
}

I was unable to find something like this in the documentation, if there is such an option, feel free to point me right there.

@iddm iddm changed the title Is there a way to change the type of original value? Is there a way to parse a number from string? Feb 15, 2018
@dtolnay
Copy link
Member

dtolnay commented Feb 15, 2018

You could provide a Deserialize impl for UserId that handles integers and strings -- playground. Or if you want to handle strings only in this one place and not change the Deserialize impl, you would do that with a deserialize_with attribute on the user_id field. That attribute specifies an alternative way to deserialize a field other than the Deserialize impl of the field's type. This page gives an example of using deserialize_with.

@iddm
Copy link
Author

iddm commented Feb 15, 2018

@dtolnay thanks, I thought about that too. But would not it be simpler for users just to have this as a macro attribute as I proposed above? This is a common problem with javascript, for example, where it does not have big integer numbers but floats only so services provide strings instead of numbers.

@dtolnay
Copy link
Member

dtolnay commented Feb 15, 2018

Yes you're right! I missed the suggestion. We have been tracking this in serde-rs/serde#553 (comment) along with some other recurring customizations that would be valuable to provide in an auxiliary library. Would you be interested in picking some of the use cases from that thread and designing a library around them to provide implementations as serialize_with / deserialize_with functions?

@iddm
Copy link
Author

iddm commented Feb 15, 2018

@dtolnay I'd try doing that, just depends on my free time. Now, it seems, I don't have any other choice, because my code really needs to parse string numbers and I want to do it gracefully :) So, this library obviously will not be able to use serde attributes because they are owned by another crate which the auxiliary library will depend on. Could you suggest me a name for such an attribute? Or, another way, the auxiliary library could just provide a module with implementations which could be used with:

#[derive(Deserialize)]
struct A {
    [serde(with = "my_auxiliary_library::string_to_int")]
    value: u64
}

Update: Ok, I think it is reasonable to provide both if possible: serde_aux attribute and the module because it will be needed anyway.

@iddm
Copy link
Author

iddm commented Feb 22, 2018

I made some very easy library because I needed this functionality very much. I think I will elaborate it later.

@spartucus
Copy link

Any official updates here?

@JusSergey
Copy link

I made some very easy library because I needed this functionality very much. I think I will elaborate it later.

Thank you so much :) I have exactly the same trouble and your library really saved me from writing the same

@serde-rs serde-rs locked and limited conversation to collaborators Nov 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

4 participants