[libcxx-commits] [PATCH] D115312: [libc++] [ranges] Simplify and fix a bug in ranges::empty.

[Arthur O'Dwyer via Phabricator via libcxx-commits]

Quuxplusone added a subscriber: tcanens.
Quuxplusone added inline comments.


================
Comment at: libcxx/include/__ranges/empty.h:46-52
+    template <class _Tp>
+    _LIBCPP_HIDE_FROM_ABI
+    static constexpr auto __go(_Tp&& __t, __priority_tag<0>)
+      noexcept(noexcept(bool(ranges::begin(__t) == ranges::end(__t))))
+      -> decltype(      bool(ranges::begin(__t) == ranges::end(__t)))
+      requires forward_iterator<decltype(ranges::begin(__t))>
+      { return          bool(ranges::begin(__t) == ranges::end(__t)); }
----------------
Note the sneaky `requires`-clause hiding in among the "write it three times" business.
I'd be willing to pull this out into a helper concept, e.g.
```
template<class _Tp>
concept __forward_iterable =
  forward_iterator<decltype(ranges::begin(declval<_Tp&>()))>;

template <__forward_iterable _Tp>
_LIBCPP_HIDE_FROM_ABI
static constexpr auto __go(_Tp&& __t, __priority_tag<0>)
  noexcept(noexcept(bool(ranges::begin(__t) == ranges::end(__t))))
  -> decltype(      bool(ranges::begin(__t) == ranges::end(__t)))
  { return          bool(ranges::begin(__t) == ranges::end(__t)); }
```
but I'm ambivalent on whether that's better.
I'm also unclear on how to observe the difference between this constraint and a simple `forward_range<_Tp&>`. @tcanens perhaps?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115312