3 ms·

> JSON numbers are arbitrary precision. > On the other hand I am not blowing dev and qa time on learning/developing tools to replace curl/jq/browser/text editor

• mr_crankypants 7y ago
  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/Reference/Global_Objects/Number/MAX_SAFE_INTEGER https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  • apaprocki 7y ago
    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 https://tc39.es/proposal-bigint/#sec-serializejsonproperty
• awinder 7y ago
  Or they'd just wrap as a string and move on with life, much as people do when they send uuids which should consume 128-bit as wide strings. The cases I've encountered that actually fundamentally required 64-bit ints are completely overshadowed by the cases where some well-intentioned developer decides to pack 64-bit ints with information to turn it into a uuid as well, so I really hope the consternation over this is from people who work a lot with mathematical apis/systems and not devs doing more heinous things with 64bit ints.
  • patrec 7y ago
    > I really hope the consternation over this is from people who work a lot with mathematical apis/systems and not devs doing more heinous things with 64bit ints. No, it's typically IDs. And my observation is that inexperienced devs start out serializing 64bit IDs as ints and get burned first before they move to text. There are several reasons why you end up with IDs > 2^53 even if 2^53 is good for enumerating ~100k things per earthling: Many cloud providers will give you IDs that are specified to be 64 bit uints, and you'd better not corrupt some fraction of them. Generating unique integers strictly serially does not scale, so you might end up with something like Twitter's snowflake. Or you might want to tag additional info (reserve a few of the low bits for the type of id, or reserve particular ranges for particular types of acccounts etc etc). I can promise you I have run into the issue in real life more than once and it's not just javascript and jq that like to silently corrupt ids by truncating them to double precision. For example pandas is really great at it as well. What makes it especially fun that often only a very small fraction of IDs will be affected (< ~1 in 2000 if uniformly distributed).
    • jdmichal 7y ago
      And this is why I say, if you don't do math on it, it's not a number! IDs are always strings. That we often choose to represent them more compactly as binary numbers is an implementation detail that should not be leaking out of your API.
• Aeolun 7y ago
  You need some integer to make 53 bits though...