Rob Ede (2018-07-29T11:04:16.000Z)
+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.crowder at farsightsoftware.com> wrote:
> 
> On Sun, Jul 29, 2018 at 9:01 AM, kai zhu
> <kaizhu256 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180729/2bc46f5a/attachment.html>
robjtede at icloud.com (2018-07-30T11:49:32.243Z)
+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` (monad-ish terminology) to get the true value as and when the programmer wants.

Hope these ideas seem reasonable. Scrutiny welcome.

Rob J T Ede
robjtede at icloud.com (2018-07-30T11:47:29.092Z)
+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` (monad-ish terminology) to get the true value of and when the programmer wants.

Hope these ideas seem reasonable. Scrutiny welcome.

Rob J T Ede
robjtede at icloud.com (2018-07-30T11:46:46.721Z)
+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.

Rob J T Ede
robjtede at icloud.com (2018-07-30T11:46:28.161Z)
+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.

Rob J T Ede