+1 on getting this sorted before stage 4
As people have said before, JSON already supports BigInts. We of course need to
preserve backwards compatibility with JS and try not to break how other
languages use JSON.
I think the best way to satisfy everyone is to give ourselves some flexibility
going forwards and JSONifying BigInts as strings doesn’t allow JSON to do what
it *can* do. That and it breaks the idea that JSON.parse(JSON.stringify(x)) is
a deep clone.
So, flexibility: there are two options in my head for this.
1. An object passed to JSON.parse with options for how to deal with integers
larger than Number can support. The current behaviour of misrepresenting them
is the default. But other options could include converting to BigInts (or
strings) if needed and always converting to BigInts (since they are
non-interoperable currently).
This approach allows the programmer to decide the behavior and plan for it in
their code.
2. It seems like the already suggested JSONNumber object could offer the same
flexibility and guarantees though. A `valueOf` that returns the misrepresented
Number for interop with existing numbers. A `toString` that gives a well
represented string conversion. (Im not 100% certain of the order these two
functions are used in auto-casting*. On mobile or else would check spec.) A
`toBigInt` / `unwrap` (modad-ish) terminology to get the true value of and when
the programmer wants.
Hope these ideas seem reasonable. Scrutiny welcome.
Regards,
Rob J T Ede
> On 29 Jul 2018, at 10:04, T.J. Crowder <tj.crow...@farsightsoftware.com>
> wrote:
>
> On Sun, Jul 29, 2018 at 9:01 AM, kai zhu
> <kaizhu...@gmail.com> wrote:
> > i support @anders’ *conservative* scheme and opened up a github-issue to try
> > and get it included before stage-4 [1].
>
> I agree with you and Anders that this should be sorted out now, not as a
> follow-on proposal. If it's left to later, people will supply their own
> `BigInt.prototype.toJSON` and cause themselves compatibility problems
> down-the-line.
>
> Don't like the raw number in quotes ("conservative" option) at all. There
> should be *some* indication that this is a bigint, just as pattern matching
> tells us the default Date serialization is a date. This could be achieved
> with just the lower-case `n` at the end, as in some early examples in the
> github issue. And to support easy two-way, `BigInt(string)` should support
> the lower-case `n` at the end.
>
> ```js
> aa = 12345678901234567890n; // BigInt primitive
> aa = JSON.stringify(aa); // '"12345678901234567890n"'
> aa = JSON.parse(aa); // '12345678901234567890n'
> aa = BigInt(aa); // BigInt primitive
> ```
>
> `^\d+n$` isn't much of a pattern, but it's a pattern. (Earlier in this thread
> I suggested `/BitInt(123)/` to match Microsoft's `/Date(123)/` which is
> unambiguous and offers a path to extendibility, but Date already goes a
> different way...)
>
> This parallels Date handling and seems a reasonable stop-gap until the next
> thing after JSON.
>
> -- T.J. Crowder
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
