Andreas Rossberg wrote:
> - YAGNI -- I have a hard time coming up with a use case that isn't
> obfuscated code (even considering generated code).

Always a good reason in the abstract, but concrete use cases have 
arisen, even in this thread. As you noted just last month (!),

"""

For ES7 I would like to revive the do-expression proposal (hopefully
at the next meeting), so that one can at least approximate the above
with

   const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { false } };

Of course, semantically the function is equivalent, and a fine
solution, if a bit verbose.


"""

> - They complicate the semantics and implementation -- for example, you
> would have to roll back non-empty expression stacks (in a stack
> machine implementation).

This is minor in both actual effect (not many naive recursive expression 
parse-tree walkers) and implementation hardship (return completion types 
all over, respect abrupt ones in expression handlers).

> - They destroy nice equivalences -- in particular, I'd like "do {...}"
> to be equivalent to "(() =>  {...})()", e.g. to minimise refactoring
> hazards.

What changed your mind from 20-December?

Anyway, JS has statements and expressions, but functions create new 
activations with their own scopes. Those create hazards when refactoring 
between statements and expressions.

Wanting the equivalence you state here tries to deny the facts of JS and 
its full (ahem, perhaps disputed legitimacy) heritage.

> - We can always allow them later, if the need should ever arise.

ES7 is later.

/be

Andreas Rossberg wrote:
> - YAGNI -- I have a hard time coming up with a use case that isn't obfuscated code (even considering generated code).

Always a good reason in the abstract, but concrete use cases have 
arisen, even in this thread. As you noted just last month (!),

---

> For ES7 I would like to revive the do-expression proposal (hopefully at the next meeting), so that one can at least approximate the above with
>
> ```js
> const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { false } };
> ```
>
> Of course, semantically the function is equivalent, and a fine solution, if a bit verbose.

---

> - They complicate the semantics and implementation -- for example, you
> would have to roll back non-empty expression stacks (in a stack
> machine implementation).

This is minor in both actual effect (not many naive recursive expression 
parse-tree walkers) and implementation hardship (return completion types 
all over, respect abrupt ones in expression handlers).

> - They destroy nice equivalences -- in particular, I'd like `do {...}`
> to be equivalent to `(() =>  {...})()`, e.g. to minimise refactoring
> hazards.

What changed your mind from 20-December?

Anyway, JS has statements and expressions, but functions create new 
activations with their own scopes. Those create hazards when refactoring 
between statements and expressions.

Wanting the equivalence you state here tries to deny the facts of JS and 
its full (ahem, perhaps disputed legitimacy) heritage.

> - We can always allow them later, if the need should ever arise.

ES7 is later.