<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 801: tuple and pair trivial members</title>
<meta property="og:title" content="Issue 801: tuple and pair trivial members">
<meta property="og:description" content="C++ library issue. Status: Resolved">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue801.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#Resolved">Resolved</a> status.</em></p>
<h3 id="801"><a href="lwg-defects.html#801">801</a>. <code>tuple</code> and <code>pair</code> trivial members</h3>
<p><b>Section:</b> 22.4 <a href="https://wg21.link/tuple">[tuple]</a> <b>Status:</b> <a href="lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple">issues</a> in [tuple].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Classes with trivial special member functions are inherently more
efficient than classes without such functions.  This efficiency is
particularly pronounced on modern ABIs that can pass small classes
in registers.  Examples include value classes such as complex numbers
and floating-point intervals.  Perhaps more important, though, are
classes that are simple collections, like <code>pair</code> and <code>tuple</code>.  When the
parameter types of these classes are trivial, the <code>pair</code>s and <code>tuple</code>s
themselves can be trivial, leading to substantial performance wins.
</p>
<p>
The current working draft make specification of trivial functions
(where possible) much easer through <code>default</code>ed and <code>delete</code>d functions.
As long as the semantics of defaulted and deleted functions match
the intended semantics, specification of defaulted and deleted
functions will yield more efficient programs.
</p>
<p>
There are at least two cases where specification of an explicitly
defaulted function may be desirable.
</p>
<p>
First, the <code>std::pair</code> template has a non-trivial default constructor,
which prevents static initialization of the pair even when the
types are statically initializable.  Changing the definition to
</p>

<blockquote><pre>
pair() = default;
</pre></blockquote>

<p>
would enable such initialization.  Unfortunately, the change is
not semantically neutral in that the current definition effectively
forces value initialization whereas the change would not value
initialize in some contexts.
</p>

<p>
** Does the committee confirm that forced value initialization
was the intent?  If not, does the committee wish to change the
behavior of <code>std::pair</code> in C++0x?
</p>
<p>
Second, the same default constructor issue applies to <code>std::tuple</code>.
Furthermore, the <code>tuple</code> copy constructor is current non-trivial,
which effectively prevents passing it in registers.  To enable
passing <code>tuples</code> in registers, the copy constructor should be
make explicitly <code>default</code>ed.  The new declarations are:
</p>

<blockquote><pre>
tuple() = default;
tuple(const tuple&amp;) = default;
</pre></blockquote>

<p>
This changes is not implementation neutral.  In particular, it
prevents implementations based on pointers to the parameter
types.  It does however, permit implementations using the
parameter types as bases.
</p>
<p>
** How does the committee wish to trade implementation
efficiency versus implementation flexibility?
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
General agreement; the first half of the issue is NAD.
</p>
<p>
Before voting on the second half, it was agreed that a "Strongly Favor"
vote meant support for trivial tuples (assuming usual requirements met),
even at the expense of other desired qualities. A "Weakly Favor" vote
meant support only if not at the expense of other desired qualities.
</p>
<p>
Concensus: Go forward, but not at expense of other desired qualities.
</p>
<p>
It was agreed to Alisdair should fold this work in with his other
pair/tuple action items, above, and that issue 801 should be "open", but
tabled until Alisdair's proposals are disposed of.
</p>
</blockquote>

<p><i>[
2009-05-27 Daniel adds:
]</i></p>


<blockquote><p>
This is partly solved by <a href="lwg-defects.html#1117" title="tuple copy constructor (Status: Resolved)">1117</a><sup><a href="https://cplusplus.github.io/LWG/issue1117" title="Latest snapshot">(i)</a></sup>.
</p></blockquote>

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


<blockquote><p>
Wait for dust to settle from fixing exception safety problem
with rvalue refs.
</p></blockquote>

<p><i>[
2009-07-20 Alisdair adds:
]</i></p>


<blockquote>
<p>
Basically, this issue is what should we do with the default constructor
for pairs and tuples of trivial types.  The motivation of the issue was
to force static initialization rather than dynamic initialization, and
was rejected in the case of pair as it would change the meaning of
existing programs.  The advice was "do the best we can" for tuple
without changing existing meaning.
</p>

<p>
Frankfurt seems to simply wait and see the resolution on no-throw move
constructors, which (I believe) is only tangentially related to this
issue, but as good as any to defer until Santa Cruz.
</p>

<p>
Looking again now, I think constant (static) initialization for pair can
be salvaged by making the default construct constexpr.  I have a
clarification from Core that this is intended to work, even if the
constructor is not trivial/constexpr, so long as no temporaries are
implied in the process (even if elided).
</p>
</blockquote>

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


<blockquote><p>
Leave as open. Alisdair to provide wording.
</p></blockquote>

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


<blockquote>
<p>
We believe this may be NAD Editorial since both pair and tuple now have
constexpr default constructors, but we're not sure.
</p>
</blockquote>


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


<blockquote><p>
Daniel believes his pair&#47;tuple paper will resolve this issue. <code>constexpr</code> 
will allow static initialization, and he is already changing the move and copy 
constructors to be defaulted.
</p></blockquote>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote><p>
The proposed resolution of 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> 
should resolve this issue.
</p></blockquote>



<p id="res-801"><b>Proposed resolution:</b></p>
<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
</p>





</body>
</html>
