Once we get our candidate functions set (both bar
s), and then whittle it down to the viable functions (still both bar
s) we have to determine the best viable function. If there is more than one, we get an ambiguity error. The steps we take to determine the best one are laid out in [over.match.best]:
[A] viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then
— for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that,
Both functions take an argument of type int
, so both conversion sequences are identical. We continue.
— the context is an initialization by user-defined conversion [...]
Does not apply.
— the context is an initialization by conversion function for direct reference binding (13.3.1.6) of a reference to function type, [...]
Does not apply.
— F1 is not a function template specialization and F2 is a function template specialization, or, if not that,
Both bar<int>
s are function template specializations. So we move onto the very last bullet point to to determine the best viable function.
— F1 and F2 are function template specializations, and the function template for F1 is more specialized
than the template for F2 according to the partial ordering rules described in 14.5.6.2.
The partial ordering rules basically boil down to us synthesizing new unique types for the arguments of both bar
overloads and performing template deduction on the other overload.
Consider the "b" overload first. Synthesize a type typename identity<Unique1>::type
and attempt to perform template deduction against T
. That succeeds. Simplest cast of template deduction there is.
Next, consider the "a" overload. Synthesize a type Unique2
and attempt to perform template deduction against typename identity<T>::type
. This fails! This is a non-deduced context - no deduction can succeed.
Since template type deduction only succeeds in a single direction, the bar(typename identity<T>::type)
overload is considered more specialized, and is chosen as the best viable candidate.
bogdan presents another interesting case for looking at partial ordering. Consider instead comparing:
template <typename T> void bar(T, T); // "c"
template <typename T> void bar(T, typename identity<T>::type ); // "d"
bar(5,5);
bar<int>(5, 5);
Again, both candidates are viable (this time even without explicitly specifying T
) so we look at the partial ordering rule.
For the "c" overload, we synthesize arguments of type UniqueC, UniqueC
and attempt to perform deduction against T, typename identity<T>::type
. This succeeds (with T == UniqueC
). So "c" is at least as specialized as "d".
For the "d" overload, we synthesize arguments of type UniqueD, typename identity<UniqueD>::type
and attempt to perform deduction against T, T
. This fails! The arguments are of different types! So "d" is not at least as specialized as "c".
Thus, the "c" overload is called.