[Bug c++/85087] call to a non-const member function on a const lvalue accepted

[Bug c++/85087] call to a non-const member function on a const lvalue accepted

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2018-03-28 00:00:00         |2021-8-1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
clang, gcc, and msvc all accepts this
ICC rejects this.

[Bug c++/85087] call to a non-const member function on a const lvalue accepted

[redi at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #0)
> While looking at bug 85043 I noticed that in the test case below, GCC
> correctly rejects the attempt to convert the const reference to B to A in
> the call to g()

No, it allows the conversion, but that produces an rvalue which can't bind to
the A& parameter of g.

> but it accepts the same invalid conversion in the context
> where a a non-const member function on the result of the conversion is
> called.  Other compilers reject both conversions.

Why should it be rejected? ((A)b) calls the conversion operator to get a const
A& and then initializes an rvalue of type A from that. The rvalue is not const,
and you can call the member function.

i.e. equivalent to:

  static_cast<A>(b.operator const A&()).f();

or:

  A(b).f();

both of which are accepted, as they should be.

EDG accepts the static_cast<A> version, but not A(b).f(), I don't know why. But
I think EDG has the bug here, not GCC.