Proposal: Modify automatic semicolon insertion in strict mode

David-Sarah Hopwood david.hopwood at
Wed Dec 10 22:05:17 PST 2008

Brendan Eich wrote:
> On Dec 9, 2008, at 1:00 AM, David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> On Dec 8, 2008, at 9:48 PM, David-Sarah Hopwood wrote:
>>>> Why? That would only happen if you added "use strict;" to a program
>>>> fragment without testing that the resulting program still parses
>>>> correctly,
>>> Parses and executes over all paths correctly, you must mean.
>> No, I don't. The context was an argument against removing semicolon
>> insertion from strict mode. If you add "use strict;" (to code that is
>> statically known, not to code that is passed to 'eval') and the resulting
>> program still parses, then you know that the lack of semicolon insertion
>> in strict mode made no difference. It isn't necessary to run the code in
>> order to test that.
> Wrong:
> s = 'c';
> b = 42;
> c = 33;
> g = 1;
> Number.prototype.exec = function(s){var c=this; return eval(s);};
> a = b
> /c/g.exec(s);
> print(a);

As you acknowledged in a follow-up, this example is invalid, because
it parses in the same way regardless of semicolon insertion. My
argument above is correct, and easily provable by observing that
ES3 only specifies semicolon insertion in cases that would otherwise
be a syntax error.

In fact the probable mistake in the above example is heuristically
detectable because "/c/..." is at the same indentation level as "a = b",
and if the "/" were intended to be a division, it would be indented.
The filter that I'm suggesting could (would, if I write it) detect that
and give a warning.

>> Of course you should do other testing as well, to account for other
>> differences between non-strict and strict mode, but that's not relevant
>> to semicolon insertion.
> How's the weather there on planet Utopia?

Please stick to technical arguments.

To answer your question about how removing semicolon insertion from
strict mode would help to avoid errors, first note that a programmer
who habitually added semicolons after every statement would be less
likely to make the error above, or similar errors, such as the one
I point out in a follow-up to Neil Mix, or the one that was discussed
when we were considering '^' as a prefix for lambda expressions.

So, if strict mode normally required semicolons (even if not in the
above specific example), and if the strict mode subset were what is
normally taught (or self-taught), then the potential for such bugs
would be reduced.

Here is another example that is discussed in the rationale of the
Jacaranda specification:

  var a = x
        + y;

Suppose that a programmer mistypes + as ++, for example:

  var a = x
        ++ y;

That will be parsed as

  var a = x;
  ++ y;

instead of as "var a = x ++ y;", which is a syntax error. In other
words, syntax errors are less likely to be detected as such, rather
than silently interpreted as something different. This applies to a
wide range of possible syntax errors.

Again, the filter I suggested could heuristically detect this mistake,
because a semicolon is inserted between two lines where the second is
indented relative to the first.

David-Sarah Hopwood

More information about the Es-discuss mailing list