On Jan 6, 2014, at 8:10 AM, Brendan Eich wrote:

> David Herman wrote:
>> On Dec 20, 2013, at 5:32 AM, Andreas Rossberg<rossberg at google.com>  wrote:
>> 
>>> >  For ES7 I would like to revive the do-expression proposal (hopefully
>>> >  at the next meeting)
>> 
>> Glad to hear you're in favor! I'll be happy to co-champion.
> 
> I will support your prospective championship ;-).
> 
> To further constrain design (since design is mostly about leaving things out), I will address the ES4-era |let (x = y, z = z /* outer z*/) ...| let blocks and let expressions, which came up recently. We should not revive these, given do expressions. do-exprs compose better with let and const (and other binding form) declarations.
> 
> Sorry if this is obvious; wanted to settle it, since it came up here in the other thread.

The major new complication of do-expressions is that they allow for the occurrence of break/continue/return abrupt completions in contexts such as for loop heads where they could not perviously occur.  However, do-expressions where still on the table when I did the spec. work for  "completion reform"  so the ES6 draft already deals with these abrupt completions in those contexts. Even though there is currently no way to produce them.

I had been considering purging that handling from the ES6 spec. but maybe I'll leave it in.

The do-expression proposal should address what happens with break/continue/return completions in such contexts.  It will probably match what is already in the ES6 spec. but if necessary the existing spec. language can change in the future since it isn't actually in play.

Allen

The major new complication of do-expressions is that they allow for the occurrence of `break`/`continue`/`return` abrupt completions in contexts such as for loop heads where they could not previously occur.  However, `do`-expressions where still on the table when I did the spec. work for  "completion reform"  so the ES6 draft already deals with these abrupt completions in those contexts. Even though there is currently no way to produce them.

I had been considering purging that handling from the ES6 spec. but maybe I'll leave it in.

The `do`-expression proposal should address what happens with `break`/`continue`/`return` completions in such contexts.  It will probably match what is already in the ES6 spec. but if necessary the existing spec. language can change in the future since it isn't actually in play.