JSON doesn’t specify its numeric types: the mapping of a string of digits to concrete numeric types is implementation-defined: so, JSON doesn’t need specific syntax for BigInts or arbitrary-precision decimals.
Current parsers cannot start returning BigInts instead of numbers without that being a breaking change. And I'm not sure anyone wants a format where the result may change types based on the size of the number, especially for languages where arbitrary precision types are not compatible with other numbers.
> Current parsers cannot start returning BigInts instead of numbers without that being a breaking change.
Current parsers aren't uniform here. Since the JSON spec is silent on what post-parsing format is used for numbers, each parser is free to do whatever makes sense in the context of the host language. I reckon you'll find some JSON parsers use bigints already, especially in languages with first-class bigint support (such as various Lisp dialects)
> And I'm not sure anyone wants a format where the result may change types based on the size of the number
That's nothing to do with the format, that's to do with the parser. Some parsers already do exactly that – use an integer type for numbers that are integers, use a floating point type for numbers that contain decimal points
> I reckon you'll find some JSON parsers already use bigints already
Yep. Python is one such language. I've seen this catch people by surprise when they discover their serial number (which granted, should have been a string in the first place) doesn't survive a trip from Python to JSON to Javascript, among other languages.
It doesn’t help that it’s called a serial number, and is sequential (hence, serial, but some manufacturers don’t care). num++ is easier than implementing increment_number_string that works on ASCII digits.
Yep, "serial number" was basically the argument for using a number type in the first place, and here they were sequential. Even then, ignoring the JSON peculiarities, it would have been ok up till someone had the brilliant idea to have x digit serial numbers for one product line, and y digit for another. With only zero padding to tell them apart. This person, not a programmer, could not fathom why it caused the "tech heads to go crazy".
