std::some-namespace::transform 有一天可以支持任何函子吗？

std::transform来自<algorithm> header适用于范围，它“使”我们能够使用范围作为它们的函子（从范畴论的意义上来说(¹)). std::transform是基于迭代器的，是的，但是std::ranges::views::transform不是，它的签名与函数语言中相应函数的签名非常匹配（对两个参数的不同顺序取模，但这没什么大不了的）。

当我看到这个问题（并且在这个过程中回答它），我了解到C++23引入了std::optional<T>::transform，这使得std::optional也是一个函子。

所有这些消息确实让我兴奋，但我不禁想到函子是通用的，如果有一个统一的接口就好了transform任何函子，例如 Haskell 中的情况。

这让我认为一个类似于std::ranges::views::transform（使用不同的名称并不是暗示ranges）可以做成定制点STL 不仅可以针对范围进行定制，还可以针对std::optional对于 STL 中的任何其他仿函数，而程序员可以为其用户定义的类自定义它。

类似地，C++23 也引入了std::optional<T>::and_then，这基本上是一元绑定std::optional。我不知道有任何类似的函数可以实现范围的单子绑定，但是 C++20 的some_range | std::ranges::views::transform(f) | std::ranges::views::join本质上是一元绑定some_range with f.

这让我觉得可能有一些通用接口，命名它mbind，可以选择任何类型。 STL 将选择加入std::optional通过实施它std::optional<T>::and_then， 例如。

该语言是否有机会或有计划有一天支持这种通用性？

I can certainly see some problems. Today std::ranges::views::transform(some_optional, some_func) is invalid, so some code might be relying on that via SFINAE. Making it suddenly work would break the code. No quite, breaking code that relies on SFINAE-based detection of invalid code is ok.

(1) 关于这个词functor，我指的是范畴论中给出的定义（另见this），而不是“具有以下特征的类的对象”的概念operator()定义”；后者在标准中没有定义甚至没有提到参考参数，它使用术语函数对象参考

可以在函数调用运算符左侧使用的对象

这让我觉得可能有一些通用接口，命名它mbind，可以选择任何类型。 ...

该语言是否有机会或有任何计划 天支持这样的通用性吗？

有P0650它提出了一个非成员一元接口，可以使用特征进行定制。该论文显示了定制expected和其他类型，可在 C++17 中实现。

已接受的提案std::optional单元操作P0798 §13.1在讨论成员函数语法的替代方案时参考 P0650：

不幸的是，如果没有某种 Haskell 风格，按照当前的提案进行上述的组合将会非常冗长do符号

std::optional<int> get_cute_cat(const image& img) {    
   return functor::map(
       functor::map(
         monad::bind(
           monad::bind(crop_to_cat(img),
             add_bow_tie),
           make_eyes_sparkle),
        make_smaller),
     add_rainbow);
 }

我的建议不一定是[P0650]的替代方案；可以确保两者之间的兼容性，并且通用提案可以使用我的提案作为其实施的一部分。

它还提到仍在开发中的其他 C++ 功能（例如统一调用语法）如何为通用一元操作提供更简洁的语法。

已接受的提案std::expected单元操作P2505没有直接引用 P0650，而是讨论“自由函数与成员函数”作为其设计考虑的一部分，最终优先考虑与std::optional一元接口。