4 ms·

BigInt is finally here in ES2020

21 points by AmruthPillai 6y ago

JoBrad 6y ago
Really sucks that they didn’t make it compatible with Math functions and other Number types. Even more type checking. Python did the same thing with Decimal at first, and it wasn’t fun to accommodate.
Lx1oG-AWb6h_ZG0 6y ago
> Using JSON.stringify() with any BigInt value will raise a TypeError as BigInt values aren't serialized in JSON by default. However, you can implement your own toJSON method if needed Sorry, why exactly can’t they also define the json.parse/stringify behavior of bigints? JSON was initially derived from JavaScript, so it seems a bit weird that a new ES standard can’t interoperate with json
- mrspeaker 6y ago
  I wondered about JSON serialization too - lots of discussion on this here https://github.com/tc39/proposal-bigint/issues/24 https://github.com/tc39/proposal-bigint/issues/24 and here https://github.com/tc39/proposal-bigint/issues/162 https://github.com/tc39/proposal-bigint/issues/162. After 15 minutes down that rabbit-hole, the answer is "it's complicated".
- zeroimpl 6y ago
  I’m sure they could make stringify work, since numbers in JSON can be arbitrarily large. But parsing JSON and having it return BigInt instead of Number just isn’t going to be able to work by default. I guess because of this, making stringify work without parse support just isn’t desirable.
  - postalrat 6y ago
    Where do you read numbers can be arbitrarily large? I thought it was limited to javascript numbers.
    - dragonwriter 6y ago
      > Where do you read numbers can be arbitrarily large? RFC 8259, Section 6, specifies unlimited number of digits for the integer and fraction parts, but allows implementations to have size and precision constraints. > I thought it was limited to javascript numbers. It suggest that IEEE754 binary64, because it is widely available and supported, should generally be safely usable (which happens to be exactly JavaScript numbers) but it does not limit JSON numbers to that range/precision.
- postalrat 6y ago
  Because bigints aren't part of the json spec? Like they said you create your own toJSON like: 'BigInt.prototype.toJSON = function() { return this.toString(); };' if you want to bend the spec.
  - dragonwriter 6y ago
    > Because bigints aren't part of the json spec? Arbitrarily sized numbers (with no guarantee on supported range or precision in processors) are part of the spec, the problem is JS already serializes/deserializes them as Number and any change would break backwards compatibility.
- dragonwriter 6y ago
  > Sorry, why exactly can’t they also define the json.parse/stringify behavior of bigints? Because every construct in JSON already has a defined way that it is parsed into JS and incorporating BigInt into that by default would break backwards compatibility of JS’s JSON handling. Interop concerns make the right JSON serialization very application dependent, too.
MaxBarraclough 6y ago
> BigInt is a built-in object that provides a way to represent whole numbers larger than 2^53 - 1, which is the largest number JavaScript can reliably represent with the Number primitive and represented by the Number.MAX_SAFE_INTEGER constant. Isn't this wrong? JavaScript's Number type can represent some integers vastly greater than this. [0] What's special about Number.MAX_SAFE_INTEGER, if I understand correctly, is that it's the smallest integer such that (Number.MAX_SAFE_INTEGER + 1) is not guaranteed to be represented faithfully by the Number type. Given the topic, I don't think I'm being pedantic. edit On second thought, I could well be mistaken. The definition of JavaScript's Number type might be such that no guarantees are made about which integers greater than Number.MAX_SAFE_INTEGER can be represented exactly. edit 2 Nope, Number.MAX_VALUE is defined to be an integer. [0] Which is to say, the largest whole number that can be represented is Number.MAX_VALUE, not Number.MAX_SAFE_INTEGER. Of course, it's not the case that Number is guaranteed to be able to exactly represent all non-negative integers less than Number.MAX_VALUE, but that isn't the same thing. The article appears to get this wrong. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_VALUE https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- smitop 6y ago
  I think you misread the sentence. It's not the largest value JS can represent, it's the largest value it can "reliably represent". After 2^53 - 1 you get incorrect results when dealing with integers, making the results not "reliable".
  - MaxBarraclough 6y ago
    When an integer can be reliably represented, that presumably means that JavaScript's definition of the Number type is such that it guarantees that a given integer can be represented exactly by the Number type. It doesn't mean you can safely do arbitrary integer arithmetic on it and get back another integer, also represented exactly. Trivially, there are no such values. Every non-negative integer up to and including Number.MAX_SAFE_INTEGER can be represented exactly by the Number type, in any compliant JavaScript implementation. It's also true though that Number.MAX_VALUE is itself defined to be an integer. It's therefore not true to say that Number.MAX_SAFE_INTEGER is the greatest integer that can be exactly represented by JavaScript's Number type. Instead, Number.MAX_SAFE_INTEGER is the greatest integer such that Number.MAX_SAFE_INTEGER can be represented precisely by the Number type, and all non-negative integers less than Number.MAX_SAFE_INTEGER can be represented exactly by the Number type. (See also my second edit to my earlier post.) It seems incorrect then that the article states: > 2^53 - 1, which is the largest number JavaScript can reliably represent with the Number primitive and represented by the Number.MAX_SAFE_INTEGER constant There's discussion of the term safely represent on the MAX_SAFE_INTEGER page. [0] [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

21 points by AmruthPillai 6y ago

Really sucks that they didn’t make it compatible with Math functions and other Number types. Even more type checking. Python did the same thing with Decimal at first, and it wasn’t fun to accommodate.

Lx1oG-AWb6h_ZG0 6y ago

> Using JSON.stringify() with any BigInt value will raise a TypeError as BigInt values aren't serialized in JSON by default. However, you can implement your own toJSON method if needed Sorry, why exactly can’t they also define the json.parse/stringify behavior of bigints? JSON was initially derived from JavaScript, so it seems a bit weird that a new ES standard can’t interoperate with json

mrspeaker 6y ago
I wondered about JSON serialization too - lots of discussion on this here https://github.com/tc39/proposal-bigint/issues/24 https://github.com/tc39/proposal-bigint/issues/24 and here https://github.com/tc39/proposal-bigint/issues/162 https://github.com/tc39/proposal-bigint/issues/162. After 15 minutes down that rabbit-hole, the answer is "it's complicated".
zeroimpl 6y ago
I’m sure they could make stringify work, since numbers in JSON can be arbitrarily large. But parsing JSON and having it return BigInt instead of Number just isn’t going to be able to work by default. I guess because of this, making stringify work without parse support just isn’t desirable.
- postalrat 6y ago
  Where do you read numbers can be arbitrarily large? I thought it was limited to javascript numbers.
  - dragonwriter 6y ago
    > Where do you read numbers can be arbitrarily large? RFC 8259, Section 6, specifies unlimited number of digits for the integer and fraction parts, but allows implementations to have size and precision constraints. > I thought it was limited to javascript numbers. It suggest that IEEE754 binary64, because it is widely available and supported, should generally be safely usable (which happens to be exactly JavaScript numbers) but it does not limit JSON numbers to that range/precision.
postalrat 6y ago
Because bigints aren't part of the json spec? Like they said you create your own toJSON like: 'BigInt.prototype.toJSON = function() { return this.toString(); };' if you want to bend the spec.
- dragonwriter 6y ago
  > Because bigints aren't part of the json spec? Arbitrarily sized numbers (with no guarantee on supported range or precision in processors) are part of the spec, the problem is JS already serializes/deserializes them as Number and any change would break backwards compatibility.
dragonwriter 6y ago
> Sorry, why exactly can’t they also define the json.parse/stringify behavior of bigints? Because every construct in JSON already has a defined way that it is parsed into JS and incorporating BigInt into that by default would break backwards compatibility of JS’s JSON handling. Interop concerns make the right JSON serialization very application dependent, too.

MaxBarraclough 6y ago

> BigInt is a built-in object that provides a way to represent whole numbers larger than 2^53 - 1, which is the largest number JavaScript can reliably represent with the Number primitive and represented by the Number.MAX_SAFE_INTEGER constant. Isn't this wrong? JavaScript's Number type can represent some integers vastly greater than this. [0] What's special about Number.MAX_SAFE_INTEGER, if I understand correctly, is that it's the smallest integer such that (Number.MAX_SAFE_INTEGER + 1) is not guaranteed to be represented faithfully by the Number type. Given the topic, I don't think I'm being pedantic. edit On second thought, I could well be mistaken. The definition of JavaScript's Number type might be such that no guarantees are made about which integers greater than Number.MAX_SAFE_INTEGER can be represented exactly. edit 2 Nope, Number.MAX_VALUE is defined to be an integer. [0] Which is to say, the largest whole number that can be represented is Number.MAX_VALUE, not Number.MAX_SAFE_INTEGER. Of course, it's not the case that Number is guaranteed to be able to exactly represent all non-negative integers less than Number.MAX_VALUE, but that isn't the same thing. The article appears to get this wrong. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_VALUE https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

smitop 6y ago
I think you misread the sentence. It's not the largest value JS can represent, it's the largest value it can "reliably represent". After 2^53 - 1 you get incorrect results when dealing with integers, making the results not "reliable".
- MaxBarraclough 6y ago
  When an integer can be reliably represented, that presumably means that JavaScript's definition of the Number type is such that it guarantees that a given integer can be represented exactly by the Number type. It doesn't mean you can safely do arbitrary integer arithmetic on it and get back another integer, also represented exactly. Trivially, there are no such values. Every non-negative integer up to and including Number.MAX_SAFE_INTEGER can be represented exactly by the Number type, in any compliant JavaScript implementation. It's also true though that Number.MAX_VALUE is itself defined to be an integer. It's therefore not true to say that Number.MAX_SAFE_INTEGER is the greatest integer that can be exactly represented by JavaScript's Number type. Instead, Number.MAX_SAFE_INTEGER is the greatest integer such that Number.MAX_SAFE_INTEGER can be represented precisely by the Number type, and all non-negative integers less than Number.MAX_SAFE_INTEGER can be represented exactly by the Number type. (See also my second edit to my earlier post.) It seems incorrect then that the article states: > 2^53 - 1, which is the largest number JavaScript can reliably represent with the Number primitive and represented by the Number.MAX_SAFE_INTEGER constant There's discussion of the term safely represent on the MAX_SAFE_INTEGER page. [0] [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...