The reason is that we don't have "async for". I would need to resume the generator on increment, but if `itr++` is an awaitable expression that needs to be co_awaited, it's not an iterator. If there was an async for (or a common pattern) I'd make generator work with it.
Y'see I don't see the need for async for. That's separate to this.
`std::generator` provides iterators. When you iterate one of its iterators the coroutine gets resumed and it yields a new value.
The reason `std::generator` is like this is because it can be called from non-coroutine code, so `co_await` isn't available. Implied in this is iterator implementations must pump the coroutine by hand.
This is very straightforward for the simple case, it gets harder if the generator suspends on say i/o. Then your generator iterator implementation needs to pump the event loop too. This isn't a hard to surmount problem to solve for Boost.Async I think. And I think a Boost level library does need to implement what the C++ standard demands, even if it's a bit dumb.
Ah, gotcha I thought you wanted that to be in async, i.e. with a co_await somewhere. Yeah that could be done & might actually be something useful for non-pushable generators. I'll look into it.
So the earlier versions of N4775 that had `for co_await` would have made the `++itr` awaitable. With std::generator the increment also rethrows exceptions. That means I could in theory have an async_for do a `co_await async::next(itr)` instead of `co_await ++itr` and have the same iterator type work. There is however a problem with "pumping the event-loop". I have the executor but I might not know the event-loop it's referring to (it might be a thread_pool) or something custom. Now I would either need to somehow create an interface to allow the user to supply a pump function or require that he uses asio::io_context for that to work. I don't like either, I think I'll hold off until there's a user asking for it.