Editorial: Add Interesting Cases of Automatic Semicolon Insertion #1062
Conversation
|
|
Some of the text in the PR was by @mathiasbynens and @bakkot , not just me! |
|
Every change I do to the author doesn't show all the authors... |
bmeck
force-pushed
the
asi-hazard
branch
2 times, most recently
from
4ae34f7 to
51db690
Compare
spec.html
Outdated
| <em>This section is non-normative.</em> | ||
| <p>ECMAScript programs can be written in a style with very few semicolons, based on a heavy dependence on automatic semicolon insertion. However, as described above, semicolons are not inserted at every newline, and some of these cases which do not have an automatically inserted semicolon can be counter-intuitive or confusing.</p> | ||
|
|
||
| <p>As new syntactic features are added to ECMAScript, additional cases requiring explicit semicolons emerge over time. As such, consistently explicit semicolon use is recommended.</p> |
There was a problem hiding this comment.
I myself am way more (╯°□°）╯︵ ┻━┻ on this one. YMMV. Good luck all.
There was a problem hiding this comment.
Missing ’:
-outside of a grammar productions existing text boundaries
+outside of a grammar production’s existing text boundaries
|
|
Hey, so - this makes me a little sad. JS is the only language I write, and I don't use semicolons. I know it's just a warning clause, but it sounds like the TC39 is saying we're bad for using the language in a particular way. And it, feels, well, a little hurtful. Feelings are hard to describe, but yeah - it's not a great feeling. I kinda wish there'd be a bit more empathy for how humans are using JS. I mean: standard doesn't do semicolons, and has almost a million downloads a month. It's by no means a definitive measure, but it probably means there's more than few people out there that don't use semicolons either. I don't expect to change anyone's mind, but felt I it should be shared. So yeah, this makes me sad - and I suspect I'm not alone. That's all. Thanks for reading & all the work y'all doing! 🙏 edit: heya, if y'all couldn't upvote / downvote this post that'd be rad. I'd rather not that this turn into some form of competition. Let's please keep this nice for everyone involved. Thanks a lot! edit: seriously. |
|
cc @kentcdodds; it would be good to get your eyes on this. |
|
👎 on this. There have been various confusions and FUD around ASI in new ES features, like when babel started requiring semicolons at the end of class method declarations for a week when ASI actually applied in that scenario. Is the preferences/biasses of the TC39 members perhaps leaking into the editorial a bit much here? It almost reads like members of TC39 would like to go out of the way to weaken this way of working? I don't believe that, but a more neutral working would help avoid this perception. Would you please consider different wording here?
Manual semicolon insertion is an inarguably more involved (more typing semicolons all over the place by hand) method of ensuring you aren't making ASI mistakes, and keeping semicolon usage consistent in a code base with or without semicolons is difficult to do by hand. This is why, in general, people use tools to enforce it either way. ECMAScript has lots of oddities, (even with semicolons) so arguing unequivocally that one approach is safer than the other is simply muddling the conversation when in both cases, people are using analysis and tooling to fundamentally solve the warts of ECMAScript semicolon bugs that are set in stone. |
|
@yoshuawuyts @bcomnes The intention - and the committee's consensus - is to discourage reliance on ASI. As such, while the text is not intended to pass judgement or say anyone is "bad" or "misusing" anything, it definitely is not intended to be neutral. The debate about whether one should or should not use semicolons isn't something that would be productive to have here, so let's all please not go down that road. |
I can't speak for TC39 as a whole, but I'd view this not as
and more as
|
Agreed, which is why I'm objecting to the wording, since its clearly taking a side on the debate. |
|
Another rewording I would be happy with:
|
Can you explain a preferable wording perhaps? The ASI hazards increasing over time is a certainty at this point. The recommendation to detect them also seems reasonable. |
This wording seems like it's pretty neutral - a linter can warn against ASI hazards whether you're relying on ASI or not. |
This is less actionable, I'd prefer not to degrade the wording to lack a path for guarding against future breakage. |
|
@bakkot, thanks for the ping. Every time I start typing something useful, someone else comes in with what I was going to say. I don't think I have much more to add to the conversation 😅 FWIW, I'm in favor of this PR as I think it's good for the TC39 to list the hazards. I'm not super in favor of the TC39 making any recommendation regarding whether or not to use the ASI feature, so perhaps some change in wording could be useful. I would be in favor of TC39 suggesting being aware of the hazards and using automated tooling (a linter) to encourage good patterns to avoid pitfalls (whether you use semicolons or not this is important). Thanks for those who are iterating on this :) |
|
@bmeck I offered 2 rewordings. |
|
@mikesamuel yay, yeah I like that a lot! That offers some comfort! 😁 Probably the other bit of implication I'm afraid of is that new features might disencourage the use of ASI completely. I wish it'd say something along the lines of
Not so much a contract, but more like - "yeah, we care about you whether or not you use semicolons". Does that make sense? |
This would not prevent future problems, but it would be a means to detect them as they are introduced. However, tools have not always remained up date with current hazards. See notes from last TC39 meeting that brought this up. |
@yoshuawuyts Bingo.
Statements like this make it sound like you have no interest in trying to reduce these cases, I think it's worth trying as ASI is working perfectly fine for a lot of people. |
I am not against ASI usage, but grammar wise it will have collisions and increased hazards. See the same notes I linked above. This is not an opinion based statement. If the grammar increases the hazards of ASI will increase. Edit: until now we have managed to work around ASI hazards as best as possible, but the limits of what can be done to avoid introducing hazards is a diminishing resource. |
That's not really the issue. The specification defines ASI in a manner that guarantees that ASI will work for properly defined new grammar constructs (there have been cases in the past where proposal authors did not understand what constitutes a "properly defined" grammar construct). The real issue is how hard TC39 will work to identify and minimize (via restricted productions or redefining a proposed feature's syntax) new ASI hazards (places where the intended meaning of the program is ambiguous without semi-colons). My understanding is that the intent of this change is to give warning that as the language grows is becoming significant harder for TC39 to identify and remediate potentially significant ASI hazards and hence the number of unmediated ASI hazards may significantly grow in the future. Writing code without semi-colons exposes the code to such future hazards when and if such code is updated in the future to use new features. The safest way to future-proof code against future ASI hazards is to use semi-colons. |
spec.html
Outdated
| <emu-clause id="sec-hazards-of-automatic-semicolon-insertion"> | ||
| <h1>Hazards of Automatic Semicolon Insertion</h1> | ||
| <em>This section is non-normative.</em> | ||
| <p>ECMAScript programs can be written in a style with very few semicolons, based on a heavy dependence on automatic semicolon insertion. However, as described above, semicolons are not inserted at every newline, and some of these cases which do not have an automatically inserted semicolon can be counter-intuitive or confusing.</p> |
There was a problem hiding this comment.
very few semicolons by relying on automatic semicolon insertion. (verbosity reduction, same content I think?)
spec.html
Outdated
|
|
||
| <p>As new syntactic features are added to ECMAScript, additional cases requiring explicit semicolons emerge over time. As such, consistently explicit semicolon use is recommended.</p> | ||
|
|
||
| <p>The term "automatic semicolon insertion hazard" refers, informally, to a place where a developer may expect a semicolon to be inserted, but according to the rules described above, it is not. The rest of this section describes a number of automatic semicolon insertion hazards in this version of ECMAScript.</p> |
There was a problem hiding this comment.
If this term is used someplace, make it an actual term with a dfn, otherwise I'm not sure we need to define a term here?
Could just start with "There are places where a developer may..." and eliminate the first part.
There was a problem hiding this comment.
I would like a phrase for this space since it is ~ a list that has items that will grow over time.
spec.html
Outdated
| <li><strong>A RegExp literal</strong>. Without a semicolon, the two lines together may be parsed instead as a division, for example if the RegExp has flags.</li> | ||
| </ul> | ||
| </emu-clause> | ||
| </emu-clause> |
|
Not popular opinion: semicolons is must |
Sounds good to me. |
In that case, I'd argue that you're misrepresenting Camp 2 since I do not identify with its wording. What's more, I don't think I can recognize anyone in the TC39 saying it the way you did, which makes me think that you may be extremizing the position of Camp 2.
I recognize one person who suggested it. That's not overlapping with Camp 2 (assuming I belong to it) since I believe this not to be a reasonable replacement for the communication about the direction of the language development coming in collision for ASI style.
It doesn't. It results in a style of programming which, while viable and mostly consistent today, may become less consistent in the future. Please, do not misrepresent the phrase "may become more inconsistent" as "should be forbidden" or "will be removed", but also don't underestimate it as "it's all fine, we handle it today, it'll be similarly ok two years from now". I believe that such dismissal of the concern is unwarranted. |
Not trying to misrepresent. I don't understand the differentiation you are trying to make though.
See #1062 (comment) and the Standard issue tracker received a few other messages with similar readings. There is likely more discussion around this I am not up to speed on. My point is that there was not a consensus over the correct reading of "camp1" and I represented a "camp2" reading accurately (perhaps not yours though, which sounds somewhat in between these two).
People are smart. Linters will make adjustments as needed. Old code won't be broken by whatever additions TC-39 adds. ASI has always been a mess. The stance I am holding strong on is that I think it would be a mistake for TC-39 to make stylistic recommendations which is a false solution to the actual problem at hand. |
I believe that's a correct interpretation of the situation. Thanks for recognizing that.
I stand corrected.
That's not something TC39 is comfortable accepting as not-actionable.
I'm sorry, but at the point where you use the phrase "stylistic recommendation" I must question your understanding not only of my position but of the whole issue. TC39 is not interested in making stylistic recommendations. Many of us are, on the other hand, interested in reducing the uneven distribution of knowledge about the impact of the future direction of the language design on ASI. We're trying to address this imbalance. |
ghost
mentioned this pull request
|
Thanks for pinging the thread, @chicoxyzzy . @ljharb @zenparsing What will it take to get this PR merged? |
|
At least #1062 (comment). Also, the text was reworded to avoid the word “hazard,” which I appreciate, but using “interesting“ instead makes the wording awkward. |
|
@bmeck Are you available to make these updates? |
|
This PR can not merge at this time, as the committee consensus we had prior to this PR going up was lost at the next meeting. We’d have to discuss it in plenary again; it would be ideal to minimize pinging this contentious and popular thread in the meantime. |
|
@ljharb The current PR refrains from making a recommendation, and simply documents the ASI cases. This PR uses the term "interesting" instead of "hazard". I agree with other commenters that we should find a new word, but I believe this is consistent with TC39's current resolution. |
…39#1062) Co-authored-by: Bradley Farias <bradley.meck@gmail.com> Co-authored-by: Daniel Ehrenberg <littledan@chromium.org> Co-authored-by: Mathias Bynens <mathias@qiwi.be>
ljharb
changed the title
There was a problem hiding this comment.
This was discussed in the editor call and in last week's TC39 meeting. Since the PR now makes no recommendations nor offers any opinions, merely lists facts, it will hopefully not be controversial to land.
Thanks to everyone for their input and passion for the language! Further issues and PRs to improve this section's accuracy are welcome.
spec.html
Outdated
| <ul> | ||
| <li><strong>An opening parenthesis (<code>(</code>)</strong>. Without a semicolon, the two lines together are treated as a |CallExpression|.</li> | ||
| <li><strong>An opening square bracket (<code>[</code>)</strong>. Without a semicolon, the two lines together are treated as property access, rather than an |ArrayLiteral| or |ArrayAssignmentPattern|.</li> | ||
| <li><strong>A template string (<code>`</code>)</strong>. Without a semicolon, the two lines together are interpreted as a tagged Template (<emu-xref href="#sec-tagged-templates"></emu-xref>), with the previous expression as the |MemberExpression|.</li> |
There was a problem hiding this comment.
| <li><strong>A template string (<code>`</code>)</strong>. Without a semicolon, the two lines together are interpreted as a tagged Template (<emu-xref href="#sec-tagged-templates"></emu-xref>), with the previous expression as the |MemberExpression|.</li> | |
| <li><strong>A template literal (<code>`</code>)</strong>. Without a semicolon, the two lines together are interpreted as a tagged Template (<emu-xref href="#sec-tagged-templates"></emu-xref>), with the previous expression as the |MemberExpression|.</li> |
ljharb
added
editorial change
and removed
editor call
Unsure on how we want to put @littledan as original author.