Babak B.

@TehShrike True... anyway, the point is that the syntax is confusing especially with `for*` `switch*` being proposed here. If they all return an implicit value, great, sound good to me....

If you don't inject new syntax into old code that doesn't expect a value, it doesn't break old code. Again, please enlighten me on how this breaks existing code. Just...

Where `const foo = if(true){ [1,2] }` breaks so does `const foo = if*(true){ [1,2] }`. So why add `*` ?

@ljharb No points are being missed on this end. So are you saying that ```javascript if (true) { [1,2] } [1] ``` The old javascript, now in a new parser...

@TehShrike Right. No `yield` should be necessary. The behavior of the existing `yield` inside a generator would be the same. The main concern @ljharb has is with old code. Old...

@ljharb Look at the original post at the top of this page. Even if you did it *everywhere* there is no conundrum. In your example it in fact would become...

As a follow up to my last comment, I stick by saying that only where a value is expected should there be an implicit do. It is possible to concoct...

If someone wanted this effect ```javascript if(true) { function doBadThings(){} } (1) // not sure why someone would do this in OLD javascript but there you have it. In this...

Note that in existing (old) Javascript this is valid ```javascript (function foo() { return 1 })() ``` but this is not ```javascript function foo() { return 1 } () ```...

So its not that we're wrapping `if` statements in `do` when used in assignments. Instead we are adding an implicit `do` when a statement is used in an expression context....