Rationalizing ASI (was: simple shorter function syntax)
Mark S. Miller
erights at google.com
Sun Jul 25 11:50:42 PDT 2010
On Sun, Jul 25, 2010 at 11:36 AM, Brendan Eich <brendan at mozilla.com> wrote:
> On Jul 25, 2010, at 10:52 AM, Mark S. Miller wrote:
> The problem is that as long as ASI exists, one will often see working code
> such as this, since it does usually work. This training of the eye is a kind
> of habituation, and in this case it is insidious because it desensitizes the
> programmer from a pattern that *should* look malformed but doesn't.
> Ok, I'll grant you ASI desensitization is a factor in human readers missing
> this kind of bug.
> In the absence of ASI, such code would never normally appear in running
> Come on! "Never" ("normally" doesn't count, it's just hedging in a way that
> tends to assume the conclusion) must mean that if only we didn't suffer from
> ASI-based desensitization to missing semicolons, we would have
> perfect manual semicolon insertion and perfect code auditing and testing.
> But utopia is not an option.
> This hazard is insidious because testing may fail to uncover it, since
> tests have bugs too, test coverage is never perfect, and what's more, if the
> function expression itself returns a similar enough function, the caller of
> the stored method might not notice any malfunction.
> So let's agree on "less often" -- not "never".
> When it does appear in running code, that should alert the programmer that
> their program violates their intention and needs to be fixed.
> That's nice, but "should" is not good enough. Empirically, it doesn't work
> that way. I'm not just going by my experience, but by the jibbering page,
> the bug reports I've seen, the Dojo guys who do use semicolons still having
> to ward off this hazard with a leading ; in each source file.
> Let's not go in circles. I claim:
> * The horses are long gone from the barn.
> * The mistake is easy to overlook even for JS coders who do use semicolons.
> * The trade-off of banning ASI rule 1 first bullet to reduce
> desensitization and eventually reduce the incidence of this kind of bug is
> not a clear win, vs. migration tax into Harmony and usability problems even
> writing fresh code.
> In order to reliably remove this hazard, we would need to ban statements
> from starting with '('. Perhaps we should consider doing so.
The problem there is the common module pattern
Although less common, defining an anonymous object literal and using it
inline is perfectly sensible:
... // includes methods mentioning "this"
Perhaps, under the hypothetical opt-in, we should also consider
CallExpression a restricted production?
CallExpression : ...
CallExpression [no newline here] Arguments
This would more reliably catch the above hazards without breaking pleasant
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss