3 ms·

On the indentation one: function createNewArray(item) { return [item] } The author claims this produces “Uncaught SyntaxError: Invalid or unexpe

On the indentation one: function createNewArray(item) { return [item] } The author claims this produces “Uncaught SyntaxError: Invalid or unexpected token”. This is incorrect; you end up with the body being `return; [item];` thanks to Automatic Semicolon Insertion, which is unlikely to be what was intended, and will produce a warning in some environments (e.g. “unreachable code after return statement” in Firefox), but is not a syntax error. I presume the author wrote slightly different code. Most especially, I don’t believe anything is ever indentation-sensitive.

jeroenhd 5y ago
This is why I hate that Javascript has automatic semicolon insertion. A whole new set of rules to keep in mind because some developers can't be bothered to put semicolons behind their expressions and statements. Unlike languages like Python, which have been designed from the ground up to avoid semicolons, or Bash, which requires very explicit multi line splits, Javascript is just not a great language to work without them and the language clearly suffers for it. Javascript shouldn't be indentation dependent, but I have no trouble believing that it's doing something weird to indents because of this "feature".
- paskozdilar 5y ago
  I'd just like to add that Go has automatic semicolon insertion, and I have never experienced any surprises with it, thanks to gofmt.
  - yakak 5y ago
    I never have trouble with automatic semicolon insertion in real JS-based projects thanks to similar format tools. JS only really has this problem when it is serving its unique position as the scripting language of the web.
  - hnlmorg 5y ago
    Go doesn't have automatic semicolon insertion. It's just not required unless for splitting multiple commands on the same line. So falls into the same category as Bash in the GPs examples. Thus Go's syntax has been designed around having semicolons omitted. Whereas JavaScript technically requires it but many browsers decided to support parsing missing semicolons for the sake of making bad websites render (much like how most browsers will support a variety of incorrectly formatted HTML documents as well). The problem here is that JavaScript's syntax wasn't designed to have semicolons omitted. Which leads to all sorts of edge case problems and no clear answer on how they should be handled.
    - fenomas 5y ago
      The JS part of your comment isn't correct at all. ASI rules are fully described in the very first JS spec, and in 20+ years of JS coding I can't recall ever having heard of browsers handling it inconsistently.
      - hnlmorg 5y ago
        Maybe it's the way the language is taught that has changed? Originally (pre-ECMA days) you were taught that you should always include a semi-colon. The older specifications certainly don't encourage dropping semicolons liberally either. Take this passage from the specification: > Most ECMAScript statements and declarations must be terminated with a semicolon. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations. Which, to me at least, reads as saying JavaScript must include a semicolon but interpreters must be tolerant of the occasional missing semicolon where intent is obvious. Somewhere along the line the attitude seems to have changed from "you should include them" to "don't bother". Or at least that's perception I get these days. I've not been heavily involved in JavaScript for a few years but I was one of the early adopters back in the days of Netscape Navigator and, later, Internet Explorer (albeit with it's differing but ever-so-similar "JSScript"). As an aside, since I'm talking about the early days of web scripting, wouldn't it be great if we brought back the language property of <script> to support other languages. Wouldn't be sensible in practice (for a whole plethora of reasons) but one can dream....
- Kaze404 5y ago
  What is this set of rules exactly? As far as I'm concerned all you have to do is not put newlines between your "return" and whatever is being returned, which is hardly a common thing anyways.
  - jeroenhd 5y ago
    The rules are here: https://262.ecma-international.org/7.0/#sec-automatic-semicolon-insertion https://262.ecma-international.org/7.0/#sec-automatic-semico... Generally, the rule seems to be "insert a semicolon wherever the syntax messes up but can be fixed by adding semicolons". Then there are some special cases (++/--/continue/break/return/throw/arrow functions/yield) with more specific rules about where semicolons are placed and when; those are probably why the example produces "unexpected" results. I think the added complexity of these special rules and cases are an unnecessary burden, and honestly the language should never have allowed leaving out semicolons when it was clearly designed to have semicolons.
    - SemanticStrengh 5y ago
      Those contrived cases do not happen in practice. What does happen systematically though is the clutter and cognitive noise of semicolons.
      - mjevans 5y ago
        Semicolons are like the periods of sentences It's so much easier to read something someone else wrote when thoughts are properly terminated Why would you ever demand that semicolons are removed They also prevent issues such as pronouns like SemanticStrength if used with mechanical automatic period insertion Seriously, semicolons are something that was baked into the design assumptions of JavaScript. Python's an example of a language where the syntax was clearly designed from the inception to avoid them. Most such languages make explicit tradeoffs and TBH I'd much rather have semicolons than whitespace sensitivity.
        SemanticStrengh 5y ago

jeroenhd 5y ago

This is why I hate that Javascript has automatic semicolon insertion. A whole new set of rules to keep in mind because some developers can't be bothered to put semicolons behind their expressions and statements. Unlike languages like Python, which have been designed from the ground up to avoid semicolons, or Bash, which requires very explicit multi line splits, Javascript is just not a great language to work without them and the language clearly suffers for it. Javascript shouldn't be indentation dependent, but I have no trouble believing that it's doing something weird to indents because of this "feature".

paskozdilar 5y ago
I'd just like to add that Go has automatic semicolon insertion, and I have never experienced any surprises with it, thanks to gofmt.
- yakak 5y ago
  I never have trouble with automatic semicolon insertion in real JS-based projects thanks to similar format tools. JS only really has this problem when it is serving its unique position as the scripting language of the web.
- hnlmorg 5y ago
  Go doesn't have automatic semicolon insertion. It's just not required unless for splitting multiple commands on the same line. So falls into the same category as Bash in the GPs examples. Thus Go's syntax has been designed around having semicolons omitted. Whereas JavaScript technically requires it but many browsers decided to support parsing missing semicolons for the sake of making bad websites render (much like how most browsers will support a variety of incorrectly formatted HTML documents as well). The problem here is that JavaScript's syntax wasn't designed to have semicolons omitted. Which leads to all sorts of edge case problems and no clear answer on how they should be handled.
  - fenomas 5y ago
    The JS part of your comment isn't correct at all. ASI rules are fully described in the very first JS spec, and in 20+ years of JS coding I can't recall ever having heard of browsers handling it inconsistently.
    - hnlmorg 5y ago
      Maybe it's the way the language is taught that has changed? Originally (pre-ECMA days) you were taught that you should always include a semi-colon. The older specifications certainly don't encourage dropping semicolons liberally either. Take this passage from the specification: > Most ECMAScript statements and declarations must be terminated with a semicolon. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations. Which, to me at least, reads as saying JavaScript must include a semicolon but interpreters must be tolerant of the occasional missing semicolon where intent is obvious. Somewhere along the line the attitude seems to have changed from "you should include them" to "don't bother". Or at least that's perception I get these days. I've not been heavily involved in JavaScript for a few years but I was one of the early adopters back in the days of Netscape Navigator and, later, Internet Explorer (albeit with it's differing but ever-so-similar "JSScript"). As an aside, since I'm talking about the early days of web scripting, wouldn't it be great if we brought back the language property of <script> to support other languages. Wouldn't be sensible in practice (for a whole plethora of reasons) but one can dream....
Kaze404 5y ago
What is this set of rules exactly? As far as I'm concerned all you have to do is not put newlines between your "return" and whatever is being returned, which is hardly a common thing anyways.
- jeroenhd 5y ago
  The rules are here: https://262.ecma-international.org/7.0/#sec-automatic-semicolon-insertion https://262.ecma-international.org/7.0/#sec-automatic-semico... Generally, the rule seems to be "insert a semicolon wherever the syntax messes up but can be fixed by adding semicolons". Then there are some special cases (++/--/continue/break/return/throw/arrow functions/yield) with more specific rules about where semicolons are placed and when; those are probably why the example produces "unexpected" results. I think the added complexity of these special rules and cases are an unnecessary burden, and honestly the language should never have allowed leaving out semicolons when it was clearly designed to have semicolons.
  - SemanticStrengh 5y ago
    Those contrived cases do not happen in practice. What does happen systematically though is the clutter and cognitive noise of semicolons.
    - mjevans 5y ago
      Semicolons are like the periods of sentences It's so much easier to read something someone else wrote when thoughts are properly terminated Why would you ever demand that semicolons are removed They also prevent issues such as pronouns like SemanticStrength if used with mechanical automatic period insertion Seriously, semicolons are something that was baked into the design assumptions of JavaScript. Python's an example of a language where the syntax was clearly designed from the inception to avoid them. Most such languages make explicit tradeoffs and TBH I'd much rather have semicolons than whitespace sensitivity.
      - SemanticStrengh 5y ago