JSON support for BigInt in ES6.
anders.rundgren.net at gmail.com
Tue Aug 14 05:57:09 UTC 2018
On 2018-08-14 06:55, J Decker wrote:
> my primary usage of json is
> in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result in the same sort of thing as the input; although I guess dates do get lost in translation anyway, but they could be handled as numbers with a few more character exceptions ':','-'(in a number),'Z',' ' the last one (the space) complicating the whole thing immensely; there is no meaning of multiple numbers without a ',' between them in JSON, so maybe not so impossible.
> and given the requirement that seems to be lost, that bigints ONLY interop with bigints, they MUST decode the same as their encoding; the JSONnumber type almost works; but requires custom code every time bigints are used. (much like dates)
> what writing a JSON parser taught me, is the type of a variable is the type of the data it has; and JSON does a really good job of representing 99% of generally communicated types. which makes generic code quite easy... without having to respecify/recast the data, the data is already the type it is.
Since the JSON standard doesn't distinguish between a single bit or BigNumber, I guess you are proposing extensions to JSON?
> but there's certainly fewer of me, than of those that thing everything is perfectly fine, and shouldn't evolve as the langugage has.
> but then there's 'don't break the net' and 'this could certainy break the net'; but since bigints didn't exist before, I guess they shouldn't be added now, because sending them to old code would break the old code.... but actually since being added; should also update JSON to support that number type (although I guess base JSON doesn't suppose ES6 number encodings like 0x, 0b, etc...)
> and again, since bigints ONLY interop with other bigints, there should be no chance they will get lost in interpretation.
> can see JSONnumber can aid application handling; but if you send bigints to an application that doesn't support bigints it's not going to work anyway; so why not just let existing json.parse throw when it doens't have bigint support?
The proposal is targeting *cross-platform applications* using JSON. The only thing it adds is offering a way to use JSON Number formatting for new numeric types, in addition to the quoting schemes which already are fully supported (and extensively used as well).
Example: A java class element like `BigInteger big;` used in a JSON context presumes that all values targeting "big" should be treated as BigIntger (=BigInt). However, there are different practices for formatting BigIntegers in JSON and they are all "right" :-)
In essence, the proposal's only ambition is making the ES6 JSON object better aligned with an already established JSON reality.
> On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> wrote:
> For good or for worse I have written a proposal for https://github.com/tc39/proposal-bigint/issues/162
> available at https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6
> Since the proposal doesn't introduce a default serialization mode, I guess nobody will be happy :-(
> OTOH, a fairly decent rationale for not specifying a default is also provided :-)
> This comment is also worth reading: https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss