Rationalizing ASI (was: simple shorter function syntax)

[Maciej Stachowiak]

On Jul 24, 2010, at 12:40 PM, Brendan Eich wrote:

> 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 ; 

That's a good point. If we had a "disable ASI" mode, would it just insert syntax errors wherever a semicolon would have been inserted, or would it make statements that could be valid multiline statements but for ASI have their expected multiline meaning? The latter would remove more of the annoyance of ASI, but it wouldn't be a subset of the language. I could see an argument for either, or for no change.

Regards,
Maciej