My talk to TC39 on Int64, Uint64, and beyond (user-defined value types, with operators and literal support) for JavaScript.

1. JS
Brendan Eich
Brave Software
@BrendanEich
Int64 & More

2. Brendan Eich Brave Software @BrendanEich
Always bet on JS
There are only two kinds of languages: the
ones people complain about and the ones
nobody uses. — Bjarne Stroustrup

3. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Previous value/operator/suffix thinking…
• Int64(0) ==> 0L // as in C#
• Uint64(0) ==> 0UL // ditto
• Float32(0) ==> 0f // ditto
• BigInt(0) ==> 0N // N to avoid i/I
• Decimal(0) ==> 0m // m or M, C/F#
• User-defined suffixes and operators: | ^ & == < <= << >> >>>
+ - * / % ~ ToBoolean unary- unary+

4. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Time passed, SIMD faded, new plan needed
• Old plan was to build on SIMD landing in living spec.html
• I hoped we would get more general “value type” semantics that way
• But time matters; as Waldemar said in July, “we should just do Int64”
• And @mikeal and I said exact same thing to each other in September
• Insight: inducting from hardcoded Int64/Uint64 (with future-proofing) is
strictly better than chained risk and complexity of layering on SIMD
• This slide deck presents the status quo and sketches future proofs

5. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
The @littledan / @brendan BBQ design
• After a BBQ joint after-meeting in January 2016 near PayPal,
@littledan and I worked out (written up via Twitter DM) a better
direct (no SIMD) plan, which is worth a recap for its constraints
• We agreed on no implicit conversions, so binary operator dispatch
needs no new magic: runtime semantics throw rather than convert
so both operands have same Type
• Unary operators could be single-dispatch or 1-ary functions
• Literals and operators are separate proposals, details mostly TBD

6. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Notable future-proofing problem: ToBoolean
• Int64 and Uint64 zero values must be “falsy”, while SIMD all-zero
vectors are truthy
• Old sketch had ToBoolean operator on deck, but it would have to
be infallible, or optimizations suffer fatally (per Andreas Rossberg)
• New future-proof idea: numeric types (“value types”) declare their
canonical zero value (arithmetic identity; one of N in “zero cohort”)
• Bonus: also requiring numeric types to declare canonical unit (one,
multiplicative identity) wins for ++/— consistency and simplicity

7. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Consequences/examples for Int64 usage
• 1L + 2L // 3L
• let x = 4; console.log(x * 5L) // TypeError
• console.log(Int64(x) * 5L) // 20L
• 0x1FFFFFFFFFFUL * 2L // TypeError
• 0x1FFFFFFFFFFUL * 2UL // OK
• 0x1FFFFFFFFFFUL * Uint64(scale) // also OK

8. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Spec.html plan of attack and status
• Split “6.1.6 The Number Type” into subclauses of new Numeric Types
clause for Number, Int64, and Uint64
• Split “20.1 Number Objects” into subclauses of new Numeric Objects
clause for Number, Int64, and Uint64 constructors/prototypes/etc.
• Check all ToNumber uses to see which ones should be ToNumeric
• Refactor 12 Expressions semantics to delegate to Type(x)::op (see next)
• Revise Number uses such as SameValueNonNumber carefully (in that
case to be SameValueNonNumeric)

12. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Future possible “value class” syntax
• value class Decimal {
constructor(x) {…}
static zero = Decimal(0);
static unit = Decimal(1);
static [Symbol.unaryMinus](x) {…}
static [Symbol.bitwiseNOT](x) {…}
// etc…
static [Symbol.add](x, y) {…}
static [Symbol.subtract](x, y) {…}
// etc…
}

13. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Future possible literal suffix support
• value class Decimal {
suffix m = fromLiteral;
suffix M = fromLiteral;
static fromLiteral(s) {…} // may throw
// etc…
}
let three = 3M; // m and M in scope too
• Question: allow RegExp for early error on invalid literal?

14. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Regular expressions for early errors?
• /(d{1,19}|
17d{18}|
18[0-3]d{17}|
184[0-3]d{16}|
1844[0-5]d{15}|
...
18446744073709551615)
UL/
• Very ugly, hard to handle other radixes, etc. Just say no! Let user-
defined numeric types’ literals throw at runtime if malformed

15. Brendan Eich Brave Software @BrendanEich
Always bet on JS
Spec Tour

16. Always bet on
Brendan Eich Brave Software @ BrendanEich
JS
Feedback requests and next steps
• Publish a browsable modified spec via brendaneich.github.io
(may move to tc39.github.io - stay tuned on Twitter!)
• Auto-generate an ins/del version of https://github.com/brendaneich/
ecma262/spec.html and publish via gh-pages
• Finish “20.1 Numeric Objects” spec changes
• Incorporate feedback on detailed changes in published spec
e.g., known bugs on 0L / 0L, 2L ** -3L, etc. to fix
• Propose operators and (separate, later) suffixes/value classes