* [Bug c++/83445] conversion function has too high priority in overload resolution
[not found] <bug-83445-4@http.gcc.gnu.org/bugzilla/>
@ 2020-08-17 18:06 ` karzh at mail dot ru
2020-08-18 9:48 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: karzh at mail dot ru @ 2020-08-17 18:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug c++/83445] conversion function has too high priority in overload resolution
[not found] <bug-83445-4@http.gcc.gnu.org/bugzilla/>
2020-08-17 18:06 ` [Bug c++/83445] conversion function has too high priority in overload resolution karzh at mail dot ru
@ 2020-08-18 9:48 ` redi at gcc dot gnu.org
2020-08-18 13:02 ` mpolacek at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-18 9:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug c++/83445] conversion function has too high priority in overload resolution
[not found] <bug-83445-4@http.gcc.gnu.org/bugzilla/>
2020-08-17 18:06 ` [Bug c++/83445] conversion function has too high priority in overload resolution karzh at mail dot ru
2020-08-18 9:48 ` redi at gcc dot gnu.org
@ 2020-08-18 13:02 ` mpolacek at gcc dot gnu.org
2020-08-18 20:29 ` karzh at mail dot ru
2020-08-19 6:44 ` karzh at mail dot ru
4 siblings, 0 replies; 5+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2020-08-18 13:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug c++/83445] conversion function has too high priority in overload resolution
[not found] <bug-83445-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-08-18 13:02 ` mpolacek at gcc dot gnu.org
@ 2020-08-18 20:29 ` karzh at mail dot ru
2020-08-19 6:44 ` karzh at mail dot ru
4 siblings, 0 replies; 5+ messages in thread
From: karzh at mail dot ru @ 2020-08-18 20:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug c++/83445] conversion function has too high priority in overload resolution
[not found] <bug-83445-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-08-18 20:29 ` karzh at mail dot ru
@ 2020-08-19 6:44 ` karzh at mail dot ru
4 siblings, 0 replies; 5+ messages in thread
From: karzh at mail dot ru @ 2020-08-19 6:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread