<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 868: Default construction and value-initialization</title>
<meta property="og:title" content="Issue 868: Default construction and value-initialization">
<meta property="og:description" content="C++ library issue. Status: C++11">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue868.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#C++11">C++11</a> status.</em></p>
<h3 id="868"><a href="lwg-defects.html#868">868</a>. Default construction and value-initialization</h3>
<p><b>Section:</b> 23 <a href="https://wg21.link/containers">[containers]</a> <b>Status:</b> <a href="lwg-active.html#C++11">C++11</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#containers">active issues</a> in [containers].</p>
<p><b>View all other</b> <a href="lwg-index.html#containers">issues</a> in [containers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++11">C++11</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The term "default constructed" is often used in wording that predates
the introduction of the concept of value-initialization. In a few such
places the concept of value-initialization is more correct than the
current wording (for example when the type involved can be a built-in)
so a replacement is in order. Two of such places are already covered by
issue <a href="lwg-closed.html#867" title="Valarray and value-initialization (Status: NAD Editorial)">867</a><sup><a href="https://cplusplus.github.io/LWG/issue867" title="Latest snapshot">(i)</a></sup>. This issue deliberately addresses the hopefully
non-controversial changes in the attempt of being approved more quickly.
A few other occurrences (for example in <code>std::tuple</code>,
<code>std::reverse_iterator</code> and <code>std::move_iterator</code>) are left to separate
issues. For <code>std::reverse_iterator</code>, see also issue <a href="lwg-closed.html#408" title="Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden? (Status: NAD Editorial)">408</a><sup><a href="https://cplusplus.github.io/LWG/issue408" title="Latest snapshot">(i)</a></sup>. This issue is
related with issue <a href="lwg-defects.html#724" title="DefaultConstructible is not defined (Status: C++11)">724</a><sup><a href="https://cplusplus.github.io/LWG/issue724" title="Latest snapshot">(i)</a></sup>.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
The list provided in the proposed resolution is not complete. James
Dennett will review the library and provide a complete list and will
double-check the vocabulary.
</p>
<p>
This issue relates to Issue <a href="lwg-defects.html#886" title="tuple construction (Status: C++11)">886</a><sup><a href="https://cplusplus.github.io/LWG/issue886" title="Latest snapshot">(i)</a></sup> tuple construction
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
The proposed resolution is incomplete.
</p>
<p>
Move to Tentatively NAD Future. Howard will contact Ganesh for wording.
If wording is forthcoming, Howard will move it back to Review.
</p>
</blockquote>

<p><i>[
2009-07-18 Ganesh updated the proposed wording.
]</i></p>


<blockquote>
<p>
Howard:  Moved back to Review.  Note that 16.4.4.2 <a href="https://wg21.link/utility.arg.requirements">[utility.arg.requirements]</a>
refers to a section that is not in the current working paper, but does refer to
a section that we expect to reappear after the de-concepts merge.  This was a
point of confusion we did not recognize when we reviewed this issue in Frankfurt.
</p>
<p>
Howard:  Ganesh also includes a survey of places in the WP surveyed for changes
of this nature and purposefully <em>not</em> treated:
</p>

<blockquote>
<p>
Places where changes are <span style="text-decoration:underline">not</span> being
proposed
</p>
<p>
In the following paragraphs, we are not proposing changes because
it's not clear whether we actually prefer value-initialization over
default-initialization (now partially covered by <a href="lwg-defects.html#1012" title="reverse_iterator default ctor should value initialize (Status: C++11)">1012</a><sup><a href="https://cplusplus.github.io/LWG/issue1012" title="Latest snapshot">(i)</a></sup>):
</p>
<ul>
    <li><p>20.3.1.3.2 <a href="https://wg21.link/unique.ptr.single.ctor">[unique.ptr.single.ctor]</a> para 3 e 7</p></li>
    <li><p>24.5.1.4 <a href="https://wg21.link/reverse.iter.cons">[reverse.iter.cons]</a> para 1</p></li>
    <li><p> [move.iter.op.const] para 1</p></li>
</ul>
<p>In the following paragraphs, the expression "default
constructed" need not be changed, because the relevant type does
not depend on a template parameter and has a user-provided
constructor:</p>
<ul>
    <li><p> [func.referenceclosure.invoke] para 12, type:
    reference_closure</p></li>
    <li><p>32.4.3.3 <a href="https://wg21.link/thread.thread.constr">[thread.thread.constr]</a> para 30, type: thread</p></li>
    <li><p>32.4.3.6 <a href="https://wg21.link/thread.thread.member">[thread.thread.member]</a> para 52, type: thread_id</p></li>
    <li><p>32.4.5 <a href="https://wg21.link/thread.thread.this">[thread.thread.this]</a>, para 1, type: thread_id</p></li>
</ul>
</blockquote>

</blockquote>

<p><i>[
2009-08-18 Daniel adds:
]</i></p>


<blockquote>
<p>
I have no objections against the currently suggested changes, but I
also cross-checked
with the list regarding intentionally excluded changes, and from this
I miss the discussion
of
</p>

<ol>
<li>
<p>
27.4.3.2 <a href="https://wg21.link/string.require">[string.require]</a> p. 2:
</p>

<blockquote><p>
"[..] The <code>Allocator</code> object used shall be a copy of the <code>Allocator></code>
object passed to the <code>basic_string</code> object's
constructor or, if the constructor does not take an <code>Allocator</code>
argument, a copy of a default-constructed
<code>Allocator</code> object."
</p></blockquote>
</li>

<li>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
29.5.3.4 <a href="https://wg21.link/rand.req.eng">[rand.req.eng]</a>, Table 109, expression "<code>T()</code>":
</p>
<blockquote><p>
Pre-&#47;post-condition: "Creates an engine with the same initial state as
all other default-constructed engines of type <code>X</code>."
</p></blockquote>

<p>
as well as in 29.5.6 <a href="https://wg21.link/rand.predef">[rand.predef]</a>/1-9 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>), 
29.5.8.1 <a href="https://wg21.link/rand.util.seedseq">[rand.util.seedseq]</a>/3, 31.7.5.2.2 <a href="https://wg21.link/istream.cons">[istream.cons]</a>/3, 
31.7.6.2.2 <a href="https://wg21.link/ostream.cons">[ostream.cons]</a>/9 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>), 
28.6.12 <a href="https://wg21.link/re.grammar">[re.grammar]</a>/2, 32.4.3.5 <a href="https://wg21.link/thread.thread.assign">[thread.thread.assign]</a>/1 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>),
</p>
<p><i>[
Candidates for the "the expression "default constructed" need not be
changed" list
]</i></p>


<p>
I'm fine, if these would be added to the intentionally exclusion list,
but mentioning them makes it
easier for other potential reviewers to decide on the relevance or
not-relevance of them for this issue.
</p>
</li>

<li>
<p>
I suggest to remove the reference of  [func.referenceclosure.invoke]
in the "it's not clear" list, because
this component does no longer exist.
</p>
</li>

<li>
<p>
I also suggest to add a short comment that all paragraphs in the
resolution whether they refer to <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf"
>N2723</a> or to <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf"
>N2914</a> numbering, because e.g. "Change 23.3.5.2 <a href="https://wg21.link/deque.cons">[deque.cons]</a> para 5" is an <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf"
>N2723</a> coordinate, while "Change 23.3.5.3 <a href="https://wg21.link/deque.capacity">[deque.capacity]</a> para 1" is an <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf"
>N2914</a> coordinate. Even better would be to use one default document
for the numbering (probably <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf"
>N2914</a>) and mention special cases (e.g. "Change 16.4.4.2 <a href="https://wg21.link/utility.arg.requirements">[utility.arg.requirements]</a> para 2" as referring to <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf"
>N2723</a> numbering).
</p>
</li>
</ol>

</blockquote>

<p><i>[
2009-08-18 Alisdair adds:
]</i></p>


<blockquote>
<p>
I strongly believe the term "default constructed" should not appear in
the library clauses unless we very clearly define a meaning for it, and
I am not sure what that would be.
</p>

<p>
In those cases where we do not want to replace "default constructed"
with "vale initialized" we should be using "default initialized".  If we
have a term that could mean either, we reduce portability of programs.
</p>

<p>
I have not done an exhaustive review to clarify if that is a vendor
freedom we have reason to support (e.g. value-init in debug,
default-init in release) so I may yet be convinced that LWG has reason
to define this new term of art, but generally C++ initialization is
confusing enough without supporting further ill-defined terms.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote><p>
Move to Ready.
</p></blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote><p>
Moved to review in order to enable conflict resolution with <a href="lwg-defects.html#704" title="MoveAssignable requirement for container value type overly strict (Status: C++11)">704</a><sup><a href="https://cplusplus.github.io/LWG/issue704" title="Latest snapshot">(i)</a></sup>.
</p></blockquote>

<p><i>[
2010-03-26 Daniel harmonized the wording with the upcoming FCD.
]</i></p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote><p>
Move to Ready.
</p></blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p id="res-868"><b>Proposed resolution:</b></p>
<p>
Change 16.4.4.2 <a href="https://wg21.link/utility.arg.requirements">[utility.arg.requirements]</a> para 2:
</p>

<blockquote><p>
2 In general, a default constructor is
not required. Certain container class member function signatures
specify <del>the default constructor</del><ins><code>T()</code></ins>
as a default argument. <code>T()</code> shall be a well-defined expression (8.5)
if one of those signatures is called using the default argument
(8.3.6).
</p></blockquote>

<p>
Change 23.3.5.2 <a href="https://wg21.link/deque.cons">[deque.cons]</a> para 3:
</p>

<blockquote><p>
3 <i>Effects:</i> Constructs a deque with <code>n</code>
<del>default constructed</del><ins>value-initialized</ins>
elements. 
</p></blockquote>

<p>
Change 23.3.5.3 <a href="https://wg21.link/deque.capacity">[deque.capacity]</a> para 1:
</p>

<blockquote><p>
1 <i>Effects:</i> If <code>sz &lt; size()</code>, equivalent
to <code>erase(begin() + sz, end());</code>. If <code>size() &lt; sz</code>, 
appends <code>sz - size()</code> <del>default constructed</del><ins>value-initialized</ins>
elements to the sequence.
</p></blockquote>

<p>
Change  [forwardlist.cons] para 3:
</p>

<blockquote><p>
3 <i>Effects:</i> Constructs a <code>forward_list</code> object with <code>n</code> 
<del>default constructed</del><ins>value-initialized</ins> elements.
</p></blockquote>

<p>
Change  [forwardlist.modifiers] para 22:
</p>

<blockquote><p>
22 <i>Effects:</i> [...] For the first signature
the inserted elements are <del>default
constructed</del><ins>value-initialized</ins>,
and for the second signature they are copies of <code>c</code>.
</p></blockquote>

<p>
Change 23.3.11.2 <a href="https://wg21.link/list.cons">[list.cons]</a> para 3:
</p>

<blockquote><p>
3 <i>Effects:</i> Constructs a <code>list</code> with <code>n</code> <del>default
constructed</del><ins>value-initialized</ins>
elements. 
</p></blockquote>

<p>
Change 23.3.11.3 <a href="https://wg21.link/list.capacity">[list.capacity]</a> para 1:
</p>

<blockquote><p>
1 <i>Effects:</i> If <code>sz &lt; size()</code>, equivalent
to <code>list&lt;T&gt;::iterator it = begin(); advance(it, sz); erase(it,
end());</code>. If <code>size() &lt; sz</code>, <code>appends sz - size()</code> 
<del>default constructed</del><ins>value-initialized</ins> elements to 
the sequence.
</p></blockquote>

<p>
Change 23.3.13.2 <a href="https://wg21.link/vector.cons">[vector.cons]</a> para 3:
</p>

<blockquote><p>
3 <i>Effects:</i> Constructs a <code>vector</code> with <code>n</code>
<del>default constructed</del><ins>value-initialized</ins>
elements. 
</p></blockquote>

<p>
Change 23.3.13.3 <a href="https://wg21.link/vector.capacity">[vector.capacity]</a> para 9:
</p>

<blockquote><p>
9 <i>Effects:</i> If <code>sz &lt; size()</code>, equivalent
to <code>erase(begin() + sz, end());</code>. If <code>size() &lt; sz</code>, appends 
<code>sz - size()</code> <del>default constructed</del><ins>value-initialized</ins>
elements to the sequence.
</p></blockquote>






</body>
</html>
