<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
  <style type="text/css">

.comment { color: #999999; font-style: italic; }
.pre { color: #000099; }
.string { color: #009900; }
.char { color: #009900; }
.float { color: #996600; }
.int { color: #999900; }
.bool { color: #000000; font-weight: bold; }
.type { color: #FF6633; }
.flow { color: #FF0000; }
.keyword { color: #990000; }
.operator { color: #663300; font-weight: bold; }
.operator { color: #663300; font-weight: bold; }
pre.code {
    border: 2px solid #666;
    background-color: #F4F4F4;
    padding-left: 10px;
    padding-top: 0px;
}
code {
    border: 2px solid #d0d0d0;
    background-color: LightYellow;
    padding: 2px;
    padding-left: 10px;
    display:table;
    white-space:pre;
    margin:2px;
    margin-bottom:10px;
}
dt {
    font-weight: bold;
}
.ins {
    background-color:#A0FFA0;
    text-decoration: underline;
}
.del {
    background-color:#FFA0A0;
    text-decoration:line-through
}    
</style>

<title>Template argument deduction for class templates (Rev. 6)</title>
</head>

<body>
<p>Document number: P0091R3<br>
Revision of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0091r2.html">P0091R2</a><br>
Date: 2016-06-24<br>
Reply-To:<br>
&nbsp;&nbsp;&nbsp;Mike Spertus, Symantec (<a href="mailto:mike_spertus@symantec.com">mike_spertus@symantec.com</a>)<br>
&nbsp;&nbsp;&nbsp;Faisal Vali <a href="mailto:faisalv@yahoo.com"> (faisalv@yahoo.com</a>)<br>
&nbsp;&nbsp;&nbsp;Richard Smith (<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>)<br>
Audience: Core Working Group
</p>

<h1>Template argument deduction for class templates (Rev. 6)</h1> 
	<h2>Changes from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0091r2.html">P0091R2</a></h2>
    <ul>
            <li>Updated wording. We gladly acknowledge extensive input
        from Jens Maurer.</li>
        <li>Uses of template arguments cannot supply template parameters</li>
    </ul>

    <h2>Summary</h2>
    <p> This paper proposes extending template argument deduction for functions
		to constructors of template classes and incorporates feedback from the EWG review of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0091r0.html">P0091R0</a> and from <a href="https://github.com/faisalv/clang/tree/clang-ctor-deduction">implementation experience</a>.</p>
<p>Currently, if we want to construct template classes, we need to specify the template arguments. 
	For example, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4498.html">N4498</a> on Variadic Lock Guards
	gives an example of acquiring a <tt>lock_guard</tt> on two mutexes inside an <tt>operator=</tt> to properly lock both the
	source and destination of the assignment. Expanding typedefs, the locks are acquired by the following statement
	(See the paper for details and rationale).
	<code>std::lock_guard&lt;std::shared_timed_mutex, std::shared_lock&lt;std::shared_timed_mutex&gt;&gt; lck(mut_, r1);</code>
	Having to specify the template arguments adds nothing but complexity! 
If constructors could deduce their template arguments "like we expect 
from other functions and methods," then the following vastly simpler and
 more intuitive code could have been used instead.
	<code>auto lock = std::lock_guard(mut_, r1);</code>

	</p>
	<p>The sections below first spell out the problem in more detail and 
then makes precise what "like we expect from other functions and 
methods" means in this context.</p>

	<h2><a name="Problem">The problem</a></h2>
	
	<p>To simplify the examples below, suppose the following definitions are in place.

<code>vector&lt;int&gt; vi1 = { 0, 1, 1, 2, 3, 5, 8 };
vector&lt;int&gt; vi2;
std::mutex m;
unique_lock&lt;std::mutex&gt; ul(m, std::defer_lock);
template&lt;class Func&gt;
class Foo() { 
public: 
    Foo(Func f) : func(f) {} 
    void operator()(int i) { 
      os &lt;&lt; "Calling with " &lt;&lt; i &lt;&lt; endl;
      f(i); 
    } 
private: 
    Func func; 
    mutex mtx;
};</code>
</p><p>In the current standard, the following objects would be constructed as shown</p>
<code>pair&lt;int, double&gt; p(2, 4.5);
auto t = make_tuple(4, 3, 2.5);
copy_n(vi1, 3, back_inserter(vi2));
<span class="comment">// Virtually impossible to pass a lambda to a template class' constructor without declaring the lambda</span>
for_each(vi2.begin(), vi2.end(), Foo&lt;<span class="comment">???</span>&gt;([&amp;](int i) { <span class="comment">...</span>}));
lock_guard&lt;std::mutex&gt; lck(foo.mtx);
lock_guard&lt;std::mutex, std::unique_lock&lt;std::mutex&gt;&gt; lck2(foo.mtx, ul); <span class="comment">// Notation from N4470</span>
auto hasher = [](X const &amp; x) -&gt; size_t { <span class="comment">/* ... */</span> };
</code>

There are several problems with the above code:
<ul>

<li>Creating "make functions" like <tt>make_tuple</tt> is confusing,
artificial, extra boilerplate, and inconsistent with how non-template classes are constructed.</li>

<li>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 <tt>make_tuple</tt> for <tt>tuple</tt>s
and <tt>back_inserter</tt> for <tt>back_insert_iterator</tt>s. Of course their own
template classes might not be as consistent or thoroughly-documented as the standard.</li>

<li>Specifying template arguments as in <tt>pair&lt;int, double&gt;(2, 4.5)</tt>
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!).
</li>
	<li>A make function may do more than just deduce constructor template arguments. Unless
	a detailed study of the documentation is made (which usually only happens when debugging
	weird unexpected behavior...), subtle changes in semantics may occur. Committee members
	and other C++ experts are invited to see if they can tell which of the above make functions
	simply do the "obvious" deduction of template arguments.</li>
<li>If we don't have a make function, we may not be able to
create class objects without prior declarations of lambdas as indicated by the <tt><span class="comment">???</span></tt>
in the code above.</li>
<li>Using make functions with classes that aren't movable like <tt>std::lock_guard</tt> requires appealing to
	highly abstruse language features like copy elision for prvalues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html">P0135R0</a>),
	contributing to the perception that C++' conceptual model is beyond ordinary mortals.</li>
<li>The useful technique of replacing a large function with a class by 
organizing its code into methods to reduce cyclomatic complexity can't 
be used for template functions</li>
</ul>

If we allowed the compiler to deduce the template arguments for constructors of
template classes, we could replace the above with:

<code>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([&amp;](int i) { <span class="comment">...</span>})); <span class="comment">// Now easy instead of virtually impossible</span>
auto lck = lock_guard(foo.mtx);
lock_guard lck2(foo.mtx, ul);
</code>

We believe this is more consistent and simpler for both users and writers of
template classes, especially for user-defined classes that might
not have carefully designed and documented make functions like <tt>pair</tt>,
<tt>tuple</tt>, and <tt>back_insert_iterator</tt>.
<h2>The Solution</h2>
<p>We propose to allow a template name referring to a class template as a
simple-type-specifier or with partially supplied explicit template arguments in two contexts:
</p>
<ul>
    <li>Simple declarations of variables (or variable templates) that are also definitions whose declarator is a <i>noptr-declarator</i>
 (i.e. not when declaring functions, template parameters, function 
parameters, non-static data members, pointers, references etc.), and</li>
    <code>
    template&lt;class ... Ts&gt; struct X { X(Ts...) };
    X x1{1}; <span class="comment">// OK X&lt;int&gt;</span>
    X x11; <span class="comment">// OK X&lt;&gt;</span>
    template&lt;class T&gt; X xv{(T*)0}; <span class="comment">// OK decltype(xv&lt;int&gt;) == X&lt;int*&gt;</span>
    extern X x2; <span class="comment">// NOT OK, needs to be a definition</span>
    X arr[10];   <span class="comment">// OK X&lt;&gt;</span>
    X x1{1}, x2{2}; <span class="comment">// OK, deduced to the same type X&lt;int&gt;</span>
    X *pointer = 0; <span class="comment">// NOT OK</span>
    X &amp;&amp;reference = X&lt;int&gt;{1};
    X function(); <span class="comment">// NOT OK</span>
    </code>
  <li>Explicit type conversion (functional notation) ([expr.type.conv])</li>
</ul>

<p>We propose two techniques to support template argument deduction for class templates:</p>
    <ul>
       <li><a href="#uec">Using implicitly synthesized deduction guides (from existing constructors)</a></li>
	   <li><a href="#udg">Using explicitly specified deduction guides</a></li>
    </ul>
	These techniques can work well together as will be explained below. They
	can also be adopted separately. Both forms received consensus straw polls
        from EWG (although note that the authors did not vote unanimously in support of implicit guides).<p></p>

    
    <h3><a name="uec">Implicitly synthesized Deduction Guides (from existing constructors)</a></h3><a name="uec">
<p>
In the case of a function-notation type conversion (e.g., "<tt>tuple(1, 2.0, false)</tt>") 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 (i.e. the implicitly synthesized deduction guides) <i>F</i> of function templates is then created as follows:</p>

<p>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 the template-name followed by the template-parameters of the class template enclosed in &lt;&gt;</p>

Deduction and overload resolution is then performed for an invented call
to <i>F</i> 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 return type of the selected <i>F</i> template specialization becomes the deduced class template specialization.
<p></p>
Let's look at an example:
<code>template&lt;typename T&gt; struct UniquePtr {
    UniquePtr(T* t);
    <span class="comment">...</span>
};

UniquePtr dp{new auto(2.0)};
</code>
<p>
In the above example, <tt>UniquePtr</tt> is missing template arguments in the 
declaration of 'dp' so they have to be deduced. To deduce the 
initialized type, the compiler then creates an overload set as follows:
</p>
        
<code>
    template&lt;typename T&gt; 
        UniquePtr&lt;T&gt; <i>F</i>(UniquePtr&lt;T&gt; const&amp;);
    template&lt;typename T&gt; 
        UniquePtr&lt;T&gt; <i>F</i>(UniquePtr&lt;T&gt; &amp;&amp;);
    template&lt;typename T&gt; 
        UniquePtr&lt;T&gt; <i>F</i>(T *p);
    
</code>
<p>
Then the compiler performs overload resolution for a call "<tt><i>F</i>(2.0)</tt>"
 
which in this case finds a unique best candidate in the last synthesized
 function and after final substitution, deduces the class template 
specialization as <tt>UniquePtr&lt;double&gt;</tt>
</p>     
<p>
Let's look at a more involved example:
<code>template&lt;typename T&gt; struct S {
  template&lt;typename U&gt; struct N {
    N(T);
    N(T, U);
    template&lt;typename V&gt; N(V, U);
  };
};

S&lt;int&gt;::N x{2.0, 1};
</code>

In this example, "<tt>S&lt;int&gt;::N</tt>" in the declaration of <tt>x</tt>
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 "<tt>S&lt;int&gt;::N</tt>" by just "<tt>S::N</tt>"
using some sort of additional level of deduction.
To deduce the initialized type, the compiler now creates an overload set as
follows:

<code>
    template&lt;typename U&gt; 
        S&lt;int&gt;::N&lt;U&gt; <i>F</i>(S&lt;int&gt;::N&lt;U&gt; const&amp;);
    template&lt;typename U&gt; 
        S&lt;int&gt;::N&lt;U&gt; <i>F</i>(S&lt;int&gt;::N&lt;U&gt; &amp;&amp;);
    template&lt;typename U&gt; 
        S&lt;int&gt;::N&lt;U&gt; <i>F</i>(int);
    template&lt;typename U&gt;
        S&lt;int&gt;::N&lt;U&gt; <i>F</i>(int, U);
    template&lt;typename U, typename V&gt; 
        S&lt;int&gt;::N&lt;U&gt; <i>F</i>(V, U);
</code>

(The first two candidates correspond to the implicitly-declared copy and move
contructors. Note that template parameter <tt>T</tt> is already known to
be <tt>int</tt> and is not a template parameter in the synthesized overload
set.)

Then the compiler performs overload resolution for a call "<tt><i>F</i>(2.0, 1)</tt>" 
which in this case finds a unique best candidate in the last synthesized function
with <tt>U = int</tt> and <tt>V = double</tt> and deduced type of <tt>S&lt;int&gt;::N&lt;int&gt;</tt>.  The initialization
is therefore treated as "<tt>S&lt;int&gt;::N&lt;int&gt; x{2.0, 1};</tt>"
</p>



<p>
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.
</p>

The case of a <i>simple-declaration</i> with copy-initialization syntax is treated
similarly to the approach described above, except that explicit constructors
and constructor templates are ignored, and the initializer expression is
used as the single call argument during the deduction process.

</a><h3><a name="uec"></a><a name="udg">Explicitly specified Deduction Guides</a></h3><a name="udg">
	<p>While the above procedure generates many useful deducible constructors,
		some constructors that we would like to be deducible are not. For example, 
		one could imaging a function <tt>make_vector</tt>
    defined as follows:</p>
	<code>template&lt;typename Iter&gt;
vector&lt;Iter::value_type&gt; make_vec(Iter b, Iter e) {
  return vector&lt;Iter::value_type&gt;(b, e);
}
    </code>
<p>Although there is no constructor in <tt>vector</tt> from which we can deduce the type
    of the vector from two iterators, one would like to be able to deduce the type of
	the vector from the value type of the two iterators.
		For example, some implementations of the STL define their <tt>value_type</tt>
<tt>typedef</tt> as follows
<code>template&lt;typename T, typename Alloc=std::allocator&lt;T&gt;&gt;
struct vector {
  struct iterator {
    typedef T value_type;
    <span class="comment">/* ... */</span>
  };
  typedef iterator::value_type value_type;
  <span class="comment">/* ... */</span>
};
</code>
The detour through <tt>vector&lt;T&gt;::iterator</tt> keeps us from
deducing that <tt>T</tt> is <tt>char</tt> in a constructor call like <tt>vector(5, 'c')</tt>.
We would certainly like constructors like that to work.</p>

<p>We suggest a notation to allow explicit specification of a deduction 
guide in the same semantic scope as the class template using the 
following syntax:
	<code>template&lt;typename T, typename Alloc = std::allocator&lt;T&gt;&gt; struct vector {
  <span class="comment">/* ... */</span>
};
template&lt;typename Iter&gt; vector(Iter b, Iter e) -&gt; vector&lt;typename iterator_traits&lt;Iter&gt;::value_type&gt;
</code>
 </p><p>In effect, this allows users to leverage all the deduction rules
 that are specifiable by any function with a standard first-class name 
and no boilerplate code in the body. It also allows us
	to suppress a standard deduction from the above process via "<tt>= delete;"</tt></p>  

    <p>Note that a deduction guide is not a function and shall not have a
 body. It participates in deduction of class template arguments in a 
similar way to the synthesized deduction guides.</p>
    <p>Additionally, it is worthwhile to note the following:</p>
    <ul><li>Deduction guides must name a class template and must be 
introduced within the same semantic scope of the class template, but 
they do not becomes members of that scope (i.e if that scope is a class)
 </li></ul>
<h4>Alternate notation</h4>
As an alternative to the above notation for explicit deduction guides, one could consider a &ldquo;declaration
	notation&rdquo;. E.g., 
<code>template&lt;typename Iter&gt; vector&lt;typename iterator_traits&lt;Iter&gt;::value_type&gt; vector(Iter b, Iter e); 
template&lt;typename Iter&gt; auto vector(Iter b, Iter e) -&gt; vector&lt;typename iterator_traits&lt;Iter&gt;::value_type&gt;; 
</code>
	<p>The point is that this uses a familiar notation to declare what the canonical &ldquo;make function&rdquo;
	would look like as a function declaration. As the above lines are not legal C++14 (cf. &sect;14p5),
	this would not reinterpret existing function declarations, and the compiler or linker would not need to check
	for a function definition. This could potentially be easier for programmers to learn as they do not need to
	learn a new grammatical construct, and there is indeed an &ldquo;function&rdquo; instantiated to match the
	declaration. The downside of the &ldquo;declaration notation&rdquo; is of course the quotes around &ldquo;function&rdquo;, as
	this is not actually a function declaration.</p>
	<p>The prototype uses &ldquo;declaration notation&rdquo;, but we believe there are no technical parsing obstacles
	to either (always a relief when defining new C++ features!) and that it is a matter of the preference of the committee.</p> 
<h3>A note on injected class names</h3>
<p>The focus on this paper is on simplifying the interface of a
	class for its clients. Within a class, one may need to explicitly specify the arguments as 
	before due to the injected class name:</p>
<code>template&lt;typename T&gt; struct X {
  template&lt;typename Iter&gt;
  X(Iter b, Iter e) { <span class="comment">/* ... */</span> }
	
  template&lt;typename Iter&gt;
  auto foo(Iter b, Iter e) { 
     return X(b, e); <span class="comment">// X&lt;U&gt; to avoid breaking change</span>
  }
	
  template&lt;typename Iter&gt;
  auto bar(Iter b, Iter e) { 
     return X&lt;Iter::value_type&gt;(b, e); <span class="comment">// Must specify what we want</span>
  }
};
</code>
</a><h3><a name="udg"></a><a name="CodeCompatibility">Code compatibility</a></h3><a name="CodeCompatibility">
While we cannot say whether it is a problem in practice, we should point out a 
scenario where auto-deduction can break compatibility. 
	
<p>Suppose I produce a library and I'm under license to preserve source 
compatibility across all 1.x upgrades, and I have this class template in
 version 1.0:</p>

<code>template<typename t=""> struct X {
  X(T);
};</typename></code>

	<p>... and in version 1.1 I rewrite it as this:</p>

<code>template<typename t=""> struct X {
  struct iterator { typedef T type; };
  X(typename iterator::type);
};</typename></code>

<p>If one of my users upgrades to C++17, with this change in the 
language, I am no longer complying with the terms of my licensing. 
Likewise, if this language change happens between me releasing 1.0 and 
1.1, I can no longer release version 1.1 because it might break some of 
my existing customers.</p>

<p>The point is: current code does not express any intent about whether 
class template parameters are deducible, based on whether they use the 
version 1.0 code or the version 1.1 code. But this change makes that 
implicit property into part of the de facto interface of the code.</p>
</a><h3><a name="CodeCompatibility"></a><a name="ProsConsImplicit">Pros and cons of implicit deduction guides</a></h3>
<p>In light of the above, we think it is worth calling out the benefits and
	costs of providing implicit deduction guides versus requiring explicit
	deduction guides everywhere</p>

<p>Basically, having to manually specify boilerplate for what is obviously expected has an 
	insidious cost as any (honest) Java programmer can tell you. There are natural
	implementations of all of the examples in <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/Problem">The Problem</a> section
	above where only implicit deduction guides are necessary. (Alternate implementations of
	those classes may require explicit guides but do not create unnatural deductions). As many classes have
	dozens of constructors, not only is creating myriad explicit deduction guides tedious and
	error-prone but will (predictably) drift out of sync with the actual constructors as the class 
	evolves. While not suitable for all purposes, this is a much-requested feature to
	simplify routine programming (cf. range-based <tt>for</tt>) and current practice or
	explicit deduction guides remain available (see next paragraph for exceptions) 
	if the implicit deduction is not sufficient, mitigating downside.</p>
	<p>So what is the cost of implicit deduction guides? The <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/CodeCompatibility">Code compatibility</a>
	section above shows that equivalent code in C++14 may no longer be equivalent in C++17 (Note that
	this example does not change the behavior of C++14 code when compiled with a C++17 compiler). This particular
	incompatibility can be rectified by adding explicit deduction guides as needed.</p>
	<p>Another cost of implicit deduction guides is that they may trigger instantiations that
	cause hard errors. For example, consider the following class</p>
	<code>template&lt;class T&gt; struct X {
     using ty = T::type;
     static auto foo() { return typename T::type{} };
     X(ty); #1
     X(decltype(foo())); #2
     X(T);
  };
		
  template&lt;class T&gt;
  struct X&lt;T*&gt; { 
    X(...);
  };
	</code>
	<p>For such a class, the prototype implementation allows</p>
<code>X x{(int *)0};</code>
<p>but normal instantiation rules suggest a hard error. We plan to discuss implications with
the committee. Note that
the current
<code>X&lt;int *&gt; x{0}</code></p>
remains legal.
	<h3>Universal reference interactions</h3>
By deducing the template arguments, sometimes and rvalue reference can be reinterpreted as a universal
	reference as the following example due to Sebastian Gesemann shows.
<code>template&lt;class T&gt;
    struct Wrapper
    {
        T value;
        Wrapper(T const&amp; x): value(x) {}
        Wrapper(T &amp;&amp; y): value(std::move(x)) {}
    };

    int main()
    {
        std::string foo = "Hello";
        auto w = Wrapper(foo);           // Error
    }
</code>
<p>In the implicit deduction guide for the second constructor, <tt>T &amp;&amp;</tt> is
	now interpreted as a universal reference rather than an rvalue reference, resulting in
	a failure to find a valid match. This does not seem to result in a dangerous deduction
	but rather a failure to compile, but Core should consider this case. 
	The resolution is to write an explicit deduction guide 
	will need to be written to explain the intent. </p>
	<code>template&lt;typename T&gt; Wrapper(T &amp;&amp;y) -&gt; Wrapper&lt;remover_reference_t&lt;T&gt;&gt;;</code>
	<p>Of course,  traditional constructor
	invocation without deduction will continue to work as well.</p>
<h2>Wording</h2>
    <p>Modify the beginning of &sect;3.1 [basic.def] as follows</p>
    <blockquote><p>A declaration (Clause 7) may introduce one or more names into a translation unit or redeclare names
introduced by previous declarations. If so, the declaration specifies the interpretation and attributes of these
        names. A declaration may also have effects including:</p>
<ul><li>a static assertion (Clause 7),</li>
<li>controlling template instantiation (14.7.2),</li>
<li><span class="ins">guiding template parameter deduction for constructors (14.9),</span></li>
<li>use of attributes (Clause 7), and</li>
<li>nothing (in the case of an
empty-declaration
    ).</li></ul> A declaration is a <em>definition</em> unless it declares a function without specifying the function's
    body (8.), it contains the <tt>extern</tt> specifier (7.1.1) or a <em>linkage-specification</em> and neither
    an <em>initializer</em> nor a <em>function-body</em>, <span class="ins">it declares a <em>deduction-guide</em> (14.9),</span>
    it declares a static data member in a class definition (9.2, 9.2.3), <span class="comment">...</span></blockquote>
    <p>Insert a paragraph after &sect;5.2.3p1 [expr.type.conv] as follows:</p>
    <blockquote>A <em>simple-type-specifier</em>
(7.1.6.2) or <em>typename-specifier</em>
        (14.6) followed by a parenthesized <em>expression-list</em>
constructs a value of the specified type given the expression list. If the expression list is a single expression,
the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding
cast expression (5.4). If the type specified is a class type, the class type shall be complete. If the expression
list specifies more than a single value, the type shall be a class with a suitably declared constructor (8.5, 12.1),
and the expression
<tt>T(x1, x2, ...)</tt>
is equivalent in effect to the declaration
<tt>T t(x1, x2, ...);</tt>
for some
invented variable
<tt>t</tt>
, with the result being the value of
<tt>t</tt>
as a prvalue.
    <p><span class="ins">A <em>template-name</em> 
        corresponding to a class template followed by a parenthesized <em>expression-list</em> constructs a value of a particular type determined as follows. Given such an
        expression <tt>T(x1, x2, ...)</tt>, construct the declaration <tt>T t(x1, x2, ...);</tt> for some invented variable <tt>t</tt>. Define the <em>deduced type</em>
        <tt>U</tt> of <tt>T(x1, x2, ...)</tt> to be
        <tt>decltype(t)</tt>, then the expression <tt>T(x1, x2, ...)</tt> will construct
        the same value of type <tt>U</tt> as the expression <tt>U(x1, x2, ...)</tt>.</span></p></blockquote>
	<p>Change &sect;7p1[dcl.dcl] as follows</p>
<blockquote><em>declaration:
	<div style="margin-left: 2em;">block-declaration<br/>
	nodeclspec-function-declaration<br>
	function-definition<br>
	template-declaration<br>
	<span class="ins">deduction-guide</span><br/>
	explicit-instantiation<br>
	linkage-specification<br>
	namespace-definition<br>
	empty-declaration<br>
	attribute-declaration<br>
    block-declaration</div></em></blockquote>
Also, change the note at the bottom of &sect;7p1 [dcl.dcl] as follows
	<blockquote>[<em>Note: asm-definitions</em> are described in 7.4, and <em>linkage-specifications</em> are
	described in 7.5. <em>Function-definitions</em> are described in 8.4 and 
	<em>template-declaration</em>s <span class="ins">and <em>deduction-guide</em>s</span> are described in Clause 14.</blockquote>
<p>Modify the start of &sect;7.1.6.2 [dcl.type.simple] as follows</p>
<blockquote><p>The simple type specifiers are</p>
<blockquote><em>simple-type-specifier:
	<div style="margin-left: 2em;">nested-name-specifier<sub>opt</sub> type-name<br/>
        nested-name-specifier <span style="font-style:normal"><tt>template</tt></span> simple-template-id<br/>
        <span class="ins">nested-name-specifier<sub>opt</sub> template-name</span><br/>
        <span style="font-style:normal"><tt>char<br/>
        char16_t<br/>
        char32_t<br/>
        wchar_t<br/>
        bool<br/>
        short<br/>
        int<br/>
        long<br/>
        signed<br/>
        unsigned<br/>
        float<br/>
        double<br/>
        void<br/>
        auto<br/></tt>
        <em>decltype-specifier</em></span>
    </div></em></blockquote></blockquote>
<p>Modify &sect;7.1.6.2p2 as follows</p>
    <blockquote>The <em>simple-type-specifier</em> <tt>auto</tt>
is a placeholder for a type to be deduced (7.1.6.4).
        <span class="ins">A <em>type-specifier</em> of the form <tt>typename</tt><sub><em>opt</em></sub> <em>nested-name-specifier<sub>opt</sub> template-name</em> is a placeholder for 
            a deduced class type and shall appear only as a <em>decl-specifier</em> in the <em>decl-specifier-seq</em> of a <em>simple-declaration</em> (7.1.6.5) or as the <em>simple-type-specifier</em> 
            a deduced class type and shall appear only as a <em>decl-specifier</em> in the <em>decl-specifier-seq</em> of a <em>simple-declaration</em> (7.1.6.5) or as the <em>simple-type-specifier</em> 
            in an explicit type conversion (functional notation) (5.2.3). The <em>template-name</em> shall name a class template
            that is not an <em>injected-class-name</em>.</span> The other
<em>simple-type-specifier</em>s specify either a previously-declared type, a type determined from an expression, or one of the
fundamental types (3.9.1). Table 9 summarizes the valid combinations of
<em>simple-type-specifier</em>s and the types
they specify.</blockquote>
<p>Modify Table 9 in &sect;7.1.6.2 [dcl.type.simple] as follows</p>
<blockquote> <table style="width:70%" border="1">
  <tr>
    <th align="left">Specifier(s)</th>
    <th align="left">Type</th>
   </tr>
  <tr>
    <td><em>type-name</em></td>
    <td>the type named</td>
  </tr>
  <tr>
    <td><em>simple-template-id</em></td>
    <td>the type as defined in 14.2</td>
  </tr>
  <tr>
    <td><span class="ins"><em>template-name</em></span></td>
      <td><span class="ins">placeholder for a type to be deduced</span></td>
  </tr>
  <tr>
    <td><tt>char</tt></td>
    <td>&ldquo;char&rdquo;</td>
  </tr>
</table> </blockquote>
<p>Add a new section &sect;7.1.6.5</p>
<blockquote><span class="ins"><b>7.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Deduced Class Template Types&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[deduced.class.type]</b><br/>
If a placeholder for a deduced class type appears as a <em>decl-specifier</em>
in the <em>decl-specifier-seq</em> of a <em>simple-declaration</em>, the <em>init-declarator</em> of that
declaration shall be of the form
<blockquote><span class="ins"><em>declarator-id attribute-specifier-seq<sub>opt</sub> initializer</em>. </span></blockquote>

The placeholder is replaced by the return type of the function
selected by overload resolution for class template deduction (13.3.1.8). If the <em>init-declarator-list</em> contains
    more than one <em>init-declarator</em>, the type that replaces the placeholder shall be the same in each deduction.
    
    <p><span class="ins">[<em>Example:</em></span> <br/>
<blockquote><pre><span class="ins">template&lt;class T&gt; struct container {
    container(T t) {}
    template&lt;class Iter&gt; container(Iter beg, Iter end);
};
template&lt;class Iter&gt;
container(Iter b, Iter e) -&gt; container&lt;typename std::iterator_traits&lt;Iter&gt;::value_type&gt;;
std::vector&lt;double&gt; v = { <span class="comment">/* ... */</span>};

container c(7); <span class="comment">// OK. Deduces int for T</span>
auto d = container(v.begin(), v.end()); <span class="comment">// OK. Deduces double for T</span>
container e{5, 6}; <span class="comment">// Ill-formed. int is not an iterator</span>
</span></pre><span class="ins"><em>&mdash; end example</em>]</span></blockquote></span></blockquote>&nbsp;
<p>Modify the definition of <em>member-declaration</em> near the start of &sect;9.2 [class.mem] as below</p>
<blockquote><em>member-declaration:
    <div style="margin-left: 2em;">attribute-specifier-seq<sub>opt</sub> decl-specifier-seq<sub>opt</sub> member-declarator-list<sub>opt</sub> ;<br/>
    function-definition<br/>
    using-declaration<br/>
    static_assert-declaration<br/>
    template-declaration<br/>
	<span class="ins">deduction-guide</span><br/>
    alias-declaration<br/>
    empty-declaration<br/>
</div></em></blockquote>
<p>Add a new section 13.3.1.8 as follows</p>
<blockquote><span class="ins"><b>13.3.1.8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Class Template Deduction&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[class.template.deduction]</b><br/>
The overload set consists of:
<ul>
 <li><span class="ins"> For each constructor of the class template designated by
   the <em>template-name</em>, a function template with the following properties
     is a candidate:</span>
     <ul>
         <li><span class="ins">The template parameters are the template parameters of the class template followed by the template parameters (including default template arguments) of the constructor, if any.</span></li>
         <li><span class="ins">The types of the function parameters are those of the constructor.</span></li>
         <li><span class="ins">The return type is the class template specialization designated by the <em>template-name</em> and template arguments corresponding to the template parameters obtained from the class template.</span></li></ul>
</li>
    <li> <span class="ins">For each <em>deduction-guide</em>, a function or function template with the following properties is a candidate:</span>
    <ul>
        <li><span class="ins">The template parameters, if any, and function parameters are those of the <em>deduction-guide</em>.</span></li>
        <li><span class="ins">The return type is the <em>simple-template-id</em> of the <em>deduction-guide</em>.</span></li></ul>
    </li>
    </ul></span></blockquote>
<p>Modify the first paragraph of clause 14 [temp] as follows</p>
    <blockquote>The <em>declaration</em> in a <em>template-declaration</em> shall
        <ul><li>declare or define a function, a class, or a variable, or</li>
        <li>define a member function, a member class, a member enumeration, or a static data member of a class
template or of a class nested within a class template, or</li>
        <li>define a member template of a class or class template, or</li>
        <li><span class="ins">be a <em>deduction-guide</em>, or</span></li>
        <li>be an <em>alias-declaration</em>.</li></ul></blockquote>
<p>Modify &sect;14.1p11 [temp.param] as follows:</p>
<blockquote>If a <em>template-parameter</em> of a class template, variable template, or alias template has a default
<em>template-argument</em>, each subsequent <em>template-parameter</em> shall either have a default
<em>template-argument</em> supplied or be a template parameter pack. If a
<em>template-parameter</em> of a primary class template, primary variable template, or
    alias template is a template parameter pack, it shall be the last <em>template-parameter</em>. A template parameter
pack of a function template shall not be followed by another template parameter unless that template
parameter can be deduced from the parameter-type-list (8.3.5) of the function template or has a default
argument (14.8.2). <span class="ins">A template parameter of a deduction guide template (14.9) that does not have a default argument shall be deducible from the parameter-type-list of the deduction guide template.</span></blockquote>
<p>Modify &sect;14.6p3 [temp.res] as follows:</p>
    <blockquote>When a <em>qualified-id</em> is intended to refer to a type that is not a member of the current instantiation (14.6.2.1)
and its <em>nested-name-specifier</em> refers to a dependent type, it shall be prefixed by the keyword
<tt>typename</tt>, forming a
<em>typename-specifier</em>. If the <em>qualified-id</em> in a <em>typename-specifier</em>
does not denote a type <span class="ins">or a class template</span>, the program is ill-formed. </blockquote>
<p>Modify &sect;14.6p4 [temp.res] as follows:</p>
<blockquote>If a specialization of a template is instantiated for a set of <em>template-argument</em>s 
    such that the <em>qualified-id</em> prefixed by <tt>typename</tt> does not denote a type <span class="ins">or a class template</span>, the specialization is ill-formed. 
The usual qualified name lookup (3.4.3) is used to find the <em>qualified-id</em> even in the presence of
<tt>typename</tt>. </blockquote>
<p>Modify &sect;14.6p6 [temp.res] as follows:</p>
<blockquote>If, for a given set of template arguments, a specialization of a template is instantiated that refers to a
<em>qualified-id</em> that denotes a type <span class="ins">or a class template</span>, and the <em>qualified-id</em>
refers to a member of an unknown specialization, the <em>qualified-id</em> shall either be prefixed by
    <tt>typename</tt> or shall be used in a context in which it implicitly names a
type as described above.</blockquote>
<p>Modify &sect;14.6p7 [temp.res] as follows:</p>
<blockquote>Within the definition of a class template or within the definition of a member of a class template following
the <em>declarator-id</em>, the keyword <tt>typename</tt>
is not required when referring to the name of a previously declared
member of the class template that declares a type <span class="ins">or a class template</span>.
    [<em>Note:</em> such names can be found using unqualified name
lookup (3.4.1), class member lookup (3.4.3.1) into the current instantiation (14.6.2.1), or class member access
expression lookup (3.4.5) when the type of the object expression is the current instantiation (14.6.2.2).
    &emdash; <em>end note</em>] </blockquote>
<p>At the end of clause 14 [Template], add a new section</p>	
	<blockquote><h3><span class="ins">14.9 Deduction guides&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[temp.deduction.guide]</span></h3>
		  <p><span class="ins">Deduction guides are used when a <em>template-name</em>
            appears as a type specifier for deducing class types (7.1.6.5). Deduction guides are not found by name lookup. Instead, when performing class template deduction (13.3.1.8), any deduction guides declared for the class template are considered. </span></p>
        <blockquote><span class="ins"><em>deduction-guide:</em></span>
            <div style="margin-left: 2em;"><span class="ins"><em>template-name</em> <tt>(</tt> <em>parameter-declaration-clause</em> <tt>) -&gt;</tt> <em>simple-template-id</em> ;</span></div></div></blockquote>
		<p><span class="ins">The same restrictions apply to the <em>parameter-declaration-clause</em>
            of a deduction guide as in a function declaration (8.3.5). The <em>simple-template-id</em> shall name a class
            template specialization. The
            <em>template-name</em> shall be the same identifier as the 
            <em>template-name</em> of the <em>simple-template-id</em>. 
            A <em>deduction-guide</em> shall
            be declared in the same scope as the corresponding class template.</span></p>

	</body></html>