Summary — Expose the library's type-indexed (type-matching) monadic dispatch on fn::sum/fn::choice as public API. It already exists internally — sum::_invoke<Ret>, sum::_transform, choice::_invoke (ref-qualified overloads), on detail::invoke_type_variadic_union — but the members are _-prefixed, undocumented, and used in no example. It's useful functionality, lets expose it to the users.
Motivation — The public value-path verbs (invoke, transform, and_then) hand each arm the alternative's value, so selection is subject to implicit conversions: fn::sum<double,int> with a lone [](double) arm silently absorbs the int alternative, and dropping an arm need not fail to compile. The value path is exhaustive for non-interconvertible alternatives (e.g. distinct enums), but there's no public way to get that guarantee for interconvertible ones. The type-indexed path provides it: each arm gets a std::in_place_type_t<T> tag, which never interconverts, so arms match by exact alternative type and a missing arm is a compile error.
Proposal — Design + expose the whole family (not just _transform): type-indexed counterparts of invoke/invoke_r/transform on sum and invoke/and_then on choice, ref-qualifier-complete and constexpr. Open: tagged-handler overloads of existing verbs vs. a distinct *_type family.
NOTE This will require preventing the index type from being put in a fn::pack. Currently the index type is std::in_place_type , which is explicitly disallowed in fn::sum, and not well supported in fn::pack (used as discriminator in pack::append()). We may also consider replacing std::in_place_type with a new, purpose made type e.g. fn::type_index .
Summary — Expose the library's type-indexed (type-matching) monadic dispatch on
fn::sum/fn::choiceas public API. It already exists internally —sum::_invoke<Ret>,sum::_transform,choice::_invoke(ref-qualified overloads), ondetail::invoke_type_variadic_union— but the members are _-prefixed, undocumented, and used in no example. It's useful functionality, lets expose it to the users.Motivation — The public value-path verbs (
invoke,transform,and_then) hand each arm the alternative's value, so selection is subject to implicit conversions:fn::sum<double,int>with a lone[](double)arm silently absorbs theintalternative, and dropping an arm need not fail to compile. The value path is exhaustive for non-interconvertible alternatives (e.g. distinct enums), but there's no public way to get that guarantee for interconvertible ones. The type-indexed path provides it: each arm gets astd::in_place_type_t<T>tag, which never interconverts, so arms match by exact alternative type and a missing arm is a compile error.Proposal — Design + expose the whole family (not just
_transform): type-indexed counterparts ofinvoke/invoke_r/transformonsumandinvoke/and_thenonchoice, ref-qualifier-complete andconstexpr. Open: tagged-handler overloads of existing verbs vs. a distinct *_type family.NOTE This will require preventing the index type from being put in a
fn::pack. Currently the index type isstd::in_place_type, which is explicitly disallowed infn::sum, and not well supported infn::pack(used as discriminator inpack::append()). We may also consider replacingstd::in_place_typewith a new, purpose made type e.g.fn::type_index.