Verbs and operator| are unconditionally noexcept — a throwing callback terminates where the member call propagates

[Bronek]

fn::optional and fn::expected compute a precise conditional noexcept for their monadic
members. The verb layer then throws that answer away: every step of the pipeline is declared
unconditionally noexcept, so an exception that the member would propagate instead crosses a
noexcept boundary and calls std::terminate.

The same operation, written the two supported ways, has two different exception behaviours:

fn::optional<int> o{42};
auto f = [](int i) noexcept(false) -> fn::optional<int> { throw std::runtime_error{"boom"}; };

o.and_then(f);        // noexcept(false) - the exception propagates.  Correct.
o | fn::and_then(f);  // noexcept(true)  - the exception hits a noexcept boundary -> std::terminate.

operator| is libfn's headline API — it is what the README's examples are written in — so this is
the path users are most likely to take.

Verified (g++ 16.1.1, clang 22.1.6, C++20 — both agree)

using O = fn::optional<int>;
constexpr auto throwing = [](int i) noexcept(false) -> O { return {i}; };
constexpr auto nothrow_ = [](int i) noexcept -> O { return {i}; };

// the member gets it right
static_assert(not noexcept(std::declval<O &>().and_then(throwing)));
static_assert(noexcept(std::declval<O &>().and_then(nothrow_)));

// the verb does not
static_assert(noexcept(std::declval<O &>() | fn::and_then(throwing)));   // <-- claims noexcept
static_assert(noexcept(std::declval<O &&>() | fn::and_then(throwing)));

// transform, and expected, behave the same way
static_assert(not noexcept(std::declval<O &>().transform(throwing_t)));
static_assert(noexcept(std::declval<O &>() | fn::transform(throwing_t)));

// and constructing the functor copies the callable into a pack - that copy can throw too
struct ThrowingCopyFn final {
  ThrowingCopyFn() = default;
  ThrowingCopyFn(ThrowingCopyFn const &) noexcept(false) {}
  ThrowingCopyFn(ThrowingCopyFn &&) noexcept(false) {}
  auto operator()(int i) const noexcept -> O { return {i}; }
};
static_assert(noexcept(fn::and_then(std::declval<ThrowingCopyFn const &>())));  // <-- claims noexcept

The four boundaries

A pipeline call passes through four unconditional noexcept declarations, any one of which is enough
to turn a propagating exception into a terminate:

1. <verb>_t::operator()(auto &&fn) const noexcept -> functor<...> — e.g. and_then.hpp:66. Copies
   the callable into pack<as_value_t<Fn>>; that copy can throw.
2. functor::operator|(some_monadic_type auto &&v, auto &&self) noexcept — functor.hpp:41.
3. pack_impl::_swap_invoke(Self &&, Fn &&, Args &&...) noexcept — pack_impl.hpp:55.
4. <verb>_t::apply::operator()(V &&v, Fn &&fn) const noexcept — e.g. and_then.hpp:82, which simply
   forwards to FWD(v).and_then(FWD(fn)), discarding its conditional spec.

Sites: the pattern is uniform across every verb — and_then, or_else, transform,
transform_error, inspect, inspect_error, recover, fail, discard, filter — in both the
nielbloid operator() and the apply::operator().

Fix

Unlike #280, this needs no new traits and is not blocked on #45: the underlying members already
compute the answer, so the chain can simply propagate it bottom-up.

// apply: key off the member's own spec
template <some_monadic_type V, typename Fn>
[[nodiscard]] constexpr auto operator()(V &&v, Fn &&fn) const
    noexcept(noexcept(FWD(v).and_then(FWD(fn)))) -> same_kind<V &&> auto
  requires invocable_and_then<Fn &&, V &&>

// the nielbloid: key off constructing the functor's pack
[[nodiscard]] constexpr auto operator()(auto &&fn) const
    noexcept(::std::is_nothrow_constructible_v<functor<and_then_t, decltype(fn)>, decltype(fn)>)
    -> functor<and_then_t, decltype(fn)>

with _swap_invoke and operator| likewise noexcept(...)-computed from what they call. There is no
cycle: each layer's spec depends only on the layer below it.

Related: #279 and #280 (the same over-promise, in operator& and in sum/pack). Distinct from
#254, which is about the members under-promising on their sum/pack arms — the opposite direction, a
layer down. Found while adding noexcept coverage to tests/fn/and_then.cpp (#85), which asserts
the current behaviour so these flip when the fix lands.

[Bronek]

Correction to the "Fix" section above — the verbs are not all alike, and my claim that this needs no
new traits holds for only half of them.

Working through the rest of the verb tests (#85), the eleven verbs split into two groups by how their
apply is written, and the split decides what the fix costs:

1. Forwarding verbs — and_then, or_else, transform, transform_error, value_or.
Their apply delegates to the monad's own member (value_or via or_else with an internally-built
lambda), and that member already computes a precise conditional spec. For these, the original claim
stands: no new traits, just propagate what is already known.

noexcept(noexcept(FWD(v).and_then(FWD(fn))))

2. Self-implementing verbs — inspect, inspect_error, recover, fail, filter.
Their apply is the implementation: it calls ::fn::invoke(FWD(fn), ...) itself, and in the case of
recover, fail and filter also constructs the result. Nothing anywhere computes an honest spec for
these — so there is no correct answer to propagate, and one has to be computed:

// inspect.hpp:61-69 — unconditionally noexcept, and it invokes a user callback
template <some_expected_non_void V, typename Fn>
[[nodiscard]] constexpr auto operator()(V &&v, Fn &&fn) const noexcept -> V &&
  requires invocable_inspect<Fn &&, V &&>
{
  if (v.has_value()) {
    ::fn::invoke(FWD(fn), ::std::as_const(v).value()); // side-effects only
  }
  return FWD(v);
}

Computing it needs a nothrow flavour of fn::invoke's invocability trait — which is exactly
fn::is_nothrow_invocable / is_nothrow_invocable_r, stubbed false in
fn/detail/functional.hpp:177-186. So this group is blocked on #45, and #280's dependency graph
(#45 → #280 → #254) extends to cover it.

That makes the second group the worse of the two: for and_then the library knows the right answer and
discards it, but for inspect it never had one.

discard is the exception and is fine as it stands — its apply takes the operand and returns void
without touching a callback, so its unconditional noexcept is accurate. The tests assert that
positively rather than as a tripwire.

[Bronek]

Fixed on bronek/bugfixes-for-release-1.0 (commit 8450c7b). The scenario in the description now behaves:

static_assert(not noexcept(std::declval<O &>().and_then(throwing)));
static_assert(not noexcept(std::declval<O &>() | fn::and_then(throwing)));  // was noexcept(true) -> terminate
static_assert(noexcept(std::declval<O &>().and_then(nothrow_)));
static_assert(noexcept(std::declval<O &>() | fn::and_then(nothrow_)));

static_assert(not noexcept(fn::and_then(std::declval<ThrowingCopyFn>())));  // the nielbloid's own store

All four boundaries are closed: the nielbloid operator(), functor::operator|, pack_impl::_swap_invoke (which came with #45/#280), and each verb's apply.

The split in the comment above held, and decided the work. The forwarding verbs propagate what the member already computes. The self-implementing ones — inspect, inspect_error, recover, fail, filter — have their spec computed, which is only possible now that is_nothrow_invocable / is_nothrow_invocable_r are real (#45, landed). discard needed nothing: it invokes no callback and returns void, so its unconditional noexcept was always accurate, and the tests assert that positively rather than as a tripwire.

One trap worth recording. A spec must weigh what the body reaches, not what it writes. My first attempt spelled inspect's as noexcept(::fn::invoke(FWD(fn), std::as_const(v).value())) — which reports noexcept(false) even for a nothrow callback, because expected::value() can throw bad_expected_access. The body only calls it once has_value() has answered, so the spec asks about the invocation with decltype of the accessor rather than noexcept of a call to it. The same applies to .error(), and to recover / fail / filter.

Tests: the pipeline's own promise is pinned once in tests/fn/functor.cpp (via a second dummy verb whose apply is honestly noexcept(false), isolating the machinery's promise from any real verb's), and each of the eleven verb files gains a noexcept TEST_CASE asserting only its own delta — including the untouched-side weighing (and_then/transform weigh the error's relocation, or_else/transform_error the value's). Green on g++ 16.1.1 and clang 22.1.6, 39/39 both.

Assisted-by: Claude:claude-opus-4-8[1m]