Sorry, my wording may have been ambiguous. What I meant was
disallowing break/continue/return inside a 'do', not giving up 'do'.
;)

/Andreas


On 7 January 2014 17:10, Brendan Eich <brendan at mozilla.com> wrote:
> 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

Sorry, my wording may have been ambiguous. What I meant was
disallowing `break`/`continue`/`return` inside a `do`, not giving up `do`.
;)