<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
  <head>
    <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
    <title>Changes between C++17 and C++20</title>
    <style type="text/css">
      html { margin: 0; padding: 0; color: black; background-color: white; }
      body { padding: 2em; font-size: medium; font-family: "DejaVu Serif", serif; line-height: 150%; }
      code { font-family: "DejaVu Sans Mono", monospace; color: #006; }

      h1, h2, h3 { margin: 1.5em 0 .75em 0; line-height: 125%; }

      sup, sub { line-height: 0; }

      div.code { white-space: pre-line; font-family: "DejaVu Sans Mono", monospace;
                 border: thin solid #E0E0E0; background-color: #F8F8F8; padding: 1em;
                 border-radius: 4px; }

      div.strictpre { white-space: pre; }

      div.code em { font-family: "DejaVu Serif", serif; }

      table { border-top: 2px solid black; border-bottom: 2px solid black; border-collapse: collapse; margin: 0 auto 3em auto; }
      thead th { border-bottom: 2px solid black; }
      tr.midsep td { border-top: 2px solid black; }
      th, td { text-align: left; vertical-align: top; padding: 1ex 1ex 1ex 1em; }
      th:first-child, td:first-child { padding-left: 1ex; }

      tr.new td { background-color: #EFE; }
      td.new:after { content: "new!"; font-family: "DejaVu Sans", sans-serif; font-weight: bold; font-size: xx-small;
                     vertical-align: top; top: -1em; right: -1em; position: relative; float: right; color: #090; }

      table.features { width: 100%; }
      .features tr a { font-family: "DejaVu Sans", sans-serif; text-decoration: none; }
      .features tbody tr { border-bottom: thin solid black; }
      .features tr td:first-child { width: 3em; }
      .features tr td:first-child + td { width: 20%; }
      .features tbody tr:hover { background-color: #F9F9FF; }

      .docinfo { float: right }
      .docinfo p { margin: 0; text-align:right; }
      .docinfo address { font-style: normal; }

      .quote { display: inline-block; clear: both; margin-left: 1ex;
               border: thin solid #E0E0E0; background-color: #F8F8F8; padding: 1ex; }

      /*  Use DIV[insert] and DIV[delete] if the entire paragraph is added or removed; otherwise
       *  use DIV[modify] and use INS/DEL elements to mark up individual changes.
       */

      div.insert { border-left: thick solid #0A0; border-right: thick solid #0A0; padding: 0 1em; }
      div.modify { border-left: thick solid #999; border-right: thick solid #999; padding: 0 1em; }
      div.delete { border-left: thick solid #A00; border-right: thick solid #A00; padding: 0 1em; }

      del { color: #A00; text-decoration: line-through; }
      ins { color: #090; }
      ins code, del code { color: inherit; }

      .box { border: thin black solid; padding: 2px; }

      ol { counter-reset: item; }
      ol > li { counter-increment: item; }
      ol ol { list-style: none; padding: 0; }
      ol ol > li:before { content: counters(item, ".") " "; }
    </style>
  </head>
  <body>
    <div class="docinfo">
      <p>ISO/IEC JTC1 SC22 WG21 P2131R0</p>
      <p>Date: 2020-03-02</p>
      <p>To: the public</p>
      <address>
        Thomas K&ouml;ppe &lt;<a href="mailto:tkoeppe@google.com">tkoeppe@google.com</a>&gt;<br>
      </address>
    </div>

    <h1>Changes between C++17 and C++20 DIS</h1>

    <h2>Abstract</h2>

    <p>This document enumerates all the major changes that have been applied to
      the C++ working draft since the publication of C++17, up to the publication
      of the C++20 DIS. Major changes are those that were added in the form
      of a dedicated paper, although not all papers are mentioned individually. The
      remaining papers are listed summarily below. Issue resolutions from the CWG or
      LWG issues lists are generally not included, but the containing papers are part
      of the summary listing. Defect reports that are not part of the published
      International Standard are marked with a &ldquo;DR&rdquo; superscript.</p>

    <h2>Contents</h2>
    <!-- fgrep -e "<h2 id=" c++20_changes.html | sed -e 's/.*id="\(.*\)">\(.*\)<\/h2>/<li><a href="#\1">\2<\/a><\/li>/g' -->
    <ol>
      <li><a href="#removed">Removed or deprecated features</a></li>
      <li><a href="#new-core-global">New core language features with global applicability</a></li>
      <li><a href="#new-core-local">New core language features with local applicability</a></li>
      <li><a href="#new-lib">New library features</a></li>
      <li><a href="#mods">Modifications to existing features</a></li>
      <li><a href="#misc">Miscellaneous</a></li>
      <li><a href="#unlisted">Unlisted papers</a></li>
      <li><a href="#dr">Defects, issues, bug fixes</a></li>
      <li><a href="#demo">Assorted snippets demonstrating C++17</a></li>
    </ol>

    <h2 id="removed">Removed or deprecated features</h2>

    <table class="features">
      <thead>
        <tr><th>Document</th><th>Summary</th><th>Examples, notes</th></tr>
      </thead>
      <tbody>
        <tr>
          <td><a href="https://wg21.link/p0619r4">P0619R4</a></td>
          <td>Removal of various deprecated features</td>
          <td>
            The following features that were already deprecated in C++17 are now removed:
            <ul style="margin: 0">
              <li>
                the <em>noexcept-specifier</em> <code>throw()</code> (use <code>noexcept</code> instead)
              </li>
              <li>
                ineffective &ldquo;C++ versions&rdquo; of compatibility headers,
                <code>&lt;ccomplex&gt;</code>, <code>&lt;ciso646&gt;</code>,
                <code>&lt;cstdalig&gt;</code>, <code>&lt;cstdbool&gt;</code>,
                <code>&lt;ctgmath&gt;</code> (there is no need for those in C++ code)</li>
              <li>
                <code>uncaught_exception</code> (use <code>uncaught_exceptions</code> instead)
              </li>
              <li>
                functional adaptors <code>not1</code>, <code>not2</code>, <code>unary_negate</code>,
                <code>binary_negate</code>, as well as the class members <code>result_type</code>,
                <code>argument_type</code>, <code>first_argument_type</code>, <code>second_argument_type</code>
                (the functionality of <code>bind</code> and <code>not_fn</code> is strictly superior).
              </li>
              <li>
                redundant members of <code>allocator</code> (which are subsumed by the <code>allocator_traits</code>
                defaults): <code>pointer</code>, <code>const_pointer</code>, <code>reference</code>, <code>const_reference</code>,
                <code>rebind</code>, <code>address</code>, <code>construct</code>, <code>destroy</code>.
              </li>
              <li><code>raw_memory_iterator</code></li>
              <li>temporary buffer API (<code>get_temporary_buffer</code>, <code>return_temporary_buffer</code>)</li>
              <li>traits <code>is_literal_type</code> and <code>result_of</code></li>
              <li>the member <code>shared_ptr::unique</code></li>
            </ul>
            Moreover, formerly implied special member functions are now declared explicitly
            throughout the standard library whenever their implicit declaration is deprecated [depr.impldec].
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1236r1">P1236R1</a></td>
          <td>Only two&rsquo;s complement representation for signed integers</td>
          <td>
            As of C++20, the only permitted representation for signed integers is
            two&rsquo;s complement. Previously, no representation was specified,
            but due to size and layout constraints, the only possible ones were
            two&rsquo;s complement, ones&rsquo; complement, and sign-magnitude.
            Support for the latter two has now been removed.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0767r1">P0767R1</a></td>
          <td>Deprecate the notion of a &ldquo;POD&rdquo; type</td>
          <td>The notion of a &ldquo;plain-old data&rdquo; (POD) type has been superseded
            by the more granular notions of <em>trivial</em> and <em>standard-layout</em>,
            and this change removes this notion from the main language specification
            (though it is retained as deprecated in Annex D).</td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0806r2">P0806R2</a></td>
          <td>Deprecate the implicit lambda capture of <code>this</code> via <code>[=]</code></td>
          <td>The capture of <code>this</code> via <code>[=]</code> is now deprecated,
            since it is irregular and potentially confusing with <code>[=, *this]</code>.
            The capture should now be spelled <code>[=, this]</code>. See also P0409R2 below.</td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1161r3">P1161R3</a></td>
          <td>Deprecate the comma operator in subscripting expressions</td>
          <td>The syntax <code>a[x, y, z]</code> is now deprecated; if this functionality
            is desired, it should be spelled <code>a[(x, y, z)]</code>. Eventual
            removal of the deprecated expression would open the door to extensions to
            the subscripting expression.</td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p1152r4">P1152R4</a>,
            <a href="https://wg21.link/p1831r1">P1831R1</a>
          </td>
          <td>Deprecate certain <code>volatile</code> qualifications</td>
          <td>The <code>volatile</code> qualifications in certain contexts where they
            would be of questionable value or outright broken are now deprecated. (This
            includes certain operands of increment/decrement and assignment expressions,
            function parameters, function return types, and the types of structured
            bindings.)</td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0966r1">P0966R1</a></td>
          <td>Deprecate shrinking <code>basic_string::reserve</code></td>
          <td>
            The default argument of the parameter of
            <code>basic_string::reserve</code> is removed and the function no longer shrinks
            capacity. The behaviour was inconsistent with <code>vector::reserve</code> and
            redundant with <code>basic_string::shrink_to_fit</code>. A deprecated
            zero-parameter overload has been added to Annex&nbsp;D.
          </td>
        </tr>

      </tbody>
    </table>

    <h2 id="new-core-global">New core language features with global applicability</h2>

    <p>These are features that may happen to you without your knowledge or consent.</p>

    <table class="features">
      <thead>
        <tr><th>Document</th><th>Summary</th><th>Examples, notes</th></tr>
      </thead>
      <tbody>
        <tr>
          <td>
            Core: <a href="https://wg21.link/p0734r0">P0734R0</a>,
            <a href="https://wg21.link/p0857r0">P0857R0</a>,
            <a href="https://wg21.link/p1084r2">P1084R2</a>,
            <a href="https://wg21.link/p1141r2">P1141R2</a>,
            <a href="https://wg21.link/p1452r2">P1452R2</a>,
            <a href="https://wg21.link/p1616r1">P1616R1</a>,
            <a href="https://wg21.link/p1972r0">P1972R0</a>,
            <a href="https://wg21.link/p1980r0">P1980R0</a>,
            <a href="https://wg21.link/p2092r0">P2092R0</a>,
            <a href="https://wg21.link/p2104r0">P2104R0</a>,
            <a href="https://wg21.link/p2113r0">P2113R0</a>;
            Library: <a href="https://wg21.link/p0898r3">P0898R3</a>,
            <a href="https://wg21.link/p1248r1">P1248R1</a>,
            <a href="https://wg21.link/p1474r1">P1474R1</a>,
            <a href="https://wg21.link/p1754r1">P1754R1</a>,
            <a href="https://wg21.link/p1878r1">P1878R1</a>,
            <a href="https://wg21.link/p1964r2">P1964R2</a>,
            <a href="https://wg21.link/p2102r0">P2102R0</a>.
          </td>
          <td>Concepts</td>
          <td>
            Concepts extend C++&rsquo;s template facility with a way to constrain a template&rsquo;s
            parameters. The constraints take part in overload resolution.</td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0912r5">P0912R5</a>,
            <a href="https://wg21.link/p2107r0">P2107R0</a>
          </td>
          <td>Coroutines</td>
          <td>Coroutines are a new kind of control flow that extends the notion of a function.</td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p1103r3">P1103R3</a>,
            <a href="https://wg21.link/p1502r1">P1502R1</a>,
            <a href="https://wg21.link/p1766r1">P1766R1</a>,
            <a href="https://wg21.link/p1811r0">P1811R0</a>,
            <a href="https://wg21.link/p1815r2">P1815R2</a>,
            <a href="https://wg21.link/p1703r1">P1703R1</a>,
            <a href="https://wg21.link/p1779r3">P1779R3</a>,
            <a href="https://wg21.link/p1857r3">P1857R3</a>,
            <a href="https://wg21.link/p1874r1">P1874R1</a>,
            <a href="https://wg21.link/p1979r0">P1979R0</a>,
            <a href="https://wg21.link/p2109r0">P2109R0</a>,
            <a href="https://wg21.link/p2115r0">P2115R0</a>
          </td>
          <td>Modules</td>
          <td>
            Modules offer a new way to organize source code that is not based on textual
            inclusion in the way header inclusions were, but instead allows for a principled
            specification of component boundaries.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0515r3">P0515R3</a>,
            <a href="https://wg21.link/p0905r1">P0905R1</a>,
            <a href="https://wg21.link/p1120r0">P1120R0</a>,
            <a href="https://wg21.link/p1185r2">P1185R2</a>,
            <a href="https://wg21.link/p1186r3">P1186R3</a>,
            <a href="https://wg21.link/p1630r1">P1630R1</a>,
            <a href="https://wg21.link/p1614r2">P1614R2</a>,
            <a href="https://wg21.link/p1855r0">P1855R0</a>,
            <a href="https://wg21.link/p1946r0">P1946R0</a>,
            <a href="https://wg21.link/p1959r0">P1959R0</a>,
            <a href="https://wg21.link/p2002r1">P2002R1</a>,
            <a href="https://wg21.link/p2085r0">P2085R0</a>
          </td>
          <td>Three-way comparison (&ldquo;spaceship&rdquo;) and defaulted comparisons</td>
          <td>
            The value of the expression <code>a&nbsp;&lt;=&gt;&nbsp;b</code> describes which one of
            <code>a&nbsp;&lt;&nbsp;b</code>, <code>a&nbsp;==&nbsp;b</code>, and <code>a&nbsp;&gt;&nbsp;b</code>
            is true.<br><br>
            A key part of this feature is that classes that provide this operator can have all of the
            six traditional, binary relational operators defined implicitly.
          </td>
        </tr>
      </tbody>
    </table>

    <h2 id="new-core-local">New core language features with local applicability</h2>

    <p>These are features where you would know if you were using them.</p>

    <table class="features">
      <thead>
        <tr><th>Document</th><th>Summary</th><th>Examples, notes</th></tr>
      </thead>
      <tbody>
        <tr>
          <td><a href="https://wg21.link/p0329r4">P0329R4</a></td>
          <td>Designated initializers</td>
          <td><code>struct X { int a; int b; }; X x { <strong>.b = 10</strong> };</code></td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0732r2">P0732R2</a>,
            <a href="https://wg21.link/p1907r1">P1907R1</a>
          </td>
          <td>Class-types in non-type template parameters</td>
          <td>
            Non-type template parameters can now be of class type:
            <code>struct X { /* ... */}; template &lt;X Value&gt; struct Y;</code>
            Certain restrictions apply to ensure that value identity can be established reliably.
            These new kinds of non-type parameters are lvalues, unlike the existing non-class ones.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0840r2">P0840R2</a></td>
          <td><code>[[no_unique_address]]</code></td>
          <td>
            An attribute that provides language support for empty or overlapping
            member objects. Previously, this effect was often achieved by using
            overlapping base class layouts (&ldquo;empty base
            optimisation&rdquo;).
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0479r5">P0479R5</a></td>
          <td><code>[[likely]]</code>, <code>[[unlikely]]</code></td>
          <td>
            Attributes to guide branch prediction. Already wide-spread as
            vendor extensions.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1007r3">P1007R3</a></td>
          <td><code>assume_aligned</code></td>
          <td>
            A special language-support function that promises to the
            implementation that a pointer is aligned in a certain way (with
            undefined behaviour if this is not in fact true at runtime), which
            allows better code generation (e.g. vectorised instructions;
            omission of preambles). Already wide-spread as vendor extensions.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1143r2">P1143R2</a></td>
          <td><code>constinit</code></td>
          <td>
            The new <code>constinit</code> keyword specifies a variable to be
            constant-initialized (and the program would be ill-formed if this is
            not possible). The variable can still be mutable, and indeed this is
            the key difference from a <code>constexpr</code> variable. Having
            constant initialization suffices to avoid any form of static
            initialization problems, and also allows local static variables to
            omit a synchronization guard on access (since there is no dynamic
            initialization that any thread would need to wait for).
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p1073r3">P1073R3</a>,
            <a href="https://wg21.link/p1937r2">P1937R2</a>
          </td>
          <td><code>consteval</code></td>
          <td>
            The new <code>consteval</code> keyword specifies a function as an
            &ldquo;immediate function&rdquo;, whose invocation is always a
            constant expression (and which thus never requires code to be
            emitted from the translation). Contrast this with <code>constexpr</code>
            functions, which <em>may</em>, but are not required to be, used as
            constant expressions.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0595r2">P0595R2</a></td>
          <td><code>is_constant_evaluated</code></td>
          <td>
            A special language-support function that tells whether the caller is
            in a constant evaluation. This allows library implementations to
            provide a constexpr-implementation as well as an optimised runtime
            implementation of the same function (whereas the constexpr
            implementation alone would not have optimal runtime performance, if
            it turned out to be needed at runtime).</td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0722r3">P0722R3</a></td>
          <td>A destroying <code>operator delete</code></td>
          <td>
            A new way to provide a deallocation function (<code>operator delete</code>,
            taking a parameter of type <code>std::destroying_delete_t</code>) with the
            effect that a <em>delete-expression</em> that would choose such a function
            does <em>not</em> call the destructor; instead, the deallocation function
            itself is required to call the destructor. See the paper for examples why
            this might be desirable.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0784r7">P0784R7</a></td>
          <td>Constexpr <code>new</code>/<code>delete</code></td>
          <td>
            Dynamic object creation and destruction may now appear in <code>constexpr</code>
            contexts, as long as every created object is destroyed. This allows, say,
            the use of a local <code>std::string</code> variable in the body of a constexpr
            function.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0476r2">P0476R2</a></td>
          <td><code>bit_cast</code></td>
          <td>
            Despite its library-looking name, this is a core language facility
            that creates objects whose object representation is copied from an
            existing object. Importantly, the target type need not be
            default-constructible. Attempts to achieve this by other means, while
            very common, often run into undefined behaviour. Example:
            <code>std::uint32_t n = std::bit_cast&lt;std::uint32_t&gt;(1.5f);</code>
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1099r5">P1099R5</a></td>
          <td><code>using enum</code></td>
          <td>
            A way to introduce the enumerator names of a scoped enumeration.
          </td>
        </tr>

      </tbody>
    </table>

    <h2 id="new-lib">New library features</h2>

    <table class="features">
      <thead>
        <tr><th>Document</th><th>Summary</th><th>Examples, notes</th></tr>
      </thead>
      <tbody>
        <tr>
          <td>
            <a href="https://wg21.link/p0896r4">P0896R4</a>,
            <a href="https://wg21.link/p1252r2">P1252R2</a>,
            <a href="https://wg21.link/p1035r7">P1035R7</a>,
            <a href="https://wg21.link/p1243r4">P1243R4</a>,
            <a href="https://wg21.link/p1391r4">P1391R4</a>,
            <a href="https://wg21.link/p1394r4">P1394R4</a>,
            <a href="https://wg21.link/p1456r1">P1456R1</a>,
            <a href="https://wg21.link/p1523r1">P1523R1</a>,
            <a href="https://wg21.link/p1716r3">P1716R3</a>,
            <a href="https://wg21.link/p1739r4">P1739R4</a>,
            <a href="https://wg21.link/p1862r1">P1862R1</a>,
            <a href="https://wg21.link/p1870r1">P1870R1</a>,
            <a href="https://wg21.link/p1871r1">P1871R1</a>,
            <a href="https://wg21.link/p1970r2">P1970R2</a>,
            <a href="https://wg21.link/p1983r0">P1983R0</a>,
            <a href="https://wg21.link/p1994r1">P1994R1</a>,
            <a href="https://wg21.link/p2091r0">P2091R0</a>,
            <a href="https://wg21.link/p2106r0">P2106R0</a>
          </td>
          <td>Ranges</td>
          <td>
            Ranges are a new model that improves on pairs of iterators. This feature consists
            of new taxonomy, new concepts, and new versions of the familiar standard library
            algorithms that live in namespace <code>std::ranges</code>.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0355r7">P0355R7</a>,
            <a href="https://wg21.link/p1361r2">P1361R2</a>,
            <a href="https://wg21.link/p1466r3">P1466R3</a>,
            <a href="https://wg21.link/p1650r0">P1650R0</a>,
            <a href="https://wg21.link/p1981r0">P1981R0</a>,
            <a href="https://wg21.link/p1982r0">P1982R0</a>
          </td>
          <td>Calendars and time zones</td>
          <td>
            A large library addition to <code>&lt;chrono&gt;</code> for civil time
            (calendars). For example: <code>auto date = 2016y/May/29;</code>
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0645r10">P0645R10</a>,
            <a href="https://wg21.link/p1361r2">P1361R2</a>,
            <a href="https://wg21.link/p1652r1">P1652R1</a>,
            <a href="https://wg21.link/p1868r2">P1868R2</a>,
            <a href="https://wg21.link/p1892r1">P1892R1</a>
          </td>
          <td>Text formatting</td>
          <td>
            <code>std::string s = std::format("{}", "Hello, world");</code>
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p1135r6">P1135R6</a>,
            <a href="https://wg21.link/p1643r1">P1643R1</a>,
            <a href="https://wg21.link/p1644r0">P1644R0</a>,
            <a href="https://wg21.link/p1865r1">P1865R1</a>
          </td>
          <td>Synchronization</td>
          <td>
            Waiting, notifications, semaphores, latches, barriers.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0631r8">P0631R8</a></td>
          <td>Mathematical constants</td>
          <td>
            Variable templates for many mathematical constants, e.g.
            <code>std::numbers::pi_v&lt;float&gt;</code>, and concrete constants
            for <code>double</code>, e.g. <code>std::numbers::pi</code>.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1208r6">P1208R6</a></td>
          <td><code>source_location</code></td>
          <td>
            A proper library type that exposes the information provided by the <code>__LINE__</code>
            and <code>__FILE__</code> macros, the <code>__func__</code> variable, and column number.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0122r7">P0122R7</a>,
            <a href="https://wg21.link/p1085r2">P1085R2</a>,
            <a href="https://wg21.link/p1024r3">P1024R3</a>,
            <a href="https://wg21.link/p1227r2">P1227R2</a>,
            <a href="https://wg21.link/p1394r4">P1394R4</a>,
            <a href="https://wg21.link/p1872r0">P1872R0</a>,
            <a href="https://wg21.link/p1976r2">P1976R2</a>,
            <a href="https://wg21.link/p2116r0">P2116R0</a>
          </td>
          <td>New class template: <code>span</code></td>
          <td>
            A <code>span</code> is a light-weight reference to a contiguous range (mutable or const);
            essentially a &ldquo;pointer and size&rdquo;: A <code>span&lt;T&gt;</code> is like a
            <code>T* p</code> and a size <code>N</code> such that <code>p[i]</code> is valid for
            <code>i</code> in [0, <code>N</code>). It is similar in purpose (and pitfalls) to
            C++17&rsquo;s <code>string_view</code>, which is a special kind of <code>span</code> adapted
            to strings.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0660r10">P0660R10</a>,
            <a href="https://wg21.link/p1869r1">P1869R1</a>
          </td>
          <td>New classes: <code>stop_token</code>, <code>jthread</code></td>
          <td>
            Mechanisms for a thread manager class that joins the thread on destruction,
            and for interrupting the running thread.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0019r8">P0019R8</a>,
            <a href="https://wg21.link/p1123r0">P1123R0</a>
          </td>
          <td>New class template: <code>atomic_ref</code></td>
          <td>
            Atomic operations on non-atomic objects.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0550r2">P0550R2</a>,
            <a href="https://wg21.link/p0777r1">P0777R1</a>
          </td>
          <td>Transformation trait: <code>remove_cvref</code></td>
          <td>
            A composition of <code>remove_cv</code> and <code>remove_reference</code>.
            Previously, the slightly different <code>decay</code> had been popular for
            this use case, even though it does too much. Existing uses of <code>decay</code>
            in the specification have been replaced with the more appropriate transformations.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0318r1">P0318R1</a></td>
          <td>Transformation traits: <code>unwrap_reference</code>, <code>unwrap_ref_decay</code></td>
          <td>
            Traits to work with <code>reference_wrapper</code>: <code>unwrap_reference_t&lt;T&gt;</code>
            is <code>U&amp;</code> if <code>T</code> is <code>reference_wrapper&lt;U&gt;</code>, and
            <code>T</code> otherwise. <code>unwrap_ref_decay</code> first applies <code>decay</code>
            before unwrapping. The motivating use case is the specification of <code>make_pair</code>;
            these traits allow users to write functions with analogous handling of <code>reference_wrapper</code>.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0887r1">P0887R1</a></td>
          <td>Transformation trait: <code>type_identity</code></td>
          <td>
            <code>type_identity_t&lt;T&gt;</code> is <code>T</code>; useful when a template parameter
            is required in a non-deduced context.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0758r1">P0758R1</a></td>
          <td>Type trait: <code>is_nothrow_convertible</code></td>
          <td>
            Like <code>is_convertible</code>, but does not throw.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1357r1">P1357R1</a></td>
          <td>Type traits: <code>is_bounded_array</code>, <code>is_unbounded_array</code></td>
          <td>
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0466r5">P0466R5</a></td>
          <td>
            Type traits: <code>is_layout_compatible</code>,
            <code>is_pointer_interconvertible_base_of</code>,
            <code>is_pointer_interconvertible_class</code>,
            <code>is_corresponding_member</code>
          </td>
          <td>
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p1115r3">P1115R3</a>,
            <a href="https://wg21.link/p1209r0">P1209R0</a>
          </td>
          <td>Free functions <code>erase</code>, <code>erase_if</code></td>
          <td>
            Free functions to provide a simple, uniform interface for erasing elements from
            a container. The functions return the number of erased elements; see also
            P0646R1 below.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p1227r2">P1227R2</a>,
            <a href="https://wg21.link/p1970r2">P1970R2</a>
          </td>
          <td>Free functions <code>size</code>, <code>ssize</code></td>
          <td>
            One is signed, the other isn&rsquo;t&hellip;
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0463r1">P0463R1</a>,
            <a href="https://wg21.link/p1612r1">P1612R1</a>
          </td>
          <td>Endianness detection</td>
          <td>
            An enum <code>endian</code> whose members <code>endian::native</code>,
            <code>endian::little</code>, <code>endian::big</code> describe the
            implementation&rsquo;s endianness.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0053r7">P0053R7</a>,
            <a href="https://wg21.link/p0753r2">P0753R2</a>
          </td>
          <td>Synchronized, buffered ostream</td>
          <td>
            A buffering ostream wrapper, <code>basic_osyncstream</code>, that causes all
            output to be emitted atomically to the wrapped ostream. Example:
            <code>std::osyncstream(std::cout) &lt;&lt; a &lt;&lt; b &lt;&lt; "foo" &lt;&lt; c &lt;&lt; '\n';</code>
            Unlike in the unwrapped version, concurrent writes to <code>cout</code> never interleave.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0769r2">P0769R2</a></td>
          <td><code>shift</code> algorithms</td>
          <td>
            New algorithms for shifting the elements of a range:
            <code>shift_left</code>, <code>shift_right</code>
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0556r3">P0556R3</a>,
            <a href="https://wg21.link/p1355r2">P1355R2</a>,
            <a href="https://wg21.link/p1956r1">P1956R1</a>
          </td>
          <td>Functions for integral power-of-2 operations</td>
          <td>
            <code>has_single_bit</code> (i.e. is a power of two),
            <code>bit_ceil</code>, <code>bit_floor</code>,
            <code>bit_width</code>
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0553r4">P0553R4</a></td>
          <td>Functions for bit operations</td>
          <td>
            Rotation (<code>rotl</code>, <code>rotr</code>),
            population count (<code>popcount</code>),
            count of number of successive zeros or ones from left or right
            (<code>countl_zero</code>, <code>countl_one</code>,
            <code>countr_zero</code>, <code>countr_one</code>).
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0811r3">P0811R3</a></td>
          <td>Functions <code>midpoint</code>, <code>lerp</code></td>
          <td>
            Interpolation functions. <code>std::midpoint(a, b)</code> computes
            essentially <code>a + b / 2</code>, but works with integers,
            floating point numbers, and pointers. <code>std::lerp</code>
            computes arbitrary linear interpolation. Both are correct even in
            corner cases.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0586r2">P0586R2</a></td>
          <td>Function templates <code>cmp_equal</code>, <code>cmp_less</code>, etc.</td>
          <td>
            These functions provide integral comparisons that produce the mathematical
            result even when the operands have different types. For example,
            <code>cmp_less(-1, 0U)</code> is <code>true</code>, whereas
            <code>-1 &lt; 0U</code> is <code>false</code> (due to arithmetic conversions).
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p1020r1">P1020R1</a>,
            <a href="https://wg21.link/p1973r1">P1973R1</a>
          </td>
          <td>Function templates <code>make_unique_for_overwrite</code>,
            <code>make_shared_for_overwrite</code>,
            <code>allocate_shared_for_overwrite</code></td>
          <td>
            The existing smart pointer creation functions <code>make_unique</code>,
            <code>make_shared</code> and
            <code>allocate_shared</code> use value-initialization when called with no
            constructor arguments (equivalent to <code>new T()</code>). This new feature
            adds functions <code>make_unique_for_overwrite</code>,
            <code>make_shared_for_overwrite</code>,
            and <code>allocate_shared_for_overwrite</code>, which take no constructor
            arguments and use default-initialization (equivalent to <code>new T</code>).
            This avoids unnecessary initialization in situations where the initial value
            is never read.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0356r5">P0356R5</a>,
            <a href="https://wg21.link/p1651r0">P1651R0</a>
          </td>
          <td>Function template <code>bind_front</code></td>
          <td>
            A simpler, more predictable version of <code>bind</code> that
            only binds arguments on the left.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0325r4">P0325R4</a></td>
          <td>Function template <code>to_array</code></td>
          <td>
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0653r2">P0653R2</a></td>
          <td>Function template <code>to_address</code></td>
          <td>
            A well-defined replacement for <code>addressof(*p)</code> that works
            even when <code>p</code> does not point to a constructed object.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0591r4">P0591R4</a></td>
          <td>Utilities for the uses-allocator construction</td>
          <td>
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1001r2">P1001R2</a></td>
          <td>New execution policy &ldquo;unsequenced&rdquo;</td>
          <td>
            Unsequenced execution allows for vectorization (even on a single thread).
          </td>
        </tr>

      </tbody>
    </table>

    <h2 id="mods">Modifications to existing features</h2>

    <table class="features">
      <thead>
        <tr><th>Document</th><th>Summary</th><th>Examples, notes</th></tr>
      </thead>
      <tbody>
        <tr>
          <td>
            <a href="https://wg21.link/p0482r6">P0482R6</a>,
            <a href="https://wg21.link/p1423r3">P1423R3</a>
          </td>
          <td>New type: <code>char8_t</code></td>
          <td>
            The type <code>char8_t</code> is analogous to the existing types <code>char16_t</code> and
            <code>char32_t</code>, i.e. a fundamental, unsigned integral type, sufficient to store
            one UTF-8 code unit. As a breaking change, the types of <code>u8</code> character literals
            (C++17, e.g. <code>u8'a'</code>) and <code>u8</code> string literals (C++11, e.g.
            <code>u8"foo"</code>) are now <code>char8_t</code> and array of <code>char8_t</code>,
            respectively; previously they were (array of) <code>char</code>. This breakage was deemed
            to be minor, since both of those features had not been widely used. This change enables
            overload resolution to distinguish intended UTF-8 from native encoding, which previously
            was only distinguished by the choice of literal, but not by the type of the literal value.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1041r4">P1041R4</a></td>
          <td>Makes <code>char16_t</code>/<code>char32_t</code> literals be UTF-16/32</td>
          <td>
            This requires that <code>char16_t</code> literals (e.g. <code>u"foo"</code>) be
            encoded as UTF-16 and <code>char32_t</code> literals (e.g. <code>U"foo"</code>)
            as UTF-32. This in analogy with <code>u8</code> literals (which are now
            <code>char8_t</code> literals), and which have already been required to be
            valid UTF-8.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0668r5">P0668R5</a>,
            <a href="https://wg21.link/p0735r1">P0735R1</a>,
            <a href="https://wg21.link/p0982r1">P0982R1</a>
          </td>
          <td>Revising the memory model</td>
          <td>
            The memory model has been revised.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0306r4">P0306R4</a>,
            <a href="https://wg21.link/p1042r1">P1042R1</a>
          </td>
          <td>Enhancements of variadic macros</td>
          <td>
            Variadic macros are now allowed to be invoked with zero variadic arguments (this was
            previously accepted as an extension by many compilers). Within a variadic macros, the
            new feature <code>__VA_OPT__(<em>content</em>)</code>
            can now be used, which expands to nothing if there are no variadic arguments, and
            to <code><em>content</em></code> otherwise. A typical use case is for a comma that is
            required if and only if there are variadic arguments: <code>define F(A, B, ...)
            vfunc(A, B __VA_OPT__(,) __VA_ARGS__)</code></td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0614r1">P0614R1</a></td>
          <td>Range-based <code>for</code> statements with initializer</td>
          <td>
            A range-based <code>for</code> statement may now contain an additional initializer:
            <code>for (Data d = FetchData(); const Row&amp; row : d.rows()) { use(row); }</code>
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0683r1">P0683R1</a></td>
          <td>Default member initializers for bit-fields</td>
          <td>
            Bit-fields can now have default member initializers: <code>struct X { int a : 2 {-2}; int b : 2 = 1; };</code>
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0960r3">P0960R3</a>,
            <a href="https://wg21.link/p1975r0">P1975R0</a>
          </td>
          <td>Aggregate initialization from a parenthesized list</td>
          <td>
            Aggregates can now be initialized with round parentheses instead of curly braces:
            <code>struct T { int a, b, c; }; T x(1, 2);</code> A (motivating) consequence is that
            <code>make_unique</code> and <code>emplace</code> now work with aggregate types.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0428r2">P0428R2</a></td>
          <td>Template head for generic lambdas</td>
          <td>
            A generic lambda may now use a template head instead of (and in addition to)
            <code>auto</code> parameters, e.g.: <code>[]&lt;typename T&gt;(T a, T&amp; b, const T&amp; c) {}</code></td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0624r2">P0624R2</a></td>
          <td>Default-constructible and assignable stateless lambdas</td>
          <td>
            Objects of stateless closure type (i.e. the type of a lambda without any captures)
            can now be default-constructed and assigned. This allows uses such as lambdas as
            container predicates.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0315r4">P0315R4</a></td>
          <td>Lambdas in unevaluated contexts</td>
          <td>
            Lambdas may now appear in unevaluated contexts (e.g. <code>using F =
            decltype([](int a, int b) { return a + b; });</code>). Combined with the
            above P0624R2, this makes lambdas usable in a wider range of situations.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0780r2">P0780R2</a>,
            <a href="https://wg21.link/p2095r0">P2095R0</a>,
          </td>
          <td>Pack expansion in lambda <em>init-capture</em></td>
          <td>
            An <em>init-capture</em> may now introduce a pack:
            <code>template &lt;typename ...Args&gt; void f(Args... args) {
            auto x = [...brgs = std::move(args)](){}; }</code></td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0409r2">P0409R2</a></td>
          <td>Lambda capture [=, this]</td>
          <td>
            It is now allowed to spell the lambda capture <code>[=, this]</code> explicitly.
            Previously, the &ldquo;<code>this</code>&rdquo; was considered redundant and forbidden.
            See also P0806R2 above.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0961r1">P0961R1</a>,
            <a href="https://wg21.link/p0969r0">P0969R0</a>,
            <a href="https://wg21.link/p1091r3">P1091R3</a>,
            <a href="https://wg21.link/p1381r1">P1381R1</a>
          </td>
          <td>Improvements for structured bindings</td>
          <td>
            P0961R1 and P0969R0 are intended as a defect resolution against C++17.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1009r2">P1009R2</a></td>
          <td>Array size deduction in <em>new-expression</em>s</td>
          <td>
            This allows <code>new int[]{1, 2, 3}</code>, which was previously ill-formed.
            This change is intended as a defect resolution against C++17.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0702r1">P0702R1</a>,
            <a href="https://wg21.link/p0739r0">P0739R0</a>,
            <a href="https://wg21.link/p1814r0">P1814R0</a>,
            <a href="https://wg21.link/p1816r0">P1816R0</a>,
            <a href="https://wg21.link/p2082r1">P2082R1</a>
          </td>
          <td>Class template argument deduction (&ldquo;CTAD&rdquo;)</td>
          <td>
            Various tweaks and improvements. Some of these are defect resolutions against C++17 (P0702R1, P0739R0).
            Aliases and aggregate templates can now use CTAD.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1825r0">P1825R0</a></td>
          <td>Copy elision and move semantics</td>
          <td>
            Rvalue reference variables can now be moved implicitly in <code>return</code> statements.
            This change is intended as a defect resolution against C++17.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0634r3">P0634R3</a></td>
          <td>Fewer required <code>typename</code> disambiguations</td>
          <td>
            This change removes the need to disambiguate a dependent name as a typename
            via the <code>typename</code> keyword from several places where this is
            already unambiguous. This removes some redundant ceremony from template code.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0846r0">P0846R0</a></td>
          <td>ADL and function templates that are not visible</td>
          <td>
            This change fixes a long-standing, somewhat obscure situation, where it was not
            possible to provide explicit template arguments for a function template that is
            meant to be found through ADL when the name was not known to refer to a function
            template. For example, <code>f&lt;A&gt;(a)</code> would have been treated as a
            binary expression <code>f &lt; A</code> rather than as a template name
            <code>f&lt;A&gt;</code>. Previously, work-arounds were required to make ADL work
            in such a situation.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0692r1">P0692R1</a></td>
          <td>Access checking on specializations</td>
          <td>
            This change fixes a long-standing, somewhat obscure situation, where it was not
            possible to declare a template specialization for a template argument that is a
            private (or protected) member type. For example, given
            <code>class Foo { class Bar {}; };</code>, the access <code>Foo::Bar</code>
            is now allowed in <code>template&lt;class&gt; struct X;
            template&lt;&gt; struct X&lt;Foo::Bar&gt;;</code>.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0892r2">P0892R2</a></td>
          <td><code>explicit(bool)</code></td>
          <td>
            The <code>explicit</code> specifier now accepts an optional boolean parameter
            (where <code>explicit(true)</code> is equivalent to <code>explicit</code> and
            <code>explicit(false)</code> is equivalent to the absence of <code>explicit</code>),
            which simplifies generic code where explicitness is &ldquo;forwarded&rdquo; from
            template parameters in some sense.</td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1301r4">P1301R4</a></td>
          <td>An optional string for <code>[[nodiscard]]</code></td>
          <td>
            A new form of the attribute now allows specifying a text (e.g. guidance for
            a user who is erroneously discarding a result), e.g.
            <code>[[nodiscard("did you mean to call a different function")]]</code>.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0848r3">P0848R3</a></td>
          <td>Conditionally trivial special member functions</td>
          <td>
            It is now possible to provide special member functions in both defaulted and non-defaulted
            forms at once, provided the declarations are constrained in a mutually exclusive way. This
            simplifies generic code where defaultedness is &ldquo;forwarded&rdquo; from template
            parameters in some sense.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1094r2">P1094R2</a></td>
          <td>Nested inline namespaces</td>
          <td>
            Inline namespaces may now appear inside a nested namespace declaration:
            <code>namespace a::inline b::c {}</code>
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p1002r1">P1002R1</a>,
            <a href="https://wg21.link/p1064r0">P1064R0</a>,
            <a href="https://wg21.link/p1327r1">P1327R1</a>,
            <a href="https://wg21.link/p1330r0">P1330R0</a>,
            <a href="https://wg21.link/p1331r2">P1331R2</a>,
            <a href="https://wg21.link/p1668r1">P1668R1</a>

          </td>
          <td><code>constexpr</code> in the core language</td>
          <td>
            Additional core language facilities are now allowed in constexpr functions:
            <code>try</code>/<code>catch</code>,
            virtual function calls,
            <code>dynamic_cast</code>/<code>typeid</code>,
            changing the active union member,
            trivial default initialization,
            <em>asm-definition</em>s.
          </td>
        </tr>

        <tr class="midsep">
          <td>
            <a href="https://wg21.link/p0202r3">P0202R3</a>,
            <a href="https://wg21.link/p0415r1">P0415R1</a>,
            <a href="https://wg21.link/p0858r0">P0858R0</a>,
            <a href="https://wg21.link/p0879r0">P0879R0</a>,
            <a href="https://wg21.link/p0972r0">P0972R0</a>,
            <a href="https://wg21.link/p0980r1">P0980R1</a>,
            <a href="https://wg21.link/p1004r2">P1004R2</a>,
            <a href="https://wg21.link/p1006r1">P1006R1</a>,
            <a href="https://wg21.link/p1065r2">P1065R2</a>,
            <a href="https://wg21.link/p1023r0">P1023R0</a>,
            <a href="https://wg21.link/p1032r1">P1032R1</a>,
            <a href="https://wg21.link/p1424r1">P1424R1</a>,
            <a href="https://wg21.link/p1645r1">P1645R1</a>
          </td>
          <td><code>constexpr</code> in the library</td>
          <td>
            Many more library functions (including member functions) are
            now <code>constexpr</code>: algorithms, utilities, <code>complex</code>,
            <code>swap</code>, <code>chrono</code>, <code>string</code>,
            <code>vector</code>,
            <code>pointer_traits</code>, <code><em>INVOKE</em></code>,
            <code>array</code> comparisons, <code>pair</code>/<code>tuple</code>,
            numeric algorithms.
            There is also a new notion of a <em>constexpr iterator</em>.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0600r1">P0600R1</a></td>
          <td><code>nodiscard</code> in the library</td>
          <td>
            Several library (member) functions are now annotated with the
            <code>[[nodiscard]]</code> attribute (for example, <code>vector::empty</code>).
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0935r0">P0935R0</a></td>
          <td>Remove accidentally-<code>explicit</code> default constructors</td>
          <td>
            This large change replaces many explicit constructors that have  default
            arguments, such as <code>explicit foo(Alloc a = Alloc());</code>, with two
            overloads, such that the resulting default constructor is not explicit.
            Previously, the one-parameter constructor was a default constructor, but
            because it was explicit, reasonable initializations such as
            <code>foo x = {};</code> had been ill-formed. This was unintended, since
            <code>explicit</code> was only meant to inhibit implicit conversions.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0919r3">P0919R3</a>,
            <a href="https://wg21.link/p1690r1">P1690R1</a>
          </td>
          <td>Heterogeneous lookup for unordered containers</td>
          <td>
            Analogous to heterogeneous lookup for ordered containers in C++14, this change
            allows transparent predicates to be defined and used in unordered containers.
            For example, an <code>unordered_map</code> with key <code>string</code> that
            uses transparent predicates can look up a <code>string_view</code> or a
            <code>const char*</code> without constructing a <code>string</code> object for
            the lookup. The details are more complicated than for ordered containers, since
            equality and hashing need to be compatible even when the types differ.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0458r2">P0458R2</a></td>
          <td>Element existence in associative containers (&ldquo;<code>contains</code>&rdquo;)</td>
          <td>
            A new member function, <code>m.contains(key)</code>, equivalent to
            <code>m.find(key) != m.end()</code>, for all associative containers.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0646r1">P0646R1</a></td>
          <td>Return element counts from <code>list</code>, <code>forward_list</code> operations</td>
          <td>
            The modifying member functions <code>remove</code>, <code>remove_if</code> and
            <code>unique</code> of <code>list</code> and <code>forward_list</code> now
            return the number of removed elements.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0457r2">P0457R2</a></td>
          <td>Prefix/suffix checking for strings</td>
          <td>
            The class templates <code>basic_string_view</code> and <code>basic_string</code>
            have new member functions <code>starts_with</code> and <code>ends_with</code>
            that test whether the string starts/ends with the given prefix/suffix (string
            or single character).
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0674r1">P0674R1</a></td>
          <td><code>make_shared</code> for arrays</td>
          <td>
            The <code>make_shared</code> creation function can now be used for array types, e.g:
            <code>make_shared&lt;T[]&gt;(N);</code> (Array types are supported by <code>shared_ptr</code>
            since C++17.)
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0020r6">P0020R6</a></td>
          <td>Floating-point <code>atomic</code></td>
          <td>
            <code>atomic&lt;float&gt;</code>, <code>atomic&lt;double&gt;</code>,
            <code>atomic&lt;long double&gt;</code>
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0718r2">P0718R2</a></td>
          <td>Atomic <code>shared_ptr</code> and <code>weak_ptr</code></td>
          <td>
            There are now partial specializations <code>atomic&lt;shared_ptr&lt;T&gt;&gt;</code>
            and <code>atomic&lt;weak_ptr&lt;T&gt;&gt;</code> that allow atomic access to a shared
            or weak pointer. This replaces the existing free function overloads
            <code>shared_ptr&lt;T&gt; atomic_load(const shared_ptr&lt;T&gt;*)</code> etc.,
            which were fragile and error-prone. The old free function overloads are now deprecated.
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0528r3">P0528R3</a>,
            <a href="https://wg21.link/p1123r0">P1123R0</a>
          </td>
          <td>Atomic compare-and-exchange in the presence of padding</td>
          <td>
            This change makes it a requirement that compare-and-exchange for an atomic
            type <code>atomic&lt;T&gt;</code> works even when the type <code>T</code>
            contains padding bits. That is, whether the expected value equals the current
            value is no longer allowed to depend on unspecified padding; implementations
            may need to do extra work to make this happen (e.g. always store a predictable
            bit pattern in the padding, or use a masked comparison).
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0439r0">P0439R0</a></td>
          <td>Make <code>memory_order</code> a scoped enumeration</td>
          <td>
            Instead of <code>std::memory_order_relaxed</code> we now have
            <code>std::memory_order::relaxed</code>, etc.. The old names are
            provided as free constants for compatibility.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0616r0">P0616R0</a></td>
          <td>Use <code>std::move</code> in <code>&lt;numeric&gt;</code> algorithms</td>
          <td>
            Algorithms such as <code>accumulate</code> used to be specified as having
            the binary operation called like <code>acc = op(acc, *it)</code>. This has
            now changed to <code>acc = op(std::move(acc), *it)</code>.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0408r7">P0408R7</a></td>
          <td>Efficient access to the buffer of <code>basic_stringbuf</code></td>
          <td>
            API additions to <code>basic_stringbuf</code> and string-stream classes
            that allow moving the buffering string in and out.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1148r0">P1148R0</a></td>
          <td>Comprehensive review of [strings]</td>
          <td>
            A thorough cleanup of the specification of <code>char_traits</code>,
            <code>basic_string_view</code>, and <code>basic_string</code>. This
            resolves numerous LWG issues.
          </td>
        </tr>

      </tbody>
    </table>

    <h2 id="misc">Miscellaneous</h2>

    <table class="features">
      <thead>
        <tr><th>Document</th><th>Summary</th><th>Examples, notes</th></tr>
      </thead>
      <tbody>
        <tr>
          <td>
            <a href="https://wg21.link/p0941r2">P0941R2</a>,
            <a href="https://wg21.link/p1353r0">P1353R0</a>,
            <a href="https://wg21.link/p1902r1">P1902R1</a>
          </td>
          <td>Feature test macros</td>
          <td>Feature test macros are now part of the working paper. This is not relevant
            to the published International Standard, but it enables vendors to support
            <em>upcoming</em> language revisions incrementally and inform users which
            features are provided by the implementation. The feature test macros were
            previously maintained in the separate <a href="https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations">SD-6</a>.</td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0754r2">P0754R2</a></td>
          <td>The <code>&lt;version&gt;</code> header</td>
          <td>
            The new header <code>&lt;version&gt;</code> is provided. It is formally empty and
            not relevant to the published International Standard, but it provides a standardized
            place for implementation-defined information. Previously, the now-removed header
            <code>&lt;ciso646&gt;</code> (see P0619R4 above) was frequently and informally used
            for this purpose. The new feature test macros (see P0941R2 above) are defined in
            this header (as well as in their contextually appropriate place).
          </td>
        </tr>

        <tr>
          <td>
            <a href="https://wg21.link/p0788r3">P0788R3</a>;
            <a href="https://wg21.link/p1458r1">P1458R1</a>,
            <a href="https://wg21.link/p1459r1">P1459R1</a>,
            <a href="https://wg21.link/p1460r1">P1460R1</a>,
            <a href="https://wg21.link/p1462r1">P1462R1</a>,
            <a href="https://wg21.link/p1463r1">P1463R1</a>,
            <a href="https://wg21.link/p1464r1">P1464R1</a>,
            <a href="https://wg21.link/p1622r3">P1622R3</a>,
            <a href="https://wg21.link/p1686r2">P1686R2</a>,
            <a href="https://wg21.link/p1718r2">P1718R2</a>,
            <a href="https://wg21.link/p1719r2">P1719R2</a>,
            <a href="https://wg21.link/p1720r2">P1720R2</a>,
            <a href="https://wg21.link/p1721r2">P1721R2</a>,
            <a href="https://wg21.link/p1722r2">P1722R2</a>,
            <a href="https://wg21.link/p1723r2">P1723R2</a>,
            <a href="https://wg21.link/p2045r1">P2045R1</a>.
          </td>
          <td>
            Replace <em>Requires</em> with <em>Constraints</em>, <em>Mandates</em>,
            <em>Preconditions</em> in the specification
          </td>
          <td>
            A change to the formal specification of the library only: the old <em>Requires</em>
            element, which was serving multiple roles, is now obsolete and replaced by three
            new elements, <em>Constraints</em> (statically checked, affects overload resolution),
            <em>Expects</em> (preconditions whose violation results in undefined behaviour), and
            <em>Mandates</em> (statically checked conditions whose violation makes the program
            ill-formed). This should not have any observable effect, but it makes it clearer which
            requirements are diagnosed, which are the user&rsquo;s responsibility, and which affect
            overload resolution (but do not produce errors per se).
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p0551r3">P0551R3</a></td>
          <td>Restrict use of <code>std</code> functions and function templates</td>
          <td>
            A significant restriction in what users are allowed to do with standard library
            functions and function templates: Users are no longer allowed to specialize
            standard library function templates, and in general to take the address of a
            standard library function (unless the function is explicitly specified as
            <em>addressable</em>). This improves implementer freedom greatly to, say,
            implement a function as an overload set or a template. It marks a significant
            clarification of policy: functions in the standard library are in general only
            supposed to be understood as <em>valid call expressions</em>, not literally as
            declared functions.
          </td>
        </tr>

        <tr>
          <td><a href="https://wg21.link/p1025r1">P1025R1</a></td>
          <td>Update reference to Unicode</td>
          <td>
            Adds an undated reference to ISO/IEC 10646, and replaces &ldquo;UCS4&rdquo; with
            &rdquo;UTF-32&ldquo;.
          </td>
        </tr>

      </tbody>
    </table>

    <h2 id="unlisted">Unlisted papers</h2>

    <p>The following papers were moved at committee meetings, but their
      contents are too specific to call out as separate features:
      <a href="https://wg21.link/p0339r6">P0339R6</a>,
      <a href="https://wg21.link/p0340r3">P0340R3</a>,
      <a href="https://wg21.link/p0357r3">P0357R3</a>,
      <a href="https://wg21.link/p0388r4">P0388R4</a>,
      <a href="https://wg21.link/p0475r1">P0475R1</a>,
      <a href="https://wg21.link/p0487r1">P0487R1</a>,
      <a href="https://wg21.link/p0602r4">P0602R4</a>,
      <a href="https://wg21.link/p0608r3">P0608R3</a>,
      <a href="https://wg21.link/p0641r2">P0641R2</a>,
      <a href="https://wg21.link/p0655r1">P0655R1</a>,
      <a href="https://wg21.link/p0704r1">P0704R1</a>,
      <a href="https://wg21.link/p0738r2">P0738R2</a>,
      <a href="https://wg21.link/p0759r1">P0759R1</a>,
      <a href="https://wg21.link/p0771r1">P0771R1</a>,
      <a href="https://wg21.link/p0809r0">P0809R0</a>,
      <a href="https://wg21.link/p0883r2">P0883R2</a>,
      <a href="https://wg21.link/p0899r1">P0899R1</a>,
      <a href="https://wg21.link/p1008r1">P1008R1</a>,
      <a href="https://wg21.link/p1131r2">P1131R2</a>,
      <a href="https://wg21.link/p1139r2">P1139R2</a>,
      <a href="https://wg21.link/p1165r1">P1165R1</a>,
      <a href="https://wg21.link/p1207r4">P1207R4</a>,
      <a href="https://wg21.link/p1285r0">P1285R0</a>,
      <a href="https://wg21.link/p1522r1">P1522R1</a>,
      <a href="https://wg21.link/p1638r1">P1638R1</a>,
      <a href="https://wg21.link/p1908r1">P1908R1</a>,
      <a href="https://wg21.link/p1960r0">P1960R0</a>,
      <a href="https://wg21.link/p1961r0">P1961R0</a>,
      <a href="https://wg21.link/p1963r0">P1963R0</a>,
      <a href="https://wg21.link/p1965r0">P1965R0</a>,
      <a href="https://wg21.link/p2101r0">P2101R0</a><!--,
      <a href="https://wg21.link/"></a>,
      <a href="https://wg21.link/"></a>-->.
      Additionally, the following otherwise unlisted papers were accepted as
      defect resolutions against C++17:
      <a href="https://wg21.link/p0588r1">P0588R1</a>,
      <a href="https://wg21.link/p0593r6">P0593R6</a>,
      <a href="https://wg21.link/p0682r1">P0682R1</a>,
      <a href="https://wg21.link/p0727r0">P0727R0</a>,
      <a href="https://wg21.link/p0859r0">P0859R0</a>,
      <a href="https://wg21.link/p0929r2">P0929R2</a>,
      <a href="https://wg21.link/p0962r1">P0962R1</a>,
      <a href="https://wg21.link/p1164r1">P1164R1</a>,
      <a href="https://wg21.link/p1286r2">P1286R2</a>,
      <a href="https://wg21.link/p1771r1">P1771R1</a>,
      <a href="https://wg21.link/p1957r2">P1957R2</a><!--,
      <a href="https://wg21.link/"></a>,
      <a href="https://wg21.link/"></a>-->.
    </p>

    <p>The following papers contain issues that have been accepted as defect reports. CWG issues are handled by
      <a href="https://wg21.link/p0710r1">P0710R1</a>,
      <a href="https://wg21.link/p0711r0">P0711R0</a>,
      <a href="https://wg21.link/p0817r0">P0817R0</a>,
      <a href="https://wg21.link/p0818r1">P0818R1</a>,
      <a href="https://wg21.link/p0968r0">P0968R0</a>,
      <a href="https://wg21.link/p1113r0">P1113R0</a>,
      <a href="https://wg21.link/p1114r0">P1114R0</a>,
      <a href="https://wg21.link/p1350r0">P1350R0</a>,
      <a href="https://wg21.link/p1358r0">P1358R0</a>,
      <a href="https://wg21.link/p1359r0">P1359R0</a>,
      <a href="https://wg21.link/p1510r0">P1510R0</a>,
      <a href="https://wg21.link/p1969r0">P1969R0</a>,
      <a href="https://wg21.link/p1968r0">P1968R0</a>,
      <a href="https://wg21.link/p1971r0">P1971R0</a>,
      <a href="https://wg21.link/p2103r0">P2103R0</a>,
      <a href="https://wg21.link/p2108r0">P2108R0</a><!--,
      <a href="https://wg21.link/"></a>,
      <a href="https://wg21.link/"></a>-->.
      LWG issues are handled by
      <a href="https://wg21.link/p0698r0">P0698R0</a>,
      <a href="https://wg21.link/p0699r0">P0699R0</a>,
      <a href="https://wg21.link/p0815r0">P0815R0</a>,
      <a href="https://wg21.link/p0864r0">P0864R0</a>,
      <a href="https://wg21.link/p0888r0">P0888R0</a>,
      <a href="https://wg21.link/p1003r0">P1003R0</a>,
      <a href="https://wg21.link/p1082r0">P1082R0</a>,
      <a href="https://wg21.link/p1224r0">P1224R0</a>,
      <a href="https://wg21.link/p1457r0">P1457R0</a>,
      <a href="https://wg21.link/p1724r0">P1724R0</a>,
      <a href="https://wg21.link/p1917r0">P1917R0</a>,
      <a href="https://wg21.link/p2051r0">P2051R0</a>,
      <a href="https://wg21.link/p2117r0">P2117R0</a><!--,
      <a href="https://wg21.link/"></a>,
      <a href="https://wg21.link/"></a>-->.
      Only specific issues may have been selected from each paper; the meeting minutes
      contain the details.<!-- The following separate papers resolve specific issues:
      <a href="https://wg21.link/"></a>.-->
      The complete accumulation of accepted issues is published in the regularly
      updated <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html">CWG issues list</a>
      and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">LWG issues list</a>.
    </p>

    <!-- p>The following papers contain (not exclusively) wording changes that do not appear in the published
      International Standard, but that are considered <a href="#dr">defects</a> in C++20:
      <a href="https://wg21.link/"></a>,
      <a href="https://wg21.link/"></a>.
    </p -->

    <h2 id="dr">Defects, issues, bug fixes</h2>

    <p>The committee maintains a list of <em>issues</em> (see links above) which contain
      suggestions for improvements in the normative wording (clarifications, simplifications,
      corrections, etc.). When an issue is accepted that affects the published
      standard (not just the new work in progress), we have a <em>defect report</em>.
      The complete specification of C++ consists of the latest published document as amended
      by the resolutions of all subsequent defect reports.
      The resolution of a defect report is also incorporated into the
      working paper (as applicable), and thus the next published revision of the Standard no
      longer has that particular issue.</p>

    <p>Therefore, the answer to the question of, say, &ldquo;what is a valid C++14
      program?&rdquo; changes over time, up until the publication of C++17, and so forth. In
      practice, the situation is a bit more complicated when compiler vendors offer conformance
      modes for specific language revisions (e.g. <code>-std=c++11</code>,
      <code>-std=c++17</code>). Vendors may consider defect resolutions to apply to <em>any</em>
      historic revision that contains the defect (whereas ISO considers only the most recent
      publication as <em>the</em> Standard).</p>

    <p>Papers that have been applied to the working draft since the publication of C++20 and
      that are intended as defect reports are annotated with &ldquo;DR&rdquo; in the above
      change summary. Defect reports against C++20 that concern older (pre-C++20) content are
      not called out here specifically, nor are defects against C++17 whose
      resolutions are included in C++20. The full history of accepted issues together with the
      Standard revisions to which they apply is implicit in the CWG and LWG issues lists, but
      it is difficult to present explicitly.</p>

    <h2 id="demo">Assorted snippets demonstrating C++20</h2>

    <div class="code"><!--
    -->int main() {}<!--
    --></div>

    <!--
    Revisit these; see if they should get dedicated entries.

    DRs:

    P0727R0 (Core Issue 1299: Temporary objects vs temporary expressions)
    P0588R1 (Simplifying implicit lambda capture)
    P0682R1 (Repairing elementary string conversions). This resolves LWG issue 2955.
    P0859R0 (Core Issue 1581: When are constexpr member functions defined?)
    P0962R1 (Relaxing the range-for loop customization point finding rules)
    P0929R2 (Checking for abstract class types)
    P1286R2 (Contra CWG DR1778)
    P1164R1 (Make create_directory() Intuitive)
    P1771R1 ([[nodiscard]] for constructors)
    P0593R6 (Implicit creation of objects for low-level object manipulation)
    P1957R2 (Converting from T* to bool should be considered narrowing (re: US 212)) (addressing US212).

    Extensions:

    P0883R2 (Fixing Atomic Initialization). This resolves NB comments CA353, US351, DE018, and RU006 and LWG issue 2334
    P2101R0 ('Models' subsumes 'satisfies' (Wording for US298 and US300)). This resolves US298, US300 and LWG issue 3345.
    -->

  </body>
</html>
