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
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 11 additions & 0 deletions src/number.rs
Original file line number Diff line number Diff line change
Expand Up @@ -279,6 +279,17 @@ impl Number {
}
}

#[cfg(feature = "arbitrary_precision")]
/// Returns the `&str` representation of the `Number`.
/// ```
/// # use serde_json::Number;
///
/// 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.

pub fn as_str(&self) -> &str {
&self.n
}

pub(crate) fn as_f32(&self) -> Option<f32> {
#[cfg(not(feature = "arbitrary_precision"))]
match self.n {
Expand Down