为什么C ++ 20范围库具有自己的名称空间？

如何解决为什么C ++ 20范围库具有自己的名称空间？

为什么在std::range::sort名称空间中实现range（以及其他基于范围的算法）？为什么不将其定义为std::sort的重载，取一个范围？

解决方法

这是为了避免破坏现有的代码库。 Eric Niebler，Sean Parent和Andrew Sutton在他们的设计论文D4128中讨论了不同的方法。

3.3.6算法返回类型已更改，以适应哨兵

...以类似的方式，大多数算法在获得新的返回类型时 普遍支持哨兵。这是一个突破性的变化 在很多情况下。在某些情况下，例如for_each，更改不太可能 非常具有破坏性。在其他情况下可能更是如此。仅仅接受 破损显然是不可接受的。我们可以想象三种方式 缓解问题：

1. 仅当迭代器和标记的类型不同时才更改返回类型。这导致界面稍微复杂一些 这可能会使用户感到困惑。它还使通用代码非常复杂， 仅使用元程序的结果就需要元编程逻辑 调用一些算法。因此，这种可能性不是 在这里探索。

2. 使算法的新返回类型隐式转换为旧的返回类型。考虑copy，它当前返回 输出迭代器的结束位置。更改以适应 标记，返回类型将更改为pair<I,O>;，即一对输入和输出迭代器。代替 返回pair，我们可以返回一种隐式对 可转换为第二个参数。这样可以避免一些破损，但是 并非所有场景。这种诡计不太可能完全消失 未被注意。

3. 在用户必须选择加入的单独命名空间中提供新的标准库。在这种情况下，直到用户都不会破坏代码 明确移植其代码。用户必须适应 然后更改返回类型。类似于clang的自动升级工具 现代化可以在这里大有帮助。

我们（作者）更喜欢（3）。

最终，它对使用C ++ 20启用的编译器进行构建的现有代码库的破坏性最小。这是他们自己喜欢的方法，似乎剩下的就是历史了。