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