Reach the uninhabited value side, split the folds, and compare packs

[Bronek]

Closes #380 — the issue's six items, one commit each (plus the merge of #382 and this CHANGELOG entry).

The uninhabited value side

An optional<copack<>> is never engaged and an expected<copack<>, E> always holds its error. Their members have been the identity there since the empty-sum doctrine — the mapping returns *this, and the callback is neither invoked nor instantiated — but the verbs answered false, so a pipeline could not reach what the member could:

verb	member	pipe, before	pipe, after
transform, and_then	identity	❌	✅ delegates to the vacuous member
inspect, filter, fail	(none)	❌	✅ operand passes through
discard	(none)	✅	✅

Two concepts name the operand class — some_empty_value, and its mirror some_empty_error (the identity expected and only it, which some_identity now spells as its third alternative). Both are well-formed for any type, answering false: the carrier test short-circuits before the value or error type is named. Pinned in concepts.cpp against void, int[], void(), a member pointer, an incomplete type — each asserted through a negated template concept, so a poisoned atomic constraint would hard-error rather than pass.

applicable_transform and friends keep answering false for these operands, deliberately: a vacuous operation consults no callback, so no callback is applicable to it. What applies is the verb, which is what monadic_invocable answers — the constraint operator| itself carries. Both concepts now document that split; it was previously discoverable only by reading the constraint.

The refusal in the identity cluster stands and is not in tension: there filter/fail cannot do their work, a rejection having nowhere to go. Over an uninhabited value side the error channel is live and the operand is in it already, so those verbs are dead code — which the type system proves.

The rest

• value_or admits a void value side. value_or() substitutes the empty value, so a failed expected<void, E> comes back engaged; any argument makes the call non-viable, there being nothing to build the empty value from. Its sibling recover has always served void expecteds, so the exclusion was an arity accident rather than a decision.
• expected_unit names expected<void, copack<>>, the family's unit.
• conjoin and disjoin each take one world. A carrier among conjoin's arguments used to become a pack element — packing the carriers rather than conjoining what they carry, and reaching their values would need value(), which throws. The data fold now refuses carriers, and a second arm folds operator& over carriers instead; a mixed list matches nothing rather than being resolved by its leading argument. disjoin is carriers-only in every arity, where it previously reached the built-in operator| and folded two integers into 3.
• pack compares element by element, <=> lexicographically. Defaulting would have deleted the comparisons for a reference element — and a pack of references is what as_pack builds from lvalues — so the folds are written out and compare referents, the semantics of fn::optional<T&> and std::tuple, whose assignment is the pointer-like operation, not their comparison. Every element decides; one that cannot be compared leaves the operator non-viable rather than ill-formed. No ordering is synthesized from <. Neither constexpr nor an exception specification is spelled, both being computed — spelling either is a hard error for an element whose own comparison does not match. A copack over packs becomes comparable as a consequence.

Behaviour changes worth knowing

conjoin(a, b) over two carriers stops producing pack<carrier, carrier> and starts folding the carrier &; disjoin(1, 2) stops compiling. Both were the point of the issue, and neither had an in-tree caller.

Verification

Six-config gate (gcc/clang × Debug/Release/validate) green, C++26 mode green (86/86), MSVC 17 green, dev 43/43.

🤖 Generated with Claude Code

https://claude.ai/code/session_0198ikYYxtCqwNG54SS1b249

[augmentcode]

🤖 Augment PR Summary

Summary: This PR expands libfn’s monadic verb layer to correctly handle carriers whose value side is uninhabited (notably optional<copack<>> and expected<copack<>, E>), aligns pipeline applicability with the already-vacuous member semantics, and adds explicit element-wise comparison for fn::pack.

Changes:

• Adds some_empty_value / some_empty_error concepts and updates some_identity to use the new naming.
• Makes value-side verbs (transform, and_then, inspect, filter, fail) accept uninhabited-value carriers by passing through / delegating without instantiating callbacks.
• Extends value_or to support expected<void, E> (only the zero-argument form is viable) and introduces expected_unit = expected<void, copack<>>.
• Splits the n-ary folds: conjoin now separates “data fold” vs “carrier fold” and refuses mixed lists; disjoin becomes carriers-only in every arity.
• Implements fn::pack == and <=> explicitly to compare referents for reference elements and to keep non-comparable elements from hard-erroring.
• Adds targeted tests covering vacuous-callback behavior, noexcept/constexpr expectations, fold refusal rules, and pack comparisons.

Technical Notes: The PR clarifies the split between per-verb applicable_* (callback applicability) and monadic_invocable (pipeline/verb applicability), and uses constrained helper folds in pack_impl so “asking answers” (non-viable) instead of failing during instantiation.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 1 suggestion posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

_compare()’s type can become void (e.g., if an element’s <=> returns a non-category type, or the element result types have no common comparison category), and then pack::operator<=> can look viable to a requires-probe but hard-error when instantiated. That seems at odds with the stated goal that “asking answers rather than erroring”; consider making the “no common category” case fail the constraint instead of failing in the body.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[Bronek]

Resolved in b66c477

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Bronek]

augment review

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
93.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[augmentcode]

Review completed. No suggestions at this time.

Comment augment review to trigger a new review at any time.