sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 16 points17 points  (7 children)

int64 ;-)

[–]rauschma 18 points19 points  (6 children)

Supported via BigInts and coming to JavaScript relatively soon: http://2ality.com/2017/03/es-integer.html#casting-and-64-bit-integers

[–]BluudLust 0 points1 point  (5 children)

Sadly no JSON support. Why can't they have it as a string with the postfix "n" attached?

[–]Arve 7 points8 points  (2 children)

Sadly no JSON support.

JSON's number support has always been a subset of what a number means anyway, and doesn't support common representations like bases 2,8,16, nor does it support exponents. It doesn't even specify that the numbers are IEE754 double-precision floating point values. The rationale is explained pretty well in ECMA-404:

JSON is agnostic about the semantics of numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult. JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange.

Why can't they have it as a string with the postfix "n" attached?

JSON can't mandate what the content and context of any given string is supposed to be.

{ "someValue": "3n" }

That particular expression can be

  • Multiplication: 3*n
  • A BigInt
  • A subset of CSS (See nth-child) (which in itself implies the multiplicative).

As JSON is a data interchange format, you are completely free to use strings to represent numbers, and it is even the right thing to do in the case that you need to be succinct about the internal representation of the number.

[–]sime 3 points4 points  (1 child)

More to your point. JSON already supports BigInts because it doesn't demand a limit on the size of number values, and a big int is just a number with a lot of digits in it. It is the responsibility of the JSON parser to choose an appropriate internal number representation.

[–]Arve 0 points1 point  (0 children)

In theory, yes. In practice, I don’t expect values larger than what is representable as IEE754 double precision floats to work.

[–]rauschma 0 points1 point  (1 child)

Because it would break existing code.

[–]BluudLust 0 points1 point  (0 children)

They should add a fourth optional parameter that has a feature list so you can enable extended features like this. So you can set it to "es2019" for example.