3

In his answer to this question and the comment section, Johannes Schaub says there's a "match error" when trying to do template type deduction for a function template that requires more arguments than have been passed:

template<class T>
void foo(T, int);

foo(42); // the template specialization foo<int>(int, int) is not viable

In the context of the other question, what's relevant is whether or not type deduction for the function template succeeds (and substitution takes place):

template<class T>
struct has_no_nested_type {};

// I think you need some specialization for which the following class template
// `non_immediate_context` can be instantiated, otherwise the program is
// ill-formed, NDR
template<>
struct has_no_nested_type<double>
{ using type = double; };

// make the error appear NOT in the immediate context
template<class T>
struct non_immediate_context
{
    using type = typename has_no_nested_type<T>::type;
};


template<class T>
typename non_immediate_context<T>::type
foo(T, int) { return {}; }

template<class T>
bool foo(T) { return {}; }


int main()
{
    foo(42);      // well-formed? clang++3.5 and g++4.8.2 accept it
    foo<int>(42); // well-formed? clang++3.5 accepts it, but not g++4.8.2
}

When instantiating the first function template foo for T == int, the substitution produces an invalid type not in the immediate context of foo. This leads to a hard error (this is what the related question is about.)

However, when letting foo deduce its template-argument, g++ and clang++ agree that no instantiation takes place. As Johannes Schaub explains, this is because there is a "match error".

Question: What is a "match error", and where and how is it specified in the Standard?

Altenative question: Why is there a difference between foo(42) and foo<int>(42) for g++?


What I've found / tried so far:

[over.match.funcs]/7 and [temp.over] seem to describe the overload resolution specifics for function templates. The latter seem to mandate the substitution of template parameters for foo.

Interestingly, [over.match.funcs]/7 triggers the process described in [temp.over] before checking for viability of the function template (specialization). Similarly, type deduction does not to take into account, say, default function arguments (other than making them a non-deduced context). It seems not to be concerned with viability, as far as I can tell.

Another possibly important aspect is how type deduction is specified. It acts on single function parameters, but I don't see where the distinction is made between parameter types that contain / are dependent on template parameters (like T const&) and those which aren't (like int).

Yet, g++ makes a difference between explicitly specifying the template parameter (hard error) and letting them be deduced (deduction failure / SFINAE). Why?

Community
  • 1
  • 1
dyp
  • 38,334
  • 13
  • 112
  • 177

1 Answers1

2

What I've summarized is the process described at 14.8.2.1p1

Template argument deduction is done by comparing each function template parameter type (call it P) with the type of the corresponding argument of the call (call it A) as described below.

In our case, we have for P (T, int) and for A, we have (int). For the first pair of P/A, which is T against int, we can match T to int (by the process described in 14.8.2.5). But for the second "pair", we have int but have no counterpart. Thus deduction cannot be made for this "pair".

Thereby, by 14.8.2.5p2, "If type deduction cannot be done for any P/A pair, ..., template argument deduction fails.".

You then won't ever come to the point where you substitute template arguments into the function template.

This can all probably described more precisely in the Standard (IMO), but I believe this is how one could implement things to match the actual behavior of Clang and GCC and it seems a reasonable interpretation of the Standardese.

Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • Hmm I always wondered where the handling of these non-dependent parameter types is described. When explicitly specifying all template arguments, the deduction step does not need to be performed, therefore no match error occurs. That sounds reasonable, but reminds me of the original 14.7.1p7 optimization (esp. wrt the two substitutions mandated in 14.8.2p6). Maybe I'm just lost in the Standardese; but I can't make out where omitting this deduction step (or "deduction"/matching of non-dependent types) is allowed. – dyp Mar 14 '14 at 21:47
  • Before argument deduction (i.e before the pattern match process), explicitly specified arguments are substituted. After that, the function parameters may become non-dependent. Partly, the precise handling of parameters that contain no parameters anymore is subject of http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1391 . Compilers currently appear to check whether an implicit conversion exist as part of the deduction process (clang does accept the first testcase, but that could be because it filters out based on actual argument count before the fact, apparently). – Johannes Schaub - litb Mar 14 '14 at 21:56
  • There's no text that says that parameters that contain no parameters anymore are ignored from the matching. 14.8.2.1p1 says *by comparing **each** function template parameter type*. The whole spec however isn't too "proof safe": Compare with 14.8.2.5p1, which says "in each case a type that is specified **in terms of template parameters** (call it P) is compared with an actual type". However I regard this as some kind of "overview" that just misses the detail that some pairs may actually be non-dependent. Still it decreases the amount of how much you can trust the text IMO. – Johannes Schaub - litb Mar 14 '14 at 21:59
  • If you do as proposed at the end, "between deduction and substitution", you will find, speaking in terms of the second example shown there, that `B` can't implicitly convert to `int` *before substituting `T`. So you reject the template before raising the actual error. But in your case, you don't have a corresponding argument to begin with. So in your case that would be an immediate error during argument deduction, as you supply it with a non-workable P/A "pair" – Johannes Schaub - litb Mar 14 '14 at 22:06
  • Also note that the explicit specification of the template argument and the error that follows later for that example in the DR can't really be compared to yours, because in the example of the DR, the error arises because of a conversion checking, and not as a result of the mere substitution. In your case, the mere substitution (and the following `::` member selection) gives rise to the instantiation of the class template. – Johannes Schaub - litb Mar 14 '14 at 22:25