Rationalizing ASI (was: simple shorter function syntax)

[Brendan Eich]

On Jul 24, 2010, at 11:58 AM, Mark S. Miller wrote:

> On Sat, Jul 24, 2010 at 9:21 AM, Kevin Curtis <kevinc1846 at gmail.com> wrote:
> [...]
> Also, is anything proposed for rationalizing ASI in Harmony.
> 
> I would welcome ideas. I was sad when we gave up on this for ES5/strict. To get this started, he's one possibility:
> 
> Applying the same rules used to recognized the "use strict" directive, within the scope of a "use strict semicolons" directive, any code that would have caused ASI is instead rejected as a static error.
> 
> Other suggestions welcome. I hate JavaScript's ASI rules.

This is quixotic in my view, and BTW Yoda said hate leads to the dark side :-|.

ASI has two parts: syntax error correction + restricted productions. The pain users feel from ASI in my experience is mostly not from the well-specified error correction part. It's mainly due to those infernal restricted productions, especially

ReturnStatement:
    return [no LineTerminator here] Expressionopt ; 

We talked at the July 2008 Oslo ("Harmony") meeting about one way to mitigate the unreported dead-code error that results from

function foo() {
   if (some) {
       if (deep) {
           if (random) {
               if (logic) {
                   if (ending) {
                       if (in_a_very_long) {
                           return
                               "I believe in the 80 column limit, so I wrapped";
                       }
                   }
               }
           }
       }
    }
    return "LOL";
}

does not burn users.  But this is "hard", as we discusssed at that meeting two years ago -- consider the case where the braces were left off.

If we eliminate restricted productions by requiring semicolon after return, break, continue, throw (why is throw restricted? it does not seem necessary given the lack of a throw; form), and postfix ++/--, is it better to go all the way and eliminate the syntactic error correction part of ASI?

The syntactic error correction part does burn users too, in my experience. Specifically in the way discussed in the spec:

The source

    a = b + c
    (d + e).print()

is not transformed by automatic semicolon insertion, because the parenthesised expression that begins the second line can be interpreted as an argument list for a function call:

    a = b + c(d + e).print()

Here there's no syntax error to correct, just the mistaken expectation of ASI. So this is really a case where ASI as a whole would need to go, to try to prevent user confusion of this sort. But I argue (a) it's way too late; (b) users will get confused anyway, even if we give ASI the boot.

Meanwhile, code that runs things together on one line and uses semicolons well everywhere *except* before }, will be punished harshly. Why?

/be