`sum` and `pack` members are unconditionally `noexcept` across throwing user-type operations

[Bronek]

Throughout include/fn/sum.hpp and include/fn/pack.hpp, members are declared unconditionally noexcept while performing operations on user types that may throw. Any such throw becomes std::terminate, and since the spec also reports noexcept == true, callers cannot even detect the hazard by querying noexcept(…).

Sites in sum.hpp:

• widening ctors :258 / :277 / :296 — copy/move-construct the active alternative from sum<Tx…> (this trio is also currently untested);
• copy ctor :314 and move ctor :330 — construct the active alternative; requires only is_copy/move_constructible, no nothrow conjunct;
• _invoke :183/:188, _transform :193/:201, and the public invoke ×4 (:400-:454), invoke_r ×4 (:473-:527), transform ×4 (:544-:598) — invoke a user callable (and construct the result);
• operator== :644 / operator!= :667 — call the user's comparison.

Sites in pack.hpp:

• append ×8 (:48-:154) — construct the appended element and copy/move the existing elements into the new pack;
• invoke ×4 (:165-:213) / invoke_r ×4 (:230-:281) — user callable.

(has_value, get_ptr, get<I> and the destructors are safe as declared.)

Fix direction: conditional noexcept keyed on the applicable traits — is_nothrow_copy/move_constructible folded over the alternatives for the ctors and append; for the dispatch members, nothrow-invocability over the dispatched set, which needs the #45 traits (currently stubbed to false in fn/detail/functional.hpp:177-186).

Related: #279 is the same defect in operator& at the optional/expected layer; #254 (fn-native noexcept for the sum/pack monadic extensions) has this issue as a prerequisite — precise specs there must derive from these members' true specs.

Tests: the #85 audit found zero noexcept assertions in tests/fn/sum.cpp / tests/fn/pack.cpp; tripwires pinning current behaviour (flipping when fixed) will land with that branch's sum/pack pass (bronek/unit_tests_cleanup).

[Bronek]

Widening the scope while adding the noexcept dimension to tests/fn/sum.cpp (#85): the value
constructors are the converse of the sites listed above — they carry no noexcept specifier at
all, so they under-promise where the rest over-promise.

static_assert(not noexcept(fn::sum<int>{42}));                             // implicit value ctor, sum.hpp:215
static_assert(not noexcept(fn::sum<int>{std::in_place_type<int>, 42}));    // in-place ctor,       sum.hpp:245

Neither can throw for int, yet both report noexcept(false). The explicit value ctor (sum.hpp:230)
and the as_sum lifts (sum.hpp:618, :629) share this. Verified on g++ 16.1.1 and clang 22.1.6.

This is the safe direction — it costs an unnecessary EH edge rather than risking std::terminate — so
it is not urgent, but the fix is the same one this issue already calls for: make the specification
conditional (noexcept(is_nothrow_constructible_v<...>)) rather than absolute, in both directions.
Worth doing in one pass so the whole type ends up with an accurate noexcept surface.

tests/fn/sum.cpp asserts the current behaviour at each site, so these flip red when the fix lands.

[Bronek]

include/fn/choice.hpp belongs on the site list too (found while adding the noexcept dimension
to tests/fn/and_then.cpp, #85).

choice wraps sum and inherits the same unconditional promise, across every value category:

• invoke ×4 (choice.hpp:199/214/229/244)
• invoke_r ×4 (:260/:276/:292/:308)
• transform ×4 (:324/:339/:354/:369)
• and_then ×4 (:383/:396/:409/:423)

Each takes a user callback and is declared noexcept regardless of what that callback promises, so a
throwing callback terminates rather than propagating.

This one is worth calling out because of the contrast with its siblings — fn::optional and
fn::expected compute a precise conditional noexcept for and_then, and fn::choice does not:

constexpr auto throwing = [](int i) noexcept(false) -> fn::optional<int> { return {i}; };
static_assert(not noexcept(std::declval<fn::optional<int> &>().and_then(throwing)));  // correct

constexpr auto throwing_c = [](auto i) noexcept(false) -> fn::choice<int> { return {i}; };
static_assert(noexcept(std::declval<fn::choice<int> &>().and_then(throwing_c)));      // over-promises

So the same monadic operation has different exception behaviour depending on which monad it is written
against. Verified on g++ 16.1.1 and clang 22.1.6.

Same fix as the sum/pack sites this issue already lists — the dispatch legs need the #45 traits.
tests/fn/and_then.cpp asserts the current behaviour, so these flip when the fix lands.

[Bronek]

Fixed on bronek/bugfixes-for-release-1.0, together with #45 — they define each other, so they had to land as one change.

The approach. Rather than hand-writing a spec per member, the invoke chain (fn/detail/functional.hpp's _invoke_detail::invoke / invoke_r) grows the noexcept specification it was missing, and _is_nothrow_invocable / _is_nothrow_invocable_r (#45, stubbed false until now) are computed by asking it. That composes by construction: a pack answers for the call over its elements, a sum for the call over every alternative, and the recursion terminates because each step strictly reduces the number of pack/sum operands.

constexpr auto mixed = fn::overload{[](int) noexcept { return 0; }, [](bool) { return 0; }};
static_assert(not noexcept(std::declval<fn::sum<bool, int> &>().invoke(mixed)));  // one throwing alternative is enough

Both directions, as this issue asks. Over-promising: the dispatch members (invoke/invoke_r/transform, the _invoke/_transform internals), the copy/move/widening constructors, pack::append (which weighs both the element it builds and every element it relocates), and operator== (which weighs the alternatives' own comparisons). Under-promising: the value constructors and the as_sum/as_pack lifts, which carried no specifier at all —

static_assert(noexcept(fn::sum<int>{42}));                           // was noexcept(false)
static_assert(noexcept(fn::sum<int>{std::in_place_type<int>, 42}));  // was noexcept(false)

choice too (the widening in this issue's comment): it no longer over-promises where optional and expected never did, so the same monadic operation now has the same exception behaviour whichever monad it is written against.

Two traps worth recording for anyone touching this again:

1. A noexcept-specifier is an ordinary constant expression, not a requires-clause — both operands of its || must be well-formed. So operator=='s "an alternative the other side does not have is never compared, and need not even be comparable" cannot be spelled as a disjunction (not type_one_of<...> || noexcept(a == b)); it needs a guarded partial specialization, or a non-comparable alternative hard-errors. Caught by the existing tests, on both compilers.
2. An explicit noexcept on a defaulted copy/move that disagrees with the implicit specification makes it deleted ([dcl.fct.def.default]). choice's = default copy/move had to drop theirs once sum's became conditional.

Knock-on, as predicted in #276: the graded lifts (sum_value/sum_error) now report noexcept(true) for trivial types, because sum's value constructor finally has a spec to derive from. Their tests flipped with this commit.

Tests: tests/fn/sum.cpp, tests/fn/pack.cpp and tests/fn/choice.cpp gain the noexcept dimension (constructors, dispatch, comparison, append/relocation), and tests/fn/detail/functional.cpp's traits tests no longer pin the stub — they assert composition through pack and sum dispatch. Green on g++ 16.1.1 and clang 22.1.6, 39/39 both.

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