ASI edits

Isiah Meadows isiahmeadows at gmail.com
Sun Jan 14 02:31:04 UTC 2018


Inline
-----

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Sat, Jan 13, 2018 at 9:54 AM, Claude Pache <claude.pache at gmail.com> wrote:
>
>
> Le 12 janv. 2018 à 22:09, Isiah Meadows <isiahmeadows at gmail.com> 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.

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

>
> —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
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list