<html>

<head>
  <meta http-equiv="Content-Type" content="text/html;charset=UTF8">

  <meta name="description" content="Proposal for C++ Standard">
  <meta name="keywords" content="C++,cplusplus,wg21">
  <meta name="author" content="Alisdair Meredith">

  <title>Reviewing Deprecated Facilities of C++17 for C++20</title>

  <style type="text/css">
    ins {background-color:#A0FFA0}
    del {background-color:#FFA0A0}
    p {text-align:justify}
    li {text-align:justify}
    blockquote.note
    {
      background-color:#E0E0E0;
      padding-left: 15px;
      padding-right: 15px;
      padding-top: 1px;
      padding-bottom: 1px;
    }
    blockquote.recommend
    {
      background-color:#ffffb0;
      padding-left: 10px;
      padding-right: 10px;
      padding-top: 1px;
      padding-bottom: 1px;
    }
    blockquote.review
    {
      background-color:#b0ffb0;
      padding-left: 10px;
      padding-right: 10px;
      padding-top: 1px;
      padding-bottom: 1px;
    }
    blockquote.review_note
    {
      background-color:#ffffcc;
      padding-left: 15px;
      padding-right: 15px;
      padding-top: 1px;
      padding-bottom: 1px;
    }
  </style>
</head>

<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">P0619R3</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2018-05-07</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Audience:</td>
  <td align="left">Core Working Group</td>
</tr><tr>
  <td align="left"></td>
  <td align="left">Library Working Group</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Alisdair Meredith &lt;<a href="mailto:ameredith1@bloomberg.net">ameredith1@bloomberg.net</a>&gt;</td>
</tr>
<tr>
  <td/>
  <td align="left">Stephan T. Lavavej &lt;<a href="mailto:stl@microsoft.com">stl@microsoft.com</a>&gt;</td>
</tr>
<tr>
  <td/>
   <td align="left">Tomasz Kamiński &lt;tomaszkam at gmail dot com&gt;</td>
</tr>
</table>

<h1>Reviewing Deprecated Facilities of C++17 for C++20</h1>

<h2>Table of Contents</h2>
<ol start="0">
<li><a href="#rev.hist">Revision History</a></li>
  <ul>
  <li><a href="#rev.0">Revision 0</a></li>
  <li><a href="#rev.1">Revision 1</a></li>
  <li><a href="#rev.2">Revision 2</a></li>
  <li><a href="#rev.3">Revision 3</a></li>
  </ul>
<li><a href="#1.0">Introduction</a></li>
<li><a href="#2.0">Stating the problem</a></li>
<li><a href="#3.0">Propose Solution</a></li>
  <ul>
  <li><a href="#3.1">D.1 Redeclaration of static constexpr data members [depr.static_constexpr]</a></li>
  <li><a href="#3.2">D.2 Implicit declaration of copy functions [depr.impldec]</a></li>
  <li><a href="#3.3">D.3 Deprecated exception specifications [depr.except.spec]</a></li>
  <li><a href="#3.4">D.4 C++ standard library headers [depr.cpp.headers]</a></li>
  <li><a href="#3.5">D.5 C standard library headers [depr.c.headers]</a></li>
  <li><a href="#3.6">D.6 char* streams [depr.str.strstreams]</a></li>
  <li><a href="#3.7">D.7 uncaught_exception [depr.uncaught]</a></li>
  <li><a href="#3.8">D.8 Old adaptable function bindings [depr.func.adaptor.binding]</a></li>
  <li><a href="#3.9">D.9 The default allocator [depr.default.allocator]</a></li>
  <li><a href="#3.10">D.10 Raw storage iterator [depr.storage.iterator]</a></li>
  <li><a href="#3.11">D.11 Temporary buffers [depr.temporary.buffer]</a></li>
  <li><a href="#3.12">D.12 Deprecated type traits [depr.meta.types]</a></li>
  <li><a href="#3.13">D.13 Deprecated iterator primitives [depr.iterator.primitives]</a></li>
  <li><a href="#3.14">D.14 Deprecated shared_ptr observers [depr.util.smartptr.shared.obs]</a></li>
  <li><a href="#3.15">D.15 Standard code conversion facets [depr.locale.stdcvt]</a></li>
  <li><a href="#3.16">D.16 Deprecated Character Conversions [depr.conversions]</a></li>
  </ul>
<li><a href="#4.0">Other Directions</a></li>
<li><a href="#5.0">Library Fixes for Deprecated Features</a></li>
<li><a href="#6.0">Formal Wording</a></li>
<li><a href="#7.0">Acknowledgements</a></li>
<li><a href="#8.0">References</a></li>
</ol>


<h2><a name="rev.hist">Revision History</a></h2>

<h3><a name="rev.0">Revision 0</a></h3>
<p>
Original version of the paper for the 2017 post-Kona mailing.
</p>

<h3><a name="rev.1">Revision 1</a></h3>
<p>
First update for the 2017 pre-Toronto mailing:
</p>

<ul>
  <li>cross-reference library issues: 2155</li>
  <li>weak recommendation to undeprecate <tt>strstream</tt>s</li>
</ul>


<h3><a name="rev.2">Revision 2</a></h3>
<p>
Update following the 2017 Toronto review:
</p>

<ul>
  <li>Note review results on each section</li>
  <li>Merge proposed resolutions into one common change-set for LWG/CWG review</li>
  <li>Update integrated wording to reflect latest working draft:
      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4700">N4700</a></li>
  <li>Write Annex C wording for removals that passed (L)EWG review</li>
</ul>


<h3><a name="rev.3">Revision 3</a></h3>
<p>
Simplified for wording review in Jacksonville/Rapperswil, 2018:
</p>

<ul>
  <li>Remove redundant proposed wording for each clause, relying on consolidated text and doc history</li>
  <li>Update integrated wording to reflect latest working draft:
      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713">N4713</a></li>
  <li>Acknowledge use of <tt>std::allocator&lt;void&gt;</tt> as a proto-allocator</li>
  <li>Note, for rationale, the addition of <tt>&lt;version&gt;</tt> header resolves some concerns</li>
</ul>


<h2><a name="1.0">1 Introduction</a></h2>
<p>
This paper evaluates all the existing deprecated facilities in
the C++17 standard, and recommends a subset as candidates for removal
in C++20.
</p>


<h2><a name="2.0">2 Stating the problem</a></h2>
<p>
With the release of a new C++ standard, we get an opportunity to revisit
the features identified for deprecation, and consider if we are prepared
to clear any out yet, either by removing completely from the standard, or
by reversing the deprecation decision and restoring the feature to full
service.
</p>
<p>
In an ideal world, the start of every release cycle would cleanse the
list of deprecated features entirely, allowing the language and library
to evolve cleanly without holding too much deadweight.  In practice,
C++ has some long-term deprecated facilities that are difficult to
remove, and equally difficult to rehabilitate.  Also, with the three
year release cadence for the C++ standard, we will often be considering
removal of features whose deprecated status has barely reached print.
</p>
<p>
The benefits of making the choice to remove early is that we will get
the most experience we can from the bleeding-edge adopters whether a
particular removal is more problematic than expected - but even this
data point is limited, as bleeding-edge adopters typically have less
reliance on deprecated features, eagerly adopting the newer replacement
facilities.
</p>
<p>
We have precedent that Core language features are good targets for
removal, typically taking two standard cycles to remove a deprecated
feature, although often prepared to entirely remove a feature even
without a period of deprecation, if the cause is strong enough.
</p>
<p>
The library experience has been mixed, with no desire to remove
anything without a period of deprecation (other than <tt>gets</tt>)
and no precedent prior to C++17 for actually removing deprecated
features.
</p>
<p>
The precedent set for the library in C++17 seems to be keener to
clear out the old code more quickly though, even removing features
deprecated as recently as C++14.  Accordingly, this paper will be
fairly aggressive in its attempt to clear out old libraries.  This
is perhaps more reasonable for the library clauses than the core
language, as the Zombie Names clause, <b>20.5.4.3.1 [zombie.names]</b>
allows vendors to continue shipping features long after they have left
the standard, as long as their existing customers rely on them.
</p>
<p>
This paper makes no attempt to offer proposals for removing features
other than those deprecated in Annex D, nor does it attempt to
identify new candidates for deprecation.
</p>


<h2><a name="3.0">3 Proposed Solution</a></h2>
<p>
We will review each deprecated facility, and make a strong and a weak
recommendation.  The strong recommendation is the preferred direction
of the authors, who lean towards early removal.  There will also be a
weak recommendation, which is an alternative proposal for the evolution
groups to consider, if the strong recommendation does not find favor.
Finally, wording is generally provided for both the strong and weak
recommendations, which will be collated into a unified Proposed Wording
section once the various recommendations have been given direction by
the corresponding evolution group.
</p>
<p>
All proposed wording is relative to the expected C++17 DIS, including
the revised clause numbers.  However, it will be updated to properly
reflect the final document in the pre-Toronto mailing, incorporating
any feedback we accrue in the meantime.
</p>

<h3><a name="3.1">D.1 Redeclaration of static constexpr data members [depr.static_constexpr]</a></h3>
<p>
Redundant <tt>constexpr</tt> declarations are a relatively recent feature
of modern C++, as the <tt>constexpr</tt> facility was not introduced until
C++11.  That said, the redundant redeclaration was not deprecated until
C++17, so there has not yet been much time for user code to respond to the
deprecation notice.
</p>

<p>
The feature seems relatively small and harmless; it is not clear that
there is a huge advantage to removing it immediately from C++20.  That
said, there is also an argument to be made for cleanliness in the standard
and prompt removal of deprecated features.  If we do wish to consider the
removal of redundant <tt>constexpr</tt> declarations, it would be best to
do so early, so that there is an opportunity for early adopters to shout
if the feature is relied on more heavily than expected.
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b>
take no action yet, consider again for C++23.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
remove this facility from C++20.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, take no action yet.
We will consider again for C++23.
</blockquote>

<blockquote class="review_note">
It seems early to be making this change, and it was not clear that it would
improve teachability of this corner of the language.  There was a suggestion
that with a little more experience, we might also consider undeprecation for
C++23
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.2">D.2 Implicit declaration of copy functions [depr.impldec]</a></h3>
<p>
This feature was deprecated towards the end of the C++11 development cycle,
and was heavily relied on prior to that.  That said, many of the deprecated
features are implicitly deleted if any move operations are declared, and
modern users are increasingly familiar with this idiom, and may find the older
deprecated behavior jarring.  It is expected that compilers will give good
warnings for code that breaks with the removal of this feature, much as they
advise about its impending demise with deprecation warnings today.
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b>
take decisive action early in the C++20 development cycle, so early adopters
can shake out the reamaining cost of updating old code.  Note that this would
be both an API and ABI breaking change, and it would be good to set that
precedent early if we wish to allow such breakage in C++20.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
take no action now, and plan to remove this feature in the next revision of
the standard that will permit both ABI and API breakage.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept weak recommendation, take no action yet.
We will consider again for C++23.
</blockquote>

<blockquote class="review_note">
There is little data yet on how much code this would break, but few
implementations provide warnings, and vendors suggest they have no
interest in adding warnings for this deprecation, as they would be
&quot;too noisy&quot;.
</blockquote>


<blockquote class="review_note">
It seems plausible that the linkage of the copy operations would be
less disruptive than linking the destructor to the copy operations,
and some future progress might be made in that direction, if enough
interest remains.  We might also consider undeprecation in a future
standard.  It seems a paper with real analysis of impact is needed
to make progress in either direction (undeprecation or removal).
</blockquote>

<blockquote class="note">
Audit standard for examples like 10.1.7.2 [dcl.type.simple]p5 that rely on
implicit copies that will now be deleted.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.3">D.3 Deprecated exception specifications [depr.except.spec]</a></h3>
<p>
The deprecated exception specification <tt>throw()</tt> was retained in C++17,
when other exception specifications were removed, to retain compatibility for
the only form that saw widespread use.  Its impact on the remaining standard
is minimal, so it costs little to retain it for another iteration, giving users
a reasonable amout of time to complete their transition, and retaining a viable
conversion path from C++03 directly to C++20.  It is worth noting that the
feature will have been deprecated for most of a decade when C++20 is published
though.
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b>
take no action now, and plan to remove this feature in C++23.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
remove the final traces of the deprecated exception specification syntax:
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept weak recommendation, remove the feature
from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference to remove noise that adds little value to the
standard, as long as vendors are free to continue supporting a
&quot;conforming extension&quot; and manage actual removal (outside
of strict conformance modes) at their own leisure.
</blockquote>




<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.4">D.4 C++ standard library headers [depr.cpp.headers]</a></h3>
<p>
The deprecated compatibility headers for C++ are mostly vacuous, merely
redirecting to other headers, or defining macros that are alreadty reserved to
the implementation.  By aliasing the C headers providing macros to emulate the
language support for keywords in C++, there is no real value intended by
supplying a C++ form of these headers.  There should be minimal harm in
removing these headers, and it would remove a possible risk of confusion, with
users trying to understand if this is some clever compatibility story for mixed
C/C++ projects.
</p>

<p>
LWG Issue 2155 specifically talks about removing
<tt>__bool_true_false_are_defined</tt>
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b>
remove the final traces of the deprecated compatibility headers:
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
take no action now, and plan to remove this feature in C++23.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, remove the feature
from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference to remove noise that adds little value to the standard,
as long as vendors are free to continue supporting a &quot;conforming
extension&quot; and manage actual removal (outside of strict conformance modes)
at their own leisure.
</blockquote>

<p>
Specific concerns were raised around the <tt>&lt;ciso646&gt;</tt> header as
some implementations are using it as the samllest header to inject version
information into their standard library.  However, any such usage is a
non-standard extension, and ongoing vwendor support is easily covered under the
zombie names clause.  Finally, the adoption of the <tt>&lt;version&gt;</tt>
header at Jacksonville, 2018 resolved most of the remaining concerns.
</p>



<!-------------------------- SECTION BREAK ------------------------>



<h3><a name="3.5">D.5 C standard library headers [depr.c.headers]</a></h3>
<p>
The basic C library headers are an essential compatibility feature,
and not going anywhere anytime soon.  However, there are certain
C++ specific counterparts that do not bring value, particularly
where the corresponding C header's job is to supply macros that
masquerade as keywords already present in the C++ langauge.
</p>

<p>
One possibility to be more aggressive here, following the decision
to not adopt <i>all</i> C11 headers as part of the C++ mapping to
C, would be to remove those same C headers from the subset that
must be shipped with a C++ compiler.  This would not prevent those
headers being supplied, as part of a full C implementation, but
would indicate that they have no value to a C++ system.
</p>

<p>
Finally, it seems clear that the C headers will be retained
essentially forever, as a vital compatibility layer with C
and POSIX.  It may be worth undeprecating the headers, and
finding a home for them as a compatibility layer in the main
standard.  It is also possible that we will want to explore
a different approach in the future once modules are part of
C++, and the library is updated to properly take advantage
of the new language feature.  Therefore, we make no
recommendation to undeprecate these headers for C++20, but
will keep looking into this space for C++23.
</p>


<blockquote class="recommend">
<b>strong recommendation:</b>
Undeprecate the remaining <b>[depr.c.headers]</b> and move it directly into
20.5.5.2 <b>[res.on.headers]</b>.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
In addition to tbe above, also remove the corresponding C headers from the
C++ standard, much as we have no corresponding <tt>&lt;stdatomic.h&gt;</tt>,
<tt>&lt;stdnoreturn.h&gt;</tt>, or <tt>&lt;threads.h&gt;</tt>, headers.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> No recommendation, take no action without a
more detailed paper.
</blockquote>

<blockquote class="review_note">
It will be difficult to reach a consensus to take any action here.
Some folks want to remove the dependency on C entirely, and remove
these headers from the C++ Standard.  Another group agree with the
strong recommendation that these headers really cannot be removed
from a real implementation, so should be recognized and maintained
as a regular non-deprecated feature.  There was no consensus for
the smaller matter of removing the vacuuous C headers, as the
<tt>#include</tt> itself is seen as part of the compatibility layer.
However, there was insufficient enthusiasm to push through the C11
vacuous headers that were deliberately not adopted for C++17 either.
</blockquote>

<blockquote class="review_note">
Related to a future paper on this topic, Walter Brown has a paper,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0657r0.pdf">P0657R0</a>,
that addresses a stronger deprecation on the use of the global
namespace by the C (and by implication, C++) headers.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.6">D.6 <tt>char*</tt> streams [depr.str.strstreams]</a></h3>
<p>
The <tt>char*</tt> streams were provided, pre-deprecated, in C++98 and
have been considered for removal before.  The underlying principle of
not removing them until a suitable replacement is available still holds,
so there should be nothing further to do at this point.  However, it is
looking increasingly likely that any future replacement facility will be
part of the <tt>std2</tt> library initiative, providing a wholesale
replacement for the current iostreams facility.  If we believe that the
future replacement is more likely to come from this direction, it would
be better to integrate this facility back into the main standard, as it
would clearly not be due a replacement within namespace <tt>std</tt> at
that point.
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b>
take no action.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
Undeprecate the <tt>char*</tt> streams.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, take no action for C++20.
</blockquote>

<blockquote class="review_note">
It seems that there will be papers addressing the required replacement facility
within the C++20 timeframe.  We will revisit this topic again for C++23.
</blockquote>


<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.7">D.7 <tt>uncaught_exception</tt> [depr.uncaught]</a></h3>
<p>
This function is a remnant of the early attempts to implement an
exception-aware API.  It turned out to be surprisingly hard to specify,
not least because it was not entirely obvious at the time that more than
one exception may be simultaneously active in a single thread.
</p>

<p>
The function seems harmless, and takes up little space in the standard,
so there is no immediate rush to remove it.  As a low level (language support)
part of the free-standing library, it is likely that some ABIs depend on
its continued existence, although library vendors would remain free to
continue supplying it for their ABI needs under the zombie names policy.
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b>
take no action yet, unless this is our once-in-a-decade opportunity to
break ABIs.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
remove the function, and add a new entry to the [zombie.names] clause.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept weak recommendation, strike from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference for removing replaced facilities from the standard
at the earliest opportunity, and letting the vendors remove the zombie
implementations at a time of their own choosing, assessing their own
customer demand.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.8">D.8 Old adaptable function bindings [depr.func.adaptor.binding]</a></h3>
<p>
The adaptable function bindings were a strong candidate for removal in C++17,
but were retained only because there was no adequate replacement for users of
the unary/binary negators to migrate to.  That feature, <tt>std::not_fn</tt>,
was added to C++17 to allow the migration path, with the plan to remove this
obsolete facility at the first opportunity in the C++20 cycle.
</p>

<p>
There are several superior alternatives available to the classic adaptable
function APIs.  <tt>std::bind</tt> does not rely on mark-up with specific
aliases in classes, and extends to an arbitrary number of parameters.
Lambda expressions are often simpler to read, and integrated directly
into the language.
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b>
remove this facility from C++20.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
Remove only the negators from C++20.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, strike from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference for removing replaced facilities from the standard
at the earliest opportunity, and letting the vendors remove the zombie
implementations at a time of their own choosing, assessing their own
customer demand.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.9">D.9 The default allocator [depr.default.allocator]</a></h3>
<p>
One surprising issue turned up with an implementation that eagerly removed
the deprecated names.  It turns out that there are platforms where <tt>size_t</tt>
and <tt>ptrdiff_t</tt> are not signed/unsigned variations on the same underlying
type, so relying on the default type computation through <tt>allocator_traits</tt>
produces ABI incompatibilities.  It appears reasonably safe to remove the other
members once direct use has diminished.  This would be a noticable compatibility
hurdle for containers trying to retain compatibility with both C++03 code and
C++20, due to the lack of <tt>allocator_traits</tt> in that earlier standard.
However, most of a decade will have passed since the publication of C++11 by the
time C++20 is published, and that may be deemed sufficient time to address
compatibility concerns.
</p>
<p>
<tt>allocator&lt;void&gt;</tt> does not serve a useful compatibility
purpose, and should safely be removed.  There are no special names to
be reserved as zombies, as all removed identifiers continue to be used
throughout the library.
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b> Undeprecate <tt>std::allocator&lt;T&gt;::size_type</tt>
and <tt>std::allocator&lt;T&gt;::difference_type</tt>, and remove the remaining
deprecated parts from the C++20 standard:
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
Undeprecate <tt>std::allocator&lt;T&gt;::size_type</tt> and
<tt>std::allocator&lt;T&gt;::difference_type</tt>, and remove
(just) <tt>std::allocator&lt;void&gt;</tt>:
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, strike from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference for removing replaced facilities from the standard
at the earliest opportunity, and letting the vendors remove the zombie
implementations at a time of their own choosing, assessing their own
customer demand.
</blockquote>

<p>
Note that there has been additional discussion on the LWG reflector since
this paper was reviewed in LEWG that <tt>std::allocator&lt;void&gt;</tt>
is an important type in the Networking TS, where it is the classic model
of a <i>proto-allocator</i>.  Removing the explicit specialization, per
the proposed resolution below, should no impact on that, as the primary
template will now provide the correct behavior.  The main concern is that
the <tt>allocate</tt> and <tt>deallocate</tt> function signatures will be
present and detectable via SFINAE, but will not instantiate if called.
In particular, this would affect explict template instantiations, rather
than the typical implicit template instantiation.  Note that this class
is no different to other allocators such as <tt>scoped_allocator_adaptor</tt>
and <tt>polymorphic_allocator</tt> in this regard, and it is suggested
that a separate paper on proto-allocators be written if we want to better
constrain allocators so that the <tt>allocate</tt> and <tt>deallocate</tt>
functions are not present (in general) for instantations for <tt>void</tt>.
</p>


<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.10">D.10 Raw storage iterator [depr.storage.iterator]</a></h3>
<p>
<tt>raw_storage_iterator</tt> is a limited facility with several shortcomings
that are unlikely to be addressed.  The most obvious is that in its intended
use in an algorithm, there is no clear way to identify how many items have
been constructed and would be cleaned up if a constructor throws.  Such a
fundamentally unsafe type has no place in a modern standard library.
</p>

<p>
Additional concerns include that it does not support allocators, and does not
call <tt>allocator_traits::construct</tt> to initialize elements, making it
unsuitable as an implementation detail for the majority of containers.
</p>

<p>
To continue as an integral part of the C++ standard library it should acquire
external deduction guides to deduce <tt>T</tt> from the <tt>value_type</tt> of
the passed <tt>OutputIterator</tt>, but it does not seem worth the effort to
revive.
</p>

<p>
The class template may live on a while longer as a zombie name, allowing
vendors to wean customers off at their own pace, but this class no longer
belongs in the C++ Standard Library.
</p>

<blockquote class="recommend">
<b>Strong recommendation:</b>
remove the deprecated iterator from C++20.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
take no action.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, strike from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference for removing replaced facilities from the standard
at the earliest opportunity, and letting the vendors remove the zombie
implementations at a time of their own choosing, assessing their own
customer demand.
</blockquote>


<blockquote class="review_note">
There was some concern that the iterator may still be safely used in
special circumstances, where the user knowa that the copy constructor
will not throw, and that allocators are not involved (requiring a call
to <tt>construt</tt>).  However, users able to reason that they can
safely use the iterator are also (generally) capable of providing their
own solution, and we prefer to remove a potentially dangerous tool from
the standard.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.11">D.11 Temporary buffers [depr.temporary.buffer]</a></h3>

<blockquote class="recommend">
<b>Strong recommendation:</b>
remove the awkward API.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
add sufficient facilities for safe use that the facility can be undeprecated.
Details are deferred to a follow-up paper, if desired.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, strike from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference for removing replaced facilities from the standard
at the earliest opportunity, and letting the vendors remove the zombie
implementations at a time of their own choosing, assessing their own
customer demand.
</blockquote>


<blockquote class="review_note">
It is worth noting that the domain itself is not dead, as SG 12
continues to work in this space.  However, this C++98 API still
offers more than it actually provides, behind an API requiring
the user to provide their own resource wrappers, so removing this
feature gives SG 12 the most freedom to pursue a correct solution
in the future.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.12">D.12 Deprecated type traits [depr.meta.types]</a></h3>

<blockquote class="recommend">
<b>Strong recommendation:</b>
Remove the traits that can live on as zombies.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
take no action at this time.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, strike from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference for removing replaced facilities from the standard
at the earliest opportunity, and letting the vendors remove the zombie
implementations at a time of their own choosing, assessing their own
customer demand.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.13">D.13 Deprecated iterator primitives [depr.iterator.primitives]</a></h3>

<blockquote class="recommend">
<b>Strong recommendation:</b>
enhance <tt>iterator_traits</tt> with implicit deductions of each
nested name, to better facilitate removal of this feature.
Details are deferred to a follow-up paper, if desired.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
remove this awkward class template, whether or not an improved
deduction facility becomes available.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Take no action.
</blockquote>

<blockquote class="review_note">
It is not clear that there is interest in pursuing the idea that
the iterator traits themselves default more of the typedef-names,
which is the main service the deprecated facility provides.  The
whole issue may become moot with the addition of concepts and
ranges to the library, but it is too early to speculate on their
impact here.
</blockquote>


<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.14">D.14 Deprecated <tt>shared_ptr</tt> observers [depr.util.smartptr.shared.obs]</a></h3>

<blockquote class="recommend">
<b>Strong recommendation:</b>
Remove misleading function, as <tt>use_count</tt> remains for single-threaded use.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
take no action yet.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Accept strong recommendation, strike from C++20.
</blockquote>

<blockquote class="review_note">
There is a preference for removing replaced facilities from the standard
at the earliest opportunity, and letting the vendors remove the zombie
implementations at a time of their own choosing, assessing their own
customer demand.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.15">D.15 Standard code conversion facets [depr.locale.stdcvt]</a></h3>

<blockquote class="recommend">
<b>Strong recommendation:</b>
Remove the header <tt>&lt;codecvt&gt;</tt>; retain all names, including header name,
as zombies.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
take no action yet.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Take no action.
</blockquote>

<blockquote class="review_note">
There was a consensus to remove, that ia held back by a dependency in D.16 [depr.conversions].
There was no consesnus ro remove the latter without at least a paper showing
how users should solve their text conversion problems without these facilities.
</blockquote>




<!-------------------------- SECTION BREAK ------------------------>


<h3><a name="3.16">D.16 Deprecated character conversions [depr.conversions]</a></h3>

<blockquote class="recommend">
<b>Strong recommendation:</b>
Remove this facility from the standard at the earliest opportunity.
</blockquote>


<blockquote class="recommend">
<b>Weak recommendation:</b>
take no action yet.
</blockquote>


<blockquote class="review">
<b>Toronto Review:</b> Take no action.
</blockquote>

<blockquote class="review_note">
There was no consesnus ro remove this facility without at least a paper showing
how users should solve their text conversion problems without these facilities.
There was a clear desire to see such a paper in order to proceed with removing
these poorly specified features.
</blockquote>



<!-------------------------- SECTION BREAK ------------------------>


<h2><a name="4.0">4 Other Directions</a></h2>
<p>
While practicing good housekeeping and clearing out Annex D for each
release may be the preferred option, there are other approaches that
may be taken.
</p>

<h4>Do Nothing</h4>
<p>
One approach, epitomised in the Java language, is that deprecated
features are discouraged for future use, but guaranteed to remain
available forever, and just accumulate.
</p>

<p>
This approach is rejected by this paper for a number of reasons.
First, C++ has been relatively successful in actually removing
its deprecated features in the past, a tradition we would like
to continue.  It also undercuts the available-forever rationale,
as it is not a guarantee we have given before.
</p>

<p>
A second concern is that we do not want to pay a cost to maintain
deprecated components forever - restricting growth of the language
for compatibility with deprecated features, or having to review
the whole of Annex D and upgrade components for every new language
release, in order to keep up with subtle shifts in the core
language.
</p>

<h4>Undeprecate</h4>
<p>
If something is deprecated, but later (re)discovered to have value,
then it could be revitalized and restored to the main standard.  For
example, this is exactly what happened to static function declarations
when the unnamed namespace was given internal linkage - it is merely
the classical way to say the same thing, and often clearer to write.
</p>

<p>
This may be a consideration for long-term deprecated features that
don't appear to be going anywhere, such as the <tt>strstream</tt>
facility, or the C headers.  It may be appropriate to find them a
home in the regular standard, and this is called out in the specific
reviews of each facility above.
</p>


<!-------------------------- SECTION BREAK ------------------------>


<h2><a name="5.0">5 Library Fixes for Deprecated Features</a></h2>
<p>
For now, this section does not contain any wording for feature removal or
undeprecation, as the proposed drafting for (re)moving each facility is
attached to the subsection reviewing those features.  Once the relevant
evolution groups have agreed which removals should proceed, the wording will be
consolidated here as a simpler direction for the project editor(s) to apply.
</p>
<p>
Below is a minimal set of edits that fix unreported issues with the current
standard, that bring it much closer to its original intent wrt some of the
features explored above.  These changes are proposed regardless of the
acceptance or rejection of any (or all) of the suggestions above.
</p>

<blockquote class="note">
Add missing zombies from prior standards:
</blockquote>

<blockquote>
<h4>20.5.4.3.1 Zombie names [zombie.names]</h4>
<ol>
<li>
In namespace <tt>std</tt>, the following names are reserved for previous
standardization: <tt>auto_ptr</tt>, <ins><tt>auto_ptr_ref</tt>,</ins>
<tt>binary_function</tt>, <tt>bind1st</tt>, <tt>bind2nd</tt>,
<tt>binder1st</tt>, <tt>binder2nd</tt>, <tt>const_mem_fun1_ref_t</tt>,
<tt>const_mem_fun1_t</tt>, <tt>const_mem_fun_ref_t</tt>,
<tt>const_mem_fun_t</tt>, <tt>get_unexpected</tt>, <ins><tt>gets</tt>,</ins>
<tt>mem_fun1_ref_t</tt>, <tt>mem_fun1_t</tt>, <tt>mem_fun_ref_t</tt>,
<tt>mem_fun_ref</tt>, <tt>mem_fun_t</tt>, <tt>mem_fun</tt>,
<tt>pointer_to_binary_function</tt>, <tt>pointer_to_unary_function</tt>,
<tt>ptr_fun</tt>, <tt>random_shuffle</tt>, <tt>set_unexpected</tt>,
<tt>unary_function</tt>, <tt>unexpected</tt>, and <tt>unexpected_handler</tt>.
</li>

<li><ins>
The following names are reserved as member types for previous standardization,
and may not be used as names for object-like macros in portable code:
<tt>io_state</tt>, <tt>open_mode</tt>, and <tt>seek_dir</tt>
</ins></li>

<li><ins>
The following name is reserved as a member function for previous
standardization, and may not be used as names for function-like macros in
portable code: <tt>stossc</tt>.
</ins></li>
</ol>
</blockquote>

<blockquote class="note">
Provide default copy operations for the following classes, so that they
no longer rely on deprecated copy constructor/assignment generation,
even if the feature is not removed:
<ul>
  <li><tt>bitset&lt;N&gt;::reference</tt> - assign, no copy ctor</li>
  <li><tt>allocator</tt> - copy ctor, no assignment</li>
  <li><tt>pmr::memory_resource</tt> - dtor only, no copy/assign</li>
  <li><tt>vector&lt;bool&gt;::reference</tt> - assign, no copy ctor</li>
  <li><tt>istream_iterator</tt> - copy ctor, no assignment</li>
  <li><tt>ostream_iterator</tt> - copy ctor, no assignment</li>
  <li><tt>istreambuf_iterator</tt> - copy ctor, no assignment</li>
  <li><tt>complex&lt;float&gt;</tt> - assign, no copy ctor</li>
  <li><tt>complex&lt;double&gt;</tt> - assign, no copy ctor</li>
  <li><tt>complex&lt;long double&gt;</tt> - assign, no copy ctor</li>
  <li><tt>ios_base::Init</tt> - dtor only, no copy/assign</li>
</ul>
</blockquote>


<!-------------------------- SECTION BREAK ------------------------>


<h2><a name="6.0">6 Integrated Proposed Wording</a></h2>

<p>
This section integrates the proposed wording of the above
recommendations as the various working groups approve them
for review by the Core and Library Working Groups.  It
immediately adopts the proposed Library Fixes for Deprecated
Features, with the expectation that libary will want to
review one integrated set of words when this paper reaches
that group.
</p>

<p>
Collected summary of recommendations:
</p>
<table>
  <tr>
    <td><b>Subclause</b></td>
    <td><b>Feature</b></td>
    <td><b>Adopted Recommendation</b></td>
    <td>Action</td>
  </tr>
  <tr>
    <td>D.1</td>
    <td>Reclare <tt>constexpr</tt> members</td>
    <td>Strong recommendation</td>
    <td>Take no action</td>
  </tr>
  <tr>
    <td>D.2</td>
    <td>Implicit special members</td>
    <td>Weak recommendation</td>
    <td>Take no action</td>
  </tr>
  <tr>
    <td>D.3</td>
    <td><tt>throw()</tt> specifications</td>
    <td>Weak recommendation</td>
    <td>Remove the feature</td>
  </tr>
  <tr>
    <td>D.4</td>
    <td>Vacuous C++ headers</td>
    <td>Strong recommendation</td>
    <td>remove all now</td>
  </tr>
  <tr>
    <td>D.5</td>
    <td>C <tt>&lt;*.h&gt;</tt> headers</td>
    <td>Need more info</td>
    <td>Recommend a paper addressing support for C headers in C++</td>
  </tr>
  <tr>
    <td>D.6</td>
    <td><tt>char *</tt> streams</td>
    <td>Strong recommendation</td>
    <td>Take no action <i>yet</i></td>
  </tr>
  <tr>
    <td>D.7</td>
    <td><tt>uncaught_exception</tt></td>
    <td>Weak recommendation</td>
    <td>Remove all now</td>
  </tr>
  <tr>
    <td>D.8</td>
    <td>Adaptable function protocol</td>
    <td>Strong recommendation</td>
    <td>Remove all now</td>
  </tr>
  <tr>
    <td>D.9</td>
    <td>Deducable <tt>allocator</tt> members</td>
    <td>Strong recommendation</td>
    <td>Remove now, with fix</td>
  </tr>
  <tr>
    <td>D.10</td>
    <td><tt>raw_storage_iterator</tt></td>
    <td>Strong recommendation</td>
    <td>Remove all now</td>
  </tr>
  <tr>
    <td>D.11</td>
    <td>Temporary buffers API</td>
    <td>Strong recommendation</td>
    <td>Remove all now</td>
  </tr>
  <tr>
    <td>D.12</td>
    <td>Deprecated type traits</td>
    <td>Strong recommendation</td>
    <td>Remove all now</td>
  </tr>
  <tr>
    <td>D.13</td>
    <td><tt>std::iterator</tt></td>
    <td>No action</td>
    <td>Welcome paper for traits deduction, tentatively defer removal to C++23</td>
  </tr>
  <tr>
    <td>D.14</td>
    <td><tt>shared_ptr::unique</tt></td>
    <td>Strong recommendation</td>
    <td>Remove now</td>
  </tr>
  <tr>
    <td>D.15</td>
    <td><tt>&ltcodecvt&gt;</tt></td>
    <td>Need more info</td>
    <td>Recommend a paper addressing D15/16</td>
  </tr>
  <tr>
    <td>D.16</td>
    <td><tt>wstring_convert</tt> et al.</td>
    <td>Need more info</td>
    <td>Recommend a paper addressing D15/16</td>
  </tr>
</table>

<p>
Full wording follows:
</p>

<blockquote>
<h4>18.4 Exception specifications [except.spec]</h4>
<ol>
<li>
The predicate indicating whether a function cannot exit via an exception is
called the <i>exception specification</i> of the function. If the predicate is false,
the function has a <i>potentially-throwing exception specification</i>, otherwise it
has a <i>non-throwing exception specification</i>. The exception specification is
either defined implicitly, or defined explicitly by using a <i>noexcept-specifier</i>
as a suffix of a function declarator (11.3.5).

<blockquote><pre>
<i>noexcept-specifier</i> :
  <tt>noexcept</tt> ( <i>constant-expression</i> )</tt>
  <tt>noexcept</tt>
  <del><tt>throw</tt> ( )</del>
</pre></blockquote>
</li>
<li>
In a <i>noexcept-specifier</i>, the <i>constant-expression</i>, if supplied,
shall be a contextually converted constant expression of type <tt>bool</tt>
(8.6); that constant expression is the exception specification of the function
type in which the <i>noexcept-specifier</i> appears. A ( token that follows
<tt>noexcept</tt> is part of the <i>noexcept-specifier</i> and does not
commence an initializer (11.6). The <i>noexcept-specifier</i> <tt>noexcept</tt>
without a <i>constant-expression</i> is equivalent to the <i>noexcept-specifier</i>
<tt>noexcept(true)</tt>. <del>The <i>noexcept-specifier</i> <tt>throw()</tt> is
deprecated (D.3), and equivalent to the <i>noexcept-specifier</i>
<tt>noexcept(true)</tt>.</del>
</li>
</ol>

<ol start="12">
<li>[ <i>Example:</i>
<pre>
   struct A {
     A(int = (A(5), 0)) noexcept;
     A(const A&amp;) noexcept;
     A(A&amp;&amp;) noexcept;
     ~A();
   };
   struct B {
     B() <del>throw()</del><ins>noexcept</ins>;
     B(const B&amp;) = default;  <i>// implicit exception specification is <tt>noexcept(true)</tt></i>
     B(B&amp;&amp;, int = (throw Y(), 0)) noexcept;
     ~B() noexcept(false);
   };
   int n = 7;
   struct D : public A, public B {
     int * p = new int[n];
     <i>// D::D() potentially-throwing, as the new operator may throw <tt>bad_alloc</tt> or <tt>bad_array_new_length</tt></i>
     <i>// D::D(const D&amp;) non-throwing</i>
     <i>// D::D(D&amp;&amp;) potentially-throwing, as the default argument for B's constructor may throw</i>
     <i>// D::~D() potentially-throwing</i>
   };
</pre>
Furthermore, if <tt>A::~A()</tt> were virtual, the program would be ill-formed
since a function that overrides a virtual function from a base class shall not
have a potentially-throwing exception specification if the base class function
has a non-throwing exception specification. &mdash; <i>end example</i> ]
</li>
</ol>


<h4>20.5.1.2 Headers [headers]</h4>
<p>
Table 17 &mdash; C++ headers for C library facilities
</p>
<table>
  <tr>
    <td><tt>&lt;cassert&gt;</tt></td>
    <td><tt>&lt;cinttypes&gt;</tt></td>
    <td><tt>&lt;csignal&gt;</tt></td>
    <td><tt>&lt;cstdio&gt;</tt></td>
    <td><tt>&lt;cwchar&gt;</tt></td>
  </tr>
  <tr>
    <td><tt><del>&lt;ccomplex&gt;</del></tt></td>
    <td><tt><del>&lt;ciso646&gt;</del></tt></td>
    <td><tt><del>&lt;cstdalign&gt;</del></tt></td>
    <td><tt>&lt;cstdlib&gt;</tt></td>
    <td><tt>&lt;cwctype&gt;</tt></td>
  </tr>
  <tr>
    <td><tt>&lt;cctype&gt;</tt></td>
    <td><tt>&lt;climits&gt;</tt></td>
    <td><tt>&lt;cstdarg&gt;</tt></td>
    <td><tt>&lt;cstring&gt;</tt></td>
    <td><tt></tt></td>
  </tr>
  <tr>
    <td><tt>&lt;cerrno&gt;</tt></td>
    <td><tt>&lt;clocale&gt;</tt></td>
    <td><tt><del>&lt;cstdbool&gt;</del></tt></td>
    <td><tt><del>&lt;ctgmath&gt;</del></tt></td>
    <td><tt></tt></td>
  </tr>
  <tr>
    <td><tt>&lt;cfenv&gt;</tt></td>
    <td><tt>&lt;cmath&gt;</tt></td>
    <td><tt>&lt;cstddef&gt;</tt></td>
    <td><tt>&lt;ctime&gt;</tt></td>
    <td><tt></tt></td>
  </tr>
  <tr>
    <td><tt>&lt;cfloat&gt;</tt></td>
    <td><tt>&lt;csetjmp&gt;</tt></td>
    <td><tt>&lt;cstdint&gt;</tt></td>
    <td><tt>&lt;cuchar&gt;</tt></td>
    <td><tt></tt></td>
  </tr>
</table>

<p>
Footnote 174) In particular, including the standard header
<tt>&lt;iso646.h&gt;</tt> <del>or <tt>&lt;ciso646&gt;</tt></del> has no effect.
</p>

<h4>20.5.1.3 Freestanding implementations [compliance]</h4>
<p>
Table 19 &mdash; C++ headers for freestanding implementations
</p>
<table>
  <tr>
    <td></td>
    <td><b>subclause</b></td>
    <td><b>header</b></td>
  </tr>
  <tr>
    <td></td>
    <td></td>
    <td><tt><del>&lt;ciso646&gt;</del></tt></td>
  </tr>
  <tr>
    <td>21.2</td>
    <td>Types</td>
    <td><tt>&lt;cstddef&gt;</tt></td>
  </tr>
  <tr>
    <td>21.3</td>
    <td>Implementation properties</td>
    <td><tt>&lt;cfloat&gt;</tt> <tt>&lt;limits&gt;</tt> <tt>&lt;climits&gt;</tt></td>
  </tr>
  <tr>
    <td>21.4</td>
    <td>Integer types</td>
    <td><tt>&lt;cstdint&gt;</tt></td>
  </tr>
  <tr>
    <td>21.5</td>
    <td>Start and termination</td>
    <td><tt>&lt;cstdlib&gt;</tt></td>
  </tr>
  <tr>
    <td>21.6</td>
    <td>Dynamic memory management</td>
    <td><tt>&lt;new&gt;</tt></td>
  </tr>
  <tr>
    <td>21.7</td>
    <td>Type identification</td>
    <td><tt>&lt;typeinfo&gt;</tt></td>
  </tr>
  <tr>
    <td>21.8</td>
    <td>Exception handling</td>
    <td><tt>&lt;exception&gt;</tt></td>
  </tr>
  <tr>
    <td>21.9</td>
    <td>Initializer lists</td>
    <td><tt>&lt;initializer_list&gt;</tt></td>
  </tr>
  <tr>
    <td>21.10</td>
    <td>Other runtime support</td>
    <td><tt>&lt;cstdarg&gt;</tt> </td>
  </tr>
  <tr>
    <td>23.15</td>
    <td>Type traits</td>
    <td><tt>&lt;type_traits&gt;</tt></td>
  </tr>
  <tr>
    <td>Clause 32</td>
    <td>Atomics</td>
    <td><tt>&lt;atomic&gt;</tt></td>
  </tr>
  <tr>
    <td><del>D.4.2, D.4.3</del></td>
    <td><del>Deprecated headers</del></td>
    <td><del><tt>&lt;cstdalign&gt;</tt> <tt>&lt;cstdbool&gt;</tt></del></td>
  </tr>
</table>


<h4>20.5.4.3.1 Zombie names [zombie.names]</h4>
<ol>
<li>
In namespace <tt>std</tt>, the following names are reserved for previous
standardization:
<ol>
  <li>&mdash; <tt>auto_ptr</tt>,</li>
  <li>&mdash; <ins><tt>auto_ptr_ref</tt>,</ins></li>
  <li>&mdash; <tt>binary_function</tt>,</li>
  <li>&mdash; <ins><tt>binary_negate</tt>,</ins></li>
  <li>&mdash; <tt>bind1st</tt>,</li>
  <li>&mdash; <tt>bind2nd</tt>,</li>
  <li>&mdash; <tt>binder1st</tt>,</li>
  <li>&mdash; <tt>binder2nd</tt>,</li>
  <li>&mdash; <tt>const_mem_fun1_ref_t</tt>,</li>
  <li>&mdash; <tt>const_mem_fun1_t</tt>,</li>
  <li>&mdash; <tt>const_mem_fun_ref_t</tt>,</li>
  <li>&mdash; <tt>const_mem_fun_t</tt>,</li>
  <li>&mdash; <ins><tt>get_temporary_buffer</tt>,</ins></li>
  <li>&mdash; <tt>get_unexpected</tt>,</li>
  <li>&mdash; <ins><tt>gets</tt>,</ins></li>
  <li>&mdash; <ins><tt>is_literal_type</tt>,</ins></li>
  <li>&mdash; <ins><tt>is_literal_type_v</tt>,</ins></li>
  <li>&mdash; <tt>mem_fun1_ref_t</tt>,</li>
  <li>&mdash; <tt>mem_fun1_t</tt>,</li>
  <li>&mdash; <tt>mem_fun_ref_t</tt>,</li>
  <li>&mdash; <tt>mem_fun_ref</tt>,</li>
  <li>&mdash; <tt>mem_fun_t</tt>,</li>
  <li>&mdash; <tt>mem_fun</tt>,</li>
  <li>&mdash; <ins><tt>not1</tt>,</ins></li>
  <li>&mdash; <ins><tt>not2</tt>,</ins></li>
  <li>&mdash; <tt>pointer_to_binary_function</tt>,</li>
  <li>&mdash; <tt>pointer_to_unary_function</tt>,</li>
  <li>&mdash; <tt>ptr_fun</tt>,</li>
  <li>&mdash; <tt>random_shuffle</tt>,</li>
  <li>&mdash; <ins><tt>raw_storage_iterator</tt>,</ins></li>
  <li>&mdash; <ins><tt>result_of</tt>,</ins></li>
  <li>&mdash; <ins><tt>result_of_t</tt>,</ins></li>
  <li>&mdash; <ins><tt>return_temporary_buffer</tt>,</ins></li>
  <li>&mdash; <tt>set_unexpected</tt>,</li>
  <li>&mdash; <tt>unary_function</tt>,</li>
  <li>&mdash; <ins><tt>unary_negate</tt>,</ins></li>
  <li>&mdash; <ins><tt>uncaught_exception</tt>,</ins></li>
  <li>&mdash; <tt>unexpected</tt>, and</li>
  <li>&mdash; <tt>unexpected_handler</tt>.</li>
</ol>
</li>
<li><ins>
The following names are reserved as member types for previous standardization,
and may not be used as a name for object-like macros in portable code:
<ol>
  <li><ins>&mdash; <tt>argument_type</tt>,</ins></li>
  <li><ins>&mdash; <tt><tt>first_argument_type</tt></tt>,</ins></li>
  <li><ins>&mdash; <tt>io_state</tt>,</ins></li>
  <li><ins>&mdash; <tt>open_mode</tt>,</ins></li>
  <li><ins>&mdash; <tt>second_argument_type</tt>, and</ins></li>
  <li><ins>&mdash; <tt>seek_dir</tt>.</ins></li>
</ol>
</ins></li>
<li><ins>
The name <tt>stossc</tt> is reserved as a member function for previous
standardization, and may not be used as names for function-like macros in
portable code.
</ins></li>

<li><ins>
The header names <tt>&lt;ccomplex&gt;</tt>, <tt>&lt;ciso646&gt;</tt>,
<tt>&lt;cstdalign&gt;</tt>, <tt>&lt;cstdbool&gt;</tt>, and
<tt>&lt;ctgmath&gt;</tt> are reserved for previous standardization.
</ins></li>
</ol>


<h4>23.9.2 Class template bitset [template.bitset]</h4>
<blockquote><pre>
namespace std {
  template&lt;size_t N&gt; class bitset {
  public:
    <i>// bit reference:</i>
    class reference {
      friend class bitset;
      reference() noexcept;
    public:
      <ins>reference(const reference&amp;) = default;</ins>
      ~reference() <del>noexcept</del>;
      reference&amp; operator=(bool x) noexcept;             <i>// for</i> b[i] = x;
      reference&amp; operator=(const reference&amp;) noexcept;   <i>// for</i> b[i] = b[j];
      bool operator~() const noexcept;                   <i>// flips the bit</i>
      operator bool() const noexcept;                    <i>// for</i> x = b[i];
      reference&amp; flip() noexcept;                        <i>// for</i> b[i].flip();
    };

    <i>// 23.9.2.1, constructors</i>
    ...
};
</pre></blockquote>


<h4>23.10.10 The default allocator [default.allocator]</h4>
<blockquote><pre>
namespace std {
  template &lt;class T&gt; class allocator {
  public:
    using value_type      = T;
    <ins>using size_type       = size_t;</ins>
    <ins>using difference_type = ptrdiff_t;</ins>
    using propagate_on_container_move_assignment = true_type;
    using is_always_equal = true_type;

    allocator() noexcept;
    allocator(const allocator&amp;) noexcept;
    template &lt;class U&gt; allocator(const allocator&lt;U&gt;&amp;) noexcept;
    ~allocator();
    <ins>allocator&amp; operator=(const allocator&amp;) noexcept = default;</ins>


    [[nodiscard]] T* allocate(size_t n);
    void deallocate(T* p, size_t n);
  };
}
</pre></blockquote>


<h4>23.12.2 Class memory_resource [mem.res.class]</h4>
<blockquote><pre>
namespace std {
  class memory_resource {
    static constexpr size_t max_align = alignof(max_align_t); <i>// exposition only</i>

  public:
    <ins>memory_resource(const memory_resource&amp;) = default;</ins>
    virtual ~memory_resource();

    <ins>memory_resource&amp; operator=(const memory_resource&amp;) = default;</ins>

    [[nodiscard]] void* allocate(size_t bytes, size_t alignment = max_align);
    void deallocate(void* p, size_t bytes, size_t alignment = max_align);

    bool is_equal(const memory_resource&amp; other) const noexcept;

  private:
    virtual void* do_allocate(size_t bytes, size_t alignment) = 0;
    virtual void do_deallocate(void* p, size_t bytes, size_t alignment) = 0;

    virtual bool do_is_equal(const memory_resource&amp; other) const noexcept = 0;
  };
}
</pre></blockquote>

<blockquote class="note">
Although copy operations are defaulted here for compatibility with
the implicit declarations of C++17, it would be consistent with
the original design to actually delete them, and provide a protected
default constructor.  All the derived implementations in the standard
library delete both copy constructor and copy-assignment, and in doing
so, inhibit the move operations too.
</blockquote>


<h4>26.3.12 Class <tt>vector&lt;bool&gt;</tt></h4>
<blockquote><pre>
namespace std {
  template &lt;class Allocator&gt;
  class vector&lt;bool, Allocator&gt; {
  public:
    <i>// types:</i>
    ...

    <i>// bit reference:</i>
    class reference {
      friend class vector;
      reference() noexcept;

    <i>public:</i>
      <ins>reference(const reference&amp;) = default;</ins>
      ~reference();
      operator bool() const noexcept;
      reference&amp; operator=(const bool x) noexcept;
      reference&amp; operator=(const reference&amp; x) noexcept;
      void flip() noexcept; // flips the bit
    };

    <i>// construct/copy/destroy:</i>
    ...
  };
}
</pre></blockquote>


<h4>27.6.1 Class template istream_iterator [istream.iterator]</h4>
<blockquote><pre>
namespace std {
  template &lt;class T, class charT = char, class traits = char_traits&lt;charT&gt;,
      class Distance = ptrdiff_t&gt;
  class istream_iterator {
  public:
    using iterator_category = input_iterator_tag;
    using value_type        = T;
    using difference_type   = Distance;
    using pointer           = const T*;
    using reference         = const T&amp;;
    using char_type         = charT;
    using traits_type       = traits;
    using istream_type      = basic_istream&lt;charT,traits&gt;;

    constexpr istream_iterator();
    istream_iterator(istream_type&amp; s);
    istream_iterator(const istream_iterator&amp; x) = default;
    ~istream_iterator() = default;

    <ins>istream_iterator&amp; operator=(const istream_iterator&amp; x) = default;</ins>
    const T&amp; operator*() const;
    const T* operator-&gt;() const;
    istream_iterator&amp; operator++();
    istream_iterator  operator++(int);
  private:
    basic_istream&lt;charT,traits&gt;* in_stream; <i>// exposition only</i>
    T value;                                <i>// exposition only</i>
  };
}
</pre></blockquote>


<h4>27.6.2 Class template ostream_iterator [ostream.iterator]</h4>
<blockquote><pre>
namespace std {
  template &lt;class charT = char, class traits = char_traits&lt;charT&gt;&gt;
  class ostream_iterator {
  public:
    using iterator_category = ouput_iterator_tag;
    using value_type        = void;
    using difference_type   = void;
    using pointer           = void;
    using reference         = void;
    using char_type         = charT;
    using traits_type       = traits;
    using ostream_type      = basic_ostream&lt;charT,traits&gt;;

    ostream_iterator(ostream_type&amp; s);
    ostream_iterator(ostream_type&amp; s, const charT* delimiter);
    ostream_iterator(const ostream_iterator&amp; x);
    ~ostream_iterator();

    <ins>ostream_iterator&amp; operator=(const ostream_iterator&amp; x) = default;</ins>
    ostream_iterator&amp; operator=(const T&amp; value);
    ostream_iterator&amp; operator*();
    ostream_iterator&amp; operator++();
    ostream_iterator&amp; operator++(int);
  private:
    basic_ostream&lt;charT,traits&gt;* out_stream;  <i>// exposition only</i>
    const charT* delim;                       <i>// exposition only</i>
  };
}
</pre></blockquote>


<h4>27.6.3 Class template istreambuf_iterator 	[istreambuf.iterator]</h4>
<blockquote><pre>
namespace std {
  template &lt;class T, class charT = char, class traits = char_traits&lt;charT&gt;&gt;
  class ostream_iterator {
  public:
    using iterator_category = ouput_iterator_tag;
    using value_type        = void;
    using difference_type   = void;
    using pointer           = void;
    using reference         = void;
    using char_type         = charT;
    using traits_type       = traits;
    using istream_type      = basic_istream&lt;charT,traits&gt;;

    class proxy;                          <i>// exposition only</i>

    constexpr istreambuf_iterator() noexcept;
    istreambuf_iterator(const istreambuf_iterator&amp;) noexcept = default;
    ~istreambuf_iterator() = default;
    istreambuf_iterator(istream_type&amp; s) noexcept;
    istreambuf_iterator(streambuf_type* s) noexcept;
    istreambuf_iterator(const proxy&amp; p) noexcept;

    <ins>istreambuf_iterator&amp; operator=(const istreambuf_iterator&amp;) noexcept = default;</ins>
    charT operator*() const;
    pointer operator-&gt;() const;
    istreambuf_iterator&amp; operator++();
    proxy operator++(int);
    bool equal(const istreambuf_iterator&amp; b) const;
  private:
    streambuf_type* sbuf_;               <i>// exposition only</i>
  };
}
</pre></blockquote>


<h4>29.5.3 complex specializations [complex.special]</h4>
<blockquote><pre>
namespace std {
  template&lt;&gt; class complex&lt;float&gt; {
  public:
    using value_type = float;

    <ins>constexpr complex(const complex&amp;) = default;</ins>
    constexpr complex(float re = 0.0f, float im = 0.0f);
    constexpr explicit complex(const complex&lt;double&gt;&amp;);
    constexpr explicit complex(const complex&lt;long double&gt;&amp;);

    constexpr float real() const;
    constexpr void real(float);
    constexpr float imag() const;
    constexpr void imag(float);

    constexpr complex operator= (float);
    constexpr complex operator+=(float);
    constexpr complex operator-=(float);
    constexpr complex operator*=(float);
    constexpr complex operator/=(float);

    constexpr complex operator=(const complex&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator= (const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator+=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator-=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator*=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator/=(const complex&lt;X&gt;&amp;);
  };

  template&lt;&gt; class complex&lt;double&gt; {
  public:
    using value_type = double;

    <ins>constexpr complex(const complex&amp;) = default;</ins>
    constexpr complex(double re = 0.0, double im = 0.0);
    constexpr complex(const complex&lt;float&gt;&amp;);
    constexpr explicit complex(const complex&lt;long double&gt;&amp;);

    constexpr double real() const;
    constexpr void real(double);
    constexpr double imag() const;
    constexpr void imag(double);

    constexpr complex operator= (double);
    constexpr complex operator+=(double);
    constexpr complex operator-=(double);
    constexpr complex operator*=(double);
    constexpr complex operator/=(double);

    constexpr complex operator=(const complex&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator= (const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator+=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator-=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator*=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator/=(const complex&lt;X&gt;&amp;);
  };

  template&lt;&gt; class complex&lt;long double&gt; {
  public:
    using value_type = long double;

    <ins>constexpr complex(const complex&amp;) = default;</ins>
    constexpr complex(long double re = 0.0L, long double im = 0.0L);
    constexpr complex(const complex&lt;float&gt;&amp;);
    constexpr complex(const complex&lt;double&gt;&amp;);

    constexpr long double real() const;
    constexpr void real(long double);
    constexpr long double imag() const;
    constexpr void imag(long double);

    constexpr complex operator= (long double);
    constexpr complex operator+=(long double);
    constexpr complex operator-=(long double);
    constexpr complex operator*=(long double);
    constexpr complex operator/=(long double);

    constexpr complex operator=(const complex&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator= (const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator+=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator-=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator*=(const complex&lt;X&gt;&amp;);
    template&lt;class X&gt; constexpr complex&amp; operator/=(const complex&lt;X&gt;&amp;);
  }; 
}
</pre></blockquote>


<h4>30.5.3.1.6 Class ios_base::Init [ios::Init]</h4>
<blockquote><pre>
namespace std {
  class ios_base::Init {
  public:
    Init();
    <ins>Init(const Init&amp;) = default;</ins>
    ~Init();

    <ins>Init&amp; operator=(const Init&amp;) = default;</ins>
  private:
    static int init_cnt; <i>// exposition only</i>
  };
}
</pre></blockquote>

<blockquote class="note">
In this case, deleting, rather than defaulting, the copy operations may well be
the right answer, although we propose the current edit as no change of existing
semantics.
</blockquote>


<h4><ins>C.5.2 Clause 18: exception handling  [diff.cpp17.except]</ins></h4>
<p><ins>
18.4
</ins></p>

<p><ins>
<b>Change:</b> Remove <tt>throw()</tt> exception specification.
</ins></p>

<p><ins>
<b>Rationale:</b> The empty dynamic exception specification was
retained for one additional C++ Standard to ease the transition
away from this feature.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 function declaration,
member function declaration, function pointer declaration, or function
reference declaration that uses <tt>throw()</tt> for its exception
specification will be rejected as ill-formed in this International Standard.
It should simply be replaced with <tt>noexcept</tt> for no change of meaning
since C++ 2017.
</ins></p>


<h4>C.2.8 Clause 20: library introduction [diff.cpp03.library]</h4>
<p>
2 <b>Affected subclause:</b> 20.5.1.2
</p>
<p>
<b>Change:</b> New headers.
</p>
<p>
<b>Rationale:</b> New functionality.
</p>
<p>
<b>Effect on original feature:</b> The following C++ headers are new:
<tt>&lt;array&gt;</tt>,
<tt>&lt;atomic&gt;</tt>,
<tt>&lt;chrono&gt;</tt>,
<tt>&lt;codecvt&gt;</tt>,
<tt>&lt;condition_variable&gt;</tt>,
<tt>&lt;forward_list&gt;</tt>,
<tt>&lt;future&gt;</tt>,
<tt>&lt;initializer_list&gt;</tt>,
<tt>&lt;mutex&gt;</tt>,
<tt>&lt;random&gt;</tt>,
<tt>&lt;ratio&gt;</tt>,
<tt>&lt;regex&gt;</tt>,
<tt>&lt;scoped_allocator&gt;</tt>,
<tt>&lt;system_error&gt;</tt>,
<tt>&lt;thread&gt;</tt>,
<tt>&lt;tuple&gt;</tt>,
<tt>&lt;typeindex&gt;</tt>,
<tt>&lt;type_traits&gt;</tt>,
<tt>&lt;unordered_map&gt;</tt>, and
<tt>&lt;unordered_set&gt;</tt>.
In addition the following C compatibility headers are new:
<del><tt>&lt;ccomplex&gt;</tt>,</del>
<tt>&lt;cfenv&gt;</tt>,
<tt>&lt;cinttypes&gt;</tt>,
<del><tt>&lt;cstdalign&gt;</tt>,</del>
<del><tt>&lt;cstdbool&gt;</tt>,</del>
<tt>&lt;cstdint&gt;</tt>,
<del><tt>&lt;ctgmath&gt;</tt>,</del> and
<tt>&lt;cuchar&gt;</tt>.
Valid C++ 2003 code that #includes headers with these names may be invalid in this International Standard.
</p>



<h4><ins>C.5.3 Clause 20: Library introduction [diff.cpp17.library]</ins></h4>
<p><ins>
20.5.1.2
</ins></p>

<p><ins>
<b>Change:</b> Remove vacuous C++ header files.
</ins></p>

<p><ins>
<b>Rationale:</b> The empty headers implied a false requirement to
achieve C compatibility with the C++ headers.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 program that
includes any of the following headers might not compile:
<tt>&lt;ccomplex&gt;</tt>, <tt>&lt;ciso646&gt;</tt>,
<tt>&lt;cstdalign&gt;</tt>, <tt>&lt;cstdbool&gt;</tt>, and
<tt>&lt;ctgmath&gt;</tt>.  The <tt>#include</tt> directives can
simply be removed with no loss of meaning.
</ins></p>



<h4><ins>C.5.4 Annex D: compatibility features [diff.cpp17.depr]</ins></h4>
<p><ins>
D.7
</ins></p>

<p><ins>
<b>Change:</b> Remove <tt>uncaught_exception</tt>.
</ins></p>

<p><ins>
<b>Rationale:</b> The function did not have a clear specification
when multiple exceptions were active, so has been superseded by
<tt>uncaught_exceptions</tt>.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 program that calls
<tt>std::uncaught_exception</tt> might not compile. It might be revised to use
<tt>std::uncaught_exceptions</tt> instead, for clear and portable semantics.
</ins></p>


<p><ins>
D.8
</ins></p>

<p><ins>
<b>Change:</b> Remove support for adaptable function API.
</ins></p>

<p><ins>
<b>Rationale:</b> The deprecated support relied on a limited convention that could
not be extended to support the general case or new language features.  It has been
superseded by direct language support with <tt>decltype</tt>, and by the
<tt>std::bind</tt> and <tt>std::not_fn</tt> function templates.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 program that relies on the presence
of <tt>result_type</tt>, <tt>argument_type</tt>, <tt>first_argument_type</tt>, or
<tt>second_argument_type</tt> in a standard library class might no longer compile. 
A valid C++ 2017 program that calls <tt>not1</tt> or <tt>not2</tt>, or uses the class
templates <tt>unary_negate</tt> or <tt>binary_negate</tt>, might not compile.
</ins></p>



<p><ins>
D.9
</ins></p>

<p><ins>
<b>Change:</b> Remove redundant members from <tt>std::allocator</tt>.
</ins></p>

<p><ins>
<b>Rationale:</b> <tt>std::allocator</tt> was overspecified, encouraging direct
usage in user containers rather than relying on <tt>std::allocator_traits</tt>,
leading to poor containers.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 program that directly makes use
of the <tt>pointer</tt>, <tt>const_pointer</tt>, <tt>reference</tt>,
<tt>const_reference</tt>, <tt>rebind</tt>, <tt>address</tt>, <tt>construct</tt>,
<tt>destroy</tt>, or <tt>max_size</tt> members of <tt>std::allocator</tt>, or that
directly calls <tt>allocate</tt> with an additional hint argument, might no longer
compile.
</ins></p>


<p><ins>
D.10
</ins></p>

<p><ins>
<b>Change:</b> Remove <tt>raw_memory_iterator</tt>.
</ins></p>

<p><ins>
<b>Rationale:</b> The iterator encouraged use of algorithms that
might throw exceptions, but did not return the number of elements
successfully constructed that might need to be destroyed in order
to avoid leaks.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 program that uses
this iterator class might no longer compile.
</ins></p>



<p><ins>
D.11
</ins></p>

<p><ins>
<b>Change:</b> Remove temporary buffers API.
</ins></p>

<p><ins>
<b>Rationale:</b> The temporary buffer facility was intended to
provide an efficient optimization for small memory requests, but
there is little evidence this was achieved in practice, while
requiring the user to provide their own exception-safe wrappers
to guard use of the facility in many cases.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 program that
calls <tt>get_temporary_buffer</tt> or <tt>return_temporary_buffer</tt>
might no longer compile.
</ins></p>



<p><ins>
D.12
</ins></p>

<p><ins>
<b>Change:</b> Remove deprecated type traits.
</ins></p>

<p><ins>
<b>Rationale:</b> The traits had unreliable or awkward interfaces.
The <tt>is_literal_type</tt> trait provided no way to detect which
subset of constructors and member functions of a type were declared
<tt>constexpr</tt>.  The <tt>result_of</tt> trait had a surprising
syntax that could not report the result of a regular function type.
It has been superseded by the <tt>invoke_result</tt> trait.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 program that relies
on the <tt>is_literal_type</tt> or <tt>result_of</tt> type traits, on
the <tt>is_literal_type_v</tt> variable template, or on the
<tt>result_of_t</tt> alias template might no longer compile.
</ins></p>


<p><ins>
D.14
</ins></p>

<p><ins>
<b>Change:</b> Remove <tt>shared_ptr::unique</tt>.
</ins></p>

<p><ins>
<b>Rationale:</b> The result of a call to this member function is
not reliable in the presence of multiple threads and weak pointers.
The member function <tt>use_count</tt> is similarly unreliable, but
has a clearer contract in such cases, and remains available for well
defined use in single-threaded cases.
</ins></p>

<p><ins>
<b>Effect on original feature:</b> A valid C++ 2017 program that calls
<tt>unique</tt> on a <tt>shared_ptr</tt> object might no longer compile.
</ins></p>



<h4>C.6.1 Modifications to headers [diff.mods.to.headers]</h4>
<ol>
<li>
For compatibility with the C standard library, the C++ standard library provides the
C headers enumerated in D.5, but their use is deprecated in C++.
</li>
<li>
There are no C++ headers for the C headers <tt>&lt;stdatomic.h&gt;</tt>,
<tt>&lt;stdnoreturn.h&gt;</tt>, and <tt>&lt;threads.h&gt;</tt>, nor are the C headers
themselves part of C++.
</li>
<li>
The <del>headers <tt>&lt;ccomplex&gt;</tt> (D.4.1) and <tt>&lt;ctgmath&gt;</tt>
(D.4.4), as well as their corresponding</del> C headers <tt>&lt;complex.h&gt;</tt>
and <tt>&lt;tgmath.h&gt;</tt><del>,</del> do not contain any of the content from the C
standard library and instead merely include other headers from the C++ standard library.
</li>
<li><del>
The headers <tt>&lt;ciso646&gt;</tt>, <tt>&lt;cstdalign&gt;</tt> (D.4.2), and
<tt>&lt;cstdbool&gt;</tt> (D.4.3) are meaningless in C++. Use of the C++ headers
<tt>&lt;ccomplex&gt;</tt>,  <tt>&lt;cstdalign&gt;</tt>, <tt>&lt;cstdbool&gt;</tt>, and
<tt>&lt;ctgmath&gt;</tt> is deprecated (D.5).
</del></li>
</ol>

<h4>C.6.2.4 Header <tt>&lt;iso646.h&gt;</tt> [diff.header.iso646.h]</h4>
<ol>
<li>
The tokens <tt>and</tt>, <tt>and_eq</tt>, <tt>bitand</tt>, <tt>bitor</tt>, <tt>compl</tt>,
<tt>not_eq</tt>, <tt>not</tt>, <tt>or</tt>, <tt>or_eq</tt>, <tt>xor</tt>, and <tt>xor_eq</tt>
are keywords in this International Standard (5.11).
<del>They do not appear as macro names defined in <tt>&lt;ciso646&gt;</tt>.</del>
</li>
</ol>

<h4>C.6.2.5 Header <tt>&lt;stdalign.h&gt;</tt> [diff.header.stdalign.h]</h4>
<ol>
<li>
The token <tt>alignas</tt> is a keyword in this International Standard (5.11).
<del>It does not appear as a macro name defined in <tt>&lt;cstdalign&gt;</tt> (D.4.2).</del>
</li>
</ol>

<h4>C.6.2.6 Header <tt>&lt;stdbool.h&gt;</tt> [diff.header.stdbool.h]</h4>
<ol>
<li>
The tokens <tt>bool</tt>, <tt>true</tt>, and <tt>false</tt> are keywords in this International Standard (5.11).
<del>They do not appear as macro names defined in <tt>&lt;cstdbool&gt;</tt> (D.4.3).</del>
</li>
</ol>


<h4><del>D.3 Deprecated exception specifications [depr.except.spec]</del></h4>
<ol>
<li><del>The <i>noexcept-specifier</i> <tt>throw()</tt> is deprecated.</del></li>
</ol>


<h4><del>D.4 C++ standard library headers [depr.cpp.headers]</del></h4>
<ol>
<li><del>
For compatibility with prior C++ International Standards, the C++ standard
library provides headers &lt;ccomplex&gt; (D.4.1), &lt;cstdalign&gt; (D.4.2), &lt;cstdbool&gt;
(D.4.3), and &lt;ctgmath&gt; (D.4.4). The use of these headers is deprecated.
</del></li>
</ol>

<h4><del>D.4.1 Header &lt;ccomplex&gt; synopsis [depr.ccomplex.syn]</del></h4>
<blockquote><pre>
<del>#include &lt;complex&gt;</del>
</pre></blockquote>
<ol>
<li><del>
The header &lt;ccomplex&gt; behaves as if it simply includes the header &lt;complex&gt; (29.5.1).
</del></li>
</ol>

<h4><del>D.4.2 Header &lt;cstdalign&gt; synopsis [depr.cstdalign.syn]</del></h4>
<blockquote><pre>
<del>#define __alignas_is_defined 1</del>
</pre></blockquote>
<ol>
<li><del>
The contents of the header &lt;cstdalign&gt; are the same as the C standard library
header &lt;stdalign.h&gt;, with the following changes: The header <cstdalign> and the
header &lt;stdalign.h&gt; shall not define a macro named alignas.
<br/>
See also: ISO C 7.15.
</del></li>
</ol>

<h4><del>D.4.3 Header &lt;cstdbool&gt; synopsis [depr.cstdbool.syn]</del></h4>
<blockquote><pre>
<del>#define __bool_true_false_are_defined 1</del>
</pre></blockquote>
<ol>
<li><del>
1 The contents of the header &lt;cstdbool&gt; are the same as the C standard
library header &lt;stdbool.h&gt;, with the following changes: The header
&lt;cstdbool&gt; and the header &lt;stdbool.h&gt; shall not define macros named bool,
true, or false.  <br/>
See also: ISO C 7.18.
</del></li>
</ol>

<h4><del>D.4.4 Header &lt;ctgmath&gt; synopsis [depr.ctgmath.syn]</del></h4>
<blockquote><pre>
<del>#include &lt;complex&gt;</del>
<del>#include &lt;cmath&gt;</del>
</pre></blockquote>
<ol>
<li><del>
The header &lt;ctgmath&gt; simply includes the headers &lt;complex&gt; (29.5.1) and &lt;cmath&gt; (29.9.1).
</del></li>
<li><del>
[ <i>Note:</i> The overloads provided in C by type-generic macros are already
provided in &lt;complex&gt; and &lt;cmath&gt; by &quot;sufficient&quot; additional overloads. &mdash; end note ]
</del></li>
</ol>

<h4>D.5 C standard library headers [depr.c.headers]</h4>
<ol start="2">
<li>
The header <tt>&lt;complex.h&gt;</tt> behaves as if it simply includes the
header <tt>&lt;<del>c</del>complex&gt;</tt> <ins>(29.5.1)</ins>. The header
<tt>&lt;tgmath.h&gt;</tt> behaves as if it simply includes the
header<ins>s</ins>
<del><tt>&lt;ctgmath&gt;</tt></del><ins><tt>&lt;complex&gt;</tt> (29.5.1) and
<tt>&lt;cmath&gt;</tt> (29.9.1)</ins>.
</li>
</ol>

<h4><del>D.8 uncaught_exception [depr.uncaught]</del></h4>
<ol>
<li><del>
The header <tt>&lt;exception&gt;</tt> has the following addition:
</del></li>
<pre><blockquote>
<del>namespace std {</del>
  <del>bool uncaught_exception() noexcept;</del>
<del>}</del>
</blockquote></pre>
<pre><del>bool uncaught_exception() noexcept;</del></pre>
<li><del>
<i>Returns:</i> <tt>uncaught_exceptions() &gt; 0</tt>.
</del></li>
</ol>


<h4><del>D.9 Old Adaptable Function Bindings  [depr.func.adaptor.binding]</del></h3>
<h4><del>D.9.1 Weak Result Types [depr.weak.result_type]</del></h4>
<ol>
  <li><del>A call wrapper (23.14.2) may have a <i>weak result type</i>.  If it does, the type
      of its member type <tt>result_type</tt> is based on the type <tt>T</tt> of the wrapper's
      target object:
  </del></li>
  <ol>
    <li><del>if <tt>T</tt> is a pointer to function type, <tt>result_type</tt> shall be a
        synonym for the return type of <tt>T</tt>;</del></li>
    <li><del>if <tt>T</tt> is a pointer to member function, <tt>result_type</tt> shall be a
        synonym for the return type of <tt>T</tt>;</del></li>
    <li><del>if <tt>T</tt> is a class type and the qualified-id <tt>T::result_type</tt> is
        valid and denotes a type (17.9.2), then <tt>result_type</tt> shall be a synonym for
        <tt>T::result_type</tt>;</del></li>
    <li><del>otherwise <tt>result_type</tt> shall not be defined.</del></li>
  </ol>
</ol>


<h4><del>D.9.2 Typedefs to Support Function Binders [depr.func.adaptor.typedefs]</del></h4>
<ol>
<li><del>
To enable old function adaptors to manipulate function objects that take one or
two arguments, many of the function objects in this International Standard correspondingly
provide <i>typedef-name</i>s <tt>argument_type</tt> and <tt>result_type</tt> for function
objects that take one argument and <tt>first_argument_type</tt>,
<tt>second_argument_type</tt>, and <tt>result_type</tt> for function objects
that take two arguments.
</del></li>

<li><del>
The following member names are defined in addition to names specified in Clause 23.14:
</del>

<blockquote><pre>
<del>namespace std {</del>
  <del>template&lt;class T&gt; struct owner_less&lt;shared_ptr&lt;T&gt; &gt; {</del>
    <del>using result_type          = bool;</del>
    <del>using first_argument_type  = shared_ptr&lt;T&gt;;</del>
    <del>using second_argument_type = shared_ptr&lt;T&gt;;</del>
  <del>};</del>

  <del>template&lt;class T&gt; struct owner_less&lt;weak_ptr&lt;T&gt; &gt; {</del>
    <del>using result_type          = bool;</del>
    <del>using first_argument_type  = weak_ptr&lt;T&gt;;</del>
    <del>using second_argument_type = weak_ptr&lt;T&gt;;</del>
  <del>};</del>

  <del>template &lt;class T&gt; class reference_wrapper {</del>
  <del>public :</del>
    <del>using result_type          = <i>see below</i>; <i>// not always defined</i></del>
    <del>using argument_type        = <i>see below</i>; <i>// not always defined</i></del>
    <del>using first_argument_type  = <i>see below</i>; <i>// not always defined</i></del>
    <del>using second_argument_type = <i>see below</i>; <i>// not always defined</i></del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct plus {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct minus {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct multiplies {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct divides {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct modulus {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct negate {</del>
    <del>using argument_type = T;</del>
    <del>using result_type   = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct equal_to {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct not_equal_to {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct greater {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct less {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct greater_equal {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct less_equal {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct logical_and {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct logical_or {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct logical_not {</del>
    <del>using argument_type = T;</del>
    <del>using result_type   = bool;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct bit_and {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct bit_or {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct bit_xor {</del>
    <del>using first_argument_type  = T;</del>
    <del>using second_argument_type = T;</del>
    <del>using result_type          = T;</del>
  <del>};</del>

  <del>template &lt;class T = void&gt; struct bit_not {</del>
    <del>using argument_type = T;</del>
    <del>using result_type   = T;</del>
  <del>};</del>

  <del>template&lt;class R, class T1&gt;</del>
  <del>class function&lt;R(T1)&gt; {</del>
  <del>public:</del>
    <del>using argument_type = T1;</del>
  <del>};</del>

  <del>template&lt;class R, class T1, class T2&gt;</del>
  <del>class function&lt;R(T1, T2)&gt; {</del>
  <del>public:</del>
    <del>using first_argument_type  = T1;</del>
    <del>using second_argument_type = T2;</del>
  <del>};</del>
<del>}</del>
</blockquote></pre>
</li>

<li><del><tt>reference_wrapper&lt;T&gt;</tt> has a weak result type (D.9.1). If
<tt>T</tt> is a function type, <tt>result_type</tt> shall be a synonym for the
return type of <tt>T</tt>.
</del></li>
<li><del>
The template specialization <tt>reference_wrapper&lt;T&gt;</tt> shall define
a nested type named <tt>argument_type</tt> as a synonym for <tt>T1</tt> only if
the type <tt>T</tt> is any of the following:
</del>
<ol>
<li><del>
&mdash; a function type or a pointer to function type taking one argument of
type <tt>T1</tt>
</del></li>
<li><del>
&mdash; a pointer to member function <tt>R T0::f <i>cv</i></tt> (where
<tt><i>cv</i></tt> represents the member function's <i>cv</i>-qualifiers); the
type <tt>T1</tt> is <tt><i>cv</i> T0*</tt>
</del></li>
<li><del>
&mdash; a class type where the <i>qualified-id</i> <tt>T::argument_type</tt> is valid
and denotes a type (17.9.2); the type <tt>T1</tt> is <tt>T::argument_type</tt>.
</del></li>
</ol></li>
<li><del>
The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall define
two nested types named <tt>first_argument_type</tt> and
<tt>second_argument_type</tt> as synonyms for <tt>T1</tt> and <tt>T2</tt>,
respectively, only if the type <tt>T</tt> is any of the following:
</del>
<ol>
<li><del>
&mdash; a function type or a pointer to function type taking two arguments of
types <tt>T1</tt> and <tt>T2</tt>
</del></li>
<li><del>
&mdash; a pointer to member function <tt>R T0::f(T2) <i>cv</i></tt> (where
<tt><i>cv</i></tt> represents the member function's <i>cv</i>-qualifiers); the
type <tt>T1</tt> is <tt><i>cv</i> T0*</tt>
</del></li>
<li><del>
&mdash; a class type where the <i>qualified-id</i>s <tt>T::first_argument_type</tt>
and <tt>T::second_argument_type</tt> are both valid and both denote types
(17.9.2); the type <tt>T1</tt> is <tt>T::first_argument_type</tt> and the type
<tt>T2</tt> is <tt>T::second_argument_type</tt>.
</li>
</ol></li>
<li><del>
All enabled specializations <tt>hash&lt;Key&gt;</tt> of <tt>hash</tt> (23.14.15) provide
two nested types, <tt>result_type</tt> and <tt>argument_type</tt>, which shall be
synonyms for <tt>size_t</tt> and <tt>Key</tt>, respectively.
</del></li>
<li><del>
The forwarding call wrapper <tt>g</tt> returned by a call to
<tt>bind(f, bound_args...)</tt> (23.14.11.3) shall have a weak result type (D.9.1).
</del></li>
<li><del>
The forwarding call wrapper <tt>g</tt> returned by a call to
<tt>bind&lt;R&gt;(f, bound_args...)</tt> (23.14.11.3) shall have a nested type
<tt>result_type</tt> defined as a synonym for <tt>R</tt>.
</del></li>
<li><del>
The simple call wrapper returned from a call to
<tt>mem_fn(pm)</tt> shall have a nested type <tt>result_type</tt> that is a
synonym for the return type of <tt>pm</tt> when <tt>pm</tt> is a pointer to
member function.
</del></li>
<li><del>
The simple call wrapper returned from a call to
<tt>mem_fn(pm)</tt> shall define two nested types named
<tt>argument_type</tt> and <tt>result_type</tt> as synonyms for
<tt><i>cv</i> T*</tt> and <tt>Ret</tt>, respectively, when <tt>pm</tt> is a
pointer to member function with <i>cv</i>-qualifier <i>cv</i> and taking no
arguments, where <tt>Ret</tt> is <tt>pm</tt>'s return type.
</del></li>
<li><del>
The simple call wrapper returned from a call to
<tt>mem_fn(pm)</tt> shall define three nested types named
<tt>first_argument_type</tt>, <tt>second_argument_type</tt>, and
<tt>result_type</tt> as synonyms for <tt>cv T*</tt>, <tt>T1</tt>, and
<tt>Ret</tt>, respectively, when <tt>pm</tt> is a pointer to member function
with <i>cv</i>-qualifier <i>cv</i> and taking one argument of type <tt>T1</tt>,
where <tt>Ret</tt> is <tt>pm</tt>'s return type.
</del></li>
<li><del>
The following member names are defined in addition to names specified in Clause 26:
</del>
<blockquote><pre>
<del>namespace std {</del>
  <del>template &lt;class Key, class T, class Compare = less&lt;Key&gt;,</del>
            <del>class Allocator = allocator&lt;pair&lt;const Key, T&gt;&gt;&gt;</del>
  <del>class map {</del>
  <del>public:</del>
     <del>class value_compare {</del>
     <del>public:</del>
       <del>using result_type          = bool;</del>
       <del>using first_argument_type  = value_type;</del>
       <del>using second_argument_type = value_type;</del>
       <del>}</del>
    <del>};</del>
  <del>};</del>

  <del>template &lt;class Key, class T, class Compare = less&lt;Key&gt;,</del>
            <del>class Allocator = allocator&lt;pair&lt;const Key, T&gt;&gt;&gt;</del>
  <del>class multimap {</del>
  <del>public:</del>
     <del>class value_compare {</del>
     <del>public:</del>
       <del>using result_type          = bool;</del>
       <del>using first_argument_type  = value_type;</del>
       <del>using second_argument_type = value_type;</del>
    <del>};</del>
  <del>};</del>
<del>}</del>
</pre></blockquote>
</li>
</ol>

<h4><del>D.9.3 Negators [depr.negators]</del></h4>
<ol>
<li><del>
The header <tt>&lt;functional&gt;</tt> has the following additions:</del>
<blockquote><pre>
<del>namespace std {</del>
  <del>template &lt;class Predicate&gt; class unary_negate;</del>
  <del>template &lt;class Predicate&gt;</del>
    <del>constexpr unary_negate&lt;Predicate&gt; not1(const Predicate&amp;);</del>
  <del>template &lt;class Predicate&gt; class binary_negate;</del>
  <del>template &lt;class Predicate&gt;</del>
    <del>constexpr binary_negate&lt;Predicate&gt; not2(const Predicate&amp;);</del>
<del>}</del>
</pre></blockquote>
</li>
<li><del>
Negators <tt>not1</tt> and <tt>not2</tt> take a unary and a binary predicate,
respectively, and return their logical negations (8.5.2.1).
</del></li>

<p><pre><blockquote>
   <del>template &lt;class Predicate&gt;</del>
     <del>class unary_negate {</del>
   <del>public:</del>
     <del>constexpr explicit unary_negate(const Predicate&amp; pred);</del>
     <del>constexpr bool operator()(const typename Predicate::argument_type&amp; x) const;</del>
     <del>using argument_type = typename Predicate::argument_type;</del>
     <del>using result_type   = bool;</del>
   <del>};</del>
</blockquote></pre></p>

<li><del>
<tt>operator()</tt> returns <tt>!pred(x)</tt>.
</del></li>

<p><pre><blockquote>
 <del>template &lt;class Predicate&gt;</del>
     <del>constexpr unary_negate&lt;Predicate&gt; not1(const Predicate&amp; pred);</del>
</blockquote></pre></p>

<li><del>
<i>Returns:</i> <tt>unary_negate&lt;Predicate&gt;(pred)</tt>.
</del></li>

<p><pre><blockquote>
  <del>template &lt;class Predicate&gt;</del>
  <del>class binary_negate {</del>
  <del>public:</del>
    <del>constexpr explicit binary_negate(const Predicate&amp; pred);</del>
    <del>constexpr bool operator()(const typename Predicate::first_argument_type&amp; x,</del>
                              <del>const typename Predicate::second_argument_type&amp; y) const;</del>
    <del>using first_argument_type = typename Predicate::first_argument_type;</del>
    <del>using second_argument_type = typename Predicate::second_argument_type;</del>
    <del>using result_type = bool;</del>
  <del>};</del>
</blockquote></pre></p>

<li><del>
<tt>operator()</tt> returns <tt>!pred(x,y)</tt>.
</del></li>

<p><pre><blockquote>
<del>template &lt;class Predicate&gt;</del>
  <del>constexpr binary_negate&lt;Predicate&gt; not2(const Predicate&amp; pred);</del>
</blockquote></pre></p>

<li><del>
<i>Returns:</i> <tt>binary_negate&lt;Predicate&gt;(pred)</tt>.
</del></li>
</ol>

</ol>


<h4><del>D.10 The default allocator [depr.default.allocator]</del></h4>
<ol>
<li><del>The following members are defined in addition to those specified in 23.10.10:</del></li>
<pre>
<del>namespace std {</del>
  <del>template &lt;&gt; class allocator&lt;void&gt; {</del>
  <del>public:</del>
    <del>using value_type    = void;</del>
    <del>using pointer       = void*;</del>
    <del>using const_pointer = const void*;</del>
    <del><i>// reference-to-void members are impossible.</i></del>
    <del>template &lt;class U&gt; struct rebind { using other = allocator&lt;U&gt;; };</del>
  <del>};</del>

  <del>template &lt;class T&gt; class allocator {</del>
  <del>public:</del>
    <del>using size_type       = size_t;</del>
    <del>using difference_type = ptrdiff_t;</del>
    <del>using pointer         = T*;</del>
    <del>using const_pointer   = const T*;</del>
    <del>using reference       = T&amp;;</del>
    <del>using const_reference = const T&amp;;</del>
    <del>template &lt;class U&gt; struct rebind { using other = allocator&lt;U&gt;; };</del>

    <del>T* address(reference x) const noexcept;</del>
    <del>const T* address(const_reference x) const noexcept;</del>

    <del>T* allocate(size_t, const void* hint);</del>

    <del>template&lt;class U, class... Args&gt;</del>
      <del>void construct(U* p, Args&amp;&amp;... args);</del>
    <del>template &lt;class U&gt;</del>
      <del>void destroy(U* p);</del>

    <del>size_t max_size() const noexcept;</del>
  <del>};</del>
<del>}</del>
</pre>

<pre><del>T* address(reference x) const noexcept;</del>
<del>const T* address(const_reference x) const noexcept;</del></pre>
<li><del>
<i>Returns:</i> The actual address of the object referenced by <tt>x</tt>, even
in the presence of an overloaded <tt>operator&amp;</tt>.
</del></li>

<pre><del>T* allocate(size_t, const void* hint);</del></pre>
<li><del>
<i>Returns:</i> A pointer to the initial element of an array of storage of size
<tt>n * sizeof(T)</tt>, aligned appropriately for objects of type <tt>T</tt>.
It is implementation-defined whether over-aligned types are supported (6.6.5).
</del></li>
<li><del>
<i>Remark:</i> the storage is obtained by calling
<tt>::operator new(std::size_t)</tt> (21.6.2), but it is unspecified when or
how often this function is called.
</del></li>
<li><del>
<i>Throws:</i> <tt>bad_alloc</tt> if the storage cannot be obtained.
</del></li>

<pre>
<del>template &lt;class U, class... Args&gt;</del>
  <del>void construct(U* p, Args&amp;&amp;... args);</del>
</pre>
<li><del>
<i>Effects:</i> <tt>::new((void *)p) U(std::forward&lt;Args&gt;(args)...)</tt>
</del></li>

<pre>
<del>template &lt;class U&gt;</del>
  <del>void destroy(U* p);</del>
</pre>
<li><del>
<i>Effects:</i> <tt>p-&gt;~U()</tt>
</del></li>

<pre><del>size_type max_size() const noexcept;</del></pre>
<li><del>
<i>Returns:</i> The largest value <tt>N</tt> for which the call
<tt>allocate(N)</tt> might succeed.
</del></li>
</ol>


<h4><del>D.11 Raw storage iterator [depr.storage.iterator]</del></h4>
<ol>
<p><del>
The header <tt>&lt;memory&gt;</tt> has the following addition:</del>
</del></p>

<pre>
  <del>namespace std {</del>
    <del>template &lt;class OutputIterator, class T&gt;</del>
    <del>class raw_storage_iterator {</del>
    <del>public:</del>
      <del>using iterator_category = output_iterator_tag;</del>
      <del>using value_type        = void;</del>
      <del>using difference_type   = void;</del>
      <del>using pointer           = void;</del>
      <del>using reference         = void;</del>

      <del>explicit raw_storage_iterator(OutputIterator x);</del>

      <del>raw_storage_iterator&amp; operator*();</del>
      <del>raw_storage_iterator&amp; operator=(const T&amp; element);</del>
      <del>raw_storage_iterator&amp; operator=(T&amp;&amp; element);</del>
      <del>raw_storage_iterator&amp; operator++();</del>
      <del>raw_storage_iterator  operator++(int);</del>
      <del>OutputIterator base() const;</del>
    <del>};</del>
  <del>}</del>
</pre>

<li><del>
<tt>raw_storage_iterator</tt> is provided to enable algorithms to store their
results into uninitialized memory. The template parameter
<tt>OutputIterator</tt> is required to have its <tt>operator*</tt> return an
object for which <tt>operator&amp;</tt> is defined and returns a pointer to
<tt>T</tt>, and is also required to satisfy the requirements of an output
iterator (27.2.4).
</del></li>

<pre>
<del>explicit raw_storage_iterator(OutputIterator x);</del>
</pre>
<li><del>
<i>Effects:</i> Initializes the iterator to point to the same value to which
<tt>x</tt> points.
</del></li>

<pre>
<del>raw_storage_iterator&amp; operator*();</del>
</pre>
<li><del>
<i>Returns:</i> <tt>*this</tt>
</del></li>

<pre>
<del>raw_storage_iterator&amp; operator=(const T&amp; element);</del>
</pre>
<li><del>
<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
</del></li>
<li><del>
<i>Effects:</i> Constructs a value from <tt>element</tt> at the location to
which the iterator points.
</del></li>
<li><del>
<i>Returns:</i> A reference to the iterator.
</del></li>

<pre>
<del>raw_storage_iterator&amp; operator=(T&amp;&amp; element);</del>
</pre>
<li><del>
<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
</del></li>
<li><del>
<i>Effects:</i> Constructs a value from <tt>std::move(element)</tt> at the
location to which the iterator points.
</del></li>
<li><del>
<i>Returns:</i> A reference to the iterator.
</del></li>

<pre>
<del>raw_storage_iterator&amp; operator++();</del>
</pre>
<li><del>
<i>Effects:</i> Pre-increment: advances the iterator and returns a reference to
the updated iterator.
</del></li>

<pre>
<del>raw_storage_iterator operator++(int);</del>
</pre>
<li><del>
<i>Effects:</i> Post-increment: advances the iterator and returns the old value
of the iterator.
</del></li>

<pre>
<del>OutputIterator base() const;</del>
</pre>
<li><del>
<i>Returns:</i> An iterator of type <tt>OutputIterator</tt> that points to the
same value as <tt>*this</tt> points to.
</del></li>
</ol>


<h4><del>D.12 Temporary buffers [depr.temporary.buffer]</del></h4>
<ol>
<li><del>
The header <tt>&lt;memory&gt;</tt> has the following additional functions:</del>
</del></li>
<blockquote><pre>
<del>namespace std {</del>
  <del><i>// 20.9.11, temporary buffers:</i></del>
  <del>template &lt;class T&gt;</del>
    <del>pair&lt;T*, ptrdiff_t&gt; get_temporary_buffer(ptrdiff_t n) noexcept;</del>
  <del>template &lt;class T&gt;</del>
    <del>void return_temporary_buffer(T* p);</del>
<del>}</del>
</pre></blockquote>

<pre>
<del>template &lt;class T&gt;</del>
  <del>pair&lt;T*, ptrdiff_t&gt; get_temporary_buffer(ptrdiff_t n) noexcept;</del>
</pre>
<li><del>
<i>Effects:</i> Obtains a pointer to uninitialized, contiguous storage for
<i>N</i> adjacent objects of type <tt>T</tt>, for some non-negative number
<i>N</i>. It is implementation-defined whether over-aligned types are supported
(3.11).
</del></li>
<li><del>
<i>Remarks:</i> Calling <tt>get_temporary_buffer</tt> with a positive number
<tt>n</tt> is a non-binding request to return storage for <tt>n</tt> objects of
type <tt>T</tt>. In this case, an implementation is permitted to return instead
storage for a non-negative number <i>N</i> of such objects, where
<i>N</i><tt>!= n</tt> (including <i>N</i><tt> == 0</tt>). [ <i>Note:</i> The
request is non-binding to allow latitude for implementation-specific
optimizations of its memory management.  - <i>end note</i> ]
</del></li>
<li><del>
<i>Returns:</i> If <tt>n &lt;= 0</tt> or if no storage could be obtained,
returns a pair <tt>P</tt> such that <tt>P.first</tt> is a null pointer value
and <tt>P.second == 0</tt>; otherwise returns a pair <tt>P</tt> such that
<tt>P.first</tt> refers to the address of the uninitialized storage and
<tt>P.second</tt> refers to its capacity <i>N</i> (in the units of
<tt>sizeof(T)</tt>).
</del></li>
</ol>

<pre>
<del>template &lt;class T&gt; void return_temporary_buffer(T* p);</del>
</pre>
<ol>
<li><del>
<i>Effects:</i> Deallocates the storage referenced by <tt>p</tt>.
</del></li>
<li><del>
<i>Requires:</i> <tt>p</tt> shall be a pointer value returned by an earlier
call to <tt>get_temporary_buffer</tt> that has not been invalidated by an
intervening call to <tt>return_temporary_buffer(T*)</tt>.
</del></li>
<li><del>
<i>Throws:</i> Nothing.
</del></li>
</ol>


<h4>D.13 Deprecated Type Traits [depr.meta.type]</h4>
<ol>
<li>
The header <tt>&lt;type_traits&gt;</tt> has the following addition:
</li>

<blockquote><pre>
namespace std {
  <del>template &lt;class T&gt; struct is_literal_type;</del>
  <del>template &lt;class T&gt; constexpr bool is_literal_type_v = is_literal_type&lt;T&gt;::value;</del>

  <del>template &lt;class&gt; struct result_of; <i>// not defined</i></del>
  <del>template &lt;class Fn, class... ArgTypes&gt; struct result_of&lt;Fn(ArgTypes...)&gt;;</del>
  <del>template &lt;class T&gt; using result_of_t = typename result_of&lt;T&gt;::type;</del>

  template&lt;class T&gt; struct is_pod;
  template&lt;class T&gt; inline constexpr bool is_pod_v = is_pod&lt;T&gt;::value;
}
</pre></blockquote>

<li>
The behavior of a program that adds specializations for any of the templates
defined in this subclause is undefined, unless explicitly permitted by the
specification of the corresponding template.
</li>

<blockquote><pre>
<del>template&lt;class T&gt; struct is_literal_type;</del>
</pre></blockquote>

<li><del>
<i>Requires:</i> <tt>remove_all_extents_t&lt;T&gt;</tt> shall be a complete type or <i>cv</i> <tt>void</tt>.
</del></li>

<li><del>
<tt>is_literal_type&lt;T&gt;</tt> is a <tt>UnaryTypeTrait</tt> (23.15.1) with a base
characteristic of <tt>true_type</tt> if <tt>T</tt> is a literal type (6.7), and
<tt>false_type</tt> otherwise.
</del></li>


<blockquote><pre>
<del>template&lt;class Fn, class... ArgTypes&gt; struct result_of&lt;Fn(ArgTypes...)&gt;;</del>
</pre></blockquote>

<li><del>
<i>Requires:</i> <tt>Fn</tt> and all types in the parameter pack <tt>ArgTypes</tt> shall be complete types, <i>cv</i> <tt>void</tt>, or arrays of unknown bound.
</del></li>

<li><del>
The partial specialization <tt>result_of&lt;Fn(ArgTypes...)&gt;</tt> is a
<tt>TransformationTrait</tt> (23.15.1) whose member typedef <tt>type</tt> is
defined if and only if <tt>invoke_result&lt;Fn, ArgTypes...&gt;::type</tt>
(23.14.4) is defined. If <tt>type</tt> is defined, it names the same type as
i<tt>nvoke_result_t&lt;Fn, ArgTypes...&gt;</tt>.
</del></li>


<blockquote><pre>
template&lt;class T&gt; struct is_pod;
</pre></blockquote>

<li>
<i>Requires:</i> <tt>remove_all_extents_t&lt;T&gt;</tt> shall be a complete type or <i>cv</i> <tt>void</tt>.
</li>

<li>
<tt>is_pod&lt;T&gt;</tt> is a <tt>UnaryTypeTrait</tt> (23.15.1) with a base
characteristic of <tt>true_type</tt> if <tt>T</tt> is a POD type, and
<tt>false_type</tt> otherwise. A POD class is a class that is both a trivial
class and a standard-layout class, and has no non-static data members of type
non-POD class (or array thereof). A POD type is a scalar type, a POD class, an
array of such a type, or a cv-qualified version of one of these types.
</li>

<li>
[ <i>Note:</i> It is unspecified whether a closure type (8.4.5.1) is a POD type.
&mdash; <i>end note</i> ]
</li>

</ol>


<h4><del>D.15 Deprecated shared_ptr observers [depr.util.smartptr.shared.obs]</del></h4>
<ol>
<li><del>
The following member is defined in addition to those members specified in 23.11.3:
</del></li>

<blockquote><pre>
<del>namespace std {</del>
  <del>template<class T> class shared_ptr {</del>
  <del>public:</del>
    <del>bool unique() const noexcept;</del>
  <del>};</del>
<del>}</del>
</pre></blockquote>

<blockquote><pre>
<del>bool unique() const noexcept;</del></del>
</pre></blockquote>

<li><del>
<i>Returns:</i> <tt>use_count() == 1</tt>.
</del></li>
</ol>

</blockquote>


<h2><a name="7.0">7 Acknowledgments</h2>
<p>
Thanks to everyone who worked on flagging these facilities for deprecation,
let's take the next step!
</p>


<h2><a name="8.0">8 References</h2>
<ul>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3201">N3201</a> Moving right along, Bjarne Stroustrup</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3203">N3203</a> Tightening the conditions for generating implicit moves, Jens Maurer</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086">N4086</a> Removing trigraphs??!, Richard Smith</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4190">N4190</a> Removing <tt>auto_ptr</tt>, <tt>random_shuffle()</tt>, And Old <tt>&lt;functional&gt;</tt> Stuff, Stephan T. Lavavej</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4259">N4259</a> Wording for std::uncaught_exceptions, Herb Sutter</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0001r1">P0001R1</a> Remove Deprecated Use of the <tt>register</tt> Keyword, Alisdair Meredith</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r0">P0002R1</a> Remove Deprecated <tt>operator++(bool)</tt>, Alisdair Meredith</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5">P0003R5</a> Remove Deprecated Exception Specifications from C++17, Alisdair Meredith</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0004r0">P0004R1</a> Remove Deprecated iostreams aliases, Alisdair Meredith</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0005r4">P0005R4</a> Adopt 'not_fn' from Library Fundamentals 2 for C++17, Alisdair Meredith, Stephan T. Lavavej, Tomasz Kamiński</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0174r0">P0174R2</a> Deprecating Vestigial Library Parts in C++17, Alisdair Meredith</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0386r2">P0386R2</a> Inline Variables, Hal Finkel and Richard Smith</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0521r0">P0521R0</a> Proposed Resolution for CA 14 (shared_ptr use_count/unique), Stephan T. Lavavej</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0618r0">P0618R0</a> Deprecating <tt>&lt;codecvt&gt;</tt>, Alisdair Meredith</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0657r0.pdf">P0657R0</a> Deprecate Certain Declarations in the Global Namespace, Walter Brown</li>
</ul>

</body>
</html>
