-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use std::expected to handle burn failures? #1439
Comments
What is an example of something this enables that we can't do right now (with the burn status stored in the burn_t)? |
It can propagate up the call chain into parts of our code that aren't Microphysics-specific. This could reduce the amount of boilerplate code significantly by using the This extension is now part of C++23: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2505r1.html For example, we could implement hydro retries like this:
|
it looks like this is a C++23 feature, right? |
Yes. You can also copy this (public domain) header file and use it now with C++17: https://github.com/TartanLlama/expected/blob/v1.1.0/include/tl/expected.hpp. |
It would be useful to handle burn/integration failures in a more modern C++ (but exception-free) way.
This could be done by having the burner return an
std::expected
object (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r3.pdf, monadic functions: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2505r1.html)(Public domain implementation here: https://github.com/TartanLlama/expected.)
It works like this:
In principle,
std::expected
objects can be propagated higher in the call stack, so it could be used thoughout Microphysics, not just in returning to the application code.The text was updated successfully, but these errors were encountered: