Proposal: Modify automatic semicolon insertion in strict mode
P T Withington
ptw at pobox.com
Thu Dec 11 07:33:47 PST 2008
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?
More information about the Es-discuss
mailing list