[BrendanEich]

No, there's an important distinction. ASI does not even kick in without a syntax error.

Yet the "expectation of ASI" or (I think more likely) "expectation of newline significance" makes people believe that they'll get a ; inserted by separating two things by one or more newlines.

Most languages do not specify error correction. HTML5 of course does; CSS too; among general programming languages it's much less common. The spec for ASI does not fit in the tried-and-true LR(1) formalism used by ECMA-262. Parsing is not all ad-hoc or equally well-formalized and proven.

In addition to ASI, ECMA-262 has to use lookahead restrictions and a bit of semantic checking to cope with what could be purely syntactic concerns (say, if it could use GLR instead of LR(1)).

[_delirium]

I suppose I'm thinking of that as implementation details; from the perspective of languages, it appears ECMA-262 does specify a well-defined language. Any input string is either rejected (not in the language at all), or is mapped unambiguously to an abstract syntax tree. So from that perspective, any sequence of characters that gets you an abstract syntax tree is a program in the language! How precisely it gets mapped is "innards of the parser" if you view languages as just string->AST mappings.

The error-correction view seems to want to add a third category, strings that are in some sense "errors", but nonetheless get unambiguously mapped to an AST. Which is strange from a classical formal-languages view, because if a string gets mapped to an AST, it's in the language, and the procedure that mapped it constitutes the parser! That category seems more like "warnings" to me, i.e. you probably shouldn't do this, but it will produce a program if you do.

[BrendanEich]

Yes, ECMA-262 completely specifies (modulo bugs) sentences that are accepted or rejected, and for those accepted, their meanings.

But that doesn't alter ASI's error-correction nature, which is not an "implementation detail" -- it's in the spec and all too observable.

You're right, it has the character of a warning system, like Dart's unsound "types". But if it had been noisy (consoles in the early days were costly), too many developers would have ignored the warnings, and users would have paid for the overhead.

Your concluding sentence is spot on, I agree people should use semicolons in JS. Relying on a Ruby-like coding style in the large is way too risky.

[web_chops]

I'm curious, does ASI actually hurt the performance of JS parsing ? I mean, will there be any performance difference between a code that properly uses semicolons versus one that relies on ASI..