Another paren-free gotcha

[Dean Landolt]

On Thu, Sep 29, 2011 at 11:09 AM, Brendan Eich <brendan at mozilla.com> wrote:

> 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.
>


Not on its own it's not -- it may close a block but what about the rest of
that block? Your curlies won't balance and you've got a syntax error. Sure,
you could choose to paper over it by indiscriminately adding closing braces
until you parse but this isn't a completely silent failure.



> 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.
>


Isn't "use strict" a useless expression statement? But that's about the only
useful use of useless expressions I can think of.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110929/6541e383/attachment.html>