littledan

In this proposed alternative to sloppy-mode function hoisting semantics, sloppy-mode FunctionDeclaration are always single var-style bindings. The var is set to the value of the function at the top of the block where the FunctionDeclaration occurs. I believe these semantics roughly match IE10 and earlier sloppy mode function hoisting semantics.

Goals

• Maintain compatibility at the intersection of what browsers have supported for a long time
• Support is self-defining functions defined in blocks (tc39/ecma262#162)
• If possible, be intelligible for users and implementors (simple semantics win out when they make sense)
• Preserve strict-mode lexical scoping of FunctionDeclarations (this proposal only affects sloppy mode)

Non-goals

• Make a lexical binding in sloppy mode, and generally try to make sloppy mode block-scoped FunctionDeclarations act like lexical bindings, including suppressing errors, when possible

littledan

Reconsidering @@species

ES2015 added the @@species feature, where subclassing of builtins is enhanced by creating instances not of this.constructor but of this.constructor[Symbol.species]. There are a few issues with @@species:

• @@species is called in some places but not others in a way that feels a bit inconsistent (from instance methods but not static methods). See bugs 1 2 (Kevin Smith)
• @@species feels a bit unnecessary. It was motivated initially by ensuring Zepto's strange use of proto would continue to work. There's already an extension point by overwriting the constructor field, a simpler fix would have been possible, and Zepto was updated a year ago to not use these patterns.
• @@species will be a lot of work to implement across standard libraries of all JS engines without a performance regression.

This document explo

littledan

Zepto compatibility concerns

@@species came up on TC39's agenda in an attempt to preserve compatibility with Zepto. A patch was merged on October 21, 2014 to remove the problematic use of __proto__, but the old code can be found here. Here's the relevant snippet:

  zepto.Z = function(dom, selector) {
    dom = dom || []
    dom.__proto__ = $.fn
    dom.selector = selector || ''
    return dom
 }

littledan

var resolve;
var promise = new Promise(r => resolve = r);
async function foo(i) {
  if (i > 100000) return promise;
  return foo(i+1);
}

foo(0);
resolve();

littledan

TC39 accepts changes through two processes--the four-stage proposal process and pull requests. Staged proposals are governed by the process document, whereas pull requests are lighter-weight, working through informal rules and conventions, as administered by the editor. This document attempts to codify a process for pull requests, mostly through writing down current practice (to help others follow along what's happening, and to help the next editor if there is a transition), but a change from current practice is included in bold.

Algorithm for getting a PR merged:

1. If the PR is purely editorial or to support layering, tag it as 'editorial' or 'layering'.
2. Otherwise, tag it as 'normative', as it makes an observable semantic change.
3. If the PR is about reflecting what some web browsers' behavior is, tag it as 'web reality'.
4. Get consensus on the PR. If this is difficult or time-consuming, mark 'needs consensus' as it is gaining consensus.
5. If the PR is tagge

littledan

@namespace
class Math {
  static abs(x: Number): Number;  // Types optional; provide cast on input and assertion on ouptut    

  @nonwritable
  static LOG10E: Number;

  // ...
}

littledan

// In the following code, take  `private` and `friend` to be extremely early strawperson names

private #x;  // Declare a private name

let obj = { outer #x: 1 };

class MyClass {
  outer #x;
  constructor(x) { this.#x = x }
}

littledan

class Vec {
  #x;
  #y;
  #z;
  
  constructor(x, y, z) {
    this.#x = x;
    this.#y = y;
    this.#z = z;
  }

littledan

A summary of the issues for WebAssembly that Dan has been thinking about:

  - CSP -- https://github.com/WebAssembly/content-security-policy/pull/13
    - When the checks happen
    - What the checks are
  - Resource limits -- https://github.com/WebAssembly/spec/issues/607
   - Should we align resource limits?
    - How should the limit on local variables be interpreted?
    - What are the magic numbers? (These have already had to rise due to lack of implementation)
    - Memory objects limit -- do we have consensus that there should be no limit? https://github.com/WebAssembly/design/issues/1167

littledan

npm install -g test262-harness
npm install -g babel-cli
npm install -g jsvu
jsvu
git clone https://github.com/tc39/test262.git
test262-harness --test262Dir test262 --babelPresets stage-3 --hostType d8 --hostPath ~/.jsvu/v8 test262/test/intl402/*