Proposal: Modify automatic semicolon insertion in strict mode

Neil Mix nmix at
Wed Dec 10 23:47:30 PST 2008

>> It's more than just making sure the file parses correctly -- it's  
>> adding
>> the semicolons too.
> You've lost the context of my original post, which answered this  
> point:

No, I followed it carefully.  I think you have an unrealistic  
expectation for uptake of your filter.

> I will write the filter, if there is agreement not to do semicolon  
> insertion
> in strict mode. I'm implementing an ANTLRv3 parser for ES3.1 anyway
> (starting with Patrick Hulsmeijer's ES3 grammar), so this will not  
> be much
> extra work.

So what?  Will you write the scripts that will perform these changes  
seamlessly within <insert-source-control-product-here>?  Will it be  
able to handle SSI macros in my source files?  What should I tell *my*  
boss if *your* code breaks something that was previously working?

You missed my point: *any* amount of work is a burden.  For what  
gain?  Exactly why is lack-of-semicolon-insertion of value to me?  Why  
should I devote even one second of my time to converting my source?

>> = function() {
>>  //...
>> } // <-- whoops, no semicolon
>> For me that qualifies as "unnecessary work," aka "pedantic."
> I hope it's not too pedantic of me to point out that "unnecessary  
> work"
> means something quite different from "pedantic". Or maybe it is  
> pedantic,
> but necessary ;-)

Requiring me to add a semicolon in a location where my intent is  
already clear is both unnecessary and pedantic. :P

> Whether the semicolon is unnecessary depends on what is on the next  
> line
> after your example. For instance:
> = function() {
>    //...
>  }
>  (anything)
> This will unintentionally apply the function to (anything) and set Foo
> to the result. So the semicolon is necessary here.

Yes, I know, which is why I cited that specific example.  You're  
missing my point: it is extremely common for JS hackers to define  
functions like above -- as an expression -- without placing a  
semicolon after the closing brace.  This is very natural, since JS is  
graphically similar to C, Java, etc.  Requiring semicolons after the  
closing brace goes against the grain of years of hacking for most  
coders.  You're asking for a change in behavior that is both ingrained  
and reflexive.

It's not out-of-line to ask for such changes, but I have yet to see  
what your rationale is, other than making parsing easier. (Which has  
zero benefit to the coder.)  What's the benefit to Joe Hacker that's  
worth the cost?

> Since the above code is valid ECMAScript, the filter can't reject it,
> but it can heuristically warn about code that is likely to have  
> omitted
> semicolons where they are needed.

If such warnings are common, the warnings become noise and are  
ignored.  And my point is that these warnings will be extremely  
common.  So you can generate warnings (lots of noise requiring  
pedantic changes to silence), or you can update the code auto-insert  
semicolons (with all the source-control and general scare-factor  
headaches that come with it).  I have a hard time seeing either option  
receiving much uptake in the community at large.

>> I don't think it's right to ask "what are the reasons someone  
>> wouldn't
>> migrate to strict mode?"  Non-migration is the de-facto "winning"
>> position.  The real question is, "why would someone bother to  
>> migrate?"
> Isn't that obvious? To provide a better chance of detecting errors in
> their code.

In code that's already working?  The signal-to-noise ratio is way  
off.  Besides, exactly how often do JS coders trip up on semicolon  
insertion behavior?

> But I suspect that strict mode will be *more* relevant for
> new code. If it is used in a large proportion of new code and in  
> heavily
> relied-on code (libraries like Prototype, jQuery, etc., and internally
> within browser implementations), then it will have been successful.

So we can agree that strict mode will receive little uptake in legacy  

Uptake in new code will only occur if strict mode provides more  
benefit than annoyance.  And I don't think semicolon insertion is a  
problem from the end-coder's perspective.  I just don't see lots of  
people saying, "gee I wish JavaScript didn't have that crazy semicolon  
insertion" or "hey, watch out for you line-endings in JavaScript."   
It's a difficult problem wrt parsing, to be sure.  But it feels like  
the desire to abolish semicolon insertion is rooted more in  
simplifying parsers than it is in making hackers' lives easier.

More information about the Es-discuss mailing list