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

# Anders Rundgren (17 days ago)

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: tc39/proposal-bigint#162

# Isiah Meadows (17 days ago)

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

# kai zhu (17 days ago)

@isiah, actionable items before stage-4 are currently being debated @ tc39/proposal-bigint#162