anders.rundgren.net at gmail.com
Wed Aug 1 05:51:27 UTC 2018
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.
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:
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:
> Take your pick! Whatever you come up with, I'm sure there will be some rotten tomatoes flying around :-)
More information about the es-discuss