What do you mean? This problem is very real. Lots of semicolon proponents think that just adding semicolons everywhere will make everything safe.
-
-
Perhaps TC39 should make that a recommendation to themselves then

-
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.
- 23 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.