[libcxx-commits] [PATCH] D101079: [libcxx][ranges] Add ranges::size CPO.

[Zoe Carver via Phabricator via libcxx-commits]

zoecarver added inline comments.


================
Comment at: libcxx/include/__ranges/size.h:58
+concept __member_size = __size_enabled<_Tp> && requires(_Tp&& __t) {
+  { _VSTD::__decay_copy(_VSTD::forward<_Tp>(__t).size()) } -> integral;
+};
----------------
cjdb wrote:
> ldionne wrote:
> > I think we need to introduce a proper concept for integer-like types:
> > 
> > 
> > ```
> > template <typename _Ip>
> > concept __integer_like = !same_as<bool, _Ip> && integral<_Ip>;
> > ```
> > 
> > According to the Standard:
> > 
> > > A type `I` other than `cv bool` is integer-like if it models `integral<I>` or if it is an integer-class type.
> > 
> > That would also be an indirection point where we can add our own implementation-defined integer-class type if we have one.
> > 
> > Right now, my understanding is that this concept would be satisfied if `t.size()` returned a `bool`. Instead, we should use `-> __integer_like` so that `bool` is excluded. Can you confirm that it's a problem and add a test that fails when that's the case?
> > 
> > This comment applies to other uses of `integral` below (and so we should add tests for those too).
> Yes, but it looks like I can do this in D100080. Nice catch! http://eel.is/c++draft/iterators#iterator.concept.winc-11
@cjdb I agree. It would be great if you could implement `__integer_like` as Louis described and then implement `__is_signed_integer_like` in terms of that. Once `__integer_like` exists I'll update this patch to use it. 


================
Comment at: libcxx/include/__ranges/size.h:81-89
+  template <class _Tp, size_t _Sz>
+  [[nodiscard]] constexpr size_t operator()(_Tp (&&)[_Sz]) const noexcept {
+    return _Sz;
+  }
+
+  template <class _Tp, size_t _Sz>
+  [[nodiscard]] constexpr size_t operator()(_Tp (&)[_Sz]) const noexcept {
----------------
ldionne wrote:
> Just thinking out loud, but this works if you pass a reference to a const array because it'll deduce `_Tp = Foo const` such that the whole signature is `Foo const (&)[_Sz]`?
Yes. Added a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101079