Peter Jaszkowiak

I recommend giving this issue a more meaningful title

I think it would be more useful to enable using statements as expressions anywhere they would currently result in an error. Including but not limited to: - Right side of...

If `do` can be used without braces (`do if (cond) { 1 } else { 2 }`) then it seems like _less_ boilerplate than parenthesis. That is my opinion based...

The ambiguity issue can be solved by saying "labels are not allowed in blocks-as-expressions, any such ambiguity will be resolved as an object literal"

I might be missing something, but the suggestion doesn't include anything about implicit return values. For the behavior you're describing, there would have to be a `return ` before the...

I suppose your point is that such behavior would require many exceptions to be backwards-compatible. Another example might be an arrow function: ```js const f = () => { 3;...

The most consistent way to make this backwards-compatible would be to say "any syntax involving a statement in the place of an expression that currently results in an error is...

Right, I was speaking within the confines of "without using do".

Pretty sure the labeled block case you have there is already invalid. From the readme: > More formally, the completion value of the StatementList can't rely on the completion value...

Does it even need to be a loop inside? ``` let x = 5; let y = do { a: { if (x === 5) { x; break a; }...