On Mon, Apr 18, 2011 at 7:46 PM, Mike Samuel <[email protected]> wrote:
> If I understand semicolon elision, then
>
> myLabel:
> for (;;) {}
>
> would be interpreted as
>
> myLabel: ;
> for (;;) {}
>
I'm still learning to details of the ES grammar, but I didn't think there
were cases where a ";" is valid after a ":". Object literals need a value
after it, labels need a subsequent statement, and switch cases need a
statement, right?
If that's the case, then you'd elide a newline following ":" (i.e. not treat
the newline like a ";") just like you would following a binary operator.
You're right that ":" is probably one of the trickier places to get this
right since it's used in so many contexts. Full disclosure: I've never
actually used labels in practice, so I may be missing something obvious
here.
> But it definitely does change behavior around mixed unary/binary
> operators in ways that affect current coding practices:
>
> var x = "foo"
> + "bar"
>
That's true. I believe in languages that default to treating newlines as
significant, the style is to put a binary operator at the end of the line
and not at the beginning of the next one. Given the above code, I don't
think it's even clear what the programmer intended. We can only assume they
wanted the binary operator because unary plus has no side-effect.
A change like I'm describing here would definitely affect existing code.
Leading commas are another place where this would need attention:
var a = 1
, b = 2
, c = 3
In that case, since there is no "unary prefix comma" operator we could
ignore the newline *before* it, but once we start adding that many special
cases, we may be ending up with something as complex as the current ASI
rules.
though lint tools' unused value warnings should catch this particular
> example.
>
Agreed, tooling can help a lot here. I don't underestimate how much work it
would be to *get* to a new behavior for how newlines are handled. It would
be a huge chore. But I do think the place we could end up after doing so
would be simpler, less error-prone, and more readable.
- bob
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
