You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Comment in Cargo.toml for feature arbitrary_precision states:
This feature makes JSON -> serde_json::Number -> JSON produce output identical to the input.
But in serde_json::de::scan_exponent, for the exponent marker (e or E), a lowercase e is inserted unconditionally to the internal representation. Therefore, for an input JSON 1.9E10 for example, a "JSON -> serde_json::Number -> JSON" roundtrip results in JSON 1.9e10, which is different from the input JSON.
Is this behaviour intended? If no other code rely on e being lowercase, I suggest we insert an e or E based on the input. Some specification requires some fields always treated as string, and in case they are presented as numbers in JSON, they should be converted to strings verbatim. arbitrary_precision is the only method I found for such circumstances, and I believe it should behave as described in Cargo.toml.
P.S. If you see the above-mentioned change appropriate, I can make a PR for this.
The text was updated successfully, but these errors were encountered:
Comment in
Cargo.toml
for featurearbitrary_precision
states:But in
serde_json::de::scan_exponent
, for the exponent marker (e
orE
), a lowercasee
is inserted unconditionally to the internal representation. Therefore, for an input JSON1.9E10
for example, a "JSON
->serde_json::Number
->JSON
" roundtrip results in JSON1.9e10
, which is different from the input JSON.Is this behaviour intended? If no other code rely on
e
being lowercase, I suggest we insert ane
orE
based on the input. Some specification requires some fields always treated as string, and in case they are presented as numbers in JSON, they should be converted to strings verbatim.arbitrary_precision
is the only method I found for such circumstances, and I believe it should behave as described inCargo.toml
.P.S. If you see the above-mentioned change appropriate, I can make a PR for this.
The text was updated successfully, but these errors were encountered: