[libcxx-commits] [PATCH] D103335: [libcxx][ranges] Adds `common_iterator`.

Zoe Carver via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Jul 14 11:19:26 PDT 2021


zoecarver added inline comments.


================
Comment at: libcxx/include/__iterator/common_iterator.h:40
+    constexpr __proxy(iter_reference_t<_Iter>&& __x)
+      : __value(_VSTD::move(__x)) {}
+
----------------
Add a comment: "iter_reference_t" is never a reference here because if it is we catch it in the if constexpr branch above where this one is called.




================
Comment at: libcxx/include/__iterator/common_iterator.h:107
+  {
+    _LIBCPP_ASSERT(holds_alternative<_Iter>(__hold_), "Preconditions violated.");
+    return *__unchecked_get<_Iter>(__hold_);
----------------
This should say something like "common_iterator not holding an iterator (holding a sentinel) must hold iterator."




================
Comment at: libcxx/include/__iterator/common_iterator.h:169
+
+    if (__x_index == __y_index)
+      return true;
----------------
ldionne wrote:
> How is this behavior really what we want? IIUC, that means that if you compare two `common_iterators` that both contain different iterators (say `It1` and `It2`) that are not comparable to each other, the `common_iterator`s will compare equal to each other even if `It1` and `It2` are "pointing" to entirely different elements. Am I misunderstanding something here, or that's an incredibly subtle (and broken) behavior to have at runtime? @tcanens Can you shed some light on this?
> 
> In all cases, we need a test where we exercise that.
We should assert these aren't both zero, even though it's non-conforming, people will thank us.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103335



More information about the libcxx-commits mailing list