This is sarcasm right? There are more rules around where and where not to use semi colons than there are in just leaving them out. If one couldn't learn the 2 rules then they could use @PrettierCode, @StandardJS, or eslint --fix which solve this problem over 35 years ago.
As a supporter of no-semi style, would you be in favor of mandatory semicolons for class fields?
-
-
As a supporter I don't personally mind the new ASI hazards. The bad ones. The worst one is `async`, so if I could get one wish, it would be to get rid of that.
-
Get rid of it how?
-
If possible, I would special-case the async "field name" in class bodies, make it not trigger ASI. (make it behave just like `get`)
-
Outside of classes, async is already a variable, so it requires a NoLineTerminatorHere. You're saying in classes relax that restriction so that you would *require* a semi for a field named get, set or async?
-
I thought fields named `get` and `set` already require a semicolon? I thought `async` should be included too. https://tc39.github.io/proposal-class-fields/#sec-asi-hazards-in-class-bodies …
-
Sorry. (this space is confusing with all the double negatives inside of double negatives). We could relax NoLineTerminatorHere for async methods in classes, but we won't be able to do that again for new contextual keywords later. Also inconsistency with async functions.
-
Consistency is impossible, but I see your other point. What if additionally semicolons are required for fields without an initializer?
-
Would that be acceptable to people who want a no-semi style?
- 21 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
