为何C++ ranges的remove_*系列算法会移动首个迭代器？

问题背景 #

阅读MSVC STL中std::ranges::remove的实现时，看到如下代码：

_First = _RANGES _Find_if_unchecked(_STD move(_First), _Last, _Pred, _Proj);

cppreference的“可能实现”中也有类似代码：

first = ranges::find_if(std::move(first), last, pred, proj);

这里的困惑点在于：几乎很少见到移动迭代器的写法，毕竟迭代器通常复制成本很低；就算要优化复制，似乎也可以用万能引用配合std::forward传递迭代器？那相较于直接按值传递，把迭代器转为右值引用有什么优势？

解答 #

• 适配高拷贝成本的迭代器：虽然大多数标准迭代器（比如指针、vector迭代器）拷贝成本可以忽略，但自定义迭代器可能持有动态资源（比如带内部缓冲区的迭代器、绑定了智能指针的迭代器），移动这类迭代器能避免不必要的资源拷贝，大幅降低开销。
• 无风险的优化：对迭代器使用std::move时，如果该迭代器类型支持移动语义，就会触发移动构造/赋值，节省成本；如果不支持，std::move会退化为普通的左值传递，调用拷贝构造，不会引入任何额外问题，属于“不赚不亏”的优化。
• 局部变量的所有权转移：在std::ranges::remove的语境里，first是函数内部的局部变量（或已经绑定到参数的变量），并非转发引用参数。此时用std::move把它的所有权转移给find_if，find_if返回新的迭代器后再赋值回first，相当于直接接管迭代器状态，避免了一次多余的拷贝操作——如果直接传递左值，find_if会先拷贝一份迭代器，而移动则跳过了这次拷贝。
• 标准库的通用设计思路：标准库需要兼容所有符合要求的迭代器类型，不能假设所有迭代器都是轻量拷贝的。使用std::move是一种通用优化策略，在不破坏正确性的前提下，给所有可能的迭代器类型提供最优的处理路径。

内容的提问来源于stack exchange，提问作者DividedByZero