On Apr 18, 2011, at 5:09 PM, Lasse Reichstein wrote: > On Mon, 18 Apr 2011 14:42:21 +0200, Jorge <jo...@jorgechamorro.com> wrote: >> I understand that it would be quite interesting to get a warning/error in >> this case: >> >> a= b >> (c= d)(); >> >> ...only that there's no ASI in this case ! > > ... and that's actually a very relevant point. > Errors with ASI comes (in my experience) exclusively in cases where there > is a newline that was intended to end the statement, but where it actually > didn't - i.e., where ASI does not insert a semicolon. > > No amount of warning about automatically inserted semicolons will help > these cases, which are indistinguishable from correctly wrapped code.
Excellent point, which I keep making and which keeps being missed. The problem is lack of ASI where people expect newline significance. It is not where ASI kicks in (in general). A lesser problem is where a restricted production bites, notably return\n long_value_here(). I once got mail from an outraged jwz about this. I just mailed back "parenthesize with the open paren on the same line as return" but I knew that was not going to diminish jwz's wrath. Given the primary problem is not ASI but its absence where users expect it due to mistakenly believing a newline is significant, one could argue the fix is not to ban ASI and tax everyone with writing lots of insignificant semicolons (in some opt-in mode hardly anyone would use, which would only crud up implementations' parser state spaces). One could argue instead that we need *more* newline signfiicance. With paren-free I avoided going this direction. I don't believe JS should have two many syntaxes in its standard, or too much variation. Losing head parens per http://wiki.ecmascript.org/doku.php?id=strawman:paren_free is a relaxation of the current grammar that (I believe) won't cost much in real parser implementations (it was easy in Narcissus, modulo the fact [see above parenthetical] that the --paren-free option makes a new mode that requires testing both ways, something I failed to do several times!). Anyway, thanks for reiterating this point. ASI can be blamed for some things, including luring users into expecting newlines to be significant outside of restricted productions and error correction scenarios. But other users want significant newlines anyway, and the "negative space" problem could be addressed by thinking about newline significance more, not just retrenching to "no asi" and typing ; all the time. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
