Re: [boost] [boost.async] Dummy co_return from a generator

On Sun, Sep 24, 2023 at 11:24 PM Andrzej Krzemienski wrote:

niedz., 24 wrz 2023 o 16:17 Klemens Morgenstern napisał(a):

...

...

...

Why? How would you want to communicate to the awaiter that the coro is done?

First, there are a bunch of use cases where the consumer of the generator doesn't need to know, like the one with the listener: keep generating until you are canceled.

Ok, so it's technically UB, but you can skip the co_return. That will however generate a warning on msvc, so it's not officially recommended or mentioned in the docs. But I tested it on all compilers and it seemed to work.

It is only UB if the control reaches the end of the body. But if I know the loop is infinite and I will be always canceling the coroutine (calling .destroy()), reaching the end of function body does not happen, and therefore no UB.

...

This is an issue with the C++ API. A coroutine promise can either have a return_value OR a return_void. I cannot have both at the same time. If that was possible, I'd do it.

OK, I now understand why std::generator does not trigger an analogous warning in MSVC. std::generator<T>::promise_type defines the pair yield_value() and return_void(). So you can yield a value from a std::generator but you cannot return one.

Question: Is it important to the design of async::generator to allow `co_return value`? All the examples of coroutines I have ever seen yield values in a loop.

I think so, especially for users that do not want to use exceptions for errors. So being able to co_return an error instead of co_yield-ing a value (e.g. using system::result) seems quite useful

...

...

Second, std::generator somehow does it. (I do not know how.)

It does it by using iterators. I.e. you advance the iterator, which will resume the coroutine. Then you check against end() if it co_returned (void) and then you get the cached value.

The async::generator does it in one call.

Yeah, so the interface of std::generator is similar to returning optional<T> form async::generator. In the sense that it returns two pieces of information: (1) whether we are at the end, (2) and if not, what value we have.

...

...

Back to your question, when I see a code structure like this:

async::generator<T> fun() { while(cond) { co_yield something; } }

I know that there is nothing to do after the last co_yield in the loop. So maybe the compiler/library should also. Modulo that this may not be doable in the library, or the hacks are too expensive.

It's doable, but the price is more API complication. I think a dummy return while annoying is the best solution. Because otherwise the user needs to use a different generator type if he wants to use a significant value return as indication he's done (e.g. a generator>.).

Given the present interface, I have two ways of checking the "I am done" state: 1. One is to call generator::operator bool() 2. The other is to inspect the state of the yielded value.

I see no use for the first one. There is an `operator bool` that doesn't do the job. Or did I misunderstand again?

It'll tell you if it co_returned. So it's useful.

Would it be correct to say that I cannot use `async::generator<T>` effectively when my type `T` doesn't have a special dummy state?

No. Throwing an exception or skipping the co_return (ignoring the MSVC warning) would solve that issue.

...

The asio::experimental::coro defaults to using an optional btw., which I find much more cumbersome as a default, especially with the example above.

I am aware of two use cases. One where the resumer decides when the generation ends, the other when it is the generator that decides. For the former case, you are right. For the latter case, using optional is no worse than testing the dummy value on one side, and putting an additional code to generate the dummy value on the other.

Sure, but from the API perspectice, you can just use a generator that co_yields T and co_returns std::nullopt. I don't see the issue with an additional dummy co_return at the end.