domenic at domenicdenicola.com (2014-01-14T17:41:08.108Z)
Unless we can identify real implementation issues, the semantics of
```js
do { }
```
should simply be those of a blocks. JS programmer shouldn't have to learn which subset of statement are invalid in a `do` expression block. In particular, I see no reason why a JS programmer should be able to refactor any valid BlockStatement in to an equivalent ExpressionStatement simply by putting a `do` in front of the leading `{`
The meaning of things like:
```js
function (x) {
for (let i of x.state!==special? x : do {return bar(x)})
foo(i)
}
```
is clear and also easy enough to specify. Unless there are some non-obvious implementation issues, I don't see why we would want to disallow such things.
The only place where the possible semantics isn't totally obvious is things like:
```js
for (x of z ? q : do {break}) ...
```
or
```js
for (x of do { if (z) q; else continue}) ...
```
The semantics in the ES6 draft for an unlabeled `break` or `continue` completion in the head of a `for` statement treats both of these as terminating the `for` statement and continuing with the statement following the `for`.
On Jan 7, 2014, at 8:22 AM, Andreas Rossberg wrote: > On 7 January 2014 17:19, Andreas Rossberg <rossberg at google.com> wrote: >> Sorry, my wording may have been ambiguous. What I meant was >> disallowing break/continue/return inside a 'do', not giving up 'do'. >> ;) > > And just to be extra-clear: by that I'm only referring to "free" > occurrences of those, that would refer to the enclosing statement. > Nested ones are fine, of course. > Unless we can identify real implementation issues, the semantics of do { } should simply be those of a blocks. JS programmer shouldn't have to learn which subset of statement are invalid in a do expression block. In particular, I see no reason why a JS programmer should be able to refactor any valid BlockStatement in to an equivalent ExpressionStatement simply by putting a 'do' in front of the leading '{' The meaning of things like: function (x) { for (let i of x.state!==special? x : do {return bar(x)}) foo(i) } is clear and also easy enough to specify. Unless there are some non-obvious implementation issues, I don't see why we would want to disallow such things. The only place where the possible semantics isn't totally obvious is things like: for (x of z ? q : do {break}) ... or for (x of do { if (z) q; else continue}) ... The semantics in the ES6 draft for an unlabeled break or continue completion in the head of a for statement threats both of these as terminating the for statement and continuing with the statement following the for. Allen > /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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140107/e35c7542/attachment.html>