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

domenic commented on this pull request.



> +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,

I'll need to think on this harder. It does seem like we have two rather different ways spec authors could do this, one of which makes sense when promises are involved, one of which makes sense when background threads are involved. Thanks for the added commit to give something concrete for us to look at.

My guess, before thinking hard, is that we'll either:

- Allow both styles, at the spec author's option; or
- Start with what kv-storage wants, then expand to what file system wants, etc., figuring it out as we go.

-- 
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#discussion_r285253498