-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add async_iterable support #720
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM! A few clarity suggestions.
This could probably use review from other implementors before it merges.... |
@bzbarsky would you have time to review this soon? I am planning to land WICG/kv-storage#68 with a reference to this pull request, but it would be even better if I could reference the base spec. |
This week is a Mozilla all-hands, so my time is very unpredictable through Friday. I can make this a priority on Monday, though. Is that good enough? |
That would be great, thank you! |
I have some concerns about how we will apply this to the Streams standard. The
but |
I've got a WIP for value-only iterators in https://github.com/heycam/webidl/compare/async-iterator-values?expand=1. |
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, | ||
|
||
The prose may also define <dfn>asynchronous iterator initialization steps</dfn> for the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are these steps allowed to do? This seems pretty open-ended... Maybe that's ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is supposed to be a step towards handling https://streams.spec.whatwg.org/#rs-get-iterator ; not sure if it's necessary to restrict anything here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we OK with the steps here calling into arbitrary script, say? (We might be; I haven't audited very carefully.)
index.bs
Outdated
|
||
<pre class="grammar" id="prod-AsyncIterable"> | ||
AsyncIterable : | ||
"async_iterable" "<" TypeWithExtendedAttributes "," TypeWithExtendedAttributes ">" ";" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason for async_iterable
rather than async iterable
? The latter seems a bit nicer to read/write to me and the grammar bit should be fine, I expect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong feelings from my side on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would personally prefer async iterable
.
Thanks for the review; I think I covered most of the issues. |
Generally looks good, thanks! I think I would still prefer |
@yuki3 Would |
I think that it should be just fine. We already have "partial dictionary", "partial interface", "callback interface", etc. I don't think that a space between "async" and "iterator" will be a problem. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we merge?
What's the support in bikeshed and WPT's respective IDL parsers? |
For WTP, I don't think we support this yet in WebIDL2.js, right @saschanaz? Would be trivial to add tho. |
@marcoscaceres Right, we don't. I can cook a PR soon. |
Just to make sure: |
"async iterable" by looking at the example. |
Ok, @saschanaz added support (w3c/webidl2.js#365). We will wait for this to merge. Probably want to bugs filed on browser engines too. |
Fixes #580.
Preview | Diff