Proposal: Modify automatic semicolon insertion in strict mode

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Sun Dec 7 21:48:06 PST 2008


Yuh-Ruey Chen wrote:
> 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.

There are, but I think it's a bad idea to change semicolon insertion
in such a way that currently valid programs are still valid but are
parsed differently.

> 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) ...;
> 
> Likewise,
> 
> ... a
> [args] ....
> 
> should parse as:
> 
> ... a;
> [args] ...;
> 
> Note that:
> 
> ... f(
> args
> ) ...
> 
> should still parse as:
> 
> ... f(args) ...;

All of these changes affect the behaviour of valid programs without making
them invalid.

> 2) Stricter rules for binary operators (including '.' and ',')
> 
> ... a
> BINARY_OP b
> 
> 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:
> 
> ... a BINARY_OP
> b ...
> 
> should still parse as:
> 
> ... a BINARY_OP b ...;
> 
> Since expressions starting with unary operators are usually valid yet
> erroneous code...

No, it's perfectly commonplace to break a line before a binary operator:

  var foo = some_very_long___________________________________expression
     + some_other_expression;

> 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
> warning:
> 
> +(a = 10)
> +func()
> 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.

This has more merit than 1) or 2). I considered it for Jacaranda, although
it didn't make it into the spec.

However, warnings are out of scope for the language specification, unless
they are in some informative annex. Also, this proposal doesn't seem to
have anything to do with semicolon insertion.

> 4) (Optional) To simplify grammar implementation, these new rules apply
> even if the expressions are nested within group operators, [...]
> 
> 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
> mode.

That's not sufficient. Strict mode is supposed to be a subset.

-- 
David-Sarah Hopwood


More information about the Es-discuss mailing list