On Jul 24, 2018, at 18:29, Anders Rundgren <[email protected]> wrote: > > On 2018-07-24 17:09, Carsten Bormann wrote: >> On Jul 24, 2018, at 16:31, Anders Rundgren <[email protected]> >> wrote: >>> >>> JSON isn’t really a topic for tc39 only but since the IETF consider JSON >>> "done", an open question is where possible future developments should take >>> place, >> No, that is not the question. >>> including dealing with new data types like BigInt. >> That, indeed, is a question for JavaScript. It has nothing to do with >> “developing” JSON; JSON can already represent BigInt just fine. > > Serializing BigInt as JSON Number is the solution then?
For applications that make good use of BigInt, I would say so. So you wouldn’t use JSON.parse, but a new interface that preserves integers beyond 2**53 as BigInt (or possibly even all integers; I don’t want to design this on a napkin) > There are a few argument against that: > > - This would typically require low-level parsers to always rely on a > BigNumber type. Oracle's JSON-B does exactly that. Currently there is no > BigNumber type in JS or .NET. There is no need for the above interface to handle floating point numbers (NR2/NR3). > - There is quite a bunch of IETF standards defining JSON structures. As far > as I know none of them exploit JSON outside of its original, JS-induced > limitations. Maybe the IETF was smart enough to stay in the confines of I-JSON… But really, JSON never had that particular limitation. A JSON-based ecosystem that wants to enable the use of JavaScript JSON.parse does, as Twitter found out when they were sending their perfectly valid JSON to JavaScript applications. > - Although BigInt is a very welcome addition to JS, usages are few and > typically confined to specific things like crypto or money. Creating > backward incompatibility for that is IMO counterproductive. Right, so maybe the motivation for touching JSON really isn’t that massive. > - Serializing BigInts as a string does not break anything. After JSON.parse, they are text strings then, not BigInts. Generally, there is the expectation that, for an interesting set of x, JSON.parse(JSON.stringify(x)) == x Hence the exception when you pass BigInt to JSON.stringify today. >>> Personally I think the JSON WG should be rebooted but apparently I’m rather >>> alone with that idea. >> Indeed. > > That might be the case but it doesn’t solve the problem. It also doesn’t create the problem of damaging JSON by instability. >> Frankly, JSON, together with the JavaScript-induced limitations in its >> ecosystem as documented in RFC 7493, is not a very brilliant data >> interchange format. > > It seems to work well in spite of not being brilliant. Right. As do bicycles. Until you need to transport a sofa or cross the Atlantic. JSON is the right tool for a large number of jobs. > Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-) Can’t disagree here :-) Grüße, Carsten _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
