Boost logo

Boost :

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-09-24 14:16:25


>>
>> 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.

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.

> 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.

> 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<system::result<size_t>>.).

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

>
> Regards,
> &rzej;
>
>>
>>
>>
>>> that the end of generation should be signaled in this way.
>>>
>>> Regards,
>>> &rzej;
>>>
>>> _______________________________________________
>>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk