On Sun, Mar 30, 2025 at 10:41 PM Stewart Becker via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I have been doing work in the world of monads and functional programming,
> and have found std::expected to be a key building block for such work. It
> works particularly well when the error type is the catch-all
> std::exception_ptr. However, there are still some drawbacks. What would
> be even better would be if:
>
> 1. std::exception_ptr supported references (including rvalue
> references) for the value type,
> 2. std::exception_ptr::value() called std::rethrow_exception(error())
> rather than throwing a std::bad_expected_access on error, and
> 3. std::exception_ptr<T, std::exception_ptr>::transform(f) and
> ::and_then(f) were noexcept. Completely noexcept is probably impossible,
> but it should be possible to wrap the transformation itself in try/catch,
> only throwing if the final copy/move of the returned result does so.
>
> I believe you meant `std::expected` instead of std::exception_ptr in the
above points? (Only the second template parameter in the third point should
be std::exception_ptr).

>
> 1.
>
> To the first point, I have found that, in order to work effectively with
> monadic continuations, more than return-by-value is needed. While a
> reference can be wrapped in a std::reference_wrapper or a pointer, this
> doesn't allow for generic programming. There also are no vocabulary
> wrappers that distinguish between lvalue and rvalue references.
>
> The paper P2988 (std::optional<T&>) expected<T&> in passing and makes the
> case for std::expected<T&, E>, but only actually proposes matters for
> std::optional<T&>, noting "... we expect future papers to propose
> std::expected<T&, E> ...". Well, maybe it is time for such a paper.
>
> Secondly, the purpose of std::expected is to encpasulate error handling,
> but when exp.transform(f) and exp.and_then(f) throw, this encapsulation is
> broken. Additionally, I find that throwing std::bad_expected_access is a
> leaky abstraction - albeit one necessary for other error types. In each
> case, it can be worked around by wrapping calls to the expected in a try /
> catch and either rewrapping (.transform) or extracting and rethrowing
> (.value) the caught exception. However, this adds a lot of boilerplate and
> significantly reduces the advantages of using std::extepected in the first
> place! This could all be covered within std::expected<T,
> std::exception_ptr> itself.
>
> Paper P3014 (Customising std::expected's exception) touches on some of the
> above, but I don't think in its current form would accommodate calling
> rethrow_exception when E is std::exception_ptr. While P3014 states that "User
> code is allowed to customize std::expected_traits for their own error
> types", std::exception_ptr is not a user type.
>
> I do acknowledge that for std::expected<T, std::exception_ptr>::value to
> call std::rethrow_exception would be a change of behaviour. However, one
> way to square this circle could be if std::expected took a third,
> defaulted, type parameter, taking the role of P3014's expected_traits<E>.
> Current behaviour can be retained by the default but still allow for
> customisation. I don't know if there is precedent for adding a type
> argument to an existing library class template. While this too would be a
> breaking change inasmuch as adding an addition template paremeter means
> std::expected would no longer match template<template<typename, typename>
> class Exp>, it is perhaps the lesser of two evils. Beyond that, it is
> difficult to see how this would break existing code. I have reached out to
> Jonathan Muller (P3014's author), but received no response.
>
> I don't know of any work on noexcept versions of std::expected::transform
> or std::expected::and_then. These are perhaps the simplest to achieve.
> std::expected<T, std::exception_ptr> could be specialised to have
> additional noexcept member functions try_transform and try_and_then, which
> internally call transform(f) and and_then(f) within a try/catch block.
>
> I would hope that adding support for reference types to std::expected is
> uncontroversial, particularly in the light of P2988. The other aspects may
> be more contentious. It would be possible to design an entirely new
> std::expected-like class template with those features. However,
> std::expected delivers a lot of valuable functionality that would simply be
> duplicated; do the additional features above really warrant a new type
> rather than attempting to improve std::expected? We already have at least
> three patterns for indicating errors, (returning error codes, throwing
> exceptions and encapsulating in std::expected). Adding yet another -
> especially one so similar to an existing pattern - would seem to complicate
> the space for little benefit. On the other hand, if the type could
> implicitly convert to and from std::expected, it may be a viable way
> forward.
>
> Stewart Becker
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>