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

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?

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.

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

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

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.

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.

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

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.

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

@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

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?

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

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.

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

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.

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

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

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.

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.

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.

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.