Chakracore: Implement Async Generators

Created on 20 Mar 2017  ·  21Comments  ·  Source: chakra-core/ChakraCore

Proposal is here: https://github.com/tc39/proposal-async-iteration
Basic idea is a combination of an async function and a generator - essentially a generator you can await within.

There are already a number of test262 tests and v8 has an implementation we can compare against.

ECMAScript Spec Feature Request Task

Most helpful comment

This has been accepted into ES2018. With support in SpiderMonkey, V8 and jsc, it would be great to get this in ChakraCore soon.

All 21 comments

SpiderMonkey also has it implemented - https://bugzilla.mozilla.org/show_bug.cgi?id=1331092

Any update on this?

@benjamingr I have no update to share yet, but I'll be sure to update this issue (and the roadmap) when I do!

This has been accepted into ES2018. With support in SpiderMonkey, V8 and jsc, it would be great to get this in ChakraCore soon.

I don't know ChakraCore teams standard practice, but it would be SUPER HELPFUL to have a Platform Status thing to track.

@rektide Are you perhaps looking for Edge's Platform Status?

Unfortunately, it looks like the async iterators/generators/loops aren't quite there yet, but overall it's a very good resource.

Is there any update on this feature/plan for when it will be implemented?

@rhuanjl See the link posted by @BobChao87

It is currently marked as UNDER CONSIDERATION and:

Roadmap Priority: High — We intend to begin development soon.

So to answer your question, no idea when really, but soon. 🤷‍♂️

@ciscoo the platform status isn't exactly up to date also it's Edge not Chakracore - features make it to CC some time before they make it to edge.

For 2 e.g.s of not up to date:

  1. Promise.prototype.finally per Edge platform status is in development BUT - it's fully functional in chakracore 1.10 (see PR 3520).
  2. Object rest/spread - per Edge platform status is under consideration BUT - it's actually experimentally implemented in CC - supported but behind a flag so should at least say in development.

Why does no one still implement or schedule this feature?

Would an external contribution be welcome here?

(Not certain I could manage this but could give it a try if an external PR would be welcome)

Yes, it would, but this feature is thought to require a good amount of effort.

Aware that this will be sizeable but i’ll make a start and see how it goes.

I’ll aim to have a PR ready to submit by mid-December but I can’t promise anything.

Please let me know by updating here if someone internally is scheduled to work on it (and hence I should stop).

I think I'm nearly there with async generator functions - will aim to open a PR this weekend.

I have not touched for-await-of or Symbol.asyncIterator yet, I will endeavour to do those in a later PR. I want to submit what I've done on async generator functions before doing the other aspects of this feature as it's going to be over 1000 lines as it is.

Cool. How did you solve the problem you described earlier regarding the need to distinguish between yield and await?

So when the asyncGenerator yields there are three possible cases:

  1. await
  2. yield
  3. yield*

Points 1 and 2 would both return to the same place with an object that had { value : something, done : false }

Point 3 would come in at the same place with an arbitrary object provided by the next call for the iterator in question.

For point 3 - add a boolean value to the ResumeYieldData struct to specifically detect this (still working on this point)

For point 1 vs point 2 omit the done value from the yielded object if it's an await (condition check in the byte code emitter for async generator await around the emission of byte code for the done value) - so after ruling out yield* can use JavascriptOperators::HasProperty to test if it was yield or await.

@EdMaurer you were right it was a lot of effort; but I had several free weekends and needed something to do :) Hopefully someone has time to review it.

Thanks so much @rhuanjl! We'll make sure it gets a look. I can't wait to get this in!

Well this now is implemented behind a feature flag.

I assume it needs TTD and profiler support before it's enabled, is there anything else it needs?

Also please point me in the right direction if a PR would be welcome for the remaining points. (not sure where to start with the profiler or TTD)

Asked before but asking again. Is there anything I can do to help get this enabled?

This was enabled by #6456

Was this page helpful?
0 / 5 - 0 ratings

Related issues

obastemur picture obastemur  ·  4Comments

crdumoul picture crdumoul  ·  4Comments

dilijev picture dilijev  ·  6Comments

kunalspathak picture kunalspathak  ·  4Comments

ross-weir picture ross-weir  ·  4Comments