Function Template Partial Ordering: Worked Examples
C++ function overloading rules are complex. C++ template rules are complex. Put the two together, and you unfortunately do not get something simple; you get a hideous monster of standardese which requires great patience and knowledge to overcome. However, since C++ is mostly cornercases, it can pay to understand how the rules apply for those times where you just can’t work out why your code won’t compile. This post will present a few stepbystep examples of how partial ordering of function templates works in order to arm you for these times of need.
Partial ordering of function templates is a step of overload resolution. It occurs when you call a function template which is overloaded and the compiler needs to decide which one is more specialized than the other. Consider this code:
template<class T> void f(T); //(1)
template<class T> void f(T const*); //(2)
int const* p = nullptr;
f(p);
We expect f(p)
to call (2)
, because p
is a int const*
. In order to decide that (2)
is more specialized than (1)
, the compiler needs to follow the function template partial ordering rules. Let’s see what the standard has to say.
Partial ordering selects which of two function templates is more specialized than the other by transforming each template in turn (see next paragraph) and performing template argument deduction using the function type.
This is not so complicated, even if the terms may be unfamiliar. Unfortunately, the “next paragraph” and the sections which it references are almost impossible to parse without a lot of background knowledge and rereadings, so I shall step through the algorithm rather than pasting the rules for you to cry over.
There are four steps which we to have work through:
 Transforming
(1)
.  Performing deduction on
(2)
with the transformed template from step 1.  Transforming
(2)
.  Performing deduction on
(1)
with the transformed template from step 3.
If one and only one of the deductions succeeds, then the template with which the deduction was performed is more specialized than the other.
Step 1: The rules state that for each template parameter, we create some unique type to use in its stead^{1}. Let’s call this unique type type_0
. You can pretend that this was defined somewhere like class type_0{};
. Now we take our function template template <class T> void f(T)
and substitute in type_0
for T
. This gives us void f(type_0)
. The transformation is complete.
Step 2: Now that we have transformed template <class T> void f(T)
into void f(type_0)
, we will perform deduction on (2)
using the transformed function type. To do this, we imagine a call to (2)
where the arguments have the type of the parameters for (1)
. Concretely, it would look like this:
template <class T> void func_2(T const*);
func_2(type_0{}); //derived from void f(type_0)
Would this call succeed? We can put it into our compiler to find out. GCC 8.1 says:
<source>: In function 'int main()':
<source>:4:18: error: no matching function for call to 'func_2(type_0)'
func_2(type_0{});
^
<source>:1:25: note: candidate: 'template<class T> void func_2(const T*)'
template <class T> void func_2(T const*);
^~~~~~
<source>:1:25: note: template argument deduction/substitution failed:
<source>:4:18: note: mismatched types 'const T*' and 'type_0'
func_2(type_0{});
^
So deduction from (1)
to (2)
fails, because the invented type type_0
cannot be used to deduce const T*
.
Step 3: Let’s try from (2)
to (1)
. Again, we’ll transform (2)
from template <class T> void f(T const*)
to void f(type_0 const*)
.
Step 4: Now we attempt deduction:
template <class T> void func_1(T);
type_0 const* arg = nullptr;
func_1(arg);
This succeeds because a type_0 const*
can be used to deduce T
. Since deduction from (1)
to (2)
fails, but deduction from (2)
to (1)
succeeds, (2)
is more specialized than (1)
and will be chosen by overload resolution.
Let’s try a different example. How about:
template<class T> void g(T); //(1)
template<class T> void g(T&); //(2)
int i = 0;
g(i);
(1)
transforms to void g(type_0)
. Before we try deduction, we need to apply one of the numerous additional rules from the standard, which says we need to replace references with the type being referred to. So template <class T> void g(T&)
becomes template <class T> void g(T)
. Deduction time:
template<class T> void func_2(T);
func_2(type_0{});
This succeeds.
Now the other direction. template<class T> void g(T&)
transforms to void g(type_0&)
, then we remove the reference to get void g(type_0)
. Our second deduction:
template<class T> void func_1(T);
func_1(type_0{});
This is effectively identical to the previous one, so of course it succeeds.
Since deduction succeeded in both directions, the call is ambiguous. Sure enough, GCC diagnoses:
<source>: In function 'int main()':
<source>:5:8: error: call of overloaded 'g(int&)' is ambiguous
g(i);
^
<source>:1:24: note: candidate: 'void g(T) [with T = int]'
template<class T> void g(T); //(1)
^
<source>:2:24: note: candidate: 'void g(T&) [with T = int]'
template<class T> void g(T&); //(2)
^
This is why the algorithm is a partial ordering: sometimes two function templates are not ordered.
I’ll give one more example. This one has multiple parameters and is a bit more subtle.
template<class T>struct identity { using type = T; };
template<class T>struct A{};
template<class T, class U> void h(typename identity<T>::type, U); //(1)
template<class T, class U> void h(T, A<U>); //(2)
h<int>(0,A<void>{});
identity
here just evaluates to its template argument, but the important thing to note is that typename identity<T>::type
is a nondeduced context, so T
cannot be deduced from the argument for that parameter.
(1)
transforms to void h(typename identity<type_0>::type, type_1)
, which is void h(type_0, type_1)
. Attempt deduction on (2)
:
template<class T, class U> void func_2(T, A<U>);
func_2(type_0{}, type_1{});
This fails because we can’t match type_1
against A<U>
.
(2)
transforms to void h(type_0, A<type_1>)
. Try deduction against (1)
:
template<class T, class U> void func_1(typename identity<T>::type, U);
func_1(type_0{}, A<type_1>{});
This fails because typename identity<T>::type
is a nondeduced context, so we can’t deduce T
.
In the example from the last section deduction succeeded both ways so the call was ambiguous. In this example, deduction fails both ways, which is also an ambiguous call.
That’s the last of the examples. Of course, there are a bunch of rules which I didn’t cover here, like Concepts, parameter packs, nontype/template template parameters, and cases where both the argument and parameter types are references. Hopefully you now have enough of an intuition that you can understand what the standard says when you inevitably hit those corner cases. If you have any partial ordering conundrums, drop them down in the comments below or send them to me on Twitter.

I’ll ignore nontype template parameters and template template parameters for simplicity, but the rules are essentially the same. ↩
Let me know what you think of this article on twitter @TartanLlama or leave a comment below!