core/coroutine: add a specialization for std::expected<void, Err> #2971
Conversation
rockwotj
force-pushed
the
co_return_std_expected
branch
from
0981c04 to
ccb0c1c
Compare
As recorded in https://www.scylladb.com/2024/05/14/better-goodput-performance-through-c-exception-handling/ under `Approach 1: Avoid The Exceptions` there are places where we would like to avoid exceptions. One approach we do is use `boost::result`, but now that we're on C++23 have instead favored using `std::expected` as it's a bit simpler and "modern" (for what that is worth). However, for side effecting functions we've started to represent that with `std::expected<void, Err>`, which is fine, but very cumbersome to fully type out. We'd like to specialize coroutine_traits to make this case less verbose, but can't do it in our application due to it being in an `internal` namespace and compatibility not being ensured. So we propose a specialization for `std::expected` that allows the syntax `co_return {};`. This is really a small quality of life improvement for us we'd like to understand if there is an appetite for having upstream.
rockwotj
force-pushed
the
co_return_std_expected
branch
from
ccb0c1c to
6069840
Compare
|
|
||
| void return_value(std::expected<void, Err>&& value) { | ||
| _promise.set_value(std::forward<std::expected<void, Err>>(value)); | ||
| } |
There was a problem hiding this comment.
I like it (and we want to move from boost::outcome to std::expected too).
But there's too much copying here. Perhaps add this to the main template with a constraint?
There was a problem hiding this comment.
@avikivity are you infavor of #2977? If so, I'll close this patch as it also handles the case.
There was a problem hiding this comment.
It's better to do it deliberately in its own pull request rather than sneak it in as part of another change.
There was a problem hiding this comment.
Well the fundamental issue is that the compiler can't infer the return type because of the template in return_value so if we want to move to return_value not being a template then this case doesn't need to be specialized anymore.
2 participants
As recorded in https://www.scylladb.com/2024/05/14/better-goodput-performance-through-c-exception-handling/ under
Approach 1: Avoid The Exceptionsthere are places where we would like to avoid exceptions. One approach we do is useboost::result, but now that we're on C++23 have instead favored usingstd::expectedas it's a bit simpler and "modern" (for what that is worth).However, for side effecting functions we've started to represent that with
std::expected<void, Err>, which is fine, but very cumbersome to fully type out. We'd like to specialize coroutine_traits to make this case less verbose, but can't do it in our application due to it being in aninternalnamespace and compatibility not being ensured.So we propose a specialization for
std::expectedthat allows the syntaxco_return {};. This is really a small quality of life improvement for us we'd like to understand if there is an appetite for having upstream.