为什么 C++20 范围库有自己的命名空间？
Why does the C++20 range library have its own namespace?
为什么 std::range::sort（以及其他基于范围的算法）在 range 命名空间中实现？为什么不将其定义为 std::sort 取范围的重载？
这是为了避免破坏现有的代码库。 Eric Niebler、Sean Parent 和 Andrew Sutton 在他们的设计论文中讨论了不同的方法 D4128。
3.3.6 Algorithm Return Types are Changed to Accommodate Sentinels
... In similar fashion, most algorithm get new return types when they
are generalized to support sentinels. This is a source-breaking change
in many cases. In some cases, like for_each, the change is unlikely to
be very disruptive. In other cases it may be more so. Merely accepting
the breakage is clearly not acceptable. We can imagine three ways to
mitigate the problem:
Only change the return type when the types of the iterator and the sentinel differ. This leads to a slightly more complicated interface
that may confuse users. It also greatly complicates generic code,
which would need metaprogramming logic just to use the result of
calling some algorithms. For this reason, this possibility is not
explored here.
Make the new return type of the algorithms implicitly convertible to the old return type. Consider copy, which currently returns the
ending position of the output iterator. When changed to accommodate
sentinels, the return type would be changed to something like pair<I, O>; that is, a pair of the input and output iterators. Instead of
returning a pair, we could return a kind of pair that is implicitly
convertible to its second argument. This avoids breakage in some, but
not all, scenarios. This subterfuge is unlikely to go completely
unnoticed.
Deliver the new standard library in a separate namespace that users must opt into. In that case, no code is broken until the user
explicitly ports their code. The user would have to accommodate the
changed return types then. An automated upgrade tool similar to clang
modernize can greatly help here.
We, the authors, prefer (3).
最终，它对使用支持 C++20 的编译器进行构建的现有代码库的破坏最小。这是他们自己喜欢的方法，似乎其余的都已成为历史。
为什么 std::range::sort（以及其他基于范围的算法）在 range 命名空间中实现？为什么不将其定义为 std::sort 取范围的重载？
这是为了避免破坏现有的代码库。 Eric Niebler、Sean Parent 和 Andrew Sutton 在他们的设计论文中讨论了不同的方法 D4128。
3.3.6 Algorithm Return Types are Changed to Accommodate Sentinels
... In similar fashion, most algorithm get new return types when they are generalized to support sentinels. This is a source-breaking change in many cases. In some cases, like
for_each, the change is unlikely to be very disruptive. In other cases it may be more so. Merely accepting the breakage is clearly not acceptable. We can imagine three ways to mitigate the problem:
Only change the return type when the types of the iterator and the sentinel differ. This leads to a slightly more complicated interface that may confuse users. It also greatly complicates generic code, which would need metaprogramming logic just to use the result of calling some algorithms. For this reason, this possibility is not explored here.
Make the new return type of the algorithms implicitly convertible to the old return type. Consider
copy, which currently returns the ending position of the output iterator. When changed to accommodate sentinels, the return type would be changed to something likepair<I, O>;that is, a pair of the input and output iterators. Instead of returning apair, we could return a kind of pair that is implicitly convertible to its second argument. This avoids breakage in some, but not all, scenarios. This subterfuge is unlikely to go completely unnoticed.Deliver the new standard library in a separate namespace that users must opt into. In that case, no code is broken until the user explicitly ports their code. The user would have to accommodate the changed return types then. An automated upgrade tool similar to clang modernize can greatly help here.
We, the authors, prefer (3).
最终，它对使用支持 C++20 的编译器进行构建的现有代码库的破坏最小。这是他们自己喜欢的方法，似乎其余的都已成为历史。