semicolon required?

[bounceme]

https://gist.github.com/jeffmo/054df782c05639da2adb#gistcomment-2112307

just reposting the comment above, if this repo is preferred for discussion

[littledan]

No, semicolons are not required; they follow normal ASI rules and may come automatically. The grammar contains semicolons, just as it does at the end of normal statements which are also subject to ASI.

[bounceme]

So there isn't any ambiguity with in/instanceof being used as property/method names?

[bakkot]

I don't think so. What ambiguity would there be? My implementations of parsers for this feature didn't run into any.

Unless you mean

class A {
  foo = prop
  in
  obj
}

? That's not actually ambiguous in the grammar; it's the same as

class A {
  foo = prop in obj;
}

There are a few of these weird edge cases when you omit semicolons; the more significant ones are to do with computed properties and generators. But, well, weird edge cases when you omit semicolons are nothing new to JS.

[bounceme]

class AB  {
a=1
in(i){}
}

babel breaks with that ^^

[bakkot]

That's because it's not valid syntax. ASI can only be performed if the next token cannot occur as part of any valid production; in that case it can.

Babel will also refuse

class A {
  foo = bar
  *baz(){}
}

for the same reason.

This is an inevitable downside of relying on ASI.

[bounceme]

well *|in|instanceof are operators, so they are just traps waiting to be fallen into

[bakkot]

I don't see this as any more of a hazard than

a = b
({c} = d)

parsing as a call expression. Again, this is an inevitable downside of relying on ASI. Tooling can help.

[bounceme]

I would say allowing the use of reserved words in situations that are basically indistinguishable from Identifier, and allowing asi in the same construct should be a major concern

[ljharb]

The concern is relying on asi- if you don't do it, you don't have to worry about things like this.

If you do, use a linter that can check it for you.

[littledan]

Thanks for explaining how ASI applies here, @bakkot. This issue seems resolved to me--you can use these names as public fields.

[littledan]

Closing as semicolons are not required.