Proposal: disable automatic semicolon insertion (looking for champion)

I want to propose a way to disable automatic semicolon insertion (ASI), because its behaviours are a little confusing sometimes, and it's probably easier to remember to put in semicolons. Plus with all the tooling available, its much easier to prevent this in the first place now.

More info: GitHub - autumnblazey/proposal-disable-asi: proposal to disable automatic semicolon insertion (ASI)

Disabling it for your own code is already long-since achievable with a linter, and thus doesn't need a proposal.

Disabling it for code you didn't author is almost guaranteed to break your program, as well as the web in general, and so such a proposal would have a hard road to persuade others that it was a good idea.

3 Likes

Not all JS developers use semicolons. Some prefer the more python-ish look. StandardJS for example:

No semicolons
JavaScript Standard Style

2 Likes

yea probably should have said this in the original post, but I'm suggesting a way similar to "use strict" to make it toggleable

What advantage do you see in this being a feature of the language? As opposed to using a tool like Eslint to achieve this.

/*eslint semi: ["error", "always"]*/

var name = "ESLint" // error!
1 Like

I feel like the presence of ASI leads to some behaviour that isn't wanted by both semi users and no semi users, and I believe its easier to have a way to turn off ASI and have the behaviour more consistent and not rely on some hacky methods to go around ASI and make it behave correctly all the time

This type of request confounds me.

Other than in the "for" statement and minification it serves no non-duplicated useful purpose in the language. If one adopts the functional style of javascript (which is where the language has been heading) and chooses to use "while" instead of "for" the semicolon can be relegated to the same category as 'eval' or 'hasOwnProperty' . In other words it is useful for specific system-like housekeeping but that is all.

Unless you are a Mozart we should all heed the advice of Emperor Joseph

"There are simply too many notes" ; :)

true true, it does seem like a lot of work to implement for such a small thing, thanks for considering though c:

It seems rational in combination with a decision to prevent treating brackets located on a next line as belonged to current expression. Thus it will solve all the cases with redundant semicolons in classes or before arrays and expressions in round brackets.

// Accidental nested property read
let array = []
[1, 2, 3].forEach(v => console.log(v))  // ⚠️ TypeError


// Accidental nested call
let value = ""
(() => console.log('Hello'))()  // ⚠️ TypeError


// SyntaxError while parsing expressions in class body
class Rect {
  width = 0
  height = 0 // ⚠️ SyntaxError
  [Symbol.toStringTag]() {
    return this.width === this.height ? 'Square' : 'Rectangle'
  }
}

"use strict"
[1, 2, 3].forEach(v => console.log(v)) // ⚠️ TypeError

I think it might be implemented due to JS already has meaningful whitespaces in some corner cases: a+++b and a+ ++b have different behavior because of whitespace. Also it makes no sense to split function call or property reading expressions into several lines anyway. If you want to get a property from a value, you'll place a bracket right next to the value.

I'm not against semicolons, but I'm agree that current parser behavior should be made sane and logical. Now the attempt to satisfy two opposite behaviors works poorly and I'd prefer to have stricter and obvious solution. Linters are de facto a standard in DX and most of linter configs prescribe to use or to avoid semicolons.

2 Likes

I initially wanted to just remove ASI entirely because it's quite redundant (now and always, you should be testing your code before you ship), but I was thinking of backwards compatibility to avoid breaking people's code, so it seemed like a toggleable was the best option.