<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 12 janv. 2018 à 22:09, Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" class="">isiahmeadows@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">I know this is probably bad timing (considering [this PR][1] and the<br class="">fallout that followed), but I was thinking that it'd be nice if we<br class="">could insert a `[no LineTerminator here]` clause in a few places, to<br class="">remove some of the ASI hazards for those going semicolon-free, along<br class="">with some extras for consistency:<br class=""><br class="">- Before the `[` in the second rule of [`MemberExpression`][2] and the<br class="">fourth rule of [`CallExpression`][3]<br class="">- Before `Arguments` in the last rule of [`MemberExpression`][2], the<br class="">third and sixth rule of [`CallExpression`][3], and<br class="">[`CoverCallExpressionAndAsyncArrowHead`][4]<br class="">- Before the `(` in [`FunctionDeclaration`][5],<br class="">[`FunctionExpression`][6], the first, fourth, and fifth rule of<br class="">[`MethodDefinition`][7], [`GeneratorMethod`][8], both rules in<br class="">[`GeneratorDeclaration`][9], and [`GeneratorFunction`][10]<br class=""><br class="">One of the practical effects would be this: this source (taken from the spec):<br class=""><br class="">```js<br class="">a = b + c<br class="">(d + e).print()<br class="">```<br class=""><br class="">is currently interpreted as:<br class=""><br class="">```js<br class="">a = b + c(d + e).print();<br class="">```<br class=""><br class="">but would, with this proposal, be interpreted as this, which is a<br class="">*lot* more intuitive with what people would expect:<br class=""><br class="">```js<br class="">a = b + c;<br class="">(d + e).print();<br class="">```<br class=""><br class="">I know there's risk of web compat concerns, but I doubt they'd be<br class="">significant for anything that's not minified via the Closure Compiler<br class="">(which limits line length by default for reasons of old IE). Also, for<br class="">most non-ASI people, they probably just forgot a semicolon anyways,<br class="">and [here][11] is a concrete example of this, where ESLint was fixing<br class="">a linter violation incorrectly because it wasn't reading it as you'd<br class="">expect.<br class=""></div></div></blockquote><div><br class=""></div>I think that the BC incompatibility issue is more than just a risk. I recall (but I couldn’t find it) that someone gave the example of some library that reads better when used as:</div><div><br class=""></div><div>```js</div><div>foo</div><div>  (bar)</div><div>  (baz)</div><div>```</div><div><br class=""></div><div>Also, cases you have forgotten, and where I *really* wish there be a [NLTH] rule, are *after* some contextual keywords that are used in prefix position, namely `get`, `set` and `static` (as it is already the case for `async`). See <a href="https://tc39.github.io/proposal-class-fields/#sec-asi-hazards-in-class-bodies" class="">https://tc39.github.io/proposal-class-fields/#sec-asi-hazards-in-class-bodies</a> for context. This is not only to satisfy my coding style, but also to ensure consistency when further contextual keywords will be added in the top level of class bodies, since those future keyword will require such a [NLTH] rule in order to be compatible with previously written field declarations that take advantage ASI.</div><div><br class=""></div><div>—Claude</div><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">[1]: <a href="https://github.com/tc39/ecma262/pull/1062" class="">https://github.com/tc39/ecma262/pull/1062</a><br class="">[2]: <a href="https://tc39.github.io/ecma262/#prod-MemberExpression" class="">https://tc39.github.io/ecma262/#prod-MemberExpression</a><br class="">[3]: <a href="https://tc39.github.io/ecma262/#prod-CallExpression" class="">https://tc39.github.io/ecma262/#prod-CallExpression</a><br class="">[4]: <a href="https://tc39.github.io/ecma262/#prod-CoverCallExpressionAndAsyncArrowHead" class="">https://tc39.github.io/ecma262/#prod-CoverCallExpressionAndAsyncArrowHead</a><br class="">[5]: <a href="https://tc39.github.io/ecma262/#prod-FunctionDeclaration" class="">https://tc39.github.io/ecma262/#prod-FunctionDeclaration</a><br class="">[6]: <a href="https://tc39.github.io/ecma262/#prod-FunctionExpression" class="">https://tc39.github.io/ecma262/#prod-FunctionExpression</a><br class="">[7]: <a href="https://tc39.github.io/ecma262/#prod-MethodDefinition" class="">https://tc39.github.io/ecma262/#prod-MethodDefinition</a><br class="">[8]: <a href="https://tc39.github.io/ecma262/#prod-GeneratorMethod" class="">https://tc39.github.io/ecma262/#prod-GeneratorMethod</a><br class="">[9]: <a href="https://tc39.github.io/ecma262/#prod-GeneratorDeclaration" class="">https://tc39.github.io/ecma262/#prod-GeneratorDeclaration</a><br class="">[10]: <a href="https://tc39.github.io/ecma262/#prod-GeneratorExpression" class="">https://tc39.github.io/ecma262/#prod-GeneratorExpression</a><br class="">[11]: <a href="https://github.com/eslint/eslint/issues/7787" class="">https://github.com/eslint/eslint/issues/7787</a><br class=""><br class="">-----<br class=""><br class="">Isiah Meadows<br class=""><a href="mailto:me@isiahmeadows.com" class="">me@isiahmeadows.com</a><br class=""><br class="">Looking for web consulting? Or a new website?<br class="">Send me an email and we can get started.<br class="">www.isiahmeadows.com<br class="">_______________________________________________<br class="">es-discuss mailing list<br class="">es-discuss@mozilla.org<br class="">https://mail.mozilla.org/listinfo/es-discuss<br class=""></div></div></blockquote></div><br class=""></body></html>