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

[Joe Hildebrand <[e-mail]>]

I've got something working in Peggy (https://peggyjs.org <https://peggyjs.org/>) with a couple minutes of work.  I can publish it if it's useful.

Or, start with https://github.com/peggyjs/peggy/blob/main/examples/json.pegjs and hack in whatever features you want.

The approach that seems right to me is to make it explicit; bigint's get suffixed with 'n', and there is not automatic promotion to break existing code.

Other features to include might come from:

- https://json5.org/
- jsonc (various places, just adds both kinds of JS comments)
- CBOR diagnostic notation (https://www.rfc-editor.org/rfc/rfc8949.html#diagnostic-notation)

If we were to add Date (which is absolutely the most important after bigint), I might want the other JS built-in types as well.  I wonder if we could reuse the CBOR tag registry, and make Date stringify to:

0('2024-01-17T16:26:23Z') 
or 
dt('2024-01-17T16:26:23Z')

(using draft-ietf-cbor-edn-literals)

— 
Joe Hildebrand

> On Jan 17, 2024, at 4:19 AM, Pete Cordell <[e-mail]> wrote:
> 
> On 17/01/2024 04:49, Joe Hildebrand wrote:
>> 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.
> 
> Thanks, Joe.  That's very interesting.
> 
> It makes my wonder, does anyone know of any existing JavaScript libraries that a browser can download on the fly that can parse JSON with big numbers?
> 
> Thanks again,
> 
> Pete.
> -- 
> ---------------------------------------------------------------------
> Pete Cordell
> Codalogic Ltd
> ---------------------------------------------------------------------