[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