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