This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-11-11

1789. Array reference vs array decay in overload resolution

The current rules make an example like

  template<class T, size_t N> void foo(T (&)[N]);
  template<class T> void foo(T *t);

  int arr[3]{1, 2, 3};
  foo(arr);

ambiguous, even though the first is an identity match and the second requires an lvalue transformation. Is this desirable?

Proposed resolution (June, 2021):

Add the following as a new bullet following 12.2.4.3 [over.ics.rank] bullet 3.2.6:

Two implicit conversion sequences of the same form are indistinguishable conversion sequences unless one of the following rules applies:

• List-initialization sequence L1 is a better conversion sequence...

• Standard conversion sequence S1 is a better conversion sequence than standard conversion sequence S2 if

• ...

• S1 and S2 include reference bindings (9.4.4 [dcl.init.ref]), and the types to which the references refer are the same type except for top-level cv-qualifiers, and the type to which the reference initialized by S2 refers is more cv-qualified than the type to which the reference initialized by S1 refers. [Example 6:...

• S1 is a reference binding to an array and S2 is an array-to-pointer conversion (7.3.3 [conv.array]). [Example 7:

    template<class T, unsigned N> void f(T (&)[N]); // #1
    template<class T> void f(T *t);                 // #2
    int r[3]{1, 2, 3};
    void g() {
      f(r);    // OK: calls #1
    }
  

  —end example]

CWG 2023-02-06

The proposed resolution prefers the T& overload over the T* overload in the example below, which is undesirable. The wording needs to be amended to limit the tiebreaker to situations where the array declarator appears in the signature.

template<class T>
int f(T&);
template<class T>
int f(T*);
int x[5];
int z = f(x);