Another paren-free gotcha

[Brendan Eich]

On Sep 29, 2011, at 9:06 AM, Peter van der Zee wrote:

> What you could do here is require paren-less headers to be single
> lined, on the same line as the `if` keyword, and require a newline
> between the paren-less header and the body. Such newline would signify
> the end of the statement header, much like ASI ("API"? ;). And if you
> want to use a block, you may put the first curly of the block on the
> same line as the paren-less header (or next line if you prefer K&R
> anyways). I'm not so sure if that would fix any of the raised
> objections though.

It would fix the first:

if a + b
 (x.y)()
z++

because of no { on same line as the head, but it would not fix the second case Waldemar showed:

if (a + b)/g > f {f = (a + b)/g}

This case is a paren-full if head followed by an unbraced body, a useless regexp expression statement. It's valid ES5. The reason this involves paren-free is that Waldemar showed how refactoring from paren-full to paren-free mixes with division and a regexp literal to make this paren-full but undesired outcome.

The ability to write useless expression statements in JS (and C) is a bug.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110929/f4f4e896/attachment.html>