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

adds as_str to Number if arbitrary_precision is enabled #1067

Merged
merged 4 commits into from
Sep 9, 2023

Conversation

chanced
Copy link
Contributor

@chanced chanced commented Sep 6, 2023

Resolves #1066 by adding as_str to Number if arbitrary_precision is enabled.

I'm sorry this is a silly question but where should I put tests for the method?

@chanced
Copy link
Contributor Author

chanced commented Sep 6, 2023

Woops, sorry. I Forgot to add #[cfg(feature = "arbitrary_precision")] somehow.

Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry this is a silly question but where should I put tests for the method?

The example code runs as a test. That is sufficient.

Thanks for the PR!

src/number.rs Outdated
Comment on lines 287 to 288
/// assert_eq!(Number::from_f64(256.0).unwrap().as_str(), "256.0");
/// assert_eq!(Number::from_f64(34.0).unwrap().as_str(), "34.0");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty different from the intended usage of as_str(), right? I don't see why one would use as_str in this manner. From #1066 I'd inferred it would be to inspect the original formatting of a number that was parsed from a JSON document using serde_json::from_str.

I think showing that representative usage would make a more compelling example.

I've learned the value of method-level example code like this is chiefly to illustrate why one would want to call it, as opposed to how to call a method in Rust, which the reader can be assumed to know by the time they are reading serde_json docs. (Yes, most of the existing examples are bad and old.)

Copy link
Contributor Author

@chanced chanced Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that makes total sense sense. Thank you for the wisdom; I'm horrible at documentation and I'm definitely trying to get better at it. The rust ecosystem has certainly raised the bar on such.

I hope the example I just committed is more in line with what you are thinking. Please let me know if there's more I can do to improve it.

edit: removed comment about an example with a leading 0 returning an error. The JSON diagram on numbers confused me; it seemed like leading 0s were allowed. However, the spec explicitly states "A number is a sequence of decimal digits with no superfluous leading zero."

Copy link
Contributor Author

@chanced chanced Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The updated example is:

for value in [
    "7",
    "12.34",
    "34e-56789",
    "0.0123456789000000012345678900000001234567890000123456789",
    "343412345678910111213141516171819202122232425262728293034",
    "-343412345678910111213141516171819202122232425262728293031",
] {
    let number: Number = serde_json::from_str(value).unwrap();
    assert_eq!(number.as_str(), value);
}

Copy link
Contributor Author

@chanced chanced Sep 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty different from the intended usage of as_str(), right? I don't see why one would use as_str in this manner. From #1066 I'd inferred it would be to inspect the original formatting of a number that was parsed from a JSON document using serde_json::from_str.

The reason I personally need as_str is to avoid an allocation via to_string.

For a bit of context, I'm working on a JSON Schema crate which evaluates serde_json::Values. In order to properly compare decimals and also to support big numeric types, I have written parsers to convert the string value of Number to num::BigRational and num::BigInt.

I hope the example illustrates the utility of having access to the underlying string. If others need to compare fractions or deal with big numbers, "arbitrary_precision" with a custom string parser is, so far as I can tell, the only viable path to achieving said goal.

@chanced chanced marked this pull request as ready for review September 7, 2023 17:49
Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@dtolnay dtolnay merged commit 028b643 into serde-rs:master Sep 9, 2023
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

It would be great if Number had an as_str method if "arbitrary_precision" is enabled.
2 participants