JSON support for BigInt in Chrome/V8
kaizhu256 at gmail.com
Sun Jul 29 08:01:27 UTC 2018
i support @anders’ *conservative* scheme and opened up a github-issue to try and get it included before stage-4 . this might be one of the last-opportunities to change the behavior before its set-in-stone.
there was a previous github-issue on bigint JSON-support  (that led to the current behavior no one is happy about), but it never discussed the *conservative* scheme, hence the revisit.
to summarize, the *conservative* scheme basically copies the same JSON-behavior as Date. users are already familiar with serializing Date, so there shouldn’t be any surprises (or at least less-surprises than throwing an error). this is the simplest, actionable, and least-offensive-to-all-parties solution i can think of (unless someone has a less-offensive-to-all idea). its also applicable in solving the same-issue for future primitives like BigDecimal.
// we copy JSON-behavior of Date
aa = 12345678901234567890n // <bigint primitive>
aa = JSON.stringify(aa) // '"12345678901234567890"' (escaped string)
aa = JSON.parse(aa) // '12345678901234567890' (un-escaped string)
aa = BigInt(aa) // <bigint primitive> (no precision-loss)
aa = new Date() // <Date object>
aa = JSON.stringify(aa) // '"2018-07-28T09:41:47.519Z"'' (escaped string)
aa = JSON.parse(aa) // '2018-07-28T09:41:47.519Z' (un-escaped string)
aa = new Date(aa) // <Date object>
 github-issue - revisit: Support JSON serialisation of BigInt values
 github-issue - [closed] Support JSON serialisation of BigInt values
kaizhu256 at gmail.com
> On 29 Jul 2018, at 12:17 PM, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> As I have tried (apparently in vain) to describe, the other languages already have solutions for BigInt (and much more), which the respectively authors consider both sufficient and good.
> ES6 is pretty late in the game and therefore rather have to adapt itself to the other players.
> These are the options:
> - "Conservative" works right out of the box (although in a somewhat inelegant way). It is backward compatible with many existing ES and non-ES JSON based applications.
> - "RFC8259" support would require changes to the ES6 JSON object. For parsing (`JSON.parse2()`), a `JSONNumber` object as proposed by Michael Theriot seems like a candidate.
> I have limited faith in extending the (for general purpose information interchange) already pretty deficient JSON type scheme; state-of-the-art applications check indata anyway making explicit type information redundant.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss