You might find this interesting:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0779r0.pdf
Obviously proposal went nowhere, but IDK why.

On Sun, Mar 27, 2022 at 8:57 PM Cesar Torres via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> There is an error handling pattern that appears repeatedly in many C++
> codebases:
>
> (1)
> ​auto maybe_result_or_error = a_function_that_may_fail();
> if (maybe_result_or_error.has_error())
> return maybe_result_or_error.error();
> auto result = maybe_result_or_error.result();
>
> Here, we call a function that may fail, in which case we get an object
> explaining or signaling the error.
> We check if the result has an error, in which case we don't want to
> continue executing the current function, and return the error, propagating
> it.
>
> Sometimes, it also looks like:
> (2.1)
> auto maybe_error = a_function_that_may_fail();
> if (maybe_error.has_error())
> return maybe.error();
> OR
> (2.2)
> auto maybe_error = a_function_that_may_fail();
> if (maybe_error.has_error())
> return;
>
>
> Here, the function we call doesn't return anything unless it fails, in
> which case we get an object signaling the error.
> As in the first case, in many cases the programmer will want the function
> to return because we
> didn't get what we wanted from that function (be it a connected socket, an
> open file, a memory allocation, etc).
> We return the error, propagating it.
>
> In other codebases, it might look like this:
>
> (3)
> auto* maybe_ptr = a_function_that_may_return_null();
> if (maybe_ptr == nullptr)
> return;
> auto result = *maybe_ptr;
>
> There is a common pattern here. We get a return value from a function,
> check if it's valid,
> in which case we unwrap that result, or if it's invalid, in which case we
> do something, often returning the error to propagate it.
>
> I propose a new syntax feature:
>
> auto result = try a_function_that_may_fail(); // for examples (1) and (3)
> AND
> try a_function_that_may_fail(); // for examples (2.1) and (2.2)
>
> This translates internally to the respective examples, and serves the
> purpose of simplifying a common pattern that, just
> like for loops with iterators, is very common to see in projects that do
> not make use of exceptions. It moves boilerplate
> away from the code in a zero-cost way.
> It should return the error value if the return value of the function it
> appears in is not void and is implicitly constructible from the
> error type. The approach to implementing this, in order to make it a soft
> feature like structured-binding, could be with
> special member function names like has_error(), result() and error(), akin
> to how structured-binding uses get() for tuples (e).
> Types like std::expected have these methods, and could be used with this
> new syntax sugar.
>
> A macro version is already in use in some projects (see references (a)
> and (b) for uses and (c) for the macro implementation),
> or is even built-in in languages like Rust (d).
>
>
> I look forward to your feedback,
> Cesar Torres.
>
>
> References:
>
> a.
> https://github.com/SerenityOS/serenity/blob/master/Documentation/Patterns.md#try-error-handling
> b.
> https://github.com/SerenityOS/serenity/blob/f7f14d52e0beeb61b133e556e3e5b841e570d364/Userland/Applications/ImageViewer/main.cpp#L42
> c.
> https://github.com/SerenityOS/serenity/blob/f7f14d52e0beeb61b133e556e3e5b841e570d364/AK/Try.h
> d.
> https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator
> e. https://en.cppreference.com/w/cpp/language/structured_binding
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>