[Bug libstdc++/115514] New: Nonconforming reverse_iterator::operator->

[Bug libstdc++/115514] New: Nonconforming reverse_iterator::operator->

[frankhb1989 at gmail dot com]

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

            Bug ID: 115514
           Summary: Nonconforming reverse_iterator::operator->
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

The last comment in LWG 1052 says "the wording in [reverse.iter.elem] (of
P0896R4) for operator-> is equivalent to the PR for LWG 1052"; unfortunately
this is not true. The adopted wording in P0896R4 uses `prev` which returns a
prvalue for the call to `operator->`, while the PR uses an lvalue `tmp` for the
call to `operator->`. Since `->` is no longer concerned in C++20's iterator
requirements, there can be observable differences when the iterator having
overloaded `operator->` with different ref-qualifiers in spite of the
equivalence to the expression formed by `operator*` (for lvalues).

The implementation in libc++ follows the standard wording literally. Actually
the original implementation (https://reviews.llvm.org/D120180) has an explicit
`std::move`, suggesting the difference has been acknowledged. (Another
difference is it only applies the resolution for C++17 onward.)

[Bug libstdc++/115514] Nonconforming reverse_iterator::operator->

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to frankhb1989 from comment #0)
> (Another difference is it only applies the resolution for C++17 onward.)

C++20 onward, I think.

[Bug libstdc++/115514] Nonconforming reverse_iterator::operator->

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The constraint on reverse_iterator::operator->() checks it for an lvalue, which
suggests nobody considered (or cared) about annoying iterators that do
something different for lvalues and rvalues.

I'm inclined to consider the difference here to be an unintended consequence of
using of std::prev, and so a defect in the spec. I think this is not something
we should care about.

[Bug libstdc++/115514] Nonconforming reverse_iterator::operator->

[de34 at live dot cn]

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

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #3 from Jiang An <de34 at live dot cn> ---
See
- https://cplusplus.github.io/LWG/issue3725
- https://cplusplus.github.io/LWG/issue3727

If "implicit expression variations"
(https://eel.is/c++draft/concepts.equality#6) apply here, then despite
std::prev returning a non-const prvalue, the behavior of operator-> on such a
prvalue should be required to be same as that on a const lvalue.

But the current standard wording just says
> These implicit expression variations are required to meet the semantic requirements of the declared expression.

It seems that we haven't forbidden the cases where an implicit expression
variation behaves differently while still meeting the semantic requirements.

[Bug libstdc++/115514] Nonconforming reverse_iterator::operator->

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jiang An from comment #3)
> See
> - https://cplusplus.github.io/LWG/issue3725
> - https://cplusplus.github.io/LWG/issue3727
> 
> If "implicit expression variations"
> (https://eel.is/c++draft/concepts.equality#6) apply here, then despite
> std::prev returning a non-const prvalue, the behavior of operator-> on such
> a prvalue should be required to be same as that on a const lvalue.

Yes, Hewill just pointed this out to me too.

It does apply here, because the function's constraints have a
requires-expression using a const lvalue operand.

> But the current standard wording just says
> > These implicit expression variations are required to meet the semantic requirements of the declared expression.
> 
> It seems that we haven't forbidden the cases where an implicit expression
> variation behaves differently while still meeting the semantic requirements.

Meh. That will only affect people intentionally doing dumb things, and we
already spend too much time tweaking the spec to forbid such things, when we
could be doing something more useful.

I think we can close this, the libstdc++ implementation is fine.