> Le 14 janv. 2018 à 03:31, Isiah Meadows <[email protected]> a écrit : > > Inline > ----- > > Isiah Meadows > [email protected] <mailto:[email protected]> > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com <http://www.isiahmeadows.com/> > > > On Sat, Jan 13, 2018 at 9:54 AM, Claude Pache <[email protected] > <mailto:[email protected]>> wrote: >> >> >> Le 12 janv. 2018 à 22:09, Isiah Meadows <[email protected]> a écrit : >> >> I know this is probably bad timing (considering [this PR][1] and the >> fallout that followed), but I was thinking that it'd be nice if we >> could insert a `[no LineTerminator here]` clause in a few places, to >> remove some of the ASI hazards for those going semicolon-free, along >> with some extras for consistency: >> >> - Before the `[` in the second rule of [`MemberExpression`][2] and the >> fourth rule of [`CallExpression`][3] >> - Before `Arguments` in the last rule of [`MemberExpression`][2], the >> third and sixth rule of [`CallExpression`][3], and >> [`CoverCallExpressionAndAsyncArrowHead`][4] >> - Before the `(` in [`FunctionDeclaration`][5], >> [`FunctionExpression`][6], the first, fourth, and fifth rule of >> [`MethodDefinition`][7], [`GeneratorMethod`][8], both rules in >> [`GeneratorDeclaration`][9], and [`GeneratorFunction`][10] >> >> One of the practical effects would be this: this source (taken from the >> spec): >> >> ```js >> a = b + c >> (d + e).print() >> ``` >> >> is currently interpreted as: >> >> ```js >> a = b + c(d + e).print(); >> ``` >> >> but would, with this proposal, be interpreted as this, which is a >> *lot* more intuitive with what people would expect: >> >> ```js >> a = b + c; >> (d + e).print(); >> ``` >> >> I know there's risk of web compat concerns, but I doubt they'd be >> significant for anything that's not minified via the Closure Compiler >> (which limits line length by default for reasons of old IE). Also, for >> most non-ASI people, they probably just forgot a semicolon anyways, >> and [here][11] is a concrete example of this, where ESLint was fixing >> a linter violation incorrectly because it wasn't reading it as you'd >> expect. >> >> >> 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: >> >> ```js >> foo >> (bar) >> (baz) >> ``` > > Do you have any ideas where I could look to potentially find it? I've > never seen *that* kind of DSL before, and that's an interesting use > case I haven't considered.
I’ve finally found, see: https://esdiscuss.org/topic/consider-adding-more-no-lineterminator-here-to-avoid-problem-caused-by-omit-the-semicolon#content-3 <https://esdiscuss.org/topic/consider-adding-more-no-lineterminator-here-to-avoid-problem-caused-by-omit-the-semicolon#content-3> Maybe not a significant example, but don’t underestimate the creativity of hackers. > >> >> 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 >> https://tc39.github.io/proposal-class-fields/#sec-asi-hazards-in-class-bodies >> >> <https://tc39.github.io/proposal-class-fields/#sec-asi-hazards-in-class-bodies> >> 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. > > I thought about those, and I would ideally like those to be similarly > chnaged, but I decided against including them in this particular > proposal, since I wanted to focus on `[` and `(`, and I wasn't as keen > on web compat (considering it's actually a style many people prefer). As someone who uses semicolon-less style, `[`, `(` and other punctuation marks are not issues, but `get`, `set` and `static` in class fields are. My analysis: https://github.com/tc39/proposal-class-fields/issues/7#issuecomment-331670382 <https://github.com/tc39/proposal-class-fields/issues/7#issuecomment-331670382> But regardless of your coding style, the historical behaviour of `get`, `set` and `static` in classes introduces some irregularity, which is always bad, while `(` and `[` do not: ```js class C { post // implicit semicolon here foo () { } } class D { get // no implicit semicolon here foo () { } } ``` There are also issues around `in` and `instanceof`, but those are more likely to produce a syntax error in case of non-working ASI, and I think they are more problematic to correct. —Claude > >> >> —Claude >> >> >> >> >> [1]: https://github.com/tc39/ecma262/pull/1062 >> [2]: https://tc39.github.io/ecma262/#prod-MemberExpression >> [3]: https://tc39.github.io/ecma262/#prod-CallExpression >> [4]: >> https://tc39.github.io/ecma262/#prod-CoverCallExpressionAndAsyncArrowHead >> [5]: https://tc39.github.io/ecma262/#prod-FunctionDeclaration >> [6]: https://tc39.github.io/ecma262/#prod-FunctionExpression >> [7]: https://tc39.github.io/ecma262/#prod-MethodDefinition >> [8]: https://tc39.github.io/ecma262/#prod-GeneratorMethod >> [9]: https://tc39.github.io/ecma262/#prod-GeneratorDeclaration >> [10]: https://tc39.github.io/ecma262/#prod-GeneratorExpression >> [11]: https://github.com/eslint/eslint/issues/7787 >> >> ----- >> >> Isiah Meadows >> [email protected] >> >> Looking for web consulting? Or a new website? >> Send me an email and we can get started. >> www.isiahmeadows.com >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
