Comment by mr_crankypants | Hacker News Reader

Comment by mr_crankypants | Hacker News Reader

Parent Full thread

It's perhaps less a limitation of JSON and more a limitation of JavaScript itself[1].

But still, given that easy consumption from JavaScript is the ultimate primordial reason for choosing JSON over other formats, it seems like trying to transmit integers with more than 53 bits of precision over JSON is asking for trouble. Because it's only a matter of time until someone will want to do something like write a new service in Node, and the JavaScript parsers for other formats are at least somewhat more likely to guide people toward using BigInt for large integers.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

In TC39, we specified BigInt to not participate in JSON by default, precisely because emitting it as a native JSON number would not be able to be read back by JSON.parse() and many other environments would also not be able to parse it without extra logic if they simply use IEEE754 double.

I explicitly asked for and achieved step 2. in the modified SerializeJSONProperty algorithm[1] so that users could decide and opt-in to serializing BigInts as strings if they so choose, with or without some sigil that could be interpreted by a reviver function. e.g.:

  > JSON.stringify(BigInt(1))
  TypeError: Do not know how to serialize a BigInt
  ...
  > BigInt.prototype.toJSON = function() { return this.toString(); }
  > JSON.stringify(BigInt(1))
  '"1"'

[1]: https://tc39.es/proposal-bigint/#sec-serializejsonproperty

Reply on news.ycombinator.com