[Bug c++/109247] [13/14 Regression] optional<T> o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:9872d56661ade358c440914361c1ebdccd975bec

commit r14-1502-g9872d56661ade358c440914361c1ebdccd975bec
Author: Jason Merrill <jason@redhat.com>
Date:   Fri May 26 12:28:15 2023 -0400

    c++: fix explicit/copy problem [PR109247]

    In the testcase, the user wants the assignment to use the operator=
declared
    in the class, but because [over.match.list] says that explicit constructors
    are also considered for list-initialization, as affirmed in CWG1228, we end
    up choosing the implicitly-declared copy assignment operator, using the
    explicit constructor template for the argument, which is ill-formed.  Other
    implementations haven't implemented CWG1228, so we keep getting bug
reports.

    Discussion in CWG led to the idea for this targeted relaxation: if we use
an
    explicit constructor for the conversion to the argument of a copy or move
    special member function, that makes the candidate worse than another.

            DR 2735
            PR c++/109247

    gcc/cp/ChangeLog:

            * call.cc (sfk_copy_or_move): New.
            (joust): Add tiebreaker for explicit conv and copy ctor.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/initlist-explicit3.C: New test.