If possible, I would special-case the async "field name" in class bodies, make it not trigger ASI. (make it behave just like `get`)
-
-
Replying to @spion @lucasazzola and
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?
1 reply 0 retweets 0 likes -
Replying to @wycats @lucasazzola and
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 …
1 reply 0 retweets 0 likes -
Replying to @spion @lucasazzola and
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.
2 replies 0 retweets 0 likes -
Replying to @wycats @lucasazzola and
Consistency is impossible, but I see your other point. What if additionally semicolons are required for fields without an initializer?
1 reply 0 retweets 0 likes -
Replying to @spion @lucasazzola and
Would that be acceptable to people who want a no-semi style?
2 replies 0 retweets 0 likes -
(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)
1 reply 0 retweets 0 likes -
Replying to @wycats @lucasazzola and
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.
2 replies 0 retweets 0 likes -
Replying to @spion @lucasazzola and
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.3 replies 0 retweets 0 likes -
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?
2 replies 0 retweets 2 likes
He's a no-semi person so I was trying to find out!
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.