[libcxx-commits] [libcxx] [libc++] Merge the private iterator_traits aliases with their ranges versions (PR #162661)

[A. Jiang via libcxx-commits]

================
@@ -71,15 +65,9 @@ struct _ClassicAlgPolicy {};
 
 template <>
 struct _IterOps<_ClassicAlgPolicy> {
-  template <class _Iter>
-  using __value_type _LIBCPP_NODEBUG = typename iterator_traits<_Iter>::value_type;
----------------
frederick-vs-ja wrote:

I submitted [LWG4080](https://cplusplus.github.io/LWG/issue4080). Perhaps we should add some discussions to it.

> * It's unclear whether
>   > Users may specialize incrementable_traits on program-defined types[.](https://eel.is/c++draft/incrementable.traits#3.sentence-1)
>   
>   
>   is intended to override the normal requirement that specializations must be equivalent to the base template.

I think overriding was intended. The standard library contains such design for `common_iterator`, although this looks quite questionable to me. If overriding is considered harmful (as it can create inconsistent value types), I think it makes more sense to disallow some user-provided specializations (and slightly fix `common_iterator`).

> * `iterator_traits<It>::value_type` may be `It::value_type` but `indirectly_readable_traits<It>::value_type` does not exist

I'm more worried about this. There can be C++17 iterators with evil `element_type` (I initially reported this in microsoft/STL#4436) which make them not C++20 iterators. If we use `__iter_value_t` like MSVC STL's current approach, some code using legacy algorithms can be accepted in C++17 but rejected in C++20.

https://github.com/llvm/llvm-project/pull/162661