Re: [heycam/webidl] Add async_iterable support (#720)

domenic commented on this pull request.

High-level comments as I skim through this between meetings. Will do more later.

> @@ -4091,6 +4104,138 @@ The following extended attributes are applicable to [=iterable declarations=]:
 </pre>
 
 
+<h4 id="idl-async-iterable">Asynchronously iterable declarations</h4>

Nit: I've never seen it spelled out as "asynchronously iterable". Maybe an "asynchronous iterable", as in the title of https://github.com/tc39/proposal-async-iteration. But "async iterable" is much more common.

> +being iterated over asynchronously to obtain a sequence of values.
+
+Note: In the ECMAScript language binding, an interface that is asynchronously iterable will have
+<code class="idl">entries</code>, <code class="idl">keys</code>, <code class="idl">values</code>,
+and {{@@asyncIterator}} properties on its [=interface prototype object=].
+
+Prose accompanying an [=interface=] with an [=asynchronously iterable declaration=] must define a
+<dfn id="dfn-get-the-next-iteration-result">get the next iteration result</dfn> algorithm.
+This algorithm receives a <b>[=this=]</b> value, which is an instance of the [=interface=] that it
+is defined for, and the <dfn export>current state</dfn>.
+It must return a {{Promise}} that either resolves with undefined – to signal the end of the
+iteration – or a tuple with three elements:
+
+1.  a value of the first type given in the declaration;
+1.  a value of the second type given in the declaration;
+1.  an opaque value that is passed back to the next invocation of the algorithm,

Hmm. This wasn't what was discussed in https://github.com/heycam/webidl/issues/580. I prefer the formulation over there, if you think it's possible to spec.

> +An [=interface=] must not have more than one [=asynchronously iterable declaration=].
+The [=inherited interfaces=] of an [=interface=] with an [=asynchronously iterable declaration=]
+must not also have an [=asynchronously iterable declaration=].
+An [=interface=] with an [=asynchronously iterable declaration=] and its [=inherited interfaces=]
+must not have a [=maplike declaration=], [=setlike declaration=], or [=iterable declaration=].
+
+The following extended attributes are applicable to [=asynchronously iterable declarations=]:
+[{{Exposed}}],
+[{{SecureContext}}].
+
+Issue: these [=extended attributes=] are not currently taken into account.
+When they are, the effect will be as you would expect.
+
+<pre class="grammar" id="prod-AsyncIterable">
+    AsyncIterable :
+        "async_iterable" "&lt;" TypeWithExtendedAttributes "," TypeWithExtendedAttributes "&gt;" ";"

For https://wicg.github.io/native-file-system/#filesystemdirectoryhandle I believe we'll want a version that only does values.

For https://streams.spec.whatwg.org/#rs-asynciterator / https://streams.spec.whatwg.org/#rs-get-iterator we'll want a version that only does values and also can be aliased to a function that takes arguments.

For the values-only version I'd stay conservative and not add keys/values/entries for now as this is uncharted territory. (Even though sync iterables do that even for values-only cases like `Set`.)

All this can be done as a follow-up, but it may be helpful to keep it in mind while designing.

-- 
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/720#pullrequestreview-232703380