Constrain relocating functors to require move-constructible value/error

[Bronek]

Problem

A functor that returns a fresh monad by value must relocate whatever it carries through, so the carried side must be move-constructible. The invocable_* concepts don't require this, so an immovable value/error type satisfies the concept and then hard-errors deep in the body (e.g. an or_else substitution failure) instead of cleanly SFINAE-rejecting.

Surfaced while adding value_or tests: fn::expected<Immovable, E> | value_or(args...) reports as invocable, then fails to compile.

Affected functors (verbs)

Functor	Relocates	Needs movable
value_or	existing value (success branch)	value
recover	existing value (success branch)	value
fail	existing error (error branch)	error
filter	whole monad via return FWD(v)	value + error

and_then / transform / or_else / transform_error delegate to the expected member and likely reject transitively (to confirm). inspect / inspect_error return V&& (no relocation) and discard returns void — none needed.

Proposal

Add an explicit movability requirement to the relevant invocable_* concepts so immovable types are SFINAE-rejected, plus negative invocability tests documenting the boundary.

Open question: simple std::is_move_constructible_v<T> vs. a value-category-precise std::is_constructible_v<T, decltype(carried)>.

Assisted-by: Claude:claude-opus-4-8

[Bronek]

Fixed on bronek/bugfixes-for-release-1.0 (commit cbfa667). The four verbs now drop the candidate instead of hard-erroring:

using E = fn::expected<helper_immovable, Error>;
static_assert(std::is_constructible_v<E, std::in_place_t, int>);        // it can be BUILT ...
static_assert(monadic_static_check<value_or_t, E>::not_invocable_with_any(1)); // ... but never CARRIED

The analysis in the description held; the open question resolves against is_move_constructible_v. The body relocates in whatever value category the operand is piped in — an lvalue is copied, an rvalue moved — so a move-only value piped as an lvalue must be rejected, and is_move_constructible_v would accept it:

using is = monadic_static_check<value_or_t, fn::expected<helper_move_only, Error>>;
static_assert(is::invocable<rvalue, prvalue>(1));      // moved
static_assert(is::invocable<crvalue, cvalue>(1));      // const-moved (the helper has a const&& ctor)
static_assert(is::not_invocable<lvalue, clvalue>(1));  // would have to copy: rejected

So the traits ask is_constructible_v<T, decltype(carried)> — the value-category-precise question — which is also exactly what each verb's noexcept spec already weighs. One asks "can it", the other "can it throw". They are _relocatable_value / _relocatable_error / _relocatable (the last for filter's return FWD(v), which takes the whole monad and hence both sides).

The table needed one correction: fail on an optional relocates nothing (it discards the value and returns nullopt), and recover on expected<void, E> has no value to carry — so neither is constrained.

A second trigger for the same lie, found while testing this (fixed here on Bronek's call, since it is one conjunct away in the same concepts). An optional<T&> binds its referent rather than carrying it, and its value_type is the referent — so is_constructible_v<value_type, Args...> said yes to fn::optional<int&> | fn::value_or(1), and the body then could not bind int& to the prvalue fallback: a hard error from inside a deduced-return body, not even SFINAE-detectable. The fallback builds the result, so that is what the concept now asks. An lvalue fallback still works, and an immovable referent stays pipeable — nothing is relocated through a reference:

static_assert(std::is_constructible_v<fn::optional<int &>::value_type, int>); // the referent, happily
static_assert(not fn::invocable_value_or<fn::optional<int &> &, int>);        // but nothing to bind to
static_assert(fn::invocable_value_or<fn::optional<int &> &, int &>);
static_assert(fn::invocable_value_or<fn::optional<helper_immovable &> &, helper_immovable &>);

recover had the identical shape (its concept asked convertible_to<value_type>, then the body built type{in_place, invoke(fn)}).

Tests: a constraints TEST_CASE in each of tests/fn/{value_or,recover,fail,filter}.cpp, using the existing helper_immovable / helper_move_only fixtures and monadic_static_check's value categories, so the boundary is documented per category rather than as a single yes/no. Green on g++ 16.1.1 and clang 22.1.6, 39/39 both.

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