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 Automatic Semicolon Insertion hazard clause #1062

Open
wants to merge 10 commits into
base: master
from

Conversation

@bmeck
Member

bmeck commented Jan 11, 2018

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

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Jan 11, 2018

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

mathiasbynens commented Jan 11, 2018

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

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Jan 11, 2018

Member

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

Member

littledan commented Jan 11, 2018

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

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Jan 11, 2018

Member

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

Member

bmeck commented Jan 11, 2018

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

@ljharb

ljharb approved these changes Jan 11, 2018

;

Show outdated Hide outdated spec.html Outdated
@jayphelps

This comment has been minimized.

Show comment
Hide comment
@jayphelps

jayphelps Jan 11, 2018

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

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

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

This comment has been minimized.

Show comment
Hide comment
@yoshuawuyts

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

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

This comment has been minimized.

Show comment
Hide comment
@bakkot

bakkot Jan 11, 2018

Contributor

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

Contributor

bakkot commented Jan 11, 2018

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

@bcomnes

This comment has been minimized.

Show comment
Hide comment
@bcomnes

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

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Jan 11, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@mikesamuel

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

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

This comment has been minimized.

Show comment
Hide comment
@bcomnes

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

This comment has been minimized.

Show comment
Hide comment
@bcomnes

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

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

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Jan 11, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Jan 11, 2018

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Jan 11, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 11, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@bcomnes

bcomnes Jan 11, 2018

@bmeck I offered 2 rewordings.

bcomnes commented Jan 11, 2018

@bmeck I offered 2 rewordings.

@yoshuawuyts

This comment has been minimized.

Show comment
Hide comment
@yoshuawuyts

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

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

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Jan 11, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@markbrown4

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

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

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Jan 11, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@allenwb

allenwb Jan 11, 2018

Member

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.

Member

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.

Show outdated Hide outdated spec.html Outdated
Show outdated Hide outdated spec.html Outdated
Show outdated Hide outdated spec.html Outdated
@valorkin

This comment has been minimized.

Show comment
Hide comment
@valorkin

valorkin Jan 11, 2018

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

valorkin commented Jan 11, 2018

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

@mikesamuel

This comment has been minimized.

Show comment
Hide comment
@mikesamuel

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

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.

@bakkot

This comment has been minimized.

Show comment
Hide comment
@bakkot

bakkot Jan 11, 2018

Contributor

One thing I want to mention - the main reason I think it's important to have something like this is because a lot of the messaging around the semi-free style says stuff to the effect of "you just have to follow this simple rule: don't start a line with ( or [", but the rule you actually have to follow is both currently more complex than is suggested and likely to get a lot more complex as the language evolves.

Because of this messaging, I am personally worried about people deciding to use semi-free style on this assumption that it is and will remain simple to do correctly and without requiring many semicolons. I think it's important for TC39 to communicate this assumption is false, and that if you'd like to avoid the risk of your semicolon usage getting less consistent and requiring new rules to maintain as you adopt new features of the language, with-semi is the way to go. I'd like to find a wording which suggests that without making anyone feel bad for their stylistic choices as long as they're made with full knowledge of the risk they're taking on, but that's tricky.

In other words, I'm worried that there's a widely held false assumption which is affecting people's decisions about code style. I don't feel the need to dictate a style, just correct that assumption.


Buuuut I'm not sure I have a better wording to offer. Maybe "As such, the simplest way to maintain a consistent style is consistent use of semicolons"?

Contributor

bakkot commented Jan 11, 2018

One thing I want to mention - the main reason I think it's important to have something like this is because a lot of the messaging around the semi-free style says stuff to the effect of "you just have to follow this simple rule: don't start a line with ( or [", but the rule you actually have to follow is both currently more complex than is suggested and likely to get a lot more complex as the language evolves.

Because of this messaging, I am personally worried about people deciding to use semi-free style on this assumption that it is and will remain simple to do correctly and without requiring many semicolons. I think it's important for TC39 to communicate this assumption is false, and that if you'd like to avoid the risk of your semicolon usage getting less consistent and requiring new rules to maintain as you adopt new features of the language, with-semi is the way to go. I'd like to find a wording which suggests that without making anyone feel bad for their stylistic choices as long as they're made with full knowledge of the risk they're taking on, but that's tricky.

In other words, I'm worried that there's a widely held false assumption which is affecting people's decisions about code style. I don't feel the need to dictate a style, just correct that assumption.


Buuuut I'm not sure I have a better wording to offer. Maybe "As such, the simplest way to maintain a consistent style is consistent use of semicolons"?

@designstorming

This comment has been minimized.

Show comment
Hide comment
@designstorming

designstorming Feb 1, 2018

Don't want semicolons? Use coffee script. Simple.

designstorming commented Feb 1, 2018

Don't want semicolons? Use coffee script. Simple.
@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Feb 1, 2018

Member

@designstorming per #1062 (comment), i'm going to edit your comment to put it behind a <details>.

Member

ljharb commented Feb 1, 2018

@designstorming per #1062 (comment), i'm going to edit your comment to put it behind a <details>.

@littledan

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Feb 9, 2018

Member

At the January 2018 TC39 meeting, the committee decided to modify this PR in the following way:

  • don't yet land the "recommendation", start by landing the description of ASI hazards (possibly with a word less judgmental-sounding than "hazard") and NoLineTerminator here hazards
  • continue to discuss the recommendation later

@bmeck Would you be up for making such a modification? Personally, I'm fine with your suggestion to not use the term "hazard" when talking about semicolon insertion cases.

Member

littledan commented Feb 9, 2018

At the January 2018 TC39 meeting, the committee decided to modify this PR in the following way:

  • don't yet land the "recommendation", start by landing the description of ASI hazards (possibly with a word less judgmental-sounding than "hazard") and NoLineTerminator here hazards
  • continue to discuss the recommendation later

@bmeck Would you be up for making such a modification? Personally, I'm fine with your suggestion to not use the term "hazard" when talking about semicolon insertion cases.

@NullVoxPopuli

This comment has been minimized.

Show comment
Hide comment
@NullVoxPopuli

NullVoxPopuli Feb 9, 2018

NullVoxPopuli commented Feb 9, 2018

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Feb 9, 2018

Member

@littledan I tried to rephrase.
@NullVoxPopuli I used "interesting", I cannot think of a good word that is neutral in all contexts.

Member

bmeck commented Feb 9, 2018

@littledan I tried to rephrase.
@NullVoxPopuli I used "interesting", I cannot think of a good word that is neutral in all contexts.

@NullVoxPopuli

This comment has been minimized.

Show comment
Hide comment
@NullVoxPopuli

NullVoxPopuli Feb 9, 2018

idk, Interesting is subjective.
Personally, I don't find hazards interesting, but I'd prefer to avoid them. :-)

imo, we should care more about clarity, and not about offending thin-skinned people.

NullVoxPopuli commented Feb 9, 2018

idk, Interesting is subjective.
Personally, I don't find hazards interesting, but I'd prefer to avoid them. :-)

imo, we should care more about clarity, and not about offending thin-skinned people.

@j-f1

This comment has been minimized.

Show comment
Hide comment
@j-f1

j-f1 Feb 9, 2018

“Potentially confusing?”

j-f1 commented Feb 9, 2018

“Potentially confusing?”

@kswedberg

This comment has been minimized.

Show comment
Hide comment
@kswedberg

kswedberg Feb 9, 2018

@bmeck "Possibly unintuitive"?

kswedberg commented Feb 9, 2018

@bmeck "Possibly unintuitive"?

@j-f1

This comment has been minimized.

Show comment
Hide comment
@j-f1

j-f1 Feb 9, 2018

“Unintuitive?”

j-f1 commented Feb 9, 2018

“Unintuitive?”

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Feb 9, 2018

Member

@kswedberg @j-f1 the [no LineTerminator here] cases are very well defined and can even be isolated on a statement level. The cases of violation of locality are very well defined but cannot be isolated to a single statment/production. If you learn how ASI works both are intuitive and "confusing" seems to be wrong if it is easily learned.

Member

bmeck commented Feb 9, 2018

@kswedberg @j-f1 the [no LineTerminator here] cases are very well defined and can even be isolated on a statement level. The cases of violation of locality are very well defined but cannot be isolated to a single statment/production. If you learn how ASI works both are intuitive and "confusing" seems to be wrong if it is easily learned.

@kswedberg

This comment has been minimized.

Show comment
Hide comment
@kswedberg

kswedberg commented Feb 9, 2018

@bmeck Fair enough

Show outdated Hide outdated spec.html Outdated
@claudepache

This comment has been minimized.

Show comment
Hide comment
@claudepache

claudepache Feb 9, 2018

Contributor

”ASI failures” (for the situations where ASI fails to insert a semicolon)?

Contributor

claudepache commented Feb 9, 2018

”ASI failures” (for the situations where ASI fails to insert a semicolon)?

@leobalter

This comment has been minimized.

Show comment
Hide comment
@leobalter

leobalter Feb 9, 2018

Member

@claudepache If it works as intended described, it's not a failure.

Member

leobalter commented Feb 9, 2018

@claudepache If it works as intended described, it's not a failure.

@claudepache

This comment has been minimized.

Show comment
Hide comment
@claudepache

claudepache Feb 9, 2018

Contributor

@leobalter Per https://en.wiktionary.org/wiki/failure, it is a failure:

failure. 1. State or condition of not meeting a desirable or intended objective (...)

because ”desirable or intended” is indeed distinct from ”described”.

But sure, it is not a failure of the parser itself, but a problem of communication between the human and the machine.

Contributor

claudepache commented Feb 9, 2018

@leobalter Per https://en.wiktionary.org/wiki/failure, it is a failure:

failure. 1. State or condition of not meeting a desirable or intended objective (...)

because ”desirable or intended” is indeed distinct from ”described”.

But sure, it is not a failure of the parser itself, but a problem of communication between the human and the machine.

@pygy

This comment has been minimized.

Show comment
Hide comment
@pygy

pygy Feb 9, 2018

Pitfalls of unintended ASI (for NoLineTerminator here cases)?
Pitfalls when relying on ASI (for what was "ASI hazards")?

Just brainstorming...

pygy commented Feb 9, 2018

Pitfalls of unintended ASI (for NoLineTerminator here cases)?
Pitfalls when relying on ASI (for what was "ASI hazards")?

Just brainstorming...

@leobalter

This comment has been minimized.

Show comment
Hide comment
@leobalter

leobalter Feb 9, 2018

Member

@claudepache the definition is right, but it doesn't make it a failure of the ASI itself, but of the user (developer) expecting something else. It's documented, it's tricky, complex, and not simple, and that's probably the reason it creates confusing behaviors for the users, and that's why it was called a hazard.

@bmeck I don't want to add much to the pile, but if you still need another name, "risk" should work. Whoever is relying on ASI as a feature, is assuming the risks due to its tricky behaviors.

Member

leobalter commented Feb 9, 2018

@claudepache the definition is right, but it doesn't make it a failure of the ASI itself, but of the user (developer) expecting something else. It's documented, it's tricky, complex, and not simple, and that's probably the reason it creates confusing behaviors for the users, and that's why it was called a hazard.

@bmeck I don't want to add much to the pile, but if you still need another name, "risk" should work. Whoever is relying on ASI as a feature, is assuming the risks due to its tricky behaviors.

@bcomnes

This comment has been minimized.

Show comment
Hide comment
@bcomnes

bcomnes Feb 9, 2018

don't yet land the "recommendation", start by landing the description of ASI hazards (possibly with a word less judgmental-sounding than "hazard") and NoLineTerminator here hazards
continue to discuss the recommendation later.

The word "hazard" isn't the issue, in fact its the perfect word to describe the situation.

The problem came down to a difference between differing intentions behind the TC-39 members who wanted this clause to be added.

Camp 1) On the surface the current wording essentially came down to "Here are places where ASI behaves strangely or in complex ways. Avoid these subtle problems by using semicolons in a consistent manner to guard against them." (A totally fair and fine recommendation and helpful list of ASI hazards TC-39 is aware of).

Camp 2) It became clear that some were reading the above recommendation as "Never rely on ASI, hazardous situation or not. Eliminate the reliance on ASI behavior by inserting semicolons wherever ASI would" .

My concern is that Camp 2 would (and did as soon a the PR went live) try to use the more general wording of camp 1 as a sign on the wall to point at to justify a much narrower recommendation. The solution in my opinion is: Adopt the more general wording of camp 1 with the explicit intention of not taking on the stricter interpretation of camp 2, or reword the recommendation to be more in line with the narrower camp 2 recommendation and explicitly adopt the intended interpretation.

bcomnes commented Feb 9, 2018

don't yet land the "recommendation", start by landing the description of ASI hazards (possibly with a word less judgmental-sounding than "hazard") and NoLineTerminator here hazards
continue to discuss the recommendation later.

The word "hazard" isn't the issue, in fact its the perfect word to describe the situation.

The problem came down to a difference between differing intentions behind the TC-39 members who wanted this clause to be added.

Camp 1) On the surface the current wording essentially came down to "Here are places where ASI behaves strangely or in complex ways. Avoid these subtle problems by using semicolons in a consistent manner to guard against them." (A totally fair and fine recommendation and helpful list of ASI hazards TC-39 is aware of).

Camp 2) It became clear that some were reading the above recommendation as "Never rely on ASI, hazardous situation or not. Eliminate the reliance on ASI behavior by inserting semicolons wherever ASI would" .

My concern is that Camp 2 would (and did as soon a the PR went live) try to use the more general wording of camp 1 as a sign on the wall to point at to justify a much narrower recommendation. The solution in my opinion is: Adopt the more general wording of camp 1 with the explicit intention of not taking on the stricter interpretation of camp 2, or reword the recommendation to be more in line with the narrower camp 2 recommendation and explicitly adopt the intended interpretation.

@zbraniecki

This comment has been minimized.

Show comment
Hide comment
@zbraniecki

zbraniecki Feb 9, 2018

@bcomnes I feel like you're missing a camp (which I belong to) which believes that:

Camp 3) We see the direction of JavaScript development likely make the "let's not use semi-colons in our code!" model become increasingly inconsistent (exemplified by /*eslint semi: ["error", "never"]*/). People who tomorrow will be making decision about their project style should understand that their choice, a couple years from now, may likely lead them to work in an environment which will feel much more inconsistent than how it feels now. We want to increase their ability to take that factor into account when making their decision (rather than assuming that its a purely aesthetic decision).
In order to help them understand the potential long term consequences of their choices, we want to state that:

a) There is a list of ASI hazards that they should understand
b) In the future we expect to introduce more ASI hazards because as a committee we decided that we will not reject a good syntactic choice just because it introduces an ASI hazard (we'll try to maintain both where possible, but we recognize that we value syntactic choices over ASI).

I think it's important to not ignore the third camp, because I believe it to be a less extreme version of the Camp 2 (we're not telling you not to, but based on how we see the language will likely develop we want you to understand what may happen), while it is more focused on the future than Camp 1, thus justifying the words like "risk" and "hazard".

zbraniecki commented Feb 9, 2018

@bcomnes I feel like you're missing a camp (which I belong to) which believes that:

Camp 3) We see the direction of JavaScript development likely make the "let's not use semi-colons in our code!" model become increasingly inconsistent (exemplified by /*eslint semi: ["error", "never"]*/). People who tomorrow will be making decision about their project style should understand that their choice, a couple years from now, may likely lead them to work in an environment which will feel much more inconsistent than how it feels now. We want to increase their ability to take that factor into account when making their decision (rather than assuming that its a purely aesthetic decision).
In order to help them understand the potential long term consequences of their choices, we want to state that:

a) There is a list of ASI hazards that they should understand
b) In the future we expect to introduce more ASI hazards because as a committee we decided that we will not reject a good syntactic choice just because it introduces an ASI hazard (we'll try to maintain both where possible, but we recognize that we value syntactic choices over ASI).

I think it's important to not ignore the third camp, because I believe it to be a less extreme version of the Camp 2 (we're not telling you not to, but based on how we see the language will likely develop we want you to understand what may happen), while it is more focused on the future than Camp 1, thus justifying the words like "risk" and "hazard".

@bcomnes

This comment has been minimized.

Show comment
Hide comment
@bcomnes

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

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 (e.g. take the original "camp1" wording + recommend one uses a parsing linter like eslint. Basically what @BrendanEich recomended), which is how both full and low semicolon styles handle the problems now anyway. I think it would be a mistake to side on either side of the bikeshed. People are smart, leave the style recommendation and editorializing up to individual members and the community.

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

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 (e.g. take the original "camp1" wording + recommend one uses a parsing linter like eslint. Basically what @BrendanEich recomended), which is how both full and low semicolon styles handle the problems now anyway. I think it would be a mistake to side on either side of the bikeshed. People are smart, leave the style recommendation and editorializing up to individual members and the community.

@mariuslundgard

This comment has been minimized.

Show comment
Hide comment
@mariuslundgard

mariuslundgard Feb 9, 2018

Guess I’m in camp 3, then.

I pointed this out when the PR first surfaced on Twitter a month or so ago:

The ASI “hazards” are there whether using low or high semicolon style. Therefore I believe TC39 should not recommend either style, but instead recommend the use of a linter (or similar).

Pointing out how ASI works is helpful to the community. So is expressing that it’s better for future code consistency to use high semicolon style (if it is indeed the intention to introduce more mandatory semicolons in future language features).

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.

mariuslundgard commented Feb 9, 2018

Guess I’m in camp 3, then.

I pointed this out when the PR first surfaced on Twitter a month or so ago:

The ASI “hazards” are there whether using low or high semicolon style. Therefore I believe TC39 should not recommend either style, but instead recommend the use of a linter (or similar).

Pointing out how ASI works is helpful to the community. So is expressing that it’s better for future code consistency to use high semicolon style (if it is indeed the intention to introduce more mandatory semicolons in future language features).

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.

@zbraniecki

This comment has been minimized.

Show comment
Hide comment
@zbraniecki

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

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.

<em>This section is non-normative.</em>
<p>ECMAScript programs can be written in a style with very few semicolons by relying on automatic semicolon insertion. As described above, semicolons are not inserted at every newline, and automatic semicolon insertion can depend on multiple tokens across line terminators.</p>
<p>As new syntactic features are added to ECMAScript, additional grammar productions could be added that cause lines relying on automatic semicolon insertion preceding them to change grammar productions when parsed. In order to prevent cases where automatic semicolon insertion could change by adding source text outside of a grammar productions existing text boundaries.</p>

This comment has been minimized.

@nathan

nathan Feb 9, 2018

Contributor

This now just says "In order to prevent thing," which isn't a complete sentence.

Edit: Also, productions => production's. (This has been pointed out before.)

@nathan

nathan Feb 9, 2018

Contributor

This now just says "In order to prevent thing," which isn't a complete sentence.

Edit: Also, productions => production's. (This has been pointed out before.)

@bcomnes

This comment has been minimized.

Show comment
Hide comment
@bcomnes

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

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

This comment has been minimized.

Show comment
Hide comment
@zbraniecki

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

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

@hax hax referenced this pull request Jul 6, 2018

Open

How to critique this proposal #32

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment