Rationalizing ASI (was: simple shorter function syntax)

[Brendan Eich]

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

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.

/be

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