Closure-compiler: Prepping for ES8 Changes

[ChadKillingsworth]

Async functions are a finished proposal and will be in the ES2017 spec. There are a couple of other interesting items I'd like to work on (though they probably won't make it to ES2017).

My team is allowed to use any feature at Stage 3 of the proposal process or higher: https://github.com/tc39/proposals

Is there a plan for handling this?

I was considering adding an ECMASCRIPT8 and ECMASCRIPT8_STRICT language level. But for features which weren't yet in any formalized spec, I was considering adding ECMASCRIPT_NEXT which is consistent with Babel.

[MatrixFrog]

At some point we'll probably need to switch from ES6 to ES2015 in the code and flags and such :(

@brad4d is making progress on async/await already; I don't think we've looked much at other features just yet.

[ChadKillingsworth]

ES2015 is still the 6th edition of the spec - it's right at the top: http://www.ecma-international.org/ecma-262/6.0/

In addition to async/await, my team is pushing to get transpilation for the object rest/spread parameters.

[brad4d]

I am, in fact, very close to having the async functions transpilation working.
They're working in not-yet-submitted code now.

What are these object rest/spread parameters you mention?
I thought we were already transpiling all of the rest/spread stuff.
Could you give me an example?

[ChadKillingsworth]

Here's the spec (as it exists today - it's still stage 2 but with an indication it's ready to move to stage 3): https://github.com/sebmarkbage/ecmascript-rest-spread

The link to the proposals I posted above is worth keeping handy. It gives a good guidance on what's being suggested an how those proposals are progressing. We use stage 3 as an indicator because there hasn't yet been a proposal withdrawn once it gets to stage 3.

[ChadKillingsworth]

ECMASCRIPT_NEXT was added.