Re: [heycam/webidl] Make async iterator return() function after failed next (#891)

@TimothyGu commented on this pull request.



> @@ -12543,8 +12543,13 @@ The \[[Prototype]] [=internal slot=] of an [=asynchronous iterator prototype obj
                 1.  Let |value| be |next|, [=converted to an ECMAScript value=].
                 1.  Return [=!=] [$CreateIterResultObject$](|value|, <emu-val>false</emu-val>).
         1.  Let |onFulfilled| be [=!=] [$CreateBuiltinFunction$](|fulfillSteps|, « »).
-        1.  Perform [=!=] [$PerformPromiseThen$](|nextPromise|, |onFulfilled|,
-            <emu-val>undefined</emu-val>, |nextPromiseCapability|).
+        1.  Let |rejectSteps| be the following steps, given |reason|:
+            1.  Set |object|'s [=default asynchronous iterator object/ongoing promise=] to
+                null.
+            1.  [=ECMAScript/Throw=] |reason|.

A few more things to think about.

```js
try {
  const a = await it.next();  // eventually rejected
} catch {
  const b = await it.next();
}
```

Async generators (and also sync generators) would set `b` to `{ value: undefined, done: true }`. We could do the same by just setting the _is finished_ flag to true, which would give us the invariant that _getting the next iteration result_ will never be called after it has rejected a promise, which is something I think spec authors could come to expect.

Alternatively, we could consider a “one bad apple spoils the bunch” semantic, where `b` gets rejected. I think we should stick with the async generator behavior though.

----

Going further, consider this case:

```js
const a = it.next();  // note: no await here
const b = it.next();
```

It seems like `b` should be settled in the same way as `b` above, as the timing of when `it.next()` is called shouldn't have any bearing on its result. But then this would require us to keep some _unsettled promise set_ on _object_'s target, which brings about additional complexity. Async generators has something analogous through the [[AsyncGeneratorQueue]] internal slot; see [spec](https://tc39.es/ecma262/#sec-asyncgenerator-abstract-operations).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/891#pullrequestreview-424962319