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

[Joe Hildebrand <[e-mail]>]

> On Jan 17, 2024, at 1:32 PM, Tim Bray <[e-mail]> wrote:
> 
> If there were going to be an ESON effort, the hills I’d die on are:
> 
>     • Lose the commas

Heh.  I was going to say "trailing commas" which is the exact opposite.  I'd have to do a little prototyping before I agreed with you that we don't need commas at all, but I suspect it would work.  This would also lose us backward-compatibility with JSON, unless the commas are optional instead of forbidden.

If we're not careful, we will just be recreating YAML -- that's another approach we could take, I suppose, but YAML has enough flexibility in its format that I sometimes have a hard time reading it.

>     • @-prefixed date stamp
>     • B-prefixed bigint
>     • 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

I think as long as we specify the behavior adequately this time, we might not need i- and f-.  We could probably discuss prefixes as an extension space over time.

>     • Comments are totally not necessary

This I *strongly* disagree with.  One of the use cases that JSON is misused for is config files, and they badly need comments.

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

All new things have to start somewhere.  Worst case, nobody uses it -- I doubt it will hurt the Internet.

— 
Joe Hildebrand