async function* foo() {
    yield new Promise(r => setTimeout(r, 1000));
    console.log('reenter');
}
const it = foo();
it.next();
it.next();

async function* foo(){ yield 0; await sleep(1000); yield 1; }
let it = foo().map(x => fetch(x));
it.next();
// almost immediately after this point, the promise returned from the first call to the underlying foo()'s `.next` settles
// then the first call to `fetch` starts
it.next() // so this can almost immediately kick off another call to the underlying foo()'s `next`, and have that actually hit the `sleep`

async function* foo(){
    yield 0;
    console.log('reenter');
    await sleep(1000);
    yield 1;
}
let it = foo();
it.next();
it.next();
console.log('end');

Logs end then reenter, the first yield doesn't settle the iterator until after a tick

let it = foo()
  .map(x => fetch(x))
  .map(r => r.json());

async function* foo() {
    yield new Promise(r => setTimeout(r, 1000));
    console.log('reenter');
}
const it = foo();
it.next();
it.next();

In fact, the implicit await is doing me a big favor in:

function parallel(limit, process) {
  function *workers() {
    for (const worker of count(limit)) {
      yield process(worker);
    }
  }
  return Promise.all(workers());
}

Out of which you can build bounded concurrency pretty easily (I’m taking the liberty of assuming the existence of AsyncIterator.from having not followed along particularly closely)

const parallelForEach = async (limit, values, process) =>
  parallel(limit, () => AsyncIterator.from(values).forEach(process));

If you want the flexibility of not blocking on the async operation before continuing the async generator body, then just don't yield the value yet.

🤔 That doesn't really make sense.

The only way to consume async iterables:

• Callers of .next() will await (they already had to, we're returning promises)
• for-await-of can be updated to await the inner value
  • Also call .return() if rejection happens

The ways to consume an async iterator:

• manual .next()
• yield* (which only works inside another async iterable)
• for-await-of

you'd get the same caught in a for-await-of
the relevant bit is that the catch handler inside the async generator gets triggered

I would phrase this as ".next() will call .error() if promise rejects"

Eg, the slides say:

// Given:
AsyncIterator.prototype = {
  async next(v) {
    return { value: await resumeWithValue(v), done }
  }

  async error(e) {
    return { value: await resumeWithError(e), done }
  }
}

// Input
async function* foo() {
    try {
        yield Promise.reject(1);
    } finally {
        console.log(2);
    }
}

// Output
async function* foo() {
    try {
        yield await Promise.reject(1);
    } finally {
        console.log(2);
    }
}

// Given:
AsyncIterator.prototype = {
  async next(v) {
    try {
      return { value: await resumeWithValue(v), done }
    } catch (e) {
      return { value: await resumeWithError(e), done }
    }
  }

  async error(e) {
    return { value: await resumeWithError(e), done }
  }
}

// Input
async function* foo() {
    try {
        yield Promise.reject(1);
    } finally {
        console.log(2);
    }
}

// Output has no change

And if we can do that, why can't we do:

// Given:
AsyncIterator.prototype = {
  async next(v) {
    try {
      return { value: await this.nextRaw(v).value, done }
    } catch (e) {
      return { value: await resumeWithError(e), done }
    }
  }

  async nextRaw(v) {
    return { value: resumeWithValue(v), done }
  }

  async error(e) {
    return { value: await resumeWithError(e), done }
  }
}

ok I think that means not changing the generator semantics, and leaving it to the producer opting in these semantics through helpers.

I assume the helper would call .throw() on the wrapped generator if it encounters a rejection ?