[Bug c++/105174] New: [Concepts] Example from temp.func.order-p6 selects wrong overload

[Bug c++/105174] New: [Concepts] Example from temp.func.order-p6 selects wrong overload

[roi.jacobson1 at gmail dot com]

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

            Bug ID: 105174
           Summary: [Concepts] Example from temp.func.order-p6 selects
                    wrong overload
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: roi.jacobson1 at gmail dot com
  Target Milestone: ---

This example from the standard:
https://timsong-cpp.github.io/cppwp/temp.func.order#example-6 fails to compile
with GCC (all versions >= 10), because the wrong overload is selected for
operator==.

I _think_ the problem might be that the permutation on the template arguments
between the specializations prevents GCC from recognizing the second is more
constrained, but I'm not too sure.

[Bug c++/105174] [Concepts] Example from temp.func.order-p6 selects wrong overload

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-04-06
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Confirmed.  P2113 was implemented in GCC 11 by commit r11-1571-g57b4daf8dc4ed7,
which says:

commit 57b4daf8dc4ed7b669cc70638866ddb00f5b7746
Date:   Thu Jun 11 23:58:54 2020 -0400

    c++: Refinements to "more constrained".

    P2113 from the last C++ meeting clarified that we only compare constraints
    on functions or function templates that have equivalent template parameters
    and function parameters.

    I'm not currently implementing the complicated handling of reversed
    comparison operators here; thinking about it now, it seems like a lot of
    complexity to support a very weird usage.  If I write two similar
comparison
    operators to be distinguished by their constraints, why would I write one
    reversed?  If they're two unrelated operators, they're very unlikely to be
    similar enough for the complexity to help.  I've started a discussion on
the
    committee reflector about changing these rules.