Arbitrary precision Integers in JavaScript:

For Stage 2

Daniel Ehrenberg

Igalia

Why do anything?

• Number can represent integers only up to 2⁵³ accurately
• 64-bit int use cases
• GUIDs, protobufs with 64-bit ints
• For Node, fields of stat, other system calls
• WebAssembly FFI, Uint64Array
• Accurate timestamps
• Seek on distributed FS
• Larger than 64-bit use cases
• Direct crypto implementation
• M/L and Scientific workloads with huge domains/ranges that can't lose precision

Why Integer rather than Int64?

• Infinite precision is most useful/expected by most users
• Implementer feedback so far: Integer is optimizable
• Wraparound logic via cast functions: Integer.asUintN/Integer.asIntN
• Better ergonomics for most users
• Integer would still be sufficient (even if awkward) to the users preferring Int64

How?

• New primitive type Integer
• Literal syntax
• Operator overloading

1n + 2n

0xffn < 0x100n

let x = 1n; x++;

Code sample

// Takes a Integer as an argument and returns a Integer�function nthPrime(nth) {� function isPrime(p) {� for (let i = 2n; i < p; i++) {� if (p % i === 0n) return false;� }� return true;� }� for (let i = 2n; ; i++) {� if (isPrime(i)) {� if (--nth === 0n) return i;� }� }�}

Code sample: asm.js (?)

function Add64Module(stdlib, foreign, buffer) {� "use asm";� var cast = stdlib.Integer.asUintN;� var values = new stdlib.Uint64Array(buffer);� function add64(aIndex, bIndex) {� aIndex = aIndex|0;� bIndex = bIndex|0;� var aValue = values[aIndex>>3];� var bValue = values[bIndex>>3];� return cast(64, aValue + bValue);� }� return { add64: add64 };�}

​

Library features

• Uint64Array, Int64Array
• elements are Integers
• Integer static methods
• Integer.parseInt
• Integer.asUintN, Integer.asIntN

No implicit coercion

• The point of Integers: maintain integer precision
• No good answer for Integer + Number
• 0.5 + 2n**53n has an answer outside of the range
• Solution: Require explicit casts
• Call Number(), Integer() to convert
• E.g., Number(1n) + 2.0 => 3.0

No implicit coercion

• What to do when coercion would happen?
• Solution: throw a TypeError, on:
• Integer + Number
• Integer < Number (?)
• + Integer
• Passing an Integer to any Web API expecting a Number
• Any ToNumber() call in the JS
• etc
• Integer === Number ⇒ false

Optimization potential

• Use fixnum infrastructure to optimize as int64 (sometimes)
• Could work with asm.js
• Multiple browsers expressed optimism about implementing with good performance

Specification status

• Detailed spec text based on Brendan’s Int64 spec
• Open issues
• Editorial: How to deal with the various spec numeric values
• Should mixed-type comparison be allowed?
• Should ToString include the literal suffix?
• Bikeshedding
• Bigger standard library, or save more for v2?
• And many more! Please come on GitHub and tell me what’s wrong with the proposal​

References

• Explainer: https://github.com/littledan/proposal-integer
• Spec: https://littledan.github.io/proposal-integer/
• Issues: https://github.com/littledan/proposal-integer/issues

Backup slides

Comparison semantics:

current proposal

​

1 < 1n TypeError

1 == 1n TypeError

1 === 1n false

Comparison semantics:

Allow semantic comparison

​

1 < 1n false

1 == 1n true

1 === 1n false