<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2336: is_trivially_constructible/is_trivially_assignable traits are always false</title>
<meta property="og:title" content="Issue 2336: is_trivially_constructible/is_trivially_assignable traits are always false">
<meta property="og:description" content="C++ library issue. Status: C++17">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2336.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++17">C++17</a> status.</em></p>
<h3 id="2336"><a href="lwg-defects.html#2336">2336</a>. <code>is_trivially_constructible/is_trivially_assignable</code> traits are always false</h3>
<p><b>Section:</b> 21.3.6.4 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a> <b>Status:</b> <a href="lwg-active.html#C++17">C++17</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-10-01 <b>Last modified:</b> 2017-07-30</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++17">C++17</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 21.3.6.4 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a> we have traits to allow testing for triviality of specific operations, such as
<code>is_trivially_constructible</code> and <code>is_trivially_assignable</code> (and their derived forms), which are specified
in terms of the following initialization and assignment, respectively:
</p>
<blockquote><pre>
T t(create&lt;Args&gt;()...);

declval&lt;T&gt;() = declval&lt;U&gt;()
</pre></blockquote>
<p>
The wording that describes the way how triviality is deduced, is in both cases of the same form:
</p>
<blockquote><p>
[&hellip; ] and the variable definition/assignment, as defined by <code>is_constructible/is_assignable</code>, is known
to call no operation that is not trivial (3.9, 12).
</p></blockquote>
<p>
The problematic part of this wording is that both definitions are specified in terms of an "object construction" function
<code>create</code> or <code>declval</code>, respectively, (The former being a conceptual function, the latter being a library function), 
but for none of these functions we can assume that they could be considered as trivial &mdash; only special member functions can 
have this property and none of these is one. This problem became obvious, when the similar issue LWG <a href="lwg-defects.html#2298" title="[CD] is_nothrow_constructible is always false because of create&lt;&gt; (Status: C++14)">2298</a><sup><a href="https://cplusplus.github.io/LWG/issue2298" title="Latest snapshot">(i)</a></sup> 
in regard to <code>is_nothrow_constructible</code> was opened.
<p/>
A possible approach to solve this specification problem is to make a blanket statement for sub-clause 21.3.6.4 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a>
that these helper functions are considered trivial for the purpose of defining these traits.
<p/>
Using this kind of wording technique can also be used to get rid of the additional helper function template <code>create</code>, which
is currently needed for the <code>is_convertible</code> and the <code>is_constructible</code> traits, because both traits are specified in
terms of contexts where technically the corresponding "object construction" function would be considered as odr-used. This is problematic,
because these traits are defined in terms of well-formed code and odr-using <code>declval</code> would make the program ill-formed (see
22.2.6 <a href="https://wg21.link/declval">[declval]</a>). So extending above blanket statement to consider <code>std::declval&lt;T&gt;()</code> as not odr-used
in the context of the corresponding trait definition would allow for replacing <code>create</code> by <code>declval</code>.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL: would you consider moving the change to 20.10 as editorial or are you uncomfortable with it?<br/>
JW: this sounds a viable editorial change<br/>
VV: I guarantee you that moving it doesn't change anything<br/>
MC: how about this: we move it to Ready as is and if we conclude moving it is editorial we can do it and if not open an issue<br/>
STL: I would like to guarantee that the lifting happens<br/>
JW: I do that! If it goes in I move it up<br/>
MC: move to Ready: in favor: 15, opposed: 0, abstain: 1 
</p>


<p id="res-2336"><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Add a new paragraph after 21.3.6.4 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a> p3 as indicated: <em>[Editorial note: The first change in
21.3.6.4 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a> p3 is recommended, because technically a Clause is always a "main chapter" &mdash; such as
Clause 20 &mdash; but every child of a Clause or sub-clause is a sub-clause]</em></p>

<blockquote>
<p>
[&hellip;]
<p/>
-3- For all of the class templates <code>X</code> declared in this <del>Clause</del><ins>sub-clause</ins>, instantiating that 
template with a template-argument that is a class template specialization may result in the implicit instantiation of the 
template argument if and only if the semantics of <code>X</code> require that the argument must be a complete type.
<p/>
<ins>-?- For the purpose of defining the templates in this sub-clause, a function call expression 
<code>declval&lt;T&gt;()</code> for any type <code>T</code> is considered to be a trivial (6.9 <a href="https://wg21.link/basic.types">[basic.types]</a>, 11.4.4 <a href="https://wg21.link/special">[special]</a>) 
function call that is not an odr-use (6.3 <a href="https://wg21.link/basic.def.odr">[basic.def.odr]</a>) of <code>declval</code> in the context of the corresponding definition 
notwithstanding the restrictions of 22.2.6 <a href="https://wg21.link/declval">[declval]</a>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 21.3.6.4 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a> p7 as indicated:</p>

<blockquote>
<p>
-7- <del>Given the following function prototype:</del>
</p>
<blockquote><pre>
<del>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();</del>
</pre></blockquote>
<p>
<del>t</del><ins>T</ins>he predicate condition for a template specialization <code>is_constructible&lt;T, Args...&gt;</code> 
shall be satisfied if and only if the following variable definition would be well-formed for some invented variable <code>t</code>:
</p>
<blockquote><pre>
T t(<del>create</del><ins>declval</ins>&lt;Args&gt;()...);
</pre></blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Add a new paragraph after 21.3.8 <a href="https://wg21.link/meta.rel">[meta.rel]</a> p2 as indicated: <em>[Editorial note: Technically we don't need
the guarantee of "a trivial function call" for the type relationship predicates at the very moment, but it seems more robust and
consistent to have the exact same guarantee here as well]</em>
</p>
<blockquote>
<p>
[&hellip;]
<p/>
-2- [&hellip;]
<p/>
<ins>-?- For the purpose of defining the templates in this sub-clause, a function call expression 
<code>declval&lt;T&gt;()</code> for any type <code>T</code> is considered to be a trivial (6.9 <a href="https://wg21.link/basic.types">[basic.types]</a>, 11.4.4 <a href="https://wg21.link/special">[special]</a>) 
function call that is not an odr-use (6.3 <a href="https://wg21.link/basic.def.odr">[basic.def.odr]</a>) of <code>declval</code> in the context of the corresponding definition 
notwithstanding the restrictions of 22.2.6 <a href="https://wg21.link/declval">[declval]</a>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 21.3.8 <a href="https://wg21.link/meta.rel">[meta.rel]</a> p4 as indicated:</p>

<blockquote>
<p>
-4- <del>Given the following function prototype:</del>
</p>
<blockquote><pre>
<del>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();</del>
</pre></blockquote>
<p>
<del>t</del><ins>T</ins>he predicate condition for a template specialization <code>is_convertible&lt;From, To&gt;</code> 
shall be satisfied if and only if the return expression in the following code would be well-formed, including any implicit 
conversions to the return type of the function:
</p>
<blockquote><pre>
To test() {
  return <del>create</del><ins>declval</ins>&lt;From&gt;();
}
</pre></blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>

</ol>






</body>
</html>
