Rationalizing ASI (was: simple shorter function syntax)

[Garrett Smith]

On 7/25/10, Mark S. Miller <erights at google.com> wrote:
> 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
>> 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".
>>
>
> Sure.
>
>
>
>> 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
>
(besides breaking uses with eval)
>     (function(){
>       ...
>     })();
>
A problem is that this module can become Arguments production in
CallExpression (and possibly NewExpression, though less likely),
depending on what comes before it (as in the asi.html example where
global.name = "mike"); That is why some scripts (Dojo, for example)
begin with a semicolon, as:

;(function(){ })();

Dojo does this, for example.

If ASI is removed from strict mode, then a semicolon will not be
inserted at the end of the input stream. If ASI were disabled, then
developers would realize right away that the problem if the Expression
from file1.js missing a semicolon were to result in an error.

In that scenario, it wouldn't make sense to have CallExpression be a
restricted production.

Garrett