[libcxx-commits] [PATCH] D113417: [libcxx] Fix enable_if condition of std::reverse_iterator::operator=

Mikhail Maltsev via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Thu Nov 11 10:39:05 PST 2021


miyuki marked an inline comment as done.
miyuki added inline comments.


================
Comment at: libcxx/include/__iterator/reverse_iterator.h:114
         is_convertible<_Up const&, _Iter>::value &&
-        is_assignable<_Up const&, _Iter>::value
+        is_assignable<_Iter, _Up const&>::value
     > >
----------------
ldionne wrote:
> Quuxplusone wrote:
> > C++17 actually doesn't constrain this `operator=` at all
> > https://timsong-cpp.github.io/cppwp/n4659/reverse.iter.op=
> > but C++20 added constraints
> > https://cplusplus.github.io/LWG/issue3435
> > which @ldionne added (in all modes) in e4d3a993c2675f46cbe99acd1bf6e6d39d9c1aee.
> > I believe we should make this constraint apply only in C++20, and follow the Standard's subtly different spec: `convertible_to, assignable_from` instead of `is_convertible, is_assignable`.
> > 
> > Scope creep: Any appetite for adding `operator<=>` at the same time, so that we could actually verify that `three_way_comparable_with<reverse_iterator<int*>, reverse_iterator<const int*>>` will be true after this patch? (I believe the only actually missing puzzle piece is `operator<=>`.)
> I added it in all modes because it's a LWG issue, not only a paper. I think that is what we want to do, however you are right we can't implement it exactly per the spec if we backport it to before C++20 (because we don't have concepts then).
> Scope creep: Any appetite for adding operator<=>

Submitted as a separate patch: D113695


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113417



More information about the libcxx-commits mailing list