What about class properties?https://github.com/tc39/ecma262/pull/1062#issuecomment-357089404 …
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?
-
(I would expect fields without initializers to be used along with documentation, which would also increase the risk of no-semis, since the offending "next line" could be way later)
-
I would probably initialise those to `undefined` explicitly and use a noUninitializedClassFields linter rule. Hope that typed dialects could take advantage of the type declaration to do better ASI without requiring initialisation.
-
Would users of standard accept this compromise? /cc
@feross It's not ridiculous and I'd be willing to give it a try at TC39. Aside: we need more representation from users of this style on TC39. -
I don't really understand. We decided to support ASI in field initializers fully specifically to support demands for this behavior from people who use the no semicolon style. Would that group prefer to be forced to use semicolons to avoid creating new ASI hazards?
- 17 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.
