[notSorella]

That's not a problem with the line joining stuff. Both `return' and `{ foo: bar }' are ENTIRE VALID statements in their own right.

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)

[cdsanchez]

`return` may be a valid statement but an object literal is not.

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.

[notSorella]

Never said it was an object literal eh. Object literals can only occur inside expressions, that's pretty well defined in the JavaScript AST too, which is described to the utmost detail in the ECMAScript specs.

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.