Kevin Gibbons

The current proposal simply bans loops (and declarations) at the end of `do` expressions entirely, preventing this from being observable.

@isiahmeadows I'm leaving it open at least until this proposal gets to stage 2 with those semantics. I'm hoping my approach works, but it will require the committee to approve.

> return, break, var, etc. all just become part of the function body. `var` can't while being consistent with the rest of the language, in particular with `function(x = eval('var...

> Practically, defining the static semantics at the level of scoping instead of feature combinations allows us to have other expression forms that have statement bodies, like the pattern matching...

> No, it's only disallowed in the context of parameter default expressions. That's what I meant, yeah: "you can't use var **in parameters** in do-expressions" (I guess I got those...

Strictly speaking, we're not required to use the same completion value semantics that `eval` uses. The argument in favor is simplicity of mental model, but to be honest I'm not...

@ljharb, I assume the point is that there's no `break`, so it can never be `1`. I agree this seems like something which would be a common error.

This would also simplify other parts of the spec, because `await` and `PromiseResolve(%Promise%, _foo_)` would never synchronously throw; e.g. https://github.com/tc39/ecma262/pull/2683 would be unnecessary because `AsyncGeneratorAwaitReturn` would become infallible.

Oh, true. The fast-path I proposed above would indeed mean changing the behavior for subclasses of the built-in Promise type in a literal call to `Promise.resolve` or `Promise.prototype.finally` (which are...

Another option would be to change the `IsPromise(x) && x.constructor == C` check to instead be `IsPromise(x) && C.prototype == x.[[Prototype]]` (and maybe also `GetOwnProperty(x, 'then') == undefined`. This is...