Perhaps TC39 should make that a recommendation to themselves then 
(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?
-
We came to this decision partly because we do have some representation on the committee from no semicolon programmers, e.g.
@Keithamus -
This is correct, and my objection was on the grounds that (barring straight for loops) semis are not a _required_ part of syntax. Saying semis should be required without initialisers, but not required with them seems like a worse decision though
-
Is the without-init/not-with-init requirement a serious proposal or a strawman? That is not a proposal of the "ASI applies in class bodies" or "ASI does not apply in class bodies" form.
-
It's a serious proposal, but unsure if it has legs. It allows broad use of no-semis with a small additional restriction for unusual cases. Not so different from other standardjs mitigations like requiring {} for if() etc.
-
I need to see a spec. On usability front it does not seem that helpful if semi required w/o init.
- 12 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.