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 <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
