<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2152: Instances of standard container types are not swappable</title>
<meta property="og:title" content="Issue 2152: Instances of standard container types are not swappable">
<meta property="og:description" content="C++ library issue. Status: LEWG">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2152.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#LEWG">LEWG</a> status.</em></p>
<h3 id="2152"><a href="lwg-active.html#2152">2152</a>. Instances of standard container types are not swappable</h3>
<p><b>Section:</b> 16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>, 23.2.2 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> <b>Status:</b> <a href="lwg-active.html#LEWG">LEWG</a>
 <b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#swappable.requirements">issues</a> in [swappable.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#LEWG">LEWG</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Sub-clause 16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a> defines two notions of swappability: a binary version defining
when two objects are <em>swappable with</em> one another, and a unary notion defining whether an object is 
<em>swappable</em> (without qualification), with the latter definition requiring that the object satisfy the 
former with respect to all values of the same type.
<p/>
Let <code>T</code> be a container type based on a non-propagating allocator whose instances do not necessarily 
compare equal. Then sub-clause 23.2.2 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> p7 implies that no object <code>t</code> 
of type <code>T</code> is swappable (by the unary definition).
<p/>
Throughout the standard it is the unary definition of "swappable" that is listed as a requirement (with the 
exceptions of 22.2.2 <a href="https://wg21.link/utility.swap">[utility.swap]</a> p4, 22.3.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a> p31, 22.4.4.4 <a href="https://wg21.link/tuple.swap">[tuple.swap]</a> p2, 
26.7.3 <a href="https://wg21.link/alg.swap">[alg.swap]</a> p2, and 26.7.3 <a href="https://wg21.link/alg.swap">[alg.swap]</a> p6, which use the binary definition). This renders 
many of the mutating sequence algorithms of sub-clause 26.7 <a href="https://wg21.link/alg.modifying.operations">[alg.modifying.operations]</a>, for example, 
inapplicable to sequences of standard container types, even where every element of the sequence is swappable 
with every other.
<p/>
Note that this concern extends beyond standard containers to all future allocator-based types.
<p/>
Resolution proposal:
<p/>
I see two distinct straightforward solutions:
</p>
<ol style="list-style-type:lower-roman">
<li>Modify the requirements of algorithms from sub-clause 26.7 <a href="https://wg21.link/alg.modifying.operations">[alg.modifying.operations]</a>, and all other
places that reference the unary "swappable" definition, to instead use the binary "swappable with" definition 
(over a domain appropriate to the context). The unary definition of "swappable" could then be removed from the 
standard.
</li>
<li>Modify sub-clause 23.2.2 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> such that objects of standard container types 
are "swappable" by the unary definition.
</li>
</ol>
<p>
I favor the latter solution, for reasons detailed in the following issue.
</p>

<p><i>[
2012-10 Portland: Move to Open 
]</i></p>


<p>
The issue is broader than containers with stateful allocotors, although they are the most obvious
example contained within the standard itself.  The basic problem is that once you have a stateful
allocator, that does not <code>propagate_on_swap</code>, then whether two objects of this type can be
swapped with well defined behavior is a run-time property (the allocators compare equal) rather
than a simple compile-time property that can be deduced from the type.  Strictly speaking, any
type where the nature of swap is a runtime property does not meet the <code>swappable</code>
requirements of C++11, although typical sequences of such types are going to have elements that
are all <code>swappable with</code> any other element in the sequence (using our other term of art
for specifying requirements) as the common case is a container of elements who all share the
same allocator.
</p>

<p>
The heart of the problem is that the <code>swappable</code> requirments demand that any two objects
of the same type be <code>swappable with</code> each other, so if any two such objects would not
be <code>swappable with</code> each other, then the whole type is never <code>swappable</code>.  Many
algorithms in clause 25 are specified in terms of <code>swappable</code> which is essentially an
overspecification as all they actually need is that any element in the sequence is <code>swappable
with</code> any other element in the sequence.
</p>

<p>
At this point Howard joins the discussion and points out that the intent of introducing the
two swap-related terms was to support <code>vector&lt;bool&gt;::reference</code> types, and we are
reading something into the wording that was never intended.  Consuses is that regardless of
the intent, that is what the words today say.
</p>

<p>
There is some support to see a paper reviewing the whole of clause 25 for this issue, and
other select clauses as may be necessary.
</p>

<p>
There was some consideration to introducing a note into the front of clause 25 to indicate
<code>swappable</code> requirements in the clause should be interpreted to allow such awkward
types, but ultimately no real enthusiasm for introducing a <code>swappable for clause 25</code>
requirement term, especially if it confusingly had the same name as a term used with a
subtly different meaning through the rest of the standard.
</p>

<p>
There was no enthusiasm for the alternate resolution of requiring containers with unequal
allocators that do not propagate provide a well-defined swap behavior, as it is not
believed to be possible without giving <code>swap</code> linear complexity for such values,
and even then would require adding the constraint that the container element types are
CopyConstructible.
</p>

<p>
Final conclusion: move to open pending a paper from a party with a strong interest in
stateful allocators.
</p>

<p><i>[2016-03 Jacksonville]</i></p>

<p>
Alisdair says that his paper <a href="https://wg21.link/P0178">P0178</a> addresses this.
</p>

<p><i>[2016-06 Oulu]</i></p>

<p><a href="https://wg21.link/P0178">P0178</a> reviewed, and sent back to LEWG for confirmation.</p>
<p>Thursday Morning: A joint LWG/LEWG meeting declined to adopt <a href="https://wg21.link/P0178">P0178</a>.</p>

<p><i>[2017-02 in Kona, LEWG responds]</i></p>

<p>Note in the issue that this is tracked <a href="https://issues.isocpp.org/show_bug.cgi?id=152">here</a></p>

<p><i>[2017-06-02 Issues Telecon]</i></p>

<p>Leave as LEWG; priority 3</p>


<p id="res-2152"><b>Proposed resolution:</b></p>
<p>
Apply <a href="https://wg21.link/P0178">P0178</a>.
</p>





</body>
</html>
