Allen Wirfs-Brock

> I'd err on how [()=> 3+4, 5+6] handles it. So, [ 7, 11 ]. Arrow function handling gives an existing framework on how dealing with , should work I...

@yuchi In theory we can define any syntax we want for each unique context. But from a human factors perspective it would be a terrible language design to have logically...

see https://github.com/tc39/proposal-do-expressions/issues/21#issuecomment-359555197 Basically, every statement form that could (perhaps only sometimes) produce a new normal completion value was change so that it ways produced a new completion value (sometimes `undefined`)...

The fact that we were able to make changes in ES6 (assuming that at least some implementations actually made those changes) suggests to me that we can probably get away...

> eval("3; {} {} if (false) {}"); // returns undefined > I love it: an empty statement has no side effects, thank goodness—unless you make it not execute... It isn't...

Well `break` produces `[[Type]]: break, [[Value]]: empty` but [_StatementList_](https://tc39.github.io/ecma262/#sec-block-runtime-semantics-evaluation) propagates non-empty completion values into any break completion records emitted by the _StatementList_ and that completion record would just pass through...

For `{1; 2 && do { break; }}` the second _ExpressionStatement's_ completion value would be `[[Value]]: empty` because expressions do not propagate completion values among sub-expressions. The completion value for...

> So: {1; 2 && do { break; }} is equivalent to (1; {break}} which is equivalent to {1; break} Perhaps a better equivalence: ```js {1; 2 && do {...

> So value && empty == empty? Does that apply to every operator? This is where some new design is required. Currently (I believe) there is no way for a...

Interesting, referring back to the spec. I see that the behavior of `if` seems to have changed between ES2015 and the current ES2018 draft: In 2015: ```js { 1; if...