Not immediately urgent given no current usage AFAIA, but will likely start to diffuse into definitions (whatwg/streams#1372 etc.)
In terms of binding, this maps to AsyncIterable<T> when converting from IDL to JS. When converting from JS to IDL, it can technically fall back on a sync iterator if an async iterator isn't found, so so would probably technically be something like AsyncIterable<T> | Iterable<T>.
This won't be an issue for the "primary" builds (ts6.0+), since the generator adds a <reference> to lib.2018.asynciterable, so Symbol.asyncIterator is always present in the project global scope.
This will be an issue for older targets, where there are no <reference> directives, and interfaces marked async_iterable have their iterator methods ([Symbol.asyncIterator]/entries/keys/values) separated out into the *.asynciterable definition files. If we follow the same logic, that is going to mean that any method or property that references async_sequence is going to have to be excluded from the main definition files. A change in approach might be necessary, ie. "backporting" the <reference> pattern to these older targets, or just typing async_sequences as any for older targets.
Not immediately urgent given no current usage AFAIA, but will likely start to diffuse into definitions (whatwg/streams#1372 etc.)
In terms of binding, this maps to
AsyncIterable<T>when converting from IDL to JS. When converting from JS to IDL, it can technically fall back on a sync iterator if an async iterator isn't found, so so would probably technically be something likeAsyncIterable<T> | Iterable<T>.This won't be an issue for the "primary" builds (ts6.0+), since the generator adds a
<reference>to lib.2018.asynciterable, soSymbol.asyncIteratoris always present in the project global scope.This will be an issue for older targets, where there are no
<reference>directives, and interfaces markedasync_iterablehave their iterator methods ([Symbol.asyncIterator]/entries/keys/values) separated out into the*.asynciterabledefinition files. If we follow the same logic, that is going to mean that any method or property that referencesasync_sequenceis going to have to be excluded from the main definition files. A change in approach might be necessary, ie. "backporting" the<reference>pattern to these older targets, or just typingasync_sequences asanyfor older targets.