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