<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- saved from url=(0068)http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0702r0.html -->
<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; }
ins {background-color:#A0FFA0}
del {background-color:#FFA0A0}
.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;
}
.del {
    background-color:#FFA0A0;
    text-decoration:line-through
}
.TODO {
    background-color: LightYellow;
    color: red;
}
	  
</style>

<title>Language support for Constructor Template Argument Deduction</title>
</head>

<body>
<p>Document number: P0702R1 <br>
Date: 2017-07-14<br>
Reply-To: Mike Spertus, Symantec (<a href="mailto:mike_spertus@symantec.com">mike_spertus@symantec.com</a>)<br>
Wording by Jason Merrill, Red Hat (<a href="mailto:jason@redhat.com">jason@redhat.com</a>)<br/>
Audience: {Evolution, Core} Working Group
</p>

<h1>Language support for Constructor Template Argument Deduction</h1>
<h2>Introduction</h2>
<p>
This paper details some language considerations that emerged in the course of 
    integrating Class Template Argument Deduction into the standard library as
adopted in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0433r2.html">p0433r2</a>
on which we hope to receive clarification from the committee.</p>


<h2>List vs direct initialization</h2>
The current standard wording implies the following:
    <code>tuple t{tuple{1, 2}};<span class="comment">   // Deduces tuple&lt;int, int&gt;</span>
vector v{vector{1, 2}}; <span class="comment">// Deduces vector&lt;vector&lt;int&gt;&gt;</span></code>
    
We find it seems inconsistent and difficult to teach that <tt>vector</tt> prefers deduction from the list constructor while such similar code
    for <tt>tuple</tt> prefers the copy constructor. In Kona, EWG <a href="http://wiki.edg.com/bin/view/Wg21kona2017/P0091R4">voted</a> (wg21-only link) 
    to prefer copying, but it is not clear whether the intent was that this apply
    to cases like <tt>vector</tt> as well.
<p>We would like EWG to clarify what was intended in this case and, if necessary, apply any change as a DR. 
In light of the example above as well as &sect;11.6.4p3.8 [dcl.init.list], we recommend that
    the copy deduction candidate be preferred to the list constructor when initializing
    from a list consisting of a single element if it
    would deduce a type that is reference-compatible with the argument.
</p>

<p>EWG voted in Toronto that cases like <tt>vector{vector{1, 2, 3}}</tt>
  should be vector&lt;int> even for classes that have an initializer_list constructor: 9 | 9 | 11 | 4 | 1
</p>

<h2>Proposed wording</h2>

Modify 16.3.1.8:

<blockquote>
  <ins>When resolving a placeholder for a deduced class type (10.1.7.5) where
  the <i>template-name</i> names a primary class template C,</ins> A set of
  functions and function templates is formed comprising:
  <ul><li>For each constructor of
      <del>the primary class template designated by the
	template-name</del>
      <ins>C</ins>
      , if <del>the template</del>
      <ins>C</ins>
      is defined, a function template with the
      following properties:</li>
    <li>The template parameters are the template parameters of <del>the class template</del>
      <ins>C</ins>
      followed by the
      template parameters (including default template arguments) of the constructor, if any.</li>
    <li>The types of the function parameters are those of the constructor.</li>
    <li>The return type is the class template specialization designated by <del>the template-name</del>
      <ins>C</ins>
      and template
      arguments corresponding to the template parameters <del>obtained from the class template</del>
      <ins>of C</ins>
      .</li>
    <li>If <del>the primary class template</del>
      C is not defined or does not declare any constructors, an additional
      function template derived as above from a hypothetical constructor C().</li>
    <li>...</li>
  </ul>

  <p/>Initialization and overload resolution are performed as described in 11.6 and
  16.3.1.3, 16.3.1.4, or 16.3.1.7 (as appropriate for the type of
  initialization performed) for an object of a hypothetical class type, where
  the selected functions and function templates are considered to be the
  constructors of that class type for the purpose of forming an overload set,
  and the initializer is provided by the context in which class template
  argument deduction was performed. <ins>As an exception, the first phase in
  16.3.1.7 (considering initializer-list constructors) is omitted
  if the initializer list consists of a single expression of type cv U, where U
  is a specialization of C or a class derived from a specialization of
  C.</ins> Each such notional constructor is considered to be explicit if the
  function or function template was generated from a constructor or
  deduction-guide that was declared explicit. All such notional constructors
  are considered to be public members of the hypothetical class type.
</blockquote>

</body></html>
