Re: [Json] JSON and int64s - any change in current best practice since I-JSON

[Joe Hildebrand <[e-mail]>]

Another approach on the horizon is:

https://github.com/tc39/proposal-json-parse-with-source

Still, moving to CBOR is likely to get you much better interoperability, as mentioned in this thread.

— 
Joe Hildebrand

> On Jan 16, 2024, at 3:04 PM, Rob Sayre <[e-mail]> wrote:
> 
> To suggest a positive path forward:
> 
> https://es.discourse.group/t/cbor-js-and-the-cbor-object/1759
> 
> That is the better fix in my opinion, because BigInts are not the only problem.
> 
> JavaScript has precise number types now (Uint8Array etc etc), and CBOR can represent these well.
> 
> Browsers also have another serialization method called "Structured Clone", which does a lot more than JSON:
> https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
> 
> I mention this one to show that CBOR is totally tractable here.
> 
> People often try to adjust JSON or write schema systems to deal with these issues, but CBOR is a better way forward (imo) because it fixes many issues all at once.
> 
> thanks,
> Rob
> 
> 
> On Tue, Jan 16, 2024 at 9:09 AM Rob Sayre <[e-mail]> wrote:
> Hi,
> 
> I had the same thought as Pete a while back, but found that JS engines actually bar you from encoding these as JSON:
> 
> > let two_55th = BigInt(2) ** BigInt(55)
> > two_55th
> 36028797018963968n
> > JSON.stringify(two_55th)
> VM189:1 Uncaught TypeError: Do not know how to serialize a BigInt
>     at JSON.stringify (<anonymous>)
>     at <anonymous>:1:6
> 
> I can't find the reference for this one, but the reason they gave was that /adding/ support broke too much running code, even though it would be easy to add, since the second command there sure does stringify that number.
> 
> I think the issue was that too many programs rely on JSON.parse returning a JavaScript Number type (distinct from BigInt), so you'll run into problems like this TypeError:
> 
> > let my_plain_number = JSON.parse("42")
> > my_plain_number
> 42
> > my_plain_number + two_55th
> VM429:1 Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions
>     at <anonymous>:1:17
> 
> So, I-JSON remains correct.
> 
> thanks,
> Rob
> 
> 
> On Tue, Jan 16, 2024 at 7:11 AM Tim Bray <[e-mail]> wrote:
> Carsten is right. You probably wouldn’t use JSON if you weren’t likely to be interchanging it with other parties over the network, other parties you don’t control.  For quite a while, it has been quite likely that the other parties use JavaScript, and the limits I-JSON places on numbers are a result of this fact. This fact isn’t going away AFAIK.
> 
> On Jan 16, 2024 at 6:22:31 AM, Carsten Bormann <[e-mail]> wrote:
>> Hi Pete,
>> 
>>> On 2024-01-16, at 14:46, Pete Cordell <[e-mail]> wrote:
>>> 
>>> Hi All,
>>> 
>>> In I-JSON it recommends encoding 64-bit values using a string because many parsers (in particular browsers) always represent numbers using floating point doubles.
>> 
>> (many parsers == JavaScript’s JSON.parse)
>> 
>>> We're over 8 years on from I-JSON and browsers now support things like BigInt.
>> 
>> I’d say the problem wasn’t so much the absence of BigInt, but the fact that JavaScript’s JSON.parse always parses JSON numbers as a JavaScript Number, which is exact only inside (-2**53, 2**53).
>> 
>>> Therefore, I'd be interested to hear if there is any community change of opinion on how 64-bit ints should be handled in JSON.
>> 
>> I think we’d first need wide support for a new equivalent to JSON.parse in JavaScript.
>> 
>> Grüße, Carsten
>> 
>> _______________________________________________
>> json mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/json
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json