[libcxx-commits] [libcxx] [libc++][ranges] P2387R3: Pipe support for user-defined range adaptors (PR #89148)

Louis Dionne via libcxx-commits libcxx-commits at lists.llvm.org
Mon Apr 22 07:06:09 PDT 2024


================
@@ -52,15 +54,21 @@ struct __range_adaptor_closure_t : _Fn, __range_adaptor_closure<__range_adaptor_
 _LIBCPP_CTAD_SUPPORTED_FOR_TYPE(__range_adaptor_closure_t);
 
 template <class _Tp>
-concept _RangeAdaptorClosure = derived_from<remove_cvref_t<_Tp>, __range_adaptor_closure<remove_cvref_t<_Tp>>>;
+_Tp __derived_from_range_adaptor_closure(__range_adaptor_closure<_Tp>*);
 
 template <class _Tp>
+concept _RangeAdaptorClosure = !ranges::range<remove_cvref_t<_Tp>> && requires {
+  { __derived_from_range_adaptor_closure((remove_cvref_t<_Tp>*)nullptr) } -> same_as<remove_cvref_t<_Tp>>;
+};
----------------
ldionne wrote:

Let's qualify this call as `ranges::__derived_from_range_adaptor_closure`. Also, let's add a comment explaining that we're checking that `_Tp` is derived from **exactly one** `range_adaptor_closure<...>` type.

Otherwise, it would have been more logical to write this constraint as `derived_from<_Tp, __range_adaptor_closure<_Tp>>`.

Finally, there should be a test that fails if we fail to handle this subtlety in the implementation, i.e. a test that fails if we used `derived_from<...>` here.

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


More information about the libcxx-commits mailing list