Proposal: Modify automatic semicolon insertion in strict mode

Brendan Eich brendan at
Thu Dec 11 00:21:10 PST 2008

On Dec 10, 2008, at 10:05 PM, David-Sarah Hopwood wrote:

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

This is not a technical argument, it's a political one (what's the  
common good for the polis). Stop trying to distract from that with  
technical digressions.

Your bold claims about a filter being zero-cost and freely available  
are not credible. And you haven't produced any evidence of a non- 
hypothetical problem with ASI worth solving in strict mode. Yes, there  
are gotchas, but they don't seem to bite users -- meanwhile, the web  
is full of JS with missing semicolon errors automatically corrected by  

Truly we could punish such sloppiness and train users who choose  
strict mode, if only they'll put up with the training. That's not  
credible either. Strict mode could well fail to be used if it is too  
pecksniffian or gradgrindian, or whatever the right Dickensian trope  
is here (both, probably).

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

That's nice, but in practice lack of semicolons are not causing bugs.  
Meanwhile, on planet Earth, there's a lot of new and old content  
that's missing semicolons, which won't move to strict mode if strict  
mode disables ASI.

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

The second "if" is a big one.

What is the bug potential? Near zero, as far as I can tell. I welcome  
real-world evidence to the contrary.

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

I don't welcome synthetic examples.

Again, what problem are you solving? I hate to add it, but I mean  
"real-world problem", one you can show biting deployed code on the  
web, or tell a few anecdotes about. Not hypothetical problems from a  
spec (ES1 had a few of those too).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list