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
