On Jul 24, 2010, at 3:38 PM, Maciej Stachowiak wrote: >> ASI has two parts: syntax error correction + restricted productions. The >> pain users feel from ASI in my experience is mostly not from the >> well-specified error correction part. It's mainly due to those infernal >> restricted productions, especially >> >> ReturnStatement: >> return [no LineTerminator here] Expressionopt ; > > That's a good point. If we had a "disable ASI" mode, would it just insert > syntax errors wherever a semicolon would have been inserted, or would it make > statements that could be valid multiline statements but for ASI have their > expected multiline meaning? The latter would remove more of the annoyance of > ASI, but it wouldn't be a subset of the language. I could see an argument for > either, or for no change.
I see three tenable alternatives: 1. Remove ASI in some opt-in version, in full -- no error correction, no restricted productions. 2. Remove ASI's restricted productions in some opt-in version, but keep the error correction aspect of ASI (i.e., remove rule 3 of the three rules of ASI at ECMA-262 7.9.1). 3. No change. I don't see why you'd remove error correction but leave the restricted productions just to have a subset language. We're adding new syntax to Harmony edition(s). Beyond this, the source of most ASI pain is the restricted productions. Error correction, especially via ASI rule 1 second bullet (inserting a ; before a }) is a win for usability. I strongly suspect we'll stick with 3 indefinitely, but I'm open to discussing 2 briefly. Better than discussing would be some codesearch.google type study of a large swath of web JS, measuring how much would break under 2. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
