Hacker News Reader

Comment by crazygringo | Hacker News Reader

> Almost all JSON consumers are either deserializing to a spec that already contains type information

But different languages interpret different strings in different ways by default.

This leads to major bugs.

One of the great strengths of JSON is that parsing a number is well-defined.

The way you're suggesting would lead to people emitting JSON with leading zeros sometimes, and then some languages end up interpreting certain numbers as octal.

No thank you.

View on HN

JSON numbers are just certain strings, but some tools that deal with json such as jq feel a need to mangle the numbers anyway

I don't know what you mean.

JSON numbers are far more restrictive than strings and carry precisely defined meaning in a way that arbitrary strings don't. They're only "just certain strings" in the same way anything can be serialized to a string, which doesn't really mean anything.

What does jq do to them?

It replaces them with different numbers, even if you don't try to do math on them :)

  echo 1.4e99999999999999 | jq
  1.7976931348623157e+308

While I agree that the meaning of json numbers exists, I'm not sure which JSON standard you're referring to that contains this meaning. json.org certainly does not contain it, and links to ECMA-404, which just says "JSON is agnostic about the semantics of numbers."

jq tries to preserve number precision if you don't do operation with them, but as you noted this is within some sanity. If you do operations the involved numbers will first be converted to binary64 (aka double), same as node and most other languages. This is what is recommended by RFC 7159 for interoperability.

Reply on news.ycombinator.com