[Bug c++/106215] New: Different template parameter order invalidates detection of more special function templates

[Bug c++/106215] New: Different template parameter order invalidates detection of more special function templates

[nico at josuttis dot de]

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

            Bug ID: 106215
           Summary: Different template parameter order invalidates
                    detection of more special function templates
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nico at josuttis dot de
  Target Milestone: ---

Consider (see https://www.godbolt.org/z/bY46369d7):

#include <vector>
#include <ranges>

//template<typename Coll, typename T>  // OK
template<typename T, typename Coll>    // ERROR on gcc only
requires std::ranges::random_access_range<Coll>
void add(Coll& coll, const T& val)
{
  coll.push_back(val);
}

template<typename Coll, typename T>
void add(Coll& coll, const T& val)
{
  coll.insert(val);
}

int main()
{
  std::vector<int> coll;
  add(coll, 42);
}


It seems the order of template parameters matters to find out whether we have a
more special overload.
AFAIK, that is not correct; the order should not matter.
Other compilers do this fine.

[Bug c++/106215] Different template parameter order invalidates detection of more special function templates

[ppalka at gcc dot gnu.org]

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

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

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

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
This seems to essentially be a dup of PR99963.  P2113R0 makes it so that
constraints are used as a tiebreaker only for overloads with equivalent
function parameter lists.  But in this case, the function parameter lists
aren't equivalent IIUC.