Re:TOML: Tom's Obvious Minimal Language
by gliptic on Sunday May 21, 2023 @12:18PM
(#36022421)
JSON allows you to store arbitrarily large integers/floats. It's only in JS this is a problem, not if you use JSON in languages that support larger (than 54-bit) integers.
[ Parent
| on HN ]
That's the freedom of unspecified behavior.
Re:TOML: Tom's Obvious Minimal Language
by marcosdumay on Sunday May 21, 2023 @01:11PM
(#36022888)
As long as the same person is on both sides of a communication channel, he has total freedom on what to say and will understand it flawlessly!
That's what standards are for, isn't it?
Annoyingly, it also doesn't support BigInt, which would alleviate this problem in JS as well
A number in JSON can have an arbitrary number of digits, i.e. it can represent any BigInt value.
Re:TOML: Tom's Obvious Minimal Language
by Supermancho on Sunday May 21, 2023 @06:08PM
(#36025101)
> A number in JSON can have an arbitrary number of digits, i.e. it can represent any BigInt value.
In my experience, violating type constraints causes problems in downstream systems (usually with parsing or trying to operate on invalid values).
Number, as defined by the JSON Schema spec. A 32-bit signed integer. It has a minimum value of -2,147,483,648 and a maximum value of 2,147,483,647
BigInt is defined by various (MSFT, MySQL, etc): -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
Most systems use a JSON String for large numbers, out of necessity, not JSON Number.
In context, BigInt refers to arbitrary precision integers [1], rather than any particular size of integer, hence "arbitrary number of digits".