From a practical standpoint, defining numbers in JSON to be "whatever double precision binary floating point does, or optionally something more precise" would h

From a practical standpoint, defining numbers in JSON to be "whatever double precision binary floating point does, or optionally something more precise" would have been good enough, and capture what we end up having anyway. Still, I prefer Crockford's choice: that JSON numbers are defined to be numbers. Infinity and the flavors of NaN are... not numbers. In an extensible data interchange format, like [edn][1], people could define conventions about more specific interpretations of numbers, e.g. #ieee754/b64 45.6653 ; this is a double We could build such a format on top of JSON (there are probably multiple), but I again agree with Crockford that this sort of thing does not belong in JSON. Makes for a bunch of headaches, though, for sure. One example is a data scientist I used to work with. He was working with lots of machine learning libraries that liked to use NaN to mean "nothing to see here." A fellow developer ended up writing code that used some sort of convention to work around it, e.g. number := decimal | {"magic-uuid": "NaN"}. I can see why some people are of the opinion "this is stupid, just allow NaNs." I disagree. [1]: https://github.com/edn-format/edn https://github.com/edn-format/edn