[Bug libstdc++/106610] elements_view::iterator::iterator_category invokes the operator*() && of the underlying iterator

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106610

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|FIXED   |INVALID

[Bug libstdc++/106610] elements_view::iterator::iterator_category invokes the operator*() && of the underlying iterator

[tkaminsk at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106610

Tomasz Kamiński  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Tomasz Kamiński  ---
I believe the standard makes us conforming, and we should not bend to support
such use-cases.

[Bug libstdc++/106610] elements_view::iterator::iterator_category invokes the operator*() && of the underlying iterator

[tkaminsk at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106610

Tomasz Kamiński  changed:

   What|Removed |Added

 CC||tkaminsk at gcc dot gnu.org

--- Comment #2 from Tomasz Kamiński  ---
Yes, I believe the intent of [concepts.equality] p6 was exactly to not require
the implementation to care about invoking operator on mutable rvalue/lvalue, if
stratification of the concept checks specifies only const lvalue calls.

[Bug libstdc++/106610] elements_view::iterator::iterator_category invokes the operator*() && of the underlying iterator

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106610

--- Comment #1 from Jonathan Wakely  ---
Isn't this invalid because of [concepts.equality] p6?

The indirectly_readable concept requires that *it works on a const lvalue,
which means it has to behave the same on lvalues and rvalues or the same type,
const and non-const.