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

[Rob Sayre <[e-mail]>]

Hi,

Yes, I've seen this one. It's difficult to object to it. What is one to
say? "no... you can't have access to the source text".

But I don't think it will really fix this problem outside of
implementations that already have a work-around in strings.

thanks,
Rob


On Wed, Jan 17, 2024 at 11:07 AM Richard Gibson <[e-mail]>
wrote:

> When it advances sometime this year,
> https://github.com/tc39/proposal-json-parse-with-source will address the
> inability to represent and interact with integers outside of the IEEE 754
> binary range in browsers and other ECMAScript implementations.
>
> On Tue, Jan 16, 2024 at 12:10 PM 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
>>
>