You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 20, 2023. It is now read-only.
letdone=false;constit={[Symbol.iterator](){return{next(){letp=Promise.resolve({value: 1, done });p.value=2;p.done=done;done=true;returnp;}}}}forawait(constvofit){console.log(v);// logs 2; if you replace @@iterator with @@asyncIterator it logs 1.}
As such, if when using await using there is no @@asyncDisposable and thus we use the @@disposable fallback, if it returns a promise it should not be awaited.
When the language uses synchronous iterators as fallbacks for asynchronous iterators (using https://tc39.es/ecma262/#sec-async-from-sync-iterator-objects), it doesn't await the promises returned by
next()
:As such, if when using
await using
there is no@@asyncDisposable
and thus we use the@@disposable
fallback, if it returns a promise it should not be awaited.The proposal spec doesn't distinguish between the method store in
@@asyncDisposable
and the one stored in@@disposable
(steps 1.a and 1.b.i of https://tc39.es/proposal-async-explicit-resource-management/#sec-getdisposemethod).I found this inconsistency while implementing this proposal in Babel: babel/babel#15633.
The text was updated successfully, but these errors were encountered: