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

[Rob Sayre <[e-mail]>]

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
>>
>