Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: Add Interesting Cases of Automatic Semicolon Insertion #1062

Merged
merged 1 commit into from Dec 11, 2019

Conversation

@bmeck
Copy link
Member

@bmeck bmeck commented Jan 11, 2018

Unsure on how we want to put @littledan as original author.

@mathiasbynens
Copy link
Member

@mathiasbynens mathiasbynens commented Jan 11, 2018

git commit --amend --author 'Daniel Ehrenberg <littledan@chromium.org>' -C HEAD

@littledan
Copy link
Member

@littledan littledan commented Jan 11, 2018

Some of the text in the PR was by @mathiasbynens and @bakkot , not just me!

@bmeck
Copy link
Member Author

@bmeck bmeck commented Jan 11, 2018

Every change I do to the author doesn't show all the authors...

@bmeck bmeck force-pushed the asi-hazard branch 2 times, most recently from 4ae34f7 to 51db690 Jan 11, 2018
ljharb
ljharb approved these changes Jan 11, 2018
Copy link
Member

@ljharb ljharb left a comment

;

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>
Copy link
Member

@ljharb ljharb Jan 11, 2018

(ノ◕ヮ◕)ノ*:・゚✧

Copy link

@rektide rektide Jan 11, 2018

I myself am way more (╯°□°)╯︵ ┻━┻ on this one. YMMV. Good luck all.

Copy link
Member

@mathiasbynens mathiasbynens Jan 13, 2018

Missing :

-outside of a grammar productions existing text boundaries
+outside of a grammar production’s existing text boundaries

@jayphelps
Copy link

@jayphelps jayphelps commented Jan 11, 2018

Unsure on how we want to put @littledan as original author.

😉 https://github.com/jayphelps/git-blame-someone-else

@yoshuawuyts
Copy link

@yoshuawuyts yoshuawuyts commented Jan 11, 2018

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.

@bakkot
Copy link
Contributor

@bakkot bakkot commented Jan 11, 2018

cc @kentcdodds; it would be good to get your eyes on this.

@bcomnes
Copy link

@bcomnes bcomnes commented Jan 11, 2018

👎 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?

As new syntactic features are added to ECMAScript, additional automatic semicolon insertion hazard's may be introduced. Automatic tooling such as linters or formatters are recommended to warn against or fix common ASI hazards and enforce a consistent usage style.

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.

@ljharb
Copy link
Member

@ljharb ljharb commented Jan 11, 2018

@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.

@mikesamuel
Copy link
Member

@mikesamuel mikesamuel commented Jan 11, 2018

@yoshuawuyts

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.

I can't speak for TC39 as a whole, but I'd view this not as

You must do things this way or you are coding wrong.

and more as

Hey, we goofed. It turns out a feature we designed and which you like to use has some obscure implications. We can't go back and change things because reasons, but here's how to make sure the code you write does what you expect it to.

@bcomnes
Copy link

@bcomnes bcomnes commented Jan 11, 2018

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.

Agreed, which is why I'm objecting to the wording, since its clearly taking a side on the debate.

@bcomnes
Copy link

@bcomnes bcomnes commented Jan 11, 2018

Another rewording I would be happy with:

As new syntactic features are added to ECMAScript, additional automatic semicolon insertion hazard's may be introduced. As a result, the number of ASI may increase, and heavy reliance upon ASI may become more complicated.

@bmeck
Copy link
Member Author

@bmeck bmeck commented Jan 11, 2018

@bcomnes

Would you please consider different wording here?

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.

@ljharb
Copy link
Member

@ljharb ljharb commented Jan 11, 2018

Automatic tooling such as linters or formatters are recommended to warn against or fix common ASI hazards and enforce a consistent usage style.

This wording seems like it's pretty neutral - a linter can warn against ASI hazards whether you're relying on ASI or not.

@bmeck
Copy link
Member Author

@bmeck bmeck commented Jan 11, 2018

@bcomnes

As new syntactic features are added to ECMAScript, additional automatic semicolon insertion hazard's may be introduced. As a result, the number of ASI may increase, and heavy reliance upon ASI may become more complicated.

This is less actionable, I'd prefer not to degrade the wording to lack a path for guarding against future breakage.

@kentcdodds
Copy link
Member

@kentcdodds kentcdodds commented Jan 11, 2018

@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 :)

@bcomnes
Copy link

@bcomnes bcomnes commented Jan 11, 2018

@bmeck I offered 2 rewordings.

@yoshuawuyts
Copy link

@yoshuawuyts yoshuawuyts commented Jan 11, 2018

@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

Hey, so ASI wasn't meant to be used by lots of people - oops, turns out it was. Even though we might not recommend you use ASI all over the place, we'll try real hard to make it so new additions to the language will have ASI too. Because we care about everyone using JavaScript.

Not so much a contract, but more like - "yeah, we care about you whether or not you use semicolons". Does that make sense?

@bmeck
Copy link
Member Author

@bmeck bmeck commented Jan 11, 2018

@bcomnes

As new syntactic features are added to ECMAScript, additional automatic semicolon insertion hazard's may be introduced. Automatic tooling such as linters or formatters are recommended to warn against or fix common ASI hazards and enforce a consistent usage style.

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.

@markbrown4
Copy link

@markbrown4 markbrown4 commented Jan 11, 2018

we'll try real hard to make it so new additions to the language will have ASI too

@yoshuawuyts Bingo.

The ASI hazards increasing over time is a certainty at this point.

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.

@bmeck
Copy link
Member Author

@bmeck bmeck commented Jan 11, 2018

@markbrown4

Statements like this make it sound like you have no interest in trying to reduce these cases, I think it's worth trying.

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.

@allenwb
Copy link
Member

@allenwb allenwb commented Jan 11, 2018

we'll try real hard to make it so new additions to the language will have ASI too

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>
Copy link
Member

@bterlson bterlson Jan 11, 2018

very few semicolons by relying on automatic semicolon insertion. (verbosity reduction, same content I think?)

Copy link
Member Author

@bmeck bmeck Jan 11, 2018

sounds good

Copy link
Member Author

@bmeck bmeck Jan 11, 2018

fixed

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>
Copy link
Member

@bterlson bterlson Jan 11, 2018

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.

Copy link
Member Author

@bmeck bmeck Jan 11, 2018

I would like a phrase for this space since it is ~ a list that has items that will grow over time.

Copy link
Member Author

@bmeck bmeck Jan 11, 2018

now a <dfn>

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>
Copy link
Member

@bterlson bterlson Jan 11, 2018

This is awesome.

exciting.

@valorkin
Copy link

@valorkin valorkin commented Jan 11, 2018

Not popular opinion: semicolons is must
Code safety first :(

@mikesamuel
Copy link
Member

@mikesamuel mikesamuel commented Jan 11, 2018

@yoshuawuyts

Not so much a contract, but more like - "yeah, we care about you whether or not you use semicolons". Does that make sense?

Sounds good to me.

@zbraniecki
Copy link
Member

@zbraniecki zbraniecki commented Feb 9, 2018

I don't see a very clear difference between camps from what you describe. Sounds like a softer wording of a camp2 argument, but fundamentally the same.

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.

A viable camp 3 would be to recommend the use of a parsing linter as a realistic solution to avoiding ASI hazards, and leave semicolon style out of the picture all together

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.

However, the (previous) misconception of this PR seems to me to be that high semicolon style automatically results in less ASI “hazards”, while it does not.

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.

spec.html Outdated Show resolved Hide resolved
@bcomnes
Copy link

@bcomnes bcomnes commented Feb 9, 2018

In that case, I'd argue that you're misrepresenting Camp 2 since I do not identify with its wording.

Not trying to misrepresent. I don't understand the differentiation you are trying to make though.

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.

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).

It results in a style of programming which, while viable and mostly consistent today, may become less consistent in the future.

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.

@zbraniecki
Copy link
Member

@zbraniecki zbraniecki commented Feb 9, 2018

I don't understand the differentiation you are trying to make though.

I believe that's a correct interpretation of the situation. Thanks for recognizing that.

See #1062 (comment) and the Standard issue tracker received a few other messages with similar readings.

I stand corrected.

ASI has always been a mess.

That's not something TC39 is comfortable accepting as not-actionable.

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'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.
This is not, and has never been, a stylistic recommendation.

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.
Trying to request TC39 not to reduce the imbalance of information but instead communicate that JavaScript cannot be written without linter tools is not addressing the issue at hand and further indicates lack of understanding of the scope of the problem.

artola
artola approved these changes Feb 16, 2018
Copy link
Member

@chicoxyzzy chicoxyzzy left a comment

👍 This is super useful change

@littledan
Copy link
Member

@littledan littledan commented Sep 11, 2019

Thanks for pinging the thread, @chicoxyzzy .

@ljharb @zenparsing What will it take to get this PR merged?

@j-f1
Copy link

@j-f1 j-f1 commented Sep 11, 2019

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.

@littledan
Copy link
Member

@littledan littledan commented Sep 11, 2019

@bmeck Are you available to make these updates?

@ljharb
Copy link
Member

@ljharb ljharb commented Sep 11, 2019

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.

@littledan
Copy link
Member

@littledan littledan commented Sep 11, 2019

@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 ljharb changed the title Editorial: Add Automatic Semicolon Insertion hazard clause Editorial: Add Interesting Cases of Automatic Semicolon Insertion Dec 11, 2019
ljharb
ljharb approved these changes Dec 11, 2019
Copy link
Member

@ljharb ljharb left a 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>
Copy link
Member

@ljharb ljharb Dec 11, 2019

Suggested change
<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 ljharb assigned ljharb and unassigned bakkot Dec 11, 2019
@tc39 tc39 locked as resolved and limited conversation to collaborators Dec 11, 2019
@ljharb ljharb merged commit f5436bf into tc39:master Dec 11, 2019
1 of 3 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.