为何C++20未为<numeric>头文件中的数值算法提供范围版本？

这个问题在C++标准委员会的讨论中被反复提及，背后主要有这么几个核心原因：

• 优先级与资源分配
  C++20是个重量级版本，要推进的核心特性太多了——概念（Concepts）、范围库（Ranges）、协程（Coroutines）、模块（Modules）...每一个都需要大量的设计和实现精力。范围库的初期目标是先覆盖最常用的通用算法（比如排序、遍历、查找类），而里的部分算法使用频率相对较低，自然就被排在了后续迭代的优先级里。

• 设计复杂度的挑战
  有些数值算法的范围版本设计起来比普通算法棘手得多。比如std::inner_product、std::partial_sum这类算法，需要同时处理输入范围、输出范围，还要考虑数值运算的兼容性（比如不同数值类型的隐式转换、运算的结合律要求）。范围库的概念体系（比如input_range、output_range）和传统迭代器模型的适配，需要仔细推敲，避免引入歧义或者破坏现有代码的兼容性。如果仓促推出，很可能留下设计缺陷，后续难以修正。

• 约束版本的渐进式完善
  其实C++20的范围算法本身就是基于概念的约束版本，但对于里的部分算法，要定义合适的概念约束并不容易。比如有些算法要求数值类型满足特定的运算性质（如可加性、可乘性），这些需要配套的概念来描述，但委员会当时更倾向于先把基础概念体系稳定下来，再逐步为数值算法补充精准的约束，避免概念体系过于臃肿。

值得一提的是，C++23已经填补了不少这方面的空白——比如新增了std::ranges::inner_product、std::ranges::partial_sum、std::ranges::adjacent_difference等范围版本的数值算法，这说明这部分功能不是被遗忘了，而是标准制定过程中分阶段推进的结果。

总的来说，这是C++标准迭代中“先满足核心需求，再逐步打磨边缘场景”的典型案例，毕竟要平衡功能完整性、实现成本、兼容性等多个维度，不可能一步到位。

内容的提问来源于stack exchange，提问作者康桓瑋