Proposal: Modify automatic semicolon insertion in strict mode

Brendan Eich brendan at
Thu Dec 11 10:26:02 PST 2008

On Dec 11, 2008, at 7:33 AM, P T Withington wrote:

> On 2008-12-11, at 03:21EST, Brendan Eich wrote:
>> 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).
> My name is Joe Hacker, and I have a question.
> I am planning on buying into es3.1, and I want to know wether your  
> semicolon insertion plan is going to prevent me from doing that?
> Here are 2 bugs that I hit currently, and an anecdote:
> Bug 1:
>  return
>     answerWithSideEffect();
> I believe you have fixed that in your campaign proposal.  Under the  
> previous administration's plan, a semi-colon was inserted so this  
> returned undefined, and never executed the next line, much to my  
> disappointment.

Glad you mentioned this. The restricted productions for break and  
continue to label, and postfix ++ and --, have this potential problem  
too, but return\noverlong-expression is the only one that bites. jwz  
gave me grief in the ancient days over it. Crock brought it up as the / 
casus belli/ behind the desire to remove ASI from 3.1 strict mode when  
we were meeting in Oslo this past July.

This is the bath-water to try to throw out, while keeping the ASI baby  
in strict mode.

At the Oslo meeting we talked about how the true bug with ASI applied  
to return\nexpr was the dead code left in its wake -- the expr; on its  
own after the return, unreachable by control flow in the common case.  
I proposed analyzing dead code and making it a strict error for return  
to orphan an expression statement.

(It's true that sometimes one hacks an early return into code to debug  
(binary search a large function for a bug, e.g.), and this would not  
be possible in strict mode. The debugger driver who is bisecting would  
have to comment out the strict pragma.)

Then at a later meeting (I think the Redmond one in September, which I  
missed) it was argued this was too onerous, since ECMA-262 does not  
require much compile-time analysis.

There are two general cases (pretend bar() is a really long expression):

1.  if (foo) {


2.  if (foo)

The braced case (1) is clear, because the basic block containing bar()  
has only one predecessor, which ends in return. This case can be  
detected while parsing -- no control flow graph dominator relation  
computation required.

The unbraced case (2) cannot be "corrected" to

     if (foo)
         return bar();

without analyzing harder (say, trying to prove foo is a constant  
truthy value) and even then guessing what is meant. And we should not  
guess based on any complicated rules or analyses. So the ES1-3 ASI  
rule *should* apply in this case, resulting in

     if (foo)

Is it really too onerous (upon implementors) for strict mode to make  
case (1) an error?

> Bug 2:
>  foo = function() {...}
>  (...)
> Under the previous administration, this did not do what I expected,  
> because I came from a language where semicolons after close braces  
> were optional.  What is your campaign proposal for this issue?

I don't propose anything. This is the first non-hypothetical report  
I've heard in all the years; sorry it hit you.

While people do leave semicolons off after assignment statements,  
including ones with function expressions as the right-hand side  
expression, it's rare to start the next statement with (.

The fact is that C and other languages that do not require ; after a  
function definition's closing brace *do* require it after function  
declarations (prototypes), and after other declarations and statements.

> Anecdote 1:
> I have a syntax directed editor which pretty much forces me to  
> insert semicolons, because it does not have a powerful enough  
> analyzer to figure out where semicolons would be inserted  
> implicitly, and it relies on semicolons to do its auto-indenting.
> How does your campaign plan to address the issue of syntax directed  
> editors?  Will they be burdened with the tax of having to implement  
> a full parser (that can gracefully recover from incomplete code  
> fragments) in order to correctly predict implicit semicolons?

Yeah, that is the right trade-off. Joe Hacker benefits, Tucker Super- 
Hacker works harder. Sorry, but you are l33t and your skilz are better  
remunerated than Joe's.


More information about the Es-discuss mailing list