That's a whole different matter, which can't make you shoot yourself in the foot without knowing it for any non-trivial code. CoffeeScript's scoping forces you to always keep track of whatever is enclosing the current…
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…
My feelings exactly :3
I really don't see any problem with the way JavaScript handles it. "Unless the following line can be part of the preceding statement, end the current statement" is a pretty natural thing to me. But well, I guess that's…
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…
And where would JavaScript not handle them in a way people don't expect them to be handled? Comparing Python's handling of semicolons with JavaScript's ASI, you get the following: -- End of statements Python and…
That's a whole different matter, which can't make you shoot yourself in the foot without knowing it for any non-trivial code. CoffeeScript's scoping forces you to always keep track of whatever is enclosing the current…
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…
My feelings exactly :3
I really don't see any problem with the way JavaScript handles it. "Unless the following line can be part of the preceding statement, end the current statement" is a pretty natural thing to me. But well, I guess that's…
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…
And where would JavaScript not handle them in a way people don't expect them to be handled? Comparing Python's handling of semicolons with JavaScript's ASI, you get the following: -- End of statements Python and…