範囲のモナド結合を実装する同様の関数は知りませんが、C++20 の some_range | std::ranges::views::transform(f) | std::ranges::views::join は本質的に のモナド束縛です some_range と f.

ranges::views::for_each 範囲のモナドバインド (読んだ）、そして私はそれを好む views::transform | views::join range-v3 の (過去の?) 複雑さ/入力の問題が原因です。

Functor と Monad のジェネリック インターフェイスを取得するかどうかについて。 そのような汎用性がテンプレートを作成するライブラリ作成者にとって有用でない限り、私はそれを疑っています。 std::expiremental::future もモナドです（そして、エグゼキュータもそうであると思います）ので、次のような一般的なアルゴリズムを書くことができます foldM この 3 つのタイプについて説明します。 Erik Niebler が range-v3 で、すべてのパイプ演算子を手作業でコーディングすることを犠牲にして Functor/Monad ライブラリを作成できることを示したと思います。

#include <fp_extremist.hpp>
template <typename M> requires Monad<M>
auto func(M m)
{
    return m
        | fp::extremist::fmap([](auto a) { return ...; })
        | fp::extremist::mbind([](auto b) { return ...; })
        ;
}

私が実際に可能だと思うのは、UFCS と |> 演算子を使用して、次の利点を得ることができます invocable |> east 構文とアルゴリズムにパイプする機能。 から バリーのブログ:

範囲アダプターはパイプ可能ですが、アルゴリズムはそうでないため、機能しません。 …

つまり、x |> f は以前と同様に f(x) として評価されますが、x |> f(y) は f(x, y) として評価されます。

PS c++ で Functor の定義を与えることは難しくありません。 <typename T> struct 提供する transform.

PSS
編集: applicative の扱い方に気づきました。

Applicative<int> a, b, c;
auto out = a
    | zip_transform(b, c
        , [](int a, int b, int c){ return a + b + c; })
    ;

zip_transform ジッパー付きだから a、 b、 c に Applicative<std::tuple<int, int, int>> そしてそれを変換します（考えてください optional、 future、 range）。 部分的に適用された関数の Applicative をいつでも使用できますが、それには C++ のスタイルではない多数のネストされた関数が含まれ、上から下への読み取り順序が乱れます。