use consistent semicolon elision rules

[flying-sheep]

my JS style elides semicolons, and method literals in class declarations have no trailing delimiter neither.

therefore requiring semicolons results in a idiosyncracy compared to the rest of the language’s grammar.

i’m aware of #25 which was about a quick fix for ambiguities by requiring them temporarily. this bug is about the backwardds-compatible idiomatic final grammar which will allow eliding semicolons.

Updated status:

this was a misunderstanding. @jeffmo explained it here.

ASI is in effect here, and babel won’t require semicolons anymore soon

[michaelficarra]

@bakkot I believe the examples you've given should be a syntax error. From the ASI rules,

When, as a Script or Module is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true:

Notice my emphasis. A semicolon would not be inserted after get because a production exists where x may follow get.

[bakkot]

@michaelficarra, I agree; that's my point. (Well, except that my second example is a syntactically valid static field declaration.)

But with semicolons inserted manually, they should be fine, I think. That is, I think this is valid syntax:

class A {
  get;
  x;
}

So, if I am understanding correctly, this is another place where you can't get away with skipping semicolons.

[michaelficarra]

Yes, that's right.

[ziemkowski]

sounds a lot like "Don't make beautiful and more readable code because if you use that clean style to write awful code that would confuse most people and any style guide should prohibit, it can end up confusing the runtime too."

[michaelficarra]

class A { x = 0; }

Eww, gross.

class A { x = 0 }

Beautiful! Totally worth all the refactoring hazards. I only need to look ahead for 1 of 10 problematic tokens every time I make a change.

[ziemkowski]

In real code, in large files, yes all these crufty archaic semicolons are just unnecessary noise.

Once you work in semicolon-free js for a couple days, the perspective switches from "why shouldn't we?" to "why should we?" with thoughts like:

"Why are people adding these unnecessary semicolons everywhere when not one place here needs them?"

Because you just don't run into these scenarios in real code and even if you did they're things that become immediately apparent and easily fixable.

[ljharb]

That's a very subjective opinion and controversial debate that we ABSOLUTELY MUST NOT get into in this thread. Just stop.

ASI rules (whether using or omitting) both require memorizing a list of rules, and applying them in your code.

A linter can help you remember, rendering the question of "which one's harder to remember" moot.

Whichever you use, any additions to the language will not make this particular debate any worse by changing those ASI rules - that's simply a nonstarter. If a given approach (using vs omitting) ends up being trickier with a syntax addition when following the existing rules, TOUGH. Adapt, or change your approach.

[michaelficarra]

@ziemkowski I hope you think of me every time you look at

class A {
  x = 0
  [Symbol.iterator]() { /* ... */ }
}

or

class A {
  x = 0
  *generatorMethod() { /* ... */ }
}

and say to yourself, "what's wrong?".

edit: I apologise to those who are following the thread for the noise caused by my responses to @ziemkowski's trolling. I was not in the mood for this kind of ASI snobbery.

[bakkot]

@allenwb, my reading of ASI is that an offending token must be one that is "not allowed by any production of the grammar", but here x is allowed by MethodDefinition even though the remainder of MethodDefinition doesn't match, and so ASI cannot occur.

[allenwb]

@bakkot oops, I think you're right. I forgot about the "any production" restriction. In that case ASI produces:

class {
get 
x; }

which is a non-ASI-correctable syntax error.

I really dislike these keyword free property declarations (same for keyword free privates). It would all work so much better if property declarations started with a contextual keyword such as public. For example:

class {
  public get /* semi-inserted here*/
  public x /*semi-inserted here */
}

or

class {
  public get, y  /* semi-inserted here */
}

That was the sort of thing we were expecting when we made ; a ClassElement. We intended that ClassBody would be treated similarly to the treatment of StatementList