Yes, the line joining is precisely where people trip up, the classic example being
return
{ foo: bar } return
{ foo: bar }returnStmt ::= "return" [ expression ] (";" or EOL)
Note that expression is optional, so it's the choice of `return' by itself being a valid statement on its own that "causes problems".
Plus, this is not really a problem that can be solved by simply putting semicolons everywhere. You can't change the parser rules by including or not semicolons.
Also, same thing with break/continue:
breakStmt ::= "break" [ label ] (";" or EOL)
continueStmt ::= "continue" [ label ] (";" or EOL)
A standalone object literal would likely be interpreted as a block and would throw a syntax error unless it were a simple identifier and a statement `{ foo: <statement> }`, in which case it would not interpret it as an object but exactly what it is, a label and a statement.
This is why JSON parsers which use eval must first wrap the object literal with parens, to make it an expression rather than a statement.
The thing is:
- `return` alone is a valid statement in its own.
- The parser just need to use a simple lookahead to decide whether the next line is part of the previous statement.
- The parser DON'T change the meaning of your programs.
All that's beside that is a matter of taste. Whether use semicolons or not is up to what sits better with each person. I'm just arguing against the silly and incorrect "technical" arguments against it.