<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2388: Handling self-assignment in the proposed library function std::exchange</title>
<meta property="og:title" content="Issue 2388: Handling self-assignment in the proposed library function std::exchange">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2388.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#NAD">NAD</a> status.</em></p>
<h3 id="2388"><a href="lwg-closed.html#2388">2388</a>. Handling self-assignment in the proposed library function <code>std::exchange</code></h3>
<p><b>Section:</b> 22.2.3 <a href="https://wg21.link/utility.exchange">[utility.exchange]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Nick Calus <b>Opened:</b> 2014-05-09 <b>Last modified:</b> 2015-05-05</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#utility.exchange">issues</a> in [utility.exchange].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3668.html">N3668</a>, the addition of a template function 
<code>std::exchange</code> had been proposed. In the rationale provided by the paper, we find the following:
</p>
<blockquote>
<p>
I chose the name for symmetry with <code>atomic_exchange</code>, since they behave the same except for this function not being atomic.
</p>
</blockquote>
<p>
and:
</p>
<blockquote>
<p>
Atomic objects provide an <code>atomic_exchange</code> function ([atomics.types.operations.req]p18) that <em>assigns a new value to the object 
and returns the old value</em>. This operation is also useful on non-atomic objects, and this paper proposes adding it to the library.
<p/>
But the specified semantics of <code>std::exchange</code> is defined as follows:
</p>
</blockquote>
<blockquote><pre>
template &lt;class T, class U=T&gt; T exchange(T&amp; obj, U&amp;&amp; new_val);
</pre>
<blockquote>
<p>
<i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
T old_val = std::move(obj);
obj = std::forward&lt;U&gt;(new_val);
return old_val;
</pre>
</blockquote>
</blockquote>
</blockquote>
<p>
When looking at the post-condition of the <code>std::exchange</code> function, one would expect the return value to be the old value 
of <code>obj</code> and also that <code>obj</code> now contains the value of <code>new_value</code>.
This post-condition is violated when <code>obj</code> is a reference to the same object as <code>new_value</code> and type <code>T</code> 
has move semantics.
<p/>
Given it's specification, it is clear that <code>std::exchange</code> is meant to be used with types that have move semantics.
Therefore, the post-condition is violated for self-assignments.
<p/>
Suppose the following situation:
<p/>
You have a vector of objects. The objects implement move semantics and are emptied when moved from.
You provide a function that allows you to replace an object at a specific index by a new object (provided by reference as 
an argument to your function). When replacing an object, your function calls a member-function <code>do_something_fancy</code> 
on the old object.
</p>
<blockquote><pre>
void your_function(int i, X&amp; new_val) {
  std::exchange(vec[i], new_val).do_something_fancy();
}
</pre></blockquote>
<p>
Your function gets called with a given index and the corresponding element of said vector. (by coincidence or by purpose, it 
doesn't really matter)
</p>
<blockquote><pre>
your_function(5, vec[5]);
</pre></blockquote>
<p>
This will cause the object at <code>vec[5]</code> to be in an empty state.
If this object would not implement move semantics, assignment performance is potentially worse, but at least it 
is not in an empty (to my business logic, invalid) state.
<p/>
So to me, the current reference implementation of <code>std::exchange</code> does not have the behavior it is expected to have.
</p>

<p><i>[2014-12-18 Telecon]</i></p>

<p>
MC: does this resolution solve the problem?
<p/>
JW: and is the cost of the extra construction and move acceptable?
<p/>
AM: not all moves are cheap
<p/>
VV: seems like a design change
<p/>
JW: maybe this should be rolled into my unwritten paper on self-swap, so we deal with them consistently
<p/>
VV: we should update the issue saying something like that and maybe NAD Future
<p/>
MC: instead, add Requires clause saying the arguments are not the same.
<p/>
JW: interesting, that can even be checked in a debug mode assertion
<p/>
MC: ACTION: send alternative P/R that we can consider
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 22.2.3 <a href="https://wg21.link/utility.exchange">[utility.exchange]</a> as indicated:</p>
<blockquote><pre>
template &lt;class T, class U=T&gt; T exchange(T&amp; obj, U&amp;&amp; new_val);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
<ins>T tmp = std::forward&lt;U&gt;(new_val);</ins>
T old_val = std::move(obj);
obj = <del>std::forward&lt;U&gt;(new_val)</del><ins>std::move(tmp)</ins>;
return old_val;
</pre>
</blockquote>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p>
<strong>Previous resolution from Marshall [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N4296.</p>

<ol>
<li><p>Change 22.2.3 <a href="https://wg21.link/utility.exchange">[utility.exchange]</a> as indicated:</p>
<blockquote><pre>
template &lt;class T, class U=T&gt; T exchange(T&amp; obj, U&amp;&amp; new_val);
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires</i>: <code>obj</code> and <code>new_val</code> shall not refer to the same object.</ins>
<p/>
-1- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
T old_val = std::move(obj);
obj = std::forward&lt;U&gt;(new_val);
return old_val;
</pre>
</blockquote>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-03-30, Marshall provides alternative wording]</i></p>


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

<p>
MC: self <code>exchange</code> does not work<br/>
MC: PR is just to add requires<br/>
STL: what if the new thing is a subobject, isn't that just as bad, any aliasing<br/>
STL: don't know that we need to do anything here if we aren't changing the implementation<br/>
NM: should remove the requires<br/>
MC: so NAD<br/>
STL: could add note<br/>
NM: remove requires<br/>
DK: requires isn't already there<br/>
RL: no note?<br/>
STL: no note, NAD, burden for next person that asks about aliasing<br/>
DK: what do we do for <code>swap</code>?<br/>
STL: self <code>swap</code> has always been noop, <code>exchange</code> could do something bad because it clears out<br/>
MC: alright, NAD it is<br/>
</p>



<p id="res-2388"><b>Proposed resolution:</b></p>
The current specification is clear about the implications described by the issue example and is as intended.





</body>
</html>
