Movatterモバイル変換

Proposed resolution (November, 2018):

Change 13.10.3.2 [temp.deduct.call] bullet 4.3 as follows:

In general, the deduction process attempts to find templateargument values that will make the deduced A identical to A(after the type A is transformed as described above). However,there are three cases that allow a difference:

• ...

• IfP is a class andP has theformsimple-template-id, then the transformedAcan be a derived classD of thededucedA. Likewise, ifP is a pointer to aclass of the formsimple-template-id, thetransformedA can be a pointer to a derivedclassD pointed to by thededucedA.However, if there is a classCthat is a (direct or indirect) base class ofD andderived (directly or indirectly) from a classB and thatwould be a valid deducedA, the deducedAcannot beB or pointer toB, respectively.[Example:

  template <typename... T> struct X;  template <> struct X<> {};  template <typename T, typename... Ts> struct X<T, Ts...> : X<Ts...> {};  struct D : X<int> {};  template <typename... T>  int f(const X<T...>&);  int x = f(D());  // callsf<int>, notf<>                   //B isX<>,C isX<int>

—end example]

Notes from the March, 2018 meeting:

The relevant specification is in 13.10.3.2 [temp.deduct.call] bullet4.3 and paragraph 5, which specifies that if there is more than onepossible deducedA, deduction fails. The consensus was to addwording similar to that of overload resolution preferring“nearer” base classes.

[Accepted as a DR at the February, 2019 meeting.]

The status of an example like the following is not clear:

  template <typename... T>              struct A;  template <>                           struct A<> {};  template <typename T, typename... Ts> struct A<T, Ts...> : A<Ts...> {};  struct B : A<int> {};  template <typename... T>  void f(const A<T...>&);  void g() {    f(B{});  }

This seems to be ambiguous in the current wording becauseA<> andA<int> both succeed in deduction.It would be reasonable to prefer the more derived specialization.