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.
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.
-
There are new ASI hazards even with initializers, e.g., when preceding a generator method.
-
Yes, I agree. I don't see the point in splitting the rules up depending on presence of initializer. Standard.js can use newline sensitivity to protect if ASI; or TC39 could carve out ASI-off in class body. No third way.
- 10 more replies
New conversation -
-
-
(standard would make initializing fields mandatory to avoid new ASI hazards in this context)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I don't know if I'm a typical no-semi user, since I value not getting new cases of "unexpected" semicolon insertion over no-semi style.
-
oops, let me try that again avoiding double negatives: I think surprising semicolon insertion is much worse than surprising semicolon non-insertion.
-
Very valid, and an underrepresented position!
End of conversation
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.