<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">



<TITLE>Defining Swappable Requirements</TITLE>

<STYLE type="text/css">
  p {text-align:justify}
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  blockquote.note
  {
   background-color:#E0E0E0;
   padding-left: 15px;
   padding-right: 15px;
   padding-top: 1px;
   padding-bottom: 1px;
  }
</STYLE>
</HEAD><BODY>
<ADDRESS style="text-align: left;">
Document number: N3048=10-0038<BR>
Project: Programming Language C++, Library Working Group<BR>
Author: <A href="mailto:daniel.kruegler@googlemail.com">Daniel Krgler</A>,
<A href="mailto:mike_spertus@symantec.com">Mike Spertus</A>,
<A href="mailto:stefanus.du.toit@intel.com">Stefanus Du Toit</A>,
<A href="mailto:wb@fnal.gov">Walter E. Brown</A><BR>
Date: 2010-03-12
</ADDRESS>
<HR>
<H1 style="text-align: center;">Defining Swappable Requirements</H1>

<UL>
<LI><A href="#Discussion">Discussion</A></LI>
<LI><A href="#Rationale">Design Rationale</A></LI>
<LI><A href="#updated_rationale">Updated Rationale and Later Changes</A></LI>
<LI><A href="#Issues_Resolved">Resolved Issues</A></LI>
<LI><A href="#Proposed_resolution">Proposed resolution</A></LI>
<LI><A href="#Akn">Acknowledgements</A></LI>
</UL>

<H2><A name="Discussion"></A>Discussion</H2>

<P>
With the removal of concepts,
library issues <A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</A>
and <A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</A> are no longer automatically solved
via the concepts <TT>std::HasSwap</TT> and <TT>std::Swappable</TT>. This paper attempts to suggest a solution that has
the nearest-possible effect as the concept solution had, but that is valid for non-template code or unconstrained template code as well.
The proposal herein attempts to discard some unnecessary constraints and inconsistencies of the current <TT>Swappable</TT> requirements, as
documented by the current wording within Table 37 ([swappable]):
</P><P>
</P><BLOCKQUOTE class="note"><P>
  The <TT>Swappable</TT> requirement is met by satisfying one or more of the following conditions:
  </P><UL>
  <LI><TT>T</TT> is <TT>Swappable</TT> if <TT>T</TT> satisfies the <TT>MoveContructible</TT> requirements (Table 33) and
  	  the <TT>MoveAssignable</TT> requirements (Table 35);
  </LI>
  <LI><TT>T</TT> is <TT>Swappable</TT> if a namespace scope function named <TT>swap</TT> exists in the same namespace as the
  definition of <TT>T</TT>, such that the expression <TT>swap(s, t)</TT> is valid and has the semantics described in this table.
  </LI>
  <LI><TT>T</TT> is <TT>Swappable</TT> if <TT>T</TT> is an array type whose element type is <TT>Swappable</TT>.
  </LI>
  </UL>
</BLOCKQUOTE>
<P>
The specific issues to be addressed are:
</P><OL>
<LI>The requirements are inconsistent, because they do not say in an unambigious way what user code has to do to satisfy the requirements.
</LI>
<LI>The dependency on <TT>MoveContructible</TT> and <TT>MoveAssignable</TT> for <EM>some special cases</EM> (the first bullet in above list) is
	very unfortunate, because the second bullet already provides a recipe that would just impose the requirements on the actual chosen <TT>swap</TT>
	overload. If this overload were a user-defined <TT>swap</TT> function, the requirements are only those of this particular
	function. This is the key problem described in library issue <A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</A>.
</LI>
<LI>The requirement of the third bullet is unnecessary, because the standard now provides a <TT>swap</TT> overload for arrays
	as part of the header <TT>&lt;utility&gt;</TT>. If we think of the array <TT>swap</TT> of a function that just forwards
	to the appropriate swap of the array's elements, this would just be the same approach as described in the bullet 2.
</LI>
<LI>Delegating to a single and unambiguous <TT>swap</TT> overload if the two <TT>swap</TT> function templates of <TT>&lt;utility&gt;</TT>
	are part of the candidate set would automatically remove any specific requirements on lvalue-ness of the arguments. In fact, it would
	just delegate to the lvalue-ness of the selected swap function. This is the key problem described in library issue
	<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</A>.
</LI>
<LI>The current <TT>Swappable</TT> requirements restrict the return type of the <TT>swap</TT> function to <TT>void</TT>. This is
	both unnecessary and atypical compared to most existing requirement sets and can be relaxed.
</LI>
</OL>
<P>

</P><H2><A name="Rationale"></A>Design Rationale</H2>
<P>
The approach used in this paper adapts the two concepts
</P><P>
</P><BLOCKQUOTE><PRE>auto concept HasSwap&lt;typename T, typename U&gt; {
  void swap(T, U);
}

auto concept Swappable&lt;typename T&gt; : HasSwap&lt;T&amp;, T&amp;&gt; { }
</PRE></BLOCKQUOTE>
<P>
to a wording form compatible with non-concept C++. Therefore this proposal
defines some normative phrases as part of Table 37  <TT>Swappable</TT> requirements [swappable]
roughly as follows:
</P><OL>
<LI><TT>HasSwap&lt;T, U&gt;</TT> &#8660; "<TT>std::declval&lt;T&gt;()</TT> is <STRONG>swappable with</STRONG> <TT>std::declval&lt;U&gt;()</TT>"
</LI>
<LI><TT>Swappable&lt;T&gt;</TT> &#8660; "<TT>T</TT> satisfies the <STRONG><TT>Swappable</TT></STRONG> requirements"
</LI>
</OL>
<P>
The first form uses expressions, matching the current style used in the library
specification of requirements that need a finer granularity than named requirements like
<TT>MoveConstructible</TT>, <TT>EqualityComparable</TT>, or <TT>Swappable</TT> would allow for.
We also suggest a third form as a replacement for the degenerate situation
</P><P>
"<TT>std::declval&lt;T&gt;()</TT> is <STRONG>swappable</STRONG>" &#8660; "<TT>std::declval&lt;T&gt;()</TT> is <STRONG>swappable with</STRONG> <TT>std::declval&lt;T&gt;()</TT>"
</P><P>
because this special case occurs frequently in the library specification. [Note that this relation is not the same
as <TT>Swappable&lt;T&gt;</TT>, because the former also supports the swapping of two rvalues]. One reviewer did not like
this wording form of this shortcut, because it would shift the inherent binary relation of swappable to a unary relation.
As a reply to this criticism two points are noteworthy:
</P><UL>
<LI>The phrase "<TT>T</TT> meets the <TT>Swappable</TT> requirements" is a similar unary reduction and that fact has
	never been considered as a fundamental defect.
</LI>
<LI>It is still possible to define wording forms that could better express the existing binary relation,
	e.g. we could instead use:
<P>
"<TT>std::declval&lt;T&gt;()</TT> is <STRONG>self-swappable</STRONG>"
</P><P>
We did not suggest this wording form because most reviewers were fine with the "<STRONG>is swappable</STRONG>" form.
</P></LI>
</UL>
<P>
The equivalences shown above only roughly apply,
because we cannot exactly simulate the special
lookup rules for concept maps in a concept-free language.
As an approximation to that lookup behavior,
a lookup context is defined in an ADL-friendly way
which allows for arrays,
for all types that do not define their own <TT>swap</TT> function,
and for all ADL-unaware types (the fundamental types)
to find the two <TT>std::swap</TT>
function templates from the header <TT>&lt;utility&gt;</TT>.
Wording is carefully crafted to avoid requiring library implementors
to include header <TT>&lt;utility&gt;</TT>,
so that they are free to take advantage
of their own internal header organization 
only user code is required to include
<TT>&lt;utility&gt;</TT> to realize the same thing.
The following example demonstrates the well-known idiom
for user code to realize a proper swappable context:
</P><P>
</P><BLOCKQUOTE><PRE>#include &lt;utility&gt;

namespace User {

  // Requires: T shall satisfy the Swappable requirements.
  template&lt;class T&gt;
  void my_swap(T&amp; t1, T&amp; t2) {
    using std::swap;
    swap(t1, t2); // OK: Uses swappable conditions for lvalues of type T
  }

}
</PRE></BLOCKQUOTE>
<H2><A name="updated_rationale"></A>Updated Rationale and Later Changes</H2>
<P>
At the March 2010 C++ meeting in Pittsburgh, a draft version of this
paper was reviewed and enhanced in several ways.
</P>
<P>
Most importantly, it was realized that the Swappable requirement (even
when updated as described above) is more constrained than appropriate
for most of its uses. In particular, many standard algorithms require
the type of an expression obtained by dereferencing an iterator to
satisfy Swappable. When expressed as a requirement on the <I>type</I>
of such an expression, it is not possible (or at least not simple) to
allow for cases where dereferencing such an iterator yields an
rvalue (in addition to the case where the dereferencing yields an lvalue).
</P>
<P>Such iterators, which yield rvalues when dereferenced, are common
in existing practice when the object returned needs to be a proxy of
some kind (thus giving rise to the term <I>proxy iterator</I>). A
simple example of such iterators in the standard library are those of
<TT>vector&lt;bool&gt;</TT>.</P>

<P>To address this issue, the proposed wording was updated to
introduce a new <TT><I>ValueSwappable</I></TT> requirement. Rather than
stating a requirement on the <I>types</I> of these dereferenced
iterator expressions, this requirement is instead intended to apply to the
<I>iterator</I> type, and thus to place a restriction on the dereferencing
<I>expressions</I> themselves. This allows simple wording that applies
equally to applicable iterators whether they yield lvalues or rvalues.</P>

<P>Nearly all existing uses of the <TT>Swappable</TT> requirement can
be replaced with a use of <TT>ValueSwappable</TT> instead. Where
<TT>Swappable</TT> was previously listed as a requirement on a type
not matching a dereferenced iterator expression, the phrase <I>lvalues
of type T shall be swappable</I> is used instead, which most closely
matches the intent of these cases.</P>

<P>In addition to the <TT>ValueSwappable</TT> requirement, the
proposed resolution was updated to introduce a symmetry requirement on
the <I>swappable with</I> construction. This ensures that swappable
values behave as expected in certain scenarios.</P>

<P>Finally, some small improvements were made to fix
editorial issues in the previous draft.</P>
<P>

</P><H2><A name="Issues_Resolved"></A>Resolved Issues</H2>
<P>
If the proposed resolution is accepted,
the following library issues will be resolved:
</P>
<TABLE border="1">
  <TBODY><TR>
    <TH>Number</TH>
    <TH>Description</TH>
  </TR>
  <TR>
    <TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</A></TD>
    <TD>Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</TD>
  </TR>
  <TR>
    <TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</A></TD>
    <TD>Enabling swap for proxy iterators</TD>
  </TR>
</TBODY></TABLE>
<P>
In addition,
we believe that accepting this proposal
will allow easier resolution of library issue
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</A>.
</P>

<H2><A name="Proposed_resolution"></A>Proposed resolution</H2>

<OL>

<LI>Change [utility.requirements]/1 as indicated <I>[Note to the editor: The second inserted sentence should be added
only if 1245 has been accepted]</I>:<BR>
<P>20.2.1 describes requirements on types <INS>and expressions</INS> used to instantiate templates defined in the C++ standard 
	library. <INS>20.2.2 describes the requirements on swappable types and swappable expressions. 20.2.3 describes the requirements 
		on hash functions.</INS> 20.2.4 describes the requirements on storage allocators.</P><P>
</P></LI>

<LI>In subclause [utility.arg.requirements], remove Table 37  Swappable requirements [swappable]:<BR>
<P>
</P><BLOCKQUOTE>
<TABLE border="1">
<CAPTION><DEL>Table 37  <TT>Swappable</TT> requirements <B>[swappable]</B></DEL></CAPTION>

<TBODY><TR>
<TH><DEL>Expression</DEL></TH>
<TH><DEL>Return type</DEL></TH>
<TH><DEL>Post-condition</DEL></TH>
</TR>
<TR>
<TD>
<DEL><TT>swap(s, t)</TT></DEL>
</TD>
<TD>
<DEL><TT>void</TT></DEL>
</TD>
<TD>
<DEL><TT>t</TT> has the value originally held by <TT>s</TT> and <TT>s</TT> has the value originally held by <TT>t</TT></DEL>
</TD>
</TR>
<TR>
<TD colspan="3">
	<BR>
  <DEL>The <TT>Swappable</TT> requirement is met by satisfying one or more of the following conditions:</DEL>
  <UL>
  <LI><DEL><TT>T</TT> is <TT>Swappable</TT> if <TT>T</TT> satisfies the <TT>MoveContructible</TT> requirements (Table 33) and
  	  the <TT>MoveAssignable</TT> requirements (Table 35);</DEL>
  </LI>
  <LI><DEL><TT>T</TT> is <TT>Swappable</TT> if a namespace scope function named <TT>swap</TT> exists in the same namespace as the
  definition of <TT>T</TT>, such that the expression <TT>swap(s, t)</TT> is valid and has the semantics described in this table.</DEL>
  </LI>
			<LI><DEL><TT>T</TT> is <TT>Swappable</TT> if <TT>T</TT> is an array type whose element type is <TT>Swappable</TT>.</DEL>
  </LI>
  </UL>
</TD>
</TR>
</TBODY></TABLE>
</BLOCKQUOTE>
</LI>

<LI>Following [utility.arg.requirements] add a new subclause: <I>[Comment to the editor: This means that all current links to 
	Table 37  Swappable requirements [swappable] have to be changed into links to subclause [swappable.requirements]. These 
	changes are <STRONG>not</STRONG> shown in the following directives.]</I><BR>
<P>
<B>20.2.2 Swappable requirements [swappable.requirements]</B><BR>
</P><P>This subclause provides definitions for swappable types and expressions. In these definitions, let <TT>t</TT> denote an expression of a type <TT>T</TT>, and let <TT>u</TT> denote an expression of a type <TT>U</TT>.</P>

<P>An object designated <TT>t</TT> is <I>swappable with</I> an object designated <TT>u</TT> if and only if:</P>

<UL>
<LI>the expressions <TT>swap(t, u)</TT> and <TT>swap(u, t)</TT> are valid when evaluated in the context described below, and</LI>
<LI>these expressions achieve the following postconditions:
<UL>
<LI>the object referred to by <TT>t</TT> has the value originally held by <TT>u</TT>, and</LI>
<LI>the object referred to by <TT>u</TT> has the value originally held by <TT>t</TT>.</LI>
</UL>
</LI>
</UL>

<P>The context in which <TT>swap(t, u)</TT> and <TT>swap(u, t)</TT> are evaluated shall ensure that a binary non-member function 
	named "swap" is selected via overload resolution ([over.match]) on a candidate set that includes:</P>
<UL>
<LI>the two <TT>swap</TT> function templates from [utility], and</LI>
<LI>the lookup set produced by argument-dependent lookup ([basic.lookup.argdep]).</LI>
</UL>

<P>
[<I>Note</I>: If T and U are both fundamental types or arrays thereof, and the declarations from the header <TT>&lt;utility&gt;</TT> are in scope, the overall lookup set described above is equivalent to that of the qualified name lookup applied to the expression <TT>std::swap(t, u)</TT> or <TT>std::swap(u, t)</TT> as appropriate.  <I>end note</I>]
</P>

<P>
[<I>Note</I>: It is unspecified whether a library component that has a swappable requirement includes the header <TT>&lt;utility&gt;</TT> to ensure an appropriate evaluation context.  <I>end note</I>]
</P>

<P>An rvalue or lvalue <TT>t</TT> is <I>swappable</I> if and only if <TT>t</TT> is swappable with any rvalue or lvalue of type <TT>T</TT> respectively.
</P>

<P>
A type <TT>X</TT> satisfying one of the iterator requirements of Clause 24 is <I>ValueSwappable</I> if <TT>*x</TT> is swappable
for any dereferenceable object <TT>x</TT> of type <TT>X</TT>.
</P>

<P>[<I>Example</I>: User code can ensure the evaluation of <TT>swap</TT> calls is performed in an appropriate context under the various conditions as follows:
</P><PRE>#include &lt;utility&gt;

// Requires: std::forward&lt;T&gt;(t) shall be swappable with std::forward&lt;U&gt;(u).
template&lt;class T, class U&gt;
void value_swap(T&amp;&amp; t, U&amp;&amp; u) {
  using std::swap;
  swap(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u)); // OK: Uses "swappable with" conditions for rvalues and lvalues
}

// Requires: lvalues of T shall be swappable.
template&lt;class T&gt;
void lv_swap(T&amp; t1, T&amp; t2) {
  using std::swap;
  swap(t1, t2); // OK: Uses swappable conditions for lvalues of type T
}

namespace N {
  struct A { int m; };
  struct Proxy { A* a; };
  Proxy proxy(A&amp; a) { return Proxy{&amp;a}; }

  void swap(A&amp; x, Proxy p) {
    std::swap(x.m, p.a-&gt;m); // OK: Uses context equivalent to swappable conditions for fundamental types
  }

  void swap(Proxy p, A&amp; x) { swap(x, p); } // Satisfy symmetry constraint
}

int main() {
  int i = 1, j = 2;
  lv_swap(i, j);
  assert(i == 2 &amp;&amp; j == 1);

  N::A a1 = {5}, a2 = {-5};
  value_swap(a1, proxy(a2));
  assert(a1.m == -5 &amp;&amp; a2.m == 5);
}
</PRE>
 <I>end example</I>]<P>
</P><P>
</P></LI>

<LI>Change paragraph 4 of [allocator.requirements] as indicated:<BR>
<P>
4 The <TT>X::pointer</TT>, <TT>X::const_pointer</TT>,
<TT>X::void_pointer</TT>, and <TT>X::const_void_pointer</TT> types
shall satisfy<BR> the requirements of <TT>EqualityComparable</TT>,
<TT>DefaultConstructible</TT>, <TT>CopyConstructible</TT>,
<TT>CopyAssignable</TT>,<BR> <DEL><TT>Swappable</TT>, </DEL>and
<TT>Destructible</TT> (20.2.1)<INS>, and lvalues of these types shall be
swappable (20.2.2).</INS><BR>
</P>
</LI>

<LI>
Change [utility.swap] as indicated <I>[Note that there are currently three declarations in the WP. One is misplaced, and the other refers to concepts. We fix this here in addition to augmenting the array swap description]</I>:
<P>
<TT>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</TT><BR>
<DEL><TT>template &lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);</TT></DEL><BR>
<BR>
..<BR>
<BR>
<DEL><TT>template&lt;ValueType T, size_t N&gt;<BR>
&nbsp;&nbsp;void swap(T (&amp;a)[N], T (&amp;b)[N]);</TT></DEL><BR>
<INS><TT>template &lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);</TT></INS><BR>
3 <I>Requires:</I> <DEL>T is Swappable (37).</DEL> <INS><TT>a[i]</TT> shall be swappable with (20.2.2) <TT>b[i]</TT> for all <TT>0 &lt;= i &lt; N</TT>.</INS><BR>
4 <I>Effects:</I> <TT>swap_ranges(a, a + N, b)</TT><BR>
</P><P>
</P></LI>

<LI>
Change [pair.pairs] as indicated:<BR>
<P>
<TT>void swap(pair&amp; p);</TT><BR>
16 <I>Effects:</I> Swaps <TT>first</TT> with <TT>p.first</TT> and <TT>second</TT> with <TT>p.second</TT>.<BR>
17 <I>Requires:</I> <DEL><TT>first_type</TT> and <TT>second_type</TT> shall be <TT>Swappable</TT>. </DEL><INS><TT>first</TT> shall be swappable with (20.2.2) <TT>p.first</TT> and <TT>second</TT> shall be swappable with <TT>p.second</TT>.</INS><BR>
</P><P>
</P></LI>

<LI>
Change [tuple.swap] as indicated:<BR>
<P>
<TT>void swap(tuple&amp; rhs);</TT><BR>
1 <I>Requires:</I> Each <DEL>type in <TT>Types</TT> shall be <TT>Swappable</TT>. </DEL><INS>Each element in <TT>*this</TT> shall be swappable with (20.2.2) the corresponding element in <TT>rhs</TT>.</INS><BR>
2 <I>Effects:</I> Calls <TT>swap</TT> for each element in <TT>*this</TT> and its corresponding element in <TT>rhs</TT>.<BR>
3 <I>Throws:</I> Nothing unless one of the element-wise <TT>swap</TT> calls throws an exception.<BR>
</P><P>
</P></LI>

<LI>
Change [unique.ptr.single] paragraph 2 as indicated:

<P>
2 If the deleter <TT>D</TT> maintains state, it is intended that
this state stay with the associated pointer as ownership is
transferred from <TT>unique_ptr</TT> to <TT>unique_ptr</TT>. The
deleter state need never be copied, only moved or swapped as pointer
ownership is moved around. That is, <DEL>the deleter need only
be</DEL> <INS>values obtained from <TT>get_deleter()</TT> must be
swappable (20.2.2), and <TT>D</TT> needs only satisfy the requirements
of </INS> <TT>MoveConstructible</TT><DEL>,</DEL> <INS>and</INS>
<TT>MoveAssignable</TT><DEL>, and <TT>Swappable</TT></DEL>, and need
not <DEL>be</DEL> <INS>satisfy the requirements of</INS> <TT>CopyConstructible</TT> (unless
copied into the <TT>unique_ptr</TT>) <DEL>n</DEL>or <TT>CopyAssignable</TT>.<BR>
</P><P>

</P></LI>

<LI>
Change the description of <TT>swap</TT> in [unique.ptr.single.modifiers] as indicated:
<P>
<TT>void swap(unique_ptr&amp; u);</TT><BR>
8 <I>Requires:</I> <DEL>The deleter <TT>D</TT></DEL><INS><TT>get_deleter()</TT></INS> shall be <DEL><TT>Swappable</TT></DEL> <INS>swappable (20.2.2)</INS> and shall not throw an exception under <TT>swap</TT>.<BR>
9 <I>Effects:</I> The stored pointers of <TT>this</TT> and <TT>u</TT> are exchanged. The stored deleters are <TT>swap</TT>'d (unqualified).<BR>
10 <I>Throws:</I> nothing.<BR>
</P><P>
</P></LI>

<LI>
Change [alg.swap] as indicated: [<I>The intention is to remove the unnecessary requirements that both iterator value-types are the same and to extend for possible rvalues, e.g. due to proxies, as well. Additionally we fix an obvious missing requirement for iter_swap that both iterator values need to be dereferencable.</I>]
<P>
<TT>
template&lt;class ForwardIterator1, class ForwardIterator2&gt;<BR>
ForwardIterator2 swap_ranges(ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2);<BR>
</TT>
1 <I>Effects</I>: For each non-negative integer <TT>n &lt; (last1 - first1)</TT> performs: <TT>swap(*(first1 + n), *(first2 + n))</TT>.<BR>
2 <I>Requires</I>: The two ranges <TT>[first1,last1)</TT> and <TT>[first2,first2 + (last1 - first1))</TT> shall not overlap. <DEL>The type of <TT>*first1</TT></DEL> <INS><TT>*(first1 + n)</TT></INS> shall be <INS>swappable with (20.2.2)</INS><DEL>the same as the type of <TT>*first2</TT></DEL> <INS><TT>*(first2 + n)</TT></INS> <DEL>and that type shall satisfy the <TT>Swappable</TT> requirements (Table 37)</DEL>.<BR>
<BR>
..<BR>
<BR>
<TT>
template&lt;class ForwardIterator1, class ForwardIterator2&gt;<BR>
void iter_swap(ForwardIterator1 a, ForwardIterator2 b);<BR>
</TT>
5 <I>Effects</I>: <TT>swap(*a, *b).</TT><BR>
6 <I>Requires</I>: <INS><TT>a</TT> and <TT>b</TT> shall be dereferenceable.</INS> <DEL>The type of</DEL> <TT>*a</TT> shall be <DEL>the same as the type of</DEL> <INS>swappable with (20.2.2)</INS> <TT>*b</TT> <DEL>and that type shall satisfy the <TT>Swappable</TT> requirements (Table 37)</DEL>.<BR>
</P><P>
</P></LI>

<LI>
Change [alg.reverse]/2 as indicated: [<I>The intention is to to extend for possible rvalues, e.g. due to proxies, as well</I>]<BR>
<P>
<TT>
template&lt;class BidirectionalIterator&gt;<BR>
void reverse(BidirectionalIterator first, BidirectionalIterator last);<BR>
</TT>
...<BR>
2 <I>Requires</I>: <DEL>The type of</DEL> <TT>*first</TT> shall <INS>be swappable (20.2.2)</INS> <DEL>satisfy the Swappable requirements (Table 37)</DEL>.<BR>
<BR>
</P><P>
</P></LI>

<LI>
Change [alg.rotate]/4 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]<BR>
<P>
<TT>
template&lt;class ForwardIterator&gt;<BR>
ForwardIterator rotate(ForwardIterator first, ForwardIterator middle, ForwardIterator last);<BR>
</TT>
...<BR>
4 <I>Requires</I>: <TT>[first,middle)</TT> and <TT>[middle,last)</TT> shall be valid ranges. <DEL>The type of <TT>*first</TT> shall satisfy the <TT>Swappable</TT> requirements (Table 37),</DEL> <INS><TT>ForwardIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <TT>MoveAssignable</TT> requirements (Table 35).<BR>
</P><P>
</P></LI>

<LI>
Change [alg.random.shuffle]/2 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
<TT>
template&lt;class RandomAccessIterator&gt;<BR>
&nbsp;&nbsp;void random_shuffle(RandomAccessIterator first,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RandomAccessIterator last);<BR>
<BR>
template&lt;class RandomAccessIterator, class RandomNumberGenerator&gt;&gt;<BR>
&nbsp;&nbsp;void random_shuffle(RandomAccessIterator first,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RandomAccessIterator last,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RandomNumberGenerator&amp;&amp; rand);<BR>
<BR>
template&lt;class RandomAccessIterator, class UniformRandomNumberGenerator&gt;&gt;<BR>
&nbsp;&nbsp;void random_shuffle(RandomAccessIterator first,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RandomAccessIterator last,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UniformRandomNumberGenerator&amp; g);<BR>
</TT>
...<BR>
2 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the <TT>Swappable</TT> requirements (Table 37)</DEL> <INS><TT>RandomAccessIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2).</INS> [..]<BR>
</P><P>
</P></LI>

<LI>
Change [alg.partitions] paragraphs 6 and 10 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
<TT>
template&lt;class ForwardIterator, class Predicate&gt;<BR>
&nbsp;&nbsp;ForwardIterator<BR>
&nbsp;&nbsp;&nbsp;&nbsp;partition(ForwardIterator first,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ForwardIterator last, Predicate pred);<BR>
</TT>
...<BR>
6 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the <TT>Swappable</TT> requirements (Table 37).</DEL> <INS><TT>ForwardIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2).</INS><BR>
</P><P>
</P><P>
<TT>
template&lt;class BidirectionalIterator, class Predicate&gt;<BR>
&nbsp;&nbsp;BidirectionalIterator<BR>
&nbsp;&nbsp;&nbsp;&nbsp;stable_partition(BidirectionalIterator first,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BidirectionalIterator last, Predicate pred);<BR>
</TT>
...<BR>
10 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the <TT>Swappable</TT> requirements (Table 37),</DEL> <INS><TT>BidirectionalIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<BR>
</P><P>
</P></LI>

<LI>
Change [sort]/2 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
</P><PRE>template&lt;class RandomAccessIterator&gt;
  void sort(RandomAccessIterator first, RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void sort(RandomAccessIterator first, RandomAccessIterator last,
            Compare comp);
</PRE>
...<BR>
2 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the <TT>Swappable</TT> requirements (Table 37),</DEL><INS><TT>RandomAccessIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<P>
</P></LI>

<LI>
Change [stable.sort]/2 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
</P><PRE>template&lt;class RandomAccessIterator&gt;
  void stable_sort(RandomAccessIterator first, RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void stable_sort(RandomAccessIterator first, RandomAccessIterator last,
                   Compare comp);
</PRE>
...<BR>
2 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the <TT>Swappable</TT> requirements (Table 37),</DEL> <INS><TT>RandomAccessIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<P>
</P></LI>

<LI>
Change [partial.sort]/2 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
</P><PRE>template&lt;class RandomAccessIterator&gt;
  void partial_sort(RandomAccessIterator first,
                    RandomAccessIterator middle,
                    RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void partial_sort(RandomAccessIterator first,
                    RandomAccessIterator middle,
                    RandomAccessIterator last,
                    Compare comp);
</PRE>
...<BR>
2 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the <TT>Swappable</TT> requirements (Table 37),</DEL> <INS><TT>RandomAccessIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<P>
</P></LI>

<LI>
Change [partial.sort.copy]/3 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
</P><PRE>template&lt;class InputIterator, class RandomAccessIterator&gt;
  RandomAccessIterator
    partial_sort_copy(InputIterator first, InputIterator last,
                      RandomAccessIterator result_first,
                      RandomAccessIterator result_last);
template&lt;class InputIterator, class RandomAccessIterator, class Compare&gt;
  RandomAccessIterator
    partial_sort_copy(InputIterator first, InputIterator last,
                      RandomAccessIterator result_first,
                      RandomAccessIterator result_last,
                      Compare comp);
</PRE>
...<BR>
3 <I>Requires</I>: <DEL>The type of <TT>*result_first</TT> shall satisfy the <TT>Swappable</TT> requirements (Table 37),</DEL> <INS><TT>RandomAccessIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*result_first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<P>
</P></LI>

<LI>
Change [alg.nth.element]/2 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
</P><PRE>template&lt;class RandomAccessIterator&gt;
  void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                   RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                   RandomAccessIterator last,  Compare comp);
</PRE>
...<BR>
2 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the Swappable requirements (Table 37),</DEL> <INS><TT>RandomAccessIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<P>
</P></LI>

<LI>
Change [alg.merge]/7 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]<BR>
<PRE>template&lt;class BidirectionalIterator&gt;
  void inplace_merge(BidirectionalIterator first,
                     BidirectionalIterator middle,
                     BidirectionalIterator last);

template&lt;class BidirectionalIterator, class Compare&gt;
  void inplace_merge(BidirectionalIterator first,
                     BidirectionalIterator middle,
                     BidirectionalIterator last,
                     Compare comp);
</PRE>
...<BR>
7 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the Swappable requirements (Table 37),</DEL> <INS><TT>BidirectionalIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<P>
</P></LI>

<LI>
Change [pop.heap]/2 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
</P><PRE>template&lt;class RandomAccessIterator&gt;
  void pop_heap(RandomAccessIterator first, RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void pop_heap(RandomAccessIterator first, RandomAccessIterator last,
                Compare comp);
</PRE>
...<BR>
2 <I>Requires</I>: The range <TT>[first,last)</TT> shall be a valid heap. <DEL>The type of <TT>*first</TT> shall satisfy the Swappable requirements (Table 37),</DEL> <INS><TT>RandomAccessIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<P>
</P></LI>

<LI>
Change [sort.heap]/2 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
</P><PRE>template&lt;class RandomAccessIterator&gt;
  void sort_heap(RandomAccessIterator first, RandomAccessIterator last);

template&lt;class RandomAccessIterator, class Compare&gt;
  void sort_heap(RandomAccessIterator first, RandomAccessIterator last,
                 Compare comp);
</PRE>
...<BR>
2 <I>Requires</I>: The range <TT>[first,last)</TT> shall be a valid heap. <DEL>The type of <TT>*first</TT> shall satisfy the Swappable requirements (Table 37),</DEL> <INS><TT>RandomAccessIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2). The type of <TT>*first</TT> shall satisfy</INS> the <TT>MoveConstructible</TT> requirements (Table 33)<DEL>,</DEL> and the <DEL>the</DEL> <TT>MoveAssignable</TT> requirements (Table 35).<BR>
<P>
</P></LI>

<LI>
Change [alg.permutation.generators] paragraphs 2 and 6 as indicated: [<I>The intention is to extend for possible rvalues, e.g. due to proxies, as well</I>]
<P>
</P><PRE>template&lt;class BidirectionalIterator&gt;
  bool next_permutation(BidirectionalIterator first,
                        BidirectionalIterator last);

template&lt;class BidirectionalIterator, class Compare&gt;
  bool next_permutation(BidirectionalIterator first,
                        BidirectionalIterator last, Compare comp);
</PRE>
...<BR>
2 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the Swappable requirements (Table 37).</DEL> <INS><TT>BidirectionalIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2).</INS>
<P>

</P><P>
</P><PRE>template&lt;class BidirectionalIterator&gt;
  bool prev_permutation(BidirectionalIterator first,
                        BidirectionalIterator last);

template&lt;class BidirectionalIterator, class Compare&gt;
  bool prev_permutation(BidirectionalIterator first,
                        BidirectionalIterator last, Compare comp);
</PRE>
...<BR>
6 <I>Requires</I>: <DEL>The type of <TT>*first</TT> shall satisfy the Swappable requirements (Table 37).</DEL> <INS><TT>BidirectionalIterator</TT> shall satisfy the requirements of <TT>ValueSwappable</TT> (20.2.2).</INS> <BR>
<P>
</P></LI>

</OL>
<H2><A name="Akn"></A>Acknowledgements</H2>
<P>
The authors would like to express their special thanks to Alberto Ganesh Barbati, Peter Dimov, Howard Hinnant, Jens Maurer,
and Mike Miller for providing several wording improvements and reviewing of several drafts of this paper. Thanks also to
Niels Dekker and Alisdair Meredith for reviewing this paper.

Finally, we acknowledge the Fermi National Accelerator Laboratory's
Computing Division for sponsoring the fourth author's participation in
the C++ standardization effort.
</P>
<P>The second, third, and fourth authors of this paper wish to extend
special thanks to Daniel Krgler for providing the initial
proposed wording that formed the basis of the proposal presented at the Pittsburgh meeting.</P>


</BODY></HTML>