关于std::reverse_iterator模板拷贝构造函数的两个技术疑问

首先明确cppreference列出的目标构造函数：

template< class U >
constexpr reverse_iterator( const reverse_iterator<U>& other );

该构造函数参与重载决议的条件为：U与Iter类型不同，且std::convertible_to<const U&, Iter>成立（C++20起）。

疑问1：为何要求U与Iter类型不同？难道同底层迭代器类型的reverse_iterator无法拷贝构造？ #

• 同类型的reverse_iterator完全可以正常拷贝构造，只是不会用到这个模板构造函数。编译器会自动为reverse_iterator<Iter>生成默认的拷贝构造函数，这个默认构造的优先级高于模板构造，专门负责处理同类型的拷贝场景。
• 要求U≠Iter是为了避免重载歧义。如果不排除U=Iter的情况，这个模板构造会成为同类型拷贝的候选函数，和默认拷贝构造的优先级相同，可能导致编译时的歧义问题。通过SFINAE规则过滤掉U=Iter的情况，就能让默认拷贝构造处理同类型拷贝，模板构造只负责不同底层迭代器类型的转换场景。

疑问2：为何使用std::convertible_to<const U&, Iter>而非std::convertible_to<U, Iter>来检查兼容性？ #

• 这个条件完全匹配构造函数的实际行为：构造时会获取other.base()，也就是一个const U&类型的底层迭代器，再将其转换为Iter类型。用const U&作为源类型，能覆盖更多合法的迭代器转换场景：
  • 比如当U是非const迭代器、Iter是const迭代器时，const U&可以隐式转换为Iter（const引用可绑定到非const对象，且非const迭代器转const迭代器是合法操作）；如果换成std::convertible_to<U, Iter>，虽然多数场景也成立，但前者更贴合实际的参数传递方式，避免了不必要的临时对象拷贝。
  • 部分迭代器的转换依赖const修饰，const U&的检查能准确确保构造函数内的转换操作合法，不会遗漏那些只能通过const引用完成的转换场景。

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