Consider the following function:<\/p>\n
template<typename T>\r\nvoid Increment(T value = 1);\r\n<\/pre>\nIf you call it with no arguments, C++ cannot deduce the template type parameter:<\/p>\n
\/\/ clang\r\nerror: no matching function for call to 'Increment'\r\ncouldn't infer template argument 'T'\r\n\r\n\/\/ gcc\r\nerror: no matching function for call to 'Increment()'\r\ncouldn't deduce template parameter 'T'\r\n\r\n\/\/ msvc\r\nerror C2672: 'Increment': no matching overload function found\r\ncould not deduce template argument for 'T'\r\n<\/pre>\n“What do you mean, you can’t deduce the template argument? It’s right there: The default parameter is
1<\/code>, soT<\/code> should beint<\/code>!”<\/p>\nThe catch is that C++ does not consider default parameters when performing template deduction. It performs deduction only with explicitly-provided parameters.<\/p>\n
A very common pattern is for the default value of a function parameter to be dependent upon a template type parameter.<\/p>\n
template<typename T>\r\nvoid SetSize(size_t N, T value = T{}<\/span>);\r\n<\/pre>\nThe intention here is that if you call
SetSize<\/code> and don’t provide a value, we will use a default-constructed value. You see this pattern, for example, instd::vector::resize()<\/code>.<\/p>\nIf default parameters were used by type inference, then you’d have a circular dependency:\u00b9 To figure out what
T<\/code> is, you need to know the default parameter, but to know the default parameter, you need to know whatT<\/code> is.\u00b2<\/p>\nBut all is not lost. If you want to provide a default type for
T<\/code>, you can provided it as part of the template type parameter list:<\/p>\ntemplate<typename T = int<\/span>>\r\nvoid Increment(T value = 1);\r\n<\/pre>\nIf you call
Increment()<\/code> with no parameters, the compiler cannot deduceT<\/code> from the actual parameters (since there are none), so it uses the default type in the template type parameter list, and you getint<\/code>. Once that’s decided, the default parameter is then implicitly converted from1<\/code>.<\/p>\n\u00b9 I wouldn’t be surprised if there turns out to be a circular dependency with overload resolution, but I am too tired to try to work out the details.<\/p>\n
\u00b2 You might say, “Sure, that general case doesn’t work, but certainly you can make it work in this case!” There is a trade-off when you add rules to handle special cases. The good part is that more cases work. The bad part is that you now have more rules. Often, it’s better to have a simple set of easily-understood and easily-remembered rules, even if they don’t cover all possible cases.\u00b3<\/p>\n