[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 #53 from Caitlin Potter (:caitp) <caitp at igalia.com> ---
Comment on attachment 305500
  --> https://bugs.webkit.org/attachment.cgi?id=305500
Patch

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

>>> Source/JavaScriptCore/builtins/AsyncGeneratorPrototype.js:123
>>> +                                        generator. at generatorState = @AsyncGeneratorStateCompleted;
>> 
>> This actually looks wrong to me, per the current spec. Unless the committee decides to go with the "yielded rejections don't affect control flow of the generator" thing (which is admittedly pretty popular), closing the generator should be left up to @asyncGeneratorResume().
>> 
>> Even if the proposal is changed, this will prevent finally blocks from being reached.
>> 
>> E.g.
>> 
>> ```js
>> let reject;
>> async function* foo() {
>>   try {
>>     yield new Promise(function(unused, rej) { reject = rej; });
>>   } finally {
>>     doImportantCleanupStuff(); // In this patch, this appears to be unreachable
>>     return 0;
>>   }
>> }
>> 
>> foo().next().then(x => print(x), e => print(e));
>> reject("Oop!");
>> ```
>> 
>> I could be wrong about this, but I _believe_ this is broken in this patch due to the generator state change here, and I think it is supposed to work in the current spec
> 
> I see following result:
> 
>   do important staff
>   returned value
>   Oop!
> 
> Is this result close to spec or 'important staff' should be returned after Oop!
> To test I used little bit modified function:
> ```
> async function* foo() {
>   try {
>     yield new Promise(function(unused, rej) { reject = rej; });
>   } finally {
>     print('do important staff');
>     return 'returned value';
>   }
> }
> 
> var f= foo()
> f.next().then(({value}) => print(value), e => print(e));
> reject("Oop!");
> f.next().then(({value}) => print(value), e => print(e));
> drainMicrotasks();
> ```

In #jslang I made a gist and spent some time analyzing it, didn't get through the whole thing, but I pretty much get the same result, so I think it's okay. https://gist.github.com/caitp/9af4de75c5ac6ff7d22b366472617e21

And yeah, the finally block would be reached if another request is queued up, regardless of whether the rejection affects control flow or not. But it still shouldn't close the generator, that doesn't really make sense.

-- 
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/20170329/d5d9088d/attachment.html>