Kevin Gibbons

> sloppy-mode function hoisting is especially complicated Another advantage of not supporting sloppy-mode scripts!

@Yoric > For the moment, the idea was to dispatch function to `let` or `var` depending on the case and to merge `const` with `var`. This is not sufficient to...

> I expect that we'll want to apply binary parsing also for JSON data. I don't know if we would, actually. ES doesn't spec JSON (except in that it provides...

@bmeurer well-designed tools should fail the build step, of course, but you can imagine a buggy compiler which outputs a binary AST which represents a program with an early error....

> Nothing can depend on early errors in the wild today, Sure it can! ```html window.onerror = function(e){ console.log('reached'); }; return; // oh no! ```

> with Tangential, but, I am *strongly* opposed to allowing this format to represent sloppy mode scripts.

Babel [as most people use it](https://babeljs.io/repl/) defaults to outputting strict mode code (including adding a `"use strict"` directive), so I'm less concerned than you are about the adoption risk to...

Incidentally, part of the reason I recommended [Shift](http://shift-ast.org/) is that well-typed Shift ASTs represent far fewer invalid programs than do well-typed Babylon ASTs - and moreover we've [enumerated](https://github.com/shapesecurity/shift-validator-js/tree/es2016) all the...

Actually, we probably also need to expose [IteratorHelperPrototype](https://tc39.es/proposal-iterator-helpers/#sec-%iteratorhelperprototype%-object) and [AsyncIteratorHelperPrototype](https://tc39.es/proposal-iterator-helpers/#sec-%asynciteratorhelperprototype%-object) too, sigh.

Iterator helpers explicitly (and [intentionally](https://github.com/tc39/proposal-iterator-helpers/issues/122#issuecomment-1176946383)) do not forward the arguments to or result from `return`, so even if we did this, if you wrote something like `iter.map(f).return()` you would necessarily...