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

[Tim Bray <[e-mail]>]

 If there were going to be an ESON effort, the hills I’d die on are:


   1. Lose the commas
   2. @-prefixed date stamp
   3. B-prefixed bigint
   4. I could live with i-prefixed and f-prefixed integers and floats if
   people cared but the JSON “number” abstraction has never got in my way
   5. Comments are totally not necessary


But this is a fever dream, JSON has been JSON for many years and probably
has more technical inertia than all the other data formats put together.

On Jan 17, 2024 at 9:27:30 AM, Rob Sayre <[e-mail]> wrote:

> On Wed, Jan 17, 2024 at 9:03 AM Carsten Bormann <[e-mail]> wrote:
>
>> On 2024-01-17, at 17:57, Tim Bray <[e-mail]> wrote:
>> >
>> >
>> >
>> > On Jan 17, 2024 at 8:54:40 AM, Carsten Bormann <[e-mail]> wrote:
>> >>
>> >> What *is* a “local bigint type” in Rust?  Ruby?  Erlang?
>> >
>> > An integer of unbounded size, no?
>>
>> But 1 is not of unbounded size, so I don’t understand what 1n means.
>>
>> The syntax 1n seems to assume that the target platform has a separable
>> type for those integers of unbounded size.  That doesn’t work with
>> platforms where integers of unbounded size aren’t anything special.  It is
>> also weird with platforms that have many bounded types to choose from (is
>> i128 OK for 1n?).
>>
>
> I still think CBOR would be better here, because you can cover all this
> stuff:
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Typed_arrays#typed_array_views
>
> and get Blobs:
> https://developer.mozilla.org/en-US/docs/Web/API/Blob
>
> and Dates:
> https://www.rfc-editor.org/rfc/rfc8949.html#section-3.4.1
>
> The BigInt in JSON issue is widely duplicated in the TC39 Github, so I do
> agree the problem is real. Might as well really go after all of this stuff
> at once, though.
>
> thanks,
> Rob
>