JSON support for BigInt in ES6. Was: javascript vision thing

[Isiah Meadows]

> Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This obviously
> has major consequences for parsers.  However, as long as you stay with the
> original JS Number scope everything works just fine.

BTW, most strongly typed languages parse numbers one of two ways:

- If it's just digits, it's parsed as an integer (typically an `int` or `long`)
- If it has floating point stuff, it's parsed as a float (typically a `double`)

> Other people (including myself) are more pragmatic and pretty much dismiss
> JSON Number as a suitable notation for numbers outside of the original JS
> scope.  This view is also aligned with most IETF and W3C standards to date
> defining JSON structures.

In general, JSON is great for prototyping protocols and easy
serialization when performance *isn't* a major concern, but that's
about it. (It's better than XML and more performant than it, but it's
still needlessly complex to parse/serialize.)

-----

Isiah Meadows
contact at isiahmeadows.com
www.isiahmeadows.com


On Wed, Aug 1, 2018 at 1:51 AM, Anders Rundgren
<anders.rundgren.net at gmail.com> wrote:
> Richard et al,
>
> If we call the situation "limbo" or not isn't that important, I just happen
> to have a preference for strong or funny expressions.
>
> The root of the problem (not only for JavaScript) is that JSON is *the only
> general purpose data interchange format in existence* that uses a single
> notion to signal "here comes a number".
>
> Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This obviously
> has major consequences for parsers.  However, as long as you stay with the
> original JS Number scope everything works just fine.
>
> One camp suggests that the right solution is to use some kind of BigNumber
> as the underlying Number type which surely is one way dealing with *data
> type overloading*.
>
> Other people (including myself) are more pragmatic and pretty much dismiss
> JSON Number as a suitable notation for numbers outside of the original JS
> scope.  This view is also aligned with most IETF and W3C standards to date
> defining JSON structures.
>
> Now to the challenge: Create a scheme that makes everybody happy!  Well, to
> be more realistic; create something that maybe nobody really likes, by
> supporting BOTH of the opposing views.
>
> Feel free slashing my minuscule change proposal:
> https://github.com/tc39/proposal-bigint/issues/162#issuecomment-408679884
>
> Cheers,
> Anders
> On 2018-08-01 05:37, Richard Gibson wrote:
>>
>> JSON is defined by ECMA-404 and RFC 8259, not by ECMA-262. An ECMAScript
>> JSON.parse implementation simply cannot accept e.g. 0n and still uphold the
>> conformance guarantees <https://tc39.github.io/ecma262/#sec-json-object>:
>>
>>     Conforming implementations of *JSON.parse* and *JSON.stringify* must
>> support the exact interchange format described in the ECMA-404 specification
>> without any deletions or extensions to the format.
>>
>>
>> Both BigInt and Symbol lack native support in JSON, and although adding in
>> custom serialization is relatively easy, custom parsing is not because
>> JSON.parse doesn't expose the text used to produce a value. But in my
>> opinion, it would be a mistake to characterize that explicit lack of support
>> as "limbo".
>>
>> On Sat, Jul 28, 2018 at 1:02 AM Anders Rundgren
>> <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>>
>> wrote:
>>
>>     On 2018-07-28 00:34, Richard Gibson wrote:
>>      > As stated even more strongly in ECMA-404:
>>      >
>>      >     Because it is so simple, it is not expected that the JSON
>> grammar will ever change. This gives JSON, as a foundational notation,
>> tremendous stability.
>>      >
>>
>>     Richard, that's great but it doesn't completely respond to my "limbo"
>> claim:
>>
>>     https://mail.mozilla.org/pipermail/es-discuss/2018-July/051388.html
>>
>>     Take your pick! Whatever you come up with, I'm sure there will be some
>> rotten tomatoes flying around :-)
>>
>>     Cheers,
>>     Anders
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss