Proposal: Modify automatic semicolon insertion in strict mode

[P T Withington]

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.

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?

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?