[libcxx-commits] [PATCH] D136268: [libc++][ranges] implement `std::views::elements_view`

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added inline comments.


================
Comment at: libcxx/include/__tuple/tuple_like.h:29-33
+template <class _Tp, class = void> struct __tuple_like : false_type {};
 
-template <class _Tp> struct __tuple_like<const _Tp> : public __tuple_like<_Tp> {};
-template <class _Tp> struct __tuple_like<volatile _Tp> : public __tuple_like<_Tp> {};
-template <class _Tp> struct __tuple_like<const volatile _Tp> : public __tuple_like<_Tp> {};
+template <class _Tp>
+struct __tuple_like<_Tp, __enable_if_t<!is_same<_Tp, __remove_cvref_t<_Tp> >::value> >
+  : public __tuple_like<__remove_cvref_t<_Tp> > {};
----------------
Here we seem to be conflating two things:

1. This old `__tuple_like` extension that I've been trying to get rid of (and did get rid of in `std::tuple`), and
2. The new //tuple-like// exposition-only concept that was introduced recently and was retrofitted into `std::pair`.

I would prefer if we introduced (2) without touching (1), so that we can proceed to the cleanup of (1) and related machinery like `__tuple_convertible` & friends separately.

It'll end up being nearly equivalent, but what I would do instead is introduce the new tuple-like and pair-like C++20 concepts separately and give them a name like `__cpp20_tuple_like`. We can then clean up the mess inside `<pair>`, remove the non-standard extension pre-C++20 and finally rename `__cpp20_tuple_like` and `__cpp20_pair_like` to `__tuple_like` and `__pair_like` once that's done.

That way, this patch will be completely orthogonal to touching `pair`, which I think is a good thing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136268/new/

https://reviews.llvm.org/D136268