Implementation status?

[benjamingr]

Given this is stage 3 (yay) - what browsers have expressed intent to start implementing this?

Are there any browsers where we can test the implementation under a flag/build already?

[domenic]

My understanding is that @caitp is implementing in V8, but that's fairly recent. She can give you a more accurate update, but I doubt it's under a flag yet.

Otherwise I haven't heard any stirrings, besides @bterlson saying he's hoping to convince the Chakra people to start soon.

[GabrielRatener]

Any chance this will land in ES2017?

[domenic]

That depends entirely on implementations.

[warent]

I love this feature and hope to see it. Given that the current syntax is
await function then wouldn't it be more consistent to say await for? I hope we can use that rather than for await

[zenparsing]

@warent Thanks for the interest! See #24 for a discussion of the keyword choice.

[benjamingr]

Just following up with this PR to add support to TypeScript.

@caitp any update on the Chrome implementation status? We're all really looking forward to this feature.

[caitp]

Prototype will probably be up for review before xmas, but landing and tuning will take longer

[benjamingr]

@caitp awesome! Thanks, once you have a prototype running I'd love to build and try it out. Really excited about this.

[DanielHerr]

Is there a Chromium/V8 issue?

[caitp]

It's only been worked on downstream so far. Some dependencies have been attached to v8:5343

[benjamingr]

@caitp I have a question about implementation if that's ok.

I was wondering if it is possible for async iterators (not necessarily in the first version) that are consumed with for..await to avoid allocating a promise for each value (since no one actually ever observes it). If so - would you be able to estimate how hard that would be?

It might have significant implications on NodeJS usage, while promises are cheap allocating one for every packet when reading from a network stream might end up being expensive.

[caitp]

Once TurboFan is able to inline promise resolution/rejection, it could probably decide to create a different microtask type when the resume location is known (ie in an AwaitExpression), and elide allocation of the Promise which is no longer escaped.

@schuay might already have plans to do something like this, not sure.

[benjamingr]

Hey, who do I bug in Safari/Edge/Firefox land to promote this?

[caitp]

@benjamingr this has been started in WebKit by someone, https://bugs.webkit.org/show_bug.cgi?id=166695.

[benjamingr]

@gskachkov let me know if there is anything I/we can do to help push this in WebKit - and if you need testing etc.

[gskachkov]

@benjamingr Yes sure, but I just started :-)

[arai-a]

prototyping for Firefox here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1331092

[DanielHerr]

Chrome/V8 Issue: https://crbug.com/v8/5855

[chicoxyzzy]

ChakraCore issue chakra-core/ChakraCore#2720

[vsemozhetbyt]

Shipped just now in V8 6.3: https://bugs.chromium.org/p/v8/issues/detail?id=5855#c36

[gskachkov]

Shipped in Safari Technical Preview 40. I hope it will be released in Safari 11.1

[zbraniecki]

SpiderMonkey enabled it around a month ago and will ship in 57: https://bugzilla.mozilla.org/show_bug.cgi?id=1352312