Proposal: Modify automatic semicolon insertion in strict mode

Yuh-Ruey Chen maian330 at
Sun Dec 7 17:15:43 PST 2008

Most people on this list consider automatic semicolon insertion
something of a mistake. However, I think this feature would be fine if
it were not so "eager" and thus causing all sorts of subtle errors and
hampering language evolution (e.g. the ongoing lambda discussion). By
eager, I mean that there are too many cases where automatic semicolon
insertion takes place.

So here's the proposal:

1) Stricter rules for function call and subscript operators

... f
(args) ...

currently parses as:

... f(args) ...;

I propose that this instead parses as:

... f;
(args) ...;


... a
[args] ....

should parse as:

... a;
[args] ...;

Note that:

... f(
) ...

should still parse as:

... f(args) ...;

2) Stricter rules for binary operators (including '.' and ',')

... a

currently parses as:

... a BINARY_OP b ...;

I propose that this instead parses as:

... a;
BINARY_OP b ...;

and thus results in a syntax error, unless it's a unary operator.

Note that:

b ...

should still parse as:

... a BINARY_OP b ...;

Since expressions starting with unary operators are usually valid yet
erroneous code...

3) All expression statements that start with an expression of lesser
precedence than an assignment operator should result in an error, or at
the very least, a warning. This applies even if the statement does have
an effect. For example, all the following lines should generate some

+(a = 10)
a * func()
[a, b, c]

OTOH, if operator overloading is ever added to the language, this will
be trickier, since user-defined operator methods may cause side effects.

4) (Optional) To simplify grammar implementation, these new rules apply
even if the expressions are nested within group operators, e.g.

... ( ... a
BINARY_OP b ... ) ...

should still parse as

... ( ... a;
BINARY_OP b ... ) ...;

and result in a syntax error. Ditto for [], and {}. I believe the
official Ruby interpreter works this way and I haven't heard many
complaints about it.

5) Since this is all clearly incompatible with existing ES3 code, this
requires an opt-in: these new rules should only be followed under strict

6) This is auxiliary to this proposal, but it needs to be stated: There
should be a tool that converts ES3 to ES-Harmony in a similar vein to
Python's 2to3 tool, that would ease the migration cost of above and
other strict mode changes.

More information about the Es-discuss mailing list