[Webkit-unassigned] [Bug 166695] [ESNext] Async iteration - Implement Async Generator

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=166695

--- Comment #6 from GSkachkov <gskachkov at gmail.com> ---
Comment on attachment 298142
  --> https://bugs.webkit.org/attachment.cgi?id=298142
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=298142&action=review

>>> Source/JavaScriptCore/builtins/AsyncGeneratorPrototype.js:39
>>> +        @throwTypeError("Async generator is executing");
>> 
>> Async Generators differ from ordinary generators, in that it's not an error to resume the generator while it's executing.
>> 
>> While it's an unlikely case, the generator is allowed to queue up additional requests while executing, and the queue of requests is drained during resumption (the proposal words this as recursive calls from AsyncGeneratorResolve / AsyncGeneratorReject -> AsyncGeneratorResumeNext)
> 
> Sure I'll remove this line.
> I've tried to replace queue by chain of promises to allow invoke 'next' many times as well. Also I have not implement&tests methods 'return' & 'throw', not sure that they work correct in this patch.

I read spec one more time and it seems that implementation of 'AsyncGenerator Abstract Operations'  with AsyncGeneratorResolve / AsyncGeneratorReject -> AsyncGeneratorResumeNext will require some additional changes in 'generator' and 'async function', so I decided that it should be not be part of this patch, and be part of the separate task - https://bugs.webkit.org/show_bug.cgi?id=166848

>>>> Source/JavaScriptCore/builtins/AsyncGeneratorPrototype.js:65
>>>> +    if (generator. at asyncGeneratorState === @AsyncGeneratorStateAwait) {
>>> 
>>> the special generator continuation is a nice idea.
>>> 
>>> Though it doesn't affect JSC just yet due to not being implemented, note that this would _probably_ be observable via the function.sent metaproperty (or at least, it is in the v8 generator implementation without some additional work).
>> 
>> Oh Sorry, not sure that I got it. 
>> Do you mean that in case of using chain of promises instead of queue, we will have visible side effects when function.sent would be implemented?
>> Could you please provide some examples that you faced in v8? I'll try to emulate on current solution, possible current approach is not viable at all.
>> 
>> Also it seems that I need to replace this by: 
>> 
>>         let wrappedValue = @newPromiseCapability(@Promise);
>>         wrappedValue. at resolve.@call(@undefined, value);
>>         wrappedValue. at promise.@then(
>>                                     function(result) { @asyncGeneratorResume(generator, promiseCapability, result, @GeneratorResumeModeNormal); },
>>                                     function(error) { @asyncGeneratorResume(generator, promiseCapability, error, @GeneratorResumeModeThrow); });
>> Because value is returned by await can be non promise value.
> 
> What I was getting at was about the `function.sent` metaproperty proposal (https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md), which allows the programmer to make `function.sent` an alias to the value the generator was resumed with (eg `generator.next("foo");` makes function.sent === "foo" inside the generator after resuming).
> 
> So, with Async Generators and await expressions, the awaited value would alias function.sent rather than the value sent via generator.next(), which observably breaks the metaproperty.
> 
> JSC does not implement function.sent yet, so it isn't really noticeable here, but it is something to pay attention to for the future, unless the proposal is withdrawn

OK. I'll keep in mind. Thanks for information.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170109/f72f70ce/attachment.html>