<!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>Moving Swap Forward (revision 1)</title>

<style type="text/css">
  p {text-align:justify}
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
</style>
</head><body>
<address style="text-align: left;">
Document number: N2979=09-0169<br>
<br>
<a href="mailto:daniel.kruegler@googlemail.com">Daniel Krgler</a><br>
2009-11-04
</address>
<hr>
<h1 style="text-align: center;">Moving Swap Forward (revision 1)</h1>
<h2>Contents</h2>

<ul>
<li><a href="#Introduction">Introduction</a>
  <ul>
	<li><a href="#SwapForwardMove"><tt>Swap</tt>, <tt>Forward</tt>, and <tt>Move</tt></a></li>
	<li><a href="#Value"><tt>Value</tt></a></li>
  </ul>
</li>
<li><a href="#RevisionHistory">Revision History</a></li>
<li><a href="#Motivation">Motivation</a></li>
<li><a href="#PossibleExtensions">Possible Extensions</a></li>
<li><a href="#Proposed_resolution">Proposed resolution</a></li>
<li><a href="#Acknowledgements">Acknowledgements</a></li>
</ul>

<h2><a name="Introduction"></a>Introduction</h2>
<p>
The functions <tt>forward</tt>, <tt>move</tt>, and <tt>swap</tt> are rather 
fundamental cornerstones which are near to language facilities instead of library 
features:
</p>
<h4><a name="SwapForwardMove"></a><tt>Swap</tt>, <tt>Forward</tt>, and <tt>Move</tt></h4>
<p>
The <tt>swap</tt> function has the very fundamental role of exchanging two things which is 
intimately related to the basics of copying and moving.
</p>
<p>
The <tt>forward</tt> function is needed to transfer the exact argument lvalueness information 
to another calling context and supports the so-called <em>perfect forwarding</em> idiom.
</p>
<p>
Finally, for the enablement of <em>move-semantics</em> an explicit cast is required
to intentionally convert even lvalues to a corresponding rvalue-reference by means of the 
<tt>move</tt> protocol.
</p>
<h4><a name="Value"></a><tt>Value</tt></h4>
<p>
With the provision of <tt>decltype</tt>, <em>late-specified return types</em>, and 
default template-arguments for function templates a new generation of <em>SFINAE</em> 
patterns will emerge to at least partially compensate the lack of concepts on the 
C++0x timescale. Using this technique, it is sometimes necessary to obtain an 
object of a known type in a non-using context, e.g. given the declaration
</p>
<blockquote><pre>
  template&lt;class T&gt;
  T&amp;&amp; value(); // not used
</pre></blockquote>
<p>
as part of the function template declaration
</p>
<blockquote><pre>
  template&lt;class To, class From&gt;
  decltype(static_cast&lt;To&gt;(value&lt;From&gt;())) convert(From&amp;&amp;);
</pre></blockquote>
<p>
or as part of a class template definition
</p>
<blockquote><pre>
  template&lt;class&gt; class result_of;

  template&lt;class Fn, class... ArgTypes&gt;
  struct result_of&lt;Fn(ArgTypes...)&gt; 
  {
    typedef decltype(value&lt;Fn&gt;()(value&lt;ArgTypes&gt;()...)) type;
  };
</pre></blockquote>
<p>

The role of the function template <tt>value()</tt> is a transformation of a type <tt>T</tt> into 
a value without <em>using</em> or <em>evaluating</em> this function. 
The name is supposed to direct the reader's attention to the fact that the expression 
<tt>value&lt;T&gt;()</tt> is an <em>lvalue</em> if and only if <tt>T</tt> is an lvalue-reference, 
otherwise an <em>rvalue</em>. To extend the domain of this function we can do a bit better by 
changing its declaration to
</p>
<blockquote><pre>
  template&lt;class T&gt;
  typename std::add_rvalue_reference&lt;T&gt;::type value(); // not used
</pre></blockquote>
<p>
which ensures that we can also use <em>cv</em> <tt>void</tt> as template parameter. The careful reader 
might have noticed that <tt>value()</tt> already exists under the name <tt>create()</tt> as part 
of the definition of the semantics of the type trait <tt>is_convertible</tt> in [meta.rel]/4.
</p>
<p>
All four presented functions are extremely light-weight, but it is expected that they will be 
part of the daily tool-box of the C++0x programmer.
</p>

<h2><a name="RevisionHistory"></a>Revision History</h2>
<p>	
<ol>
  <li>N2979 - Revision 1
    <ul>
    <li>Added another naming proposal (<tt>&lt;value&gt;</tt>) for the new hosting header by Walter Brown 
    	(see <a href="#Motivation">Motivation</a>).
    </li>
    <li>Added suggestion to add function <tt>rval()</tt> as alternative to existing <tt>move()</tt> by Bjarne 
    	Stroustrup (see <a href="#PossibleExtensions">Possible Extensions</a>).
    </li>
    <li>Added the new header <tt>&lt;move&gt;</tt> to table 13 of library headers and table 15 of freestanding headers.
    </li>
    <li>Removed inclusion of header <tt>&lt;move&gt;</tt> in <tt>&lt;utility&gt;</tt>.
    </li>
    <li>Make the program ill-formed with required diagnostic, if <tt>value()</tt> is <em>used</em>.
    </li>
    <li>Complete support for <tt>void</tt> types as arguments of <tt>common_type</tt> (Table 51 update) and minor wording fixes.
    </li>
    <li>Adaption to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a> numbering.
    </li>
    <li>Minor wording fixes.
    </li>
    </ul>	
  </li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2958.html">N2958</a> - Initial version
  </li>
</ol>

<h2><a name="Motivation"></a>Motivation</h2>
<p>
The three existing functions are located in the two headers <tt>&lt;utility&gt;</tt>
and <tt>&lt;algorithm&gt;</tt>, which are both quite huge. This means that using
these extremely fundamental functions always introduces a large overhead of code.
</p><p>
This negative aspect has lead to the national body comment 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2939.html#UK300"><b>UK 300</b></a> 
and this paper attempts to provide a solution for that, including an addition of a facility which
according to the author's assumptions is of similar fundamentability and usefulness
in template code.
</p><p>
The basic approach suggested in this paper is
</p><ul>
<li>
to move the current definitions of <tt>forward</tt>, <tt>move</tt>, and <tt>swap</tt> to 
a new small header in a backward-compatible manner;
</li>
<li>
to provide a new facility <tt>value()</tt> useful in the definition of constrained or
auto-deduced templates;
</li>
</ul>
<p>
Several naming suggestions for the header had been thought of - among these were <tt>&lt;transfer&gt;</tt> 
and <tt>&lt;moving&gt;</tt> - the currently proposed name is simply <b><tt>&lt;move&gt;</tt></b> 
following one prominent tradition of the standard headers to name the header equal 
to the name of one of its components. 
<p>
However, the similarly short and descriptive name <b><tt>&lt;value&gt;</tt></b> was recently suggested by 
Walter Brown and should be considered, because all of <tt>move</tt>, <tt>forward</tt>, <tt>swap</tt>, and 
<tt>value</tt> are intimately related to <em>values</em>. The author would like to get feedback, which
name would be preferred.
<p>
Similarly, several naming alternatives for <tt>value</tt> were also considered, e.g. <tt>decl</tt>
(suggested by Alisdair Meredith), <tt>create</tt>, <tt>make</tt>, or <tt>fwd</tt>. The name 
<b><tt>value</tt></b> has the advantage of not causing a confusion with already existing names 
(<tt>forward</tt>, <tt>decltype</tt>), it also emphasizes better its actual intention - the
effect of attempting to get an <em>rvalue</em> or an <em>lvalue</em> - over <tt>make</tt> or <tt>create</tt>.
<p>
Several mechanisms were considered to ensure that an unguarded programmer cannot too easily misuse
the <em>undefined</em> function <tt>value</tt>. It is impossible to mark it as an <em>deleted</em>
function, because that would produce unwanted compile-time errors or silent removals from the
overload set, depending on the context of its occurrence. It was considered to mark the function
with the attribute <tt>[[noreturn]]</tt>, but the author has the suspicion that this might 
produce unwanted warnings of compilers or other diagnostic tools also for the <em>intended</em> 
use-cases and still wouldn't prevent using it. A third option was thought of, namely to provide 
indeed a <em>definition</em> which would either cause termination or the raise of an exception. 
This idea was rejected, because such a misuse might reveal too late in the software development 
process. The fourth option, to simply provide no definition at all and to rely on linker diagnostics 
to make any abuse obvious, was considered as a bad choice because of the late diagnostics. After
feedback from core language experts it was decided that it should be feasible to require that
the code is ill-formed, if the function is used, as demonstrated by the following prototype
implementation:
</p>
<blockquote><pre>
  template&lt;class T&gt;
  struct value_protector { 
    static const bool stop = false;
    static typename std::add_rvalue_reference&lt;T&gt;::type delegate(); // undefined
  };

  template&lt;class T&gt;
  typename std::add_rvalue_reference&lt;T&gt;::type value() {
    static_assert(value_protector&lt;T&gt;::stop, "value() must not be used!");
    return value_protector&lt;T&gt;::delegate();
  }
</pre></blockquote>
<p>
The proposed wording attempts to prevent direct coupling to other components by using
words that explain effects and semantics instead of code, e.g. the <tt>swap</tt> overload for 
arrays should have the same effect as a call to <tt>swap_ranges</tt>, but that should not imply
that <tt>&lt;algorithm&gt;</tt> should be included as well. Similarly should the declaration
of <tt>value()</tt> not imply the inclusion of the complete <tt>&lt;type_traits&gt;</tt>
header just because its semantics depends on the semantic of <tt>add_rvalue_reference</tt>.
To prevent existing libraries to perform heroic efforts to satisfy this intention, the
wording uses no binding request, but instead a non-normative, encouraging wording style.
<p>

</p><h2><a name="PossibleExtensions"></a>Possible Extensions</h2>
<p>
Besides the here proposed additions to the standard library further extensions of the presented ideas 
were brought to the author's consideration, among of these were two functions <b><tt>rvalue()</tt></b>
and <b><tt>lvalue()</tt></b>,
</p>
<blockquote><pre>
  template&lt;class T&gt;
  T&amp; lvalue(); // not used

  template&lt;class T&gt;
  typename add_rvalue_reference&lt;typename remove_reference&lt;T&gt;::type&gt;::type rvalue(); // not used
</pre></blockquote>
<p>
that could be considered as specialized versions of <tt>value()</tt>, because they would explicitly
name the wanted lvalueness of the return type. Until now, no convincing examples came up that would
indicate that these would be of equivalent usefulness, so this paper does not suggest to add them. 
Should indeed interest exist, they could be added later.
<p>
Bjarne Stroustrup suggested to add the function <b><tt>rval()</tt></b> with the same parameter 
type list, return type, and semantics as the existing <tt>move()</tt> function, because of the 
misleading character of the name of the latter (it doesn't move at all). The author believes that such an 
addition should be done preferrably now and not later, but would like to ask for feedback from other 
committee members regarding the preferred direction.

</p><h2><a name="Proposed_resolution"></a>Proposed resolution</h2>
<p>
The following suggested wording bases on the numbering of 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>.
</p><p>
[<i>The following wording assumes that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a> 
	has been applied. This proposal does not depend on the suggested resolution of N2951, but it simplifies the wording here.
  If N2951 would be rejected, this wording need only an update that ensures that the equivalent semantic effect of identity 
  is realized</i>]
</p><p>
</p><ol>
<li>
Adapt the text of 17.6.1.2 [headers]/2 and add one further entry to Table 13 - C++ library headers ([headers]):
<blockquote><p>
The C++ standard library provides <del>50</del><ins>51</ins> C++ library headers, as shown in Table 13.
</p></blockquote><blockquote>
<table border="1">
<caption>Table 13 - C++ library headers</caption>

<tbody>

<tr>
<td>...</td>
<td>...</td>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>
<tr>
<td>...</td>
<td><tt>&lt;initializer_list&gt;</tt></td>
<td><tt>&lt;memory&gt;</tt></td>
<td><tt>&lt;stack&gt;</tt></td>
<td>...</td>
</tr>
<tr>
<td>...</td>
<td><tt>&lt;iomanip&gt;</tt></td>
<td><ins><tt>&lt;move&gt;</tt></ins></td>
<td><tt>&lt;stdexcept&gt;</tt></td>
<td>...</td>
</tr>
<tr>
<td>...</td>
<td>...</td>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>

</tbody></table>
</blockquote>

<p>

</p></li>
<li>
Add one further entry to Table 15 - C++ headers for freestanding implementations ([using.overview]):
<p>
</p><blockquote>
<table border="1">
<caption>Table 15 - C++ headers for freestanding implementations</caption>

<tbody><tr>
<th>Subclause</th>
<th>Header(s)</th>
</tr>

<tr>
<td>...</td>
<td>...</td>
</tr>
<tr>
<td>18.10&#8195;Other runtime support</td>
<td><tt>&lt;cstdarg&gt;</tt></td>
</tr>
<tr>
<td><ins>20.3 &#8195;Move and forward functions</ins></td>
<td><ins><tt>&lt;move&gt;</tt></ins></td>
</tr>
<tr>
<td>20.6 &#8195;Type traits</td>
<td><tt>&lt;type_traits&gt;</tt></td>
</tr>

</tbody></table>
</blockquote>

<p>

</p></li>
<li>
Add one further entry to Table 30 - General utilities library summary ([utilities])
immediately before <tt>&lt;utility&gt;</tt>:
<p>

</p><blockquote>
<table border="1">
<caption>Table 30 - General utilities library summary</caption>

<tbody><tr>
<th>Subclause</th>
<th>Header(s)</th>
</tr>

<tr>
<td>20.2&#8195;Requirements</td>
<td>&nbsp;</td>
</tr>
<tr>
<td><ins>20.3&#8195;Move and forward functions</ins></td>
<td><ins><tt>&lt;move&gt;</tt></ins></td>
</tr>
<tr>
<td>...</td>
<td>...</td>
</tr>

</tbody></table>
</blockquote>

<p>

</p></li><li>Change [utilities.general]/2:
<blockquote>
<p>
The following subclauses describe utility and allocator requirements, <ins>move/forward utilities,</ins> 
utility components, compile-time rational arithmetic, tuples, type traits templates, function objects, 
dynamic memory management utilities, and date/time utilities, as summarized in Table 30.
</p></blockquote>
</li>
<li>Add a new clause just before [utility]:
<blockquote>
<p>
<ins>20.3    Move and forward functions    [move.forward]</ins>
</p><p>
<ins>This subclause describes components used by C++ programs, particularly in templates,
to perform fundamental operations related to moving, forwarding, and swapping objects.</ins>
</p><p>
<ins><b>Header <tt>&lt;move&gt;</tt> synopsis</b></ins>
</p><p>
</p><blockquote><pre><ins>namespace std {</ins>

  <ins>// 20.3.1, forward/move:</ins>
  <ins>template &lt;class T, class U&gt; T&amp;&amp; forward(U&amp;&amp; u);</ins>
  <ins>template &lt;class T&gt; <i>MT</i> move(T&amp;&amp;);</ins>

  <ins>// 20.3.2, value:</ins>
  <ins>template &lt;class T&gt; <i>VT</i> value(); // for unused context</ins>

  <ins>// 20.3.3, swap:</ins>
  <ins>template &lt;class T&gt; void swap(T&amp; a, T&amp; b);</ins>
  <ins>template &lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);</ins>

<ins>}</ins>
</pre></blockquote>
<p>
<ins><b>20.3.1 forward/move helpers [forward]</b></ins>
</p><p>
<ins>The library provides templated helper functions to simplify applying move semantics 
to an lvalue and to simplify the implementation of forwarding functions.</ins>
</p></blockquote>
<p>
[<i>NB: The following is a relocation of the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a>
wording from [forward] around p. 3. Additionally a Notes clause is added to signal implementors that they should not include 
the header <tt>&lt;type_traits&gt;</tt> here:</i>]
</p><p>
</p><blockquote><pre><ins>template &lt;class T, class U&gt; T&amp;&amp; forward(U&amp;&amp; u);</ins>
</pre>
<p></p><blockquote>
<ins><i>Returns:</i> <tt>static_cast&lt;T&amp;&amp;&gt;(u)</tt>.</ins>
<p>
<ins><i>Remarks:</i> If the following constraints are not met, this signature shall not participate in overload resolution:</ins>
</p><ul><li>
<ins>The type formed by <tt>remove_reference&lt;U&gt;::type*</tt> shall be implicitly convertible to the type <tt>remove_reference&lt;T&gt;::type*</tt>, and</ins> 
</li>
<li>
<ins>if <tt>T</tt> is an lvalue reference type, then <tt>U</tt> shall be an lvalue reference type.</ins>
</li>
</ul>
<p>
<ins><i>Notes:</i> Implementations are encouraged but not required to avoid including the header 
	<tt>&lt;type_traits&gt;</tt> to realize this definition.</ins>
</p><p>
</p></blockquote></blockquote>

<p>
[<i>NB: The following is an unconditional relocation of the example from [forward]/5:</i>]
</p><blockquote><blockquote>
<ins>[<i>Example:</i></ins><pre><ins>
template &lt;class T, class A1, class A2&gt;
shared_ptr&lt;T&gt; factory(A1&amp;&amp; a1, A2&amp;&amp; a2) {
  return shared_ptr&lt;T&gt;(new T(std::forward&lt;A1&gt;(a1), std::forward&lt;A2&gt;(a2)));
}

struct A {
  A(int&amp;, const double&amp;);
};

void g() {
  shared_ptr&lt;A&gt; sp1 = factory&lt;A&gt;(2, 1.414); // error: 2 will not bind to int&amp;
  int i = 2;
  shared_ptr&lt;A&gt; sp2 = factory&lt;A&gt;(i, 1.414); // OK
}
</ins></pre><ins>
In the first call to factory, A1 is deduced as int, so 2 is forwarded to A's constructor as an
rvalue. In the second call to factory, A1 is deduced as int&amp;, so i is forwarded to A's constructor as
an lvalue. In both cases, A2 is deduced as double, so 1.414 is forwarded to A's constructor
as an rvalue. &mdash; <i>end example</i>]</ins>
</blockquote>

</blockquote>
[<i>NB: The following is a relocation of <tt>move</tt> from [forward]/7-9 with one further
change: The introduction of <tt>MT</tt> is supposed to signal implementors that they
should not include the header <tt>&lt;type_traits&gt;</tt> here:</i>]
<blockquote>
	
<pre><ins>
template &lt;class T&gt; <i>MT</i> move(T&amp;&amp; t);
</ins></pre>

<blockquote>
<ins><i>Returns:</i> <tt>t</tt>.</ins>
<p>
<ins><i>Remarks:</i> The return type <i><tt>MT</tt></i> shall be defined equivalent to 
<tt>typename remove_reference&lt;T&gt;::type&amp;&amp;</tt>.</ins>
<p>	
<ins><i>Notes:</i> Implementations are encouraged but not required to avoid including the header 
<tt>&lt;type_traits&gt;</tt> to realize the definition of <i><tt>MT</tt></i>.</ins>
</p><p>
<ins>[<i>Example</i>:</ins></p><pre><ins>
template &lt;class T, class A1&gt;
shared_ptr&lt;T&gt; factory(A1&amp;&amp; a1) {
  return shared_ptr&lt;T&gt;(new T(std::forward&lt;A1&gt;(a1)));
}

struct A {
  A();
  A(const A&amp;); // copies from lvalues
  A(A&amp;&amp;); // moves from rvalues
};

void g() {
  A a;
  shared_ptr&lt;A&gt; sp1 = factory&lt;A&gt;(a); // "a" binds to A(const A&amp;)
  shared_ptr&lt;A&gt; sp1 = factory&lt;A&gt;(std::move(a)); // "a" binds to A(A&amp;&amp;)
}
</ins></pre><ins>
- In the first call to factory, A1 is deduced as A&amp;, so a is forwarded as a non-const lvalue. This binds to
the constructor A(const A&amp;), which copies the value from a. In the second call to factory, because of
the call std::move(a), A1 is deduced as A, so a is forwarded as an rvalue. This binds to the constructor
A(A&amp;&amp;), which moves the value from a. &mdash; <i>end example</i>]</ins>
</blockquote>

</blockquote>
[<i>NB: Here starts the wording for the new library component <tt>value</tt>. The introduction of 
<tt>VT</tt> is supposed to signal implementors that they should not include the header 
<tt>&lt;type_traits&gt;</tt> here:</i>]
<blockquote>

<ins><b>20.3.2 Function template <tt>value</tt> [value]</b></ins>
<p>
<ins>The library provides the function template <tt>value</tt> to simplify
the definition of expressions in unevaluated and unused contexts ([basic.def.odr], [expr]). The 
template parameter <tt>T</tt> of <tt>value</tt> may be an incomplete type.</ins>

</p><pre><ins>
template &lt;class T&gt; <i>VT</i> value(); // for unused context
</ins></pre>

<blockquote>
<ins><i>Remarks:</i> The return type <i><tt>VT</tt></i> shall be defined equivalent to 
<tt>typename add_rvalue_reference&lt;T&gt;::type</tt>. If the function is <em>used</em> according 
to [basic.def.odr], the program shall be ill-formed.</ins>
<p>
<ins><i>Notes:</i> Implementations are encouraged but not required to avoid including the header 
	<tt>&lt;type_traits&gt;</tt> to realize the definition of <i><tt>VT</tt></i>.</ins>
</p><p>
<ins>[<i>Example</i>:</ins></p><blockquote><pre><ins>
template&lt;class To, class From&gt;
decltype(static_cast&lt;To&gt;(value&lt;From&gt;())) convert(From&amp;&amp;);
</ins></pre></blockquote>
<p><ins>
declares a function template <tt>convert</tt>, which does only participate in overloading, if the type
<tt>From</tt> can be explicitly casted to type <tt>To</tt> &mdash; <i>end example</i>]</ins>
</p></blockquote>

</blockquote>
[<i>NB: The following is a relocation of <tt>swap</tt> from [algorithms] with two further
changes: First, the clause is named [swap] instead of [algo.swap], because the latter is supposed to
be conserved for its other components. Second, the references by numbers are replaced by references
by ID's, third, the semantic definition of the overload for arrays uses wording to encourage implementors 
not to include header <tt>&lt;algorithm&gt;</tt> here. Except for this no change in semantics is intended 
but the introduction of the normative "equivalent to" phrase seems to fix a current wording impreciseness.</i>]
<blockquote>

<ins><b>20.3.3 <tt>Swap</tt> function templates [swap]</b></ins>
<pre><ins>
template&lt;class T&gt;
void swap(T&amp; a, T&amp; b);
</ins></pre>
<p>
<ins><i>Requires:</i> Type <tt>T</tt> shall be <tt>MoveConstructible</tt> ([moveconstructible]) and 
<tt>MoveAssignable</tt> ([moveassignable]).</ins>	
</p><p>
<ins><i>Effects:</i> Exchanges values stored in two locations.</ins>

</p><pre><ins>
template&lt;class T, size_t N&gt;
void swap(T (&amp;a)[N], T (&amp;b)[N]);	
</ins></pre>
<p>
<ins><i>Effects:</i> Equivalent to <tt>swap_ranges(a, a + N, b)</tt>.</ins>
</p><p>
<ins><i>Notes:</i> Implementations are encouraged but not required to avoid including the header <tt>&lt;algorithm&gt;</tt> 
to realize the definition of this <tt>swap</tt> overload.</ins>

</p></blockquote>
</li>
<li>Change [utilities] as indicated:
<p>
[<i>NB: Neither <tt>move</tt> nor <tt>forward</tt> were part of TR1, therefore including header <tt>&lt;move&gt;</tt> here was dropped.</i>]
</p><blockquote>
<p>
<b>Header <tt>&lt;utility&gt;</tt> synopsis</b>
</p><p>
</p><blockquote><pre>#include &lt;initializer_list&gt;

namespace std {
  ...
  <del>// 20.3.2, forward/move:</del>
  <del>template &lt;class T&gt; struct identity;</del>
  <del>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp;);</del>
  <del>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp;);</del>
  ...
}
</pre></blockquote></blockquote>
</li>
<li>
Remove the complete clause 20.3.2 [forward].
<p>

</p></li><li>Change [meta.rel]/4 as indicated:
<p>
[<i>NB: This wording change is just an editorial simplification of the definition of
<tt>is_convertible</tt>. No wording change is intended, but we use already the wording
that was introduced with LWG defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a></i>]
</p><p>
...
<del>Given the following function prototype:</del>
</p><blockquote><pre><del>
template &lt;class T&gt; 
typename add_rvalue_reference&lt;T&gt;::type create();
</del></pre></blockquote>
<del>t</del><ins>T</ins>he predicate condition for a template specialization <tt>is_convertible&lt;From, To&gt;</tt> 
shall be satisfied if and only if the return expression in the following code would be well-formed, including 
any implicit conversions to the return type of the function.
<blockquote><pre>To test() { 
  return <del>create</del><ins>value</ins>&lt;From&gt;(); 
}
</pre></blockquote>
[<i>Note:</i> This requirement gives well defined results for reference types, <tt>void</tt> types, array types, 
	and function types. &mdash; <i>end note</i>]
<p>

</p></li><li>
Change the entry for <tt>common_type</tt> in Table 51 &mdash; Other transformations ([meta.trans.other]):
<p>
[<i>NB: This wording change extends the type domain of <tt>common_type</tt> for cv <tt>void</tt> =&gt; cv <tt>void</tt> 
transformations and thus makes <tt>common_type</tt> usable for all binary type combinations that are supported by 
<tt>is_convertible</tt></i>]
</p>

<blockquote>
<table border="1">
<caption>Table 51 &mdash; Other transformations</caption>

<tbody><tr>
<th>Template</th>
<th>Condition</th>
<th>Comments</th>
</tr>

<tr>
<td><tt>template &lt;class... T&gt;
struct common_type;</tt></td>
<td>&nbsp;</td>
<td>The member typedef <tt>type</tt> shall be defined as set out below. All types in the parameter pack <tt>T</tt> 
shall be complete <ins>or (possibly cv-qualified) void</ins>. A program may specialize this trait if at least one 
template parameter in the specialization is a user-defined type. [ <i>Note:</i>: Such specializations are needed 
when only explicit conversions are desired among the template arguments. &mdash; <i>end note</i> ]</td>
</tr>

</tbody></table>
</blockquote>

<p>

</p></li><li>Change [meta.trans.other]/3 as indicated:
<p>
[<i>NB: This wording change is more than an editorial simplification of the definition of
<tt>common_type</tt>: It also extends its usefulness for cv <tt>void</tt> types as outlined above</i>]
</p><p>
The nested typedef <tt>common_type::type</tt> shall be defined as follows:
</p>
<blockquote><pre>...
template &lt;class T, class U&gt;
struct common_type&lt;T, U&gt; {
<del>private:
  static T&amp;&amp; __t();
  static U&amp;&amp; __u();
public:</del>
  typedef decltype(true ? <del>__t</del><ins>value&lt;T&gt;</ins>() : <del>__u</del><ins>value&lt;U&gt;</ins>()) type;
};
...
</pre></blockquote>
</li>
<li>Change 25 [algorithms], header <tt>&lt;algorithm&gt;</tt> as indicated:
<p>
[<i>NB: The explicit addition of &lt;move&gt; ensures backward compatibility versus C++03</i>]
</p><p>
<b>Header <tt>&lt;algorithm&gt;</tt> synopsis</b>
</p><blockquote><pre><ins>#include &lt;move&gt;</ins>

namespace std {
  ...
  // 25.3.3, swap:
  <del>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</del>
  <del>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);</del>
  template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator2 swap_ranges(ForwardIterator1 first1,
  ForwardIterator1 last1, ForwardIterator2 first2);
  template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  void iter_swap(ForwardIterator1 a, ForwardIterator2 b);
  ...
 }
</pre></blockquote>
</li>
<li>Change 25.3.3 [alg.swap] as indicated:
<p>
</p><pre><del>
template&lt;class T&gt;
void swap(T&amp; a, T&amp; b);
</del></pre>
<p>
<del><i>Requires:</i> Type <tt>T</tt> shall be <tt>MoveConstructible</tt> (33) and 
<tt>MoveAssignable</tt> (35).</del>	
</p><p>
<del><i>Effects:</i> Exchanges values stored in two locations.</del>

</p><pre><del>
template&lt;class T, size_t N&gt;
void swap(T (&amp;a)[N], T (&amp;b)[N]);	
</del></pre>
<p>
<del><i>Effects:</i> <tt>swap_ranges(a, a + N, b)</tt>.</del>

</p></li></ol>
	
<h2><a name="Acknowledgements"></a>Acknowledgements</h2>
<p>
The author would like to thank Alisdair Meredith for his encouragement to write this paper
and for his inspiration to add the <tt>value</tt> function, Howard Hinnant and Walter Brown
for their careful suggestions which really helped improving this document, Jens Maurer for 
his help clearing up some core language subtleties regarding <em>unused</em> entities, and 
Joe Gottman for his active support to get compile-time errors for any (mis)use of <tt>value()</tt>.
Gabriel Dos Reis, Christopher Jefferson, Bjarne Stroustrup, and Ville Voutilainen participated 
in discussions and suggested improvements.
</p><p>
</p>
</body></html>