Work on ECMAScript 2017?

[nzakas]

I'm curious if you have thoughts about beginning to implement ES 2017 features as they are approved. This week it looks like several proposals will move to stage 4 ( one already has: tc39/proposals@6826a19, and it looks like async/await will tio), and as soon as that happens, ESLint tends to start receiving requests for support.

If you're open to it, I'm happy to work on proposals as they reach stage 4 and submit them as PRs.

[ljharb]

async/await is now stage 4 as well.
@marijnh @RReverser, thoughts?

[rictic]

I spent a couple hours hacking on parsing async/await this morning. It seems trickier than it initially appeared. AFAICT parsing async functions robustly without some form of backtracking or lookahead will involve a lot of duplication of code, or some significant refactoring (I'm new to the acorn codebase, but as far as I could tell the tokenizer doesn't support backtracking or lookahead).

This arises from the fact that async isn't a keyword, so when you encounter it you can't be sure whether it's being used as an identifier or as the function modifier without knowing whether what follows is a function definition.

e.g.

• async () is a call expression on the async identifier.
• async () => {} is an async arrow function expression.

Fortunately await should be easier. It looks like it's not allowed as an identifier inside an async function.

[RReverser]

I think we can do it under, of course, a new ecmaVersion conditional. There is no need to start from scratch as @matAtWork / @MatAtBread implemented a plugin here https://github.com/MatAtBread/acorn-es7-plugin/ a while back and I know @caitp was going to help to get syntactic details fixed, but I don't know which stage it's at now.

I suggest you might want to work together to figure out if there are any discrepancies with the formal spec syntax, and if not, we can bring it upstream.

[caitp]

The goal with that was only as far as getting it to render and/or prettyprint better in Chrome devtools. I wasn't planning on doing any significant work to improve it in Acorn or other ES parsers.

Anyways, per your question (assuming it was about the status of being ratified and moved into ECMA262), async functions is at Stage 4, so it might be time to start looking at getting support for that upstream.

[rictic]

Huh, if I'm reading this right, it looks like acorn-es7-plugin implements lookahead by cloning the parser: https://github.com/MatAtBread/acorn-es7-plugin/blob/master/acorn-es7-plugin.js#L165

[TimothyGu]

I implemented some state cloning in #317 for supporting let as identifier, but that was replaced with a non-lookahead approach. Check 8f46eb5 and 8e93062 and see if those help.

[MatAtBread]

Yeah, that sounds right. TBH, it wasn't written to be the nicest/fastest implementation, but it has a fair number of users and I think most of the wrinkles are now fixed (see issues on the plugin).

I probably didn't spend enough time attempting to understand acorn in enough detail, so things like lookahead (which I think is needed to disambiguate things like async(x) from async(x)=> ) could probably have been done but by cloning the parsers but by specific members or similar state maintaining variables

[rictic]

For the record, it looks like #446 implements async/await

[marijnh]

#446 was merged. And yes, we're open to implementing other ES2017 pieces when they become stable. Closing this.

[ljharb]

@marijnh what about trailing function commas? That's the other syntactic change that's stage 4.

[marijnh]

Patches welcome, or otherwise we'll probably get to it when the standard as a whole is finalized.

[ljharb]

It's a living standard - it's finalized the instant it's merged.

I'll file a separate issue for trailing function commas.