Int64

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-prooﬁng) 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-prooﬁng 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)

9. 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…  }

10. Always bet on Brendan Eich Brave Software @ BrendanEich JS Future possible literal sufﬁx 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?

11. 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- deﬁned numeric types’ literals throw at runtime if malformed

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

13. 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