[Bug c++/83445] conversion function has too high priority in overload resolution

[Bug c++/83445] conversion function has too high priority in overload resolution

[karzh at mail dot ru]

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

Alexander Karzhenkov <karzh at mail dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |karzh at mail dot ru

--- Comment #1 from Alexander Karzhenkov <karzh at mail dot ru> ---
Candidate functions considered by overload resolution are

  Target::Target(Source const&);
  constexpr Target::Target(Target const&);
  constexpr Target::Target(Target&&);

The first one doesn't require any user-defined conversion and therefore should
win.

The bug appears to be fixed in gcc 8, but it occurs again in gcc 9 and later
versions.

[Bug c++/83445] conversion function has too high priority in overload resolution

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Invoking Target(Source const&) is a user-defined conversion too. The conversion
sequence requires binding a reference to the Source object and then converting
it to a Target.

In C++17 there is no call to Target(Target const&) or Target(Target&&) because
the temporary returned by Source::operator Target() is materialized directly
into an object of type Target.

Clang agrees with GCC that Source::operator Target() is a better conversion,
but I can't find the wording specifying that.

[Bug c++/83445] conversion function has too high priority in overload resolution

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I think this is a desired effect of r269667.  The wording isn't in the standard
yet, though.

[Bug c++/83445] conversion function has too high priority in overload resolution

[karzh at mail dot ru]

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

--- Comment #4 from Alexander Karzhenkov <karzh at mail dot ru> ---
r269667 concerns initializing an object from prvalue.
Here we have `Target` being initialized from lvalue if type `Source`.

What we can consider as being initialized from prvalue is the argument of copy
constructor. It would get the result of `Source::operator Target()`, but this
can be optimized out here. Such optimization, however, is not a mandatory copy
elision (introduced by C++17). The latter is not applicable to reference
initialization.

The mandatory copy elision also is not applicable to initialization `Target`
from `Source` as they are different types (see [dcl.init], item 17.6.1).

In case of direct initialization the candidates are all constructors of
`Target`, but not the conversion operator of `Source` (see [over.match.ctor]).
One of constructors must be called (but this call can be optimized out). The
question here is about implicit conversion for argument of the constructor.

Overload resolution matches the argument of each constructor against the
initializer (which is lvalue of `Source`). The best match is for `Target(Source
const&)` as it doesn't require any user-defined conversion.

If compiler prefers `Target(Target const&)`, it has to perform copy
initialization of its argument from `Source`. Such copy initialization cannot
be performed without user-defined conversion, so it is worse.

Invoking the constructor `Target(Source const&)` is user-defined conversion
whereas binding `Source const&` to `source` is not. But the constructor is
invoked explicitly; overload resolution only takes into account
argument/parameter match.

[Bug c++/83445] conversion function has too high priority in overload resolution

[karzh at mail dot ru]

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

--- Comment #5 from Alexander Karzhenkov <karzh at mail dot ru> ---
Also note that const-qualifier on `Source::operator Target()` affects the
conversion sequence (see https://godbolt.org/z/MexGW9). This seems inconsistent
here.