On Thu, 2025-09-11 at 21:44 +0200, Ted Lyngmo via Std-Proposals wrote:
> 2025-09-11 13:21, Avi Kivity via Std-Proposals:
> > The Standard says
> > >
> > > If searches for the names return_void and return_value in the
> > > scope
> > > of the promise type each find any declarations, the program is
> > > ill-
> > > formed.
> >
> > However, there are cases where one wants both "co_return;" and
> > co_return something;" statements in the same coroutine.
> >
> > The cases are when the coroutine returns a sum type such as
> > std::future
> > or std::expected, and one of the options is void (e.g.
> > std::future<void> or std::expected<void, something>. In these
> > cases,
> > one would want
>
> Do you mean that you want it selectable at runtime depending on if
> the
> `std::expected` contains the expected, void, or `something´? How
> would
> that look in an example (that is accepted by an earlier version of
> gcc)?
>

With the old gcc (or my proposal), I could write


future<> my_coroutine(int x) {
    if (x < 0) {
        co_return make_exception_future(std::invalid_argument());
    }
    // do some work
    co_return;
}


The first co_return dispatches to return_value(). The second co_return
dispatches to return_void(). But the two cannot exist according to the
Standard.

My proposal is to allow them to coexist.


> A working example at godbolt would be nice to see it in action.
>


Whipping up coroutine demos is hard due to all the boilerplate. I'll
try.



> Otherwise, isn't that what _constexpr-if_ solves?
>


No, the two forms (co_return; and co_return expr;) are disallowed. I
want to allow them.


> Best regards,
> Ted Lyngmo