adds as_str to Number if arbitrary_precision is enabled

[chanced]

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]

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

[dtolnay]

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!

[dtolnay]

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.)

[chanced]

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."

[chanced]

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);
}

[chanced]

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.

[dtolnay]

Thanks!