<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    CWG Issue 1967</TITLE>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  .DEL { text-decoration:line-through; background-color: #FFD0D0 }
  @media (prefers-color-scheme: dark) {
    HTML { background-color:#202020; color:#f0f0f0; }
    A { color:#5bc0ff; }
    A:visited { color:#c6a8ff; }
    A:hover, a:focus { color:#afd7ff; }
    INS { background-color:#033a16; color:#aff5b4; }
    .INS { background-color: #033a16; }
    DEL { background-color:#67060c; color:#ffdcd7; }
    .DEL { background-color:#67060c; }
  }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<P><EM>This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21
  Core Issues List revision 118b.
  See http://www.open-std.org/jtc1/sc22/wg21/ for the official
  list.</EM></P>
<P>2025-09-28</P>
<HR>
<A NAME="1967"></A><H4>1967.
  
Temporary lifetime and move-elision
</H4>
<B>Section: </B>11.9.6&#160; [<A href="https://wg21.link/class.copy.elision">class.copy.elision</A>]
 &#160;&#160;&#160;

 <B>Status: </B>CD4
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-07-11<BR>


<P>[Moved to DR at the May, 2015 meeting.]</P>



<P>When copy elision is performed, the lifetime of the
merged object ends at the later of the times the two
objects' lifetimes would have ended.  If the copy elision is
done using a move constructor, however, it might make sense
to assume that the moved-from object's lifetime is no longer
interesting and the lifetime should be that of the moved-to
object.</P>

<P><B>Proposed resolution (April, 2015):</B></P>

<P>Change 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#31">class.copy.ctor</A>] paragraph 31 as follows:</P>

<BLOCKQUOTE>

When certain criteria are met, an implementation is allowed to
omit the copy/move construction of a class object, even if the
constructor selected for the copy/move operation and/or the
destructor for the object have side effects. In such cases, the
implementation treats the source and target of the omitted
copy/move operation as simply two different ways of referring to
the same object<DEL>, and</DEL><INS>. If the first parameter of the
selected constructor is an rvalue reference to the object's type,</INS>
the destruction of that object occurs <INS>when the target would have
been destroyed; otherwise, the destruction occurs</INS> at the
later of the times when the two objects would have been destroyed
without the optimization.<SUP>122</SUP> This elision of copy/move
operations, called <I>copy elision</I>, is permitted...

</BLOCKQUOTE>

<BR><BR>
</BODY>
</HTML>
