Using for await…of with synchronous iterables

by

Yes, it is strange, and you should not do this. Don’t iterate arrays of promises, it leads exactly to the unhandled-rejections problem you mentioned. (See also this more specific explanation.)

So why is this supported in the language? To continue with the sloppy promise semantics.

You can find the exact reasoning in this comment of the issue discussing this part of the proposal:

I think we should fall back to Symbol.iterator because our current
Promise semantics are all about allowing sync things to be used as
async things. You might call this “sloppiness”. It follows
@groundwater’s logic above,
but I just want to spell out the parallels in more detail.

The “chaining” semantics of .then are all about this. You can return a
Promise from .then or a scalar value; it’s all the same. You call
Promise.resolve not to wrap something in a Promise, but to cast
something to a Promise–get an asynchronous value when you have
something-or-other.

The semantics of async and await are all about being sloppy as well.
You can slap await on any non-Promise expression in an async function
and everything works fine, exactly the same way, except that you yield
control to the job queue. Similarly, you can “defensively” put async
around whatever you want, as long as you await the result. If you have
a function that returns a Promise–whatever! you can make that an
async function, and, from a user perspective, nothing changes (even
if, technically, you get a different Promise object out).

Async iterators and generators should work the same way. Just like you
can await a value that, accidentally, wasn’t a Promise, a reasonable
user would expect to be able to yield* a sync iterator within an async
generator. for await loops should similarly “just work” if a user
defensively marks a loop that way, thinking that they maybe might be
getting an async iterator.

I think it would be a big deal to break all of these parallels. It
would make async iterators less ergonomic. Let’s discuss this the next
time async generators/iterators come up on the agenda at TC39.

More Related Contents:

  1. Async function returning promise, instead of value
  2. Use async await with Array.map
  3. Waiting for more than one concurrent await operation
  4. async/await always returns promise
  5. How to turn this callback into a promise using async/await?
  6. How to return values from async functions using async-await from function? [duplicate]
  7. How to “await” for a callback to return?
  8. Async function not returning value, but console.log() does: how to do? [duplicate]
  9. What is the difference between JavaScript promises and async await?
  10. SyntaxError: Unexpected token function – Async Await Nodejs
  11. Why do I need to await an async function when it is not supposedly returning a Promise?
  12. Why are await and async valid variable names?
  13. Is there a way to wrap an await/async try/catch block to every function?
  14. Slowdown due to non-parallel awaiting of promises in async generators
  15. using async await and .then together
  16. How to implement a pseudo blocking async queue in JS/TS?
  17. How to know if a function is async?
  18. Async function without await in JavaScript
  19. How to wait until a predicate condition becomes true in JavaScript?
  20. What is the Operator Precedence of Await?
  21. Is async await truly non-blocking in the browser?
  22. Difference of using async / await vs promises?
  23. Get Knex.js transactions working with ES7 async/await
  24. Node.js mongodb driver async/await queries
  25. Does an async function always need to be called with await?
  26. Async Await map not awaiting async function to complete inside map function before mapping next item
  27. Await an iterative function without delimiter in JS
  28. Cypress.io How to handle async code
  29. ASYNC / AWAIT SyntaxError: await is only valid in async functions and the top level bodies of modules
  30. JS async/await – why does await need async?

Leave a Comment