N3602

Revision of a section of N3405=12-0095

2013-03-14

Mike Spertus, Symantec

mike_spertus@symantec.com

Daveed Vandevoorde, Edison Design Group

daveed@edg.com





Template parameter deduction for constructors

This paper proposes extending template parameter deduction for functions to constructors of template classes. The clearest way to describe the problem and solution is with some examples.

Suppose we have defined the following. vector<int> vi1 = { 0, 1, 1, 2, 3, 5, 8 }; vector<int> vi2; template<class Func> class Foo() { public: Foo(Func f) : func(f) {} void operator()(int i) { os << "Calling with " << i << endl; f(i); } private: Func func; }; Currently, if we want to instantiate template classes, we need to either specify the template parameters or use a "make_*" wrapper, leverage template parameter deduction for functions, or punt completely: pair<int, double> p(2, 4.5); auto t = make_tuple(4, 3, 2.5); copy_n(vi1, 3, back_inserter(vi2)); for_each(vi.begin(), vi.end(), Foo< >([&](int i) { })); There are several problems with the above code:

Creating “make functions” like make_tuple is confusing, artificial, extra boilerplate, and inconsistent with how non-template classes are constructed.

is confusing, artificial, extra boilerplate, and inconsistent with how non-template classes are constructed. Since the standard library doesn't follow any consistent convention for make functions, users have to scurry through documentation to find they need to use make_tuple for tuple s and back_inserter for back_insert_iterator s. Of course their own template classes might not be as consistent or thoroughly-documented as the standard.

for s and for s. Of course their own template classes might not be as consistent or thoroughly-documented as the standard. Specifying template parameters as in pair<int, double>(2, 4.5) should be unnecessary since they can be inferred from the type of the arguments, as is usual with template functions (this is the reason the standard provides make functions for many template classes in the first place!).

should be unnecessary since they can be inferred from the type of the arguments, as is usual with template functions (this is the reason the standard provides make functions for many template classes in the first place!). If we don't have a make function, we may not be able to create class objects at all as indicated by the in the code above.

pair p(2, 4.5); tuple t(4, 3, 2.5); copy_n(vi1, 3, back_insert_iterator(vi2)); for_each(vi.begin(), vi.end(), Foo([&](int i) { }));

pair

tuple

back_insert_iterator

The Deduction Process

We propose to allow a template name referring to a class template as a simple-type-specifier in two contexts:

Functional-notation simple type conversions ([expr.type.conv], and

Simple-declarations of the form "decl-specifier-seq id-expression initializer".

In the case of a function-notation type conversion (e.g., " tuple(1, 2.0, false) ") or a direct parenthesized or braced initialization, the initialization is resolved as follows. First, constructors and constructor templates declared in the named template are enumerated. Let Ci be such a constructor or constructor template; together they form an overload set. A parallel overload set F of function templates is then created as follows: For each Ci a function template is constructed with template parameters that include both those of the named class template and if Ci is a constructor template, those of that template (default arguments are included too) -- the function parameters are the constructor parameters, and the return type is void Deduction and overload resolution is then performed for a synthesized call to F with the parenthesized or braced expressions used as arguments. If that call doesn't yield a "best viable function", the program is ill-formed. Otherwise, the template name is treated as the class-name that is obtained from the named class template with the deduced arguments corresponding to that template's parameters.

Let's look at an example: template<typename T> struct S { template<typename U> struct N { N(T); N(T, U); template<typename V> N(V, U); }; }; S<int>::N x{2.0, 1}; In this example, " S<int>::N " in the declaration of x is missing template arguments, so the approach above kicks in. Template arguments can only be left out this way from the "type" of the declaration, but not from any name qualifiers used in naming the template; i.e., we couldn't replace " S<int>::N " by just " S::N " using some sort of additional level of deduction. To deduce the initialized type, the compiler now creates an overload set as follows: template<typename U> void F(S<int>::N<U> const&); template<typename U> void F(S<int>::N<U> &&); template<typename U> void F(int); template<typename U> void F(int, U); template<typename U, typename V> void F(V, U); (The first two candidates correspond to the implicitly-declared copy and move contructors. Note that template parameter T is already known to be int and is not a template parameter in the synthesized overload set.) Then the compiler performs overload resolution for a call " F(2.0, 1) " which in this case finds a unique best candidate in the last synthesized function with U = int and V = double . The initialization is therefore treated as " S<int>::N<int> x{2.0, 1}; "

Note that after the deduction process described above the initialization may still end up being ill-formed. For example, a selected constructor might be inaccessible or deleted, or the selected template instance might have been specialized or partially specialized in such a way that the candidate constructors will not match the initializer.