Boost logo

Boost-Commit :

Subject: [Boost-commit] svn:boost r51566 - sandbox/committee/LWG
From: bdawes_at_[hidden]
Date: 2009-03-03 08:32:13


Author: bemandawes
Date: 2009-03-03 08:32:09 EST (Tue, 03 Mar 2009)
New Revision: 51566
URL: http://svn.boost.org/trac/boost/changeset/51566

Log:
cleanup
Text files modified:
   sandbox/committee/LWG/0xCD1_Comments.html | 5076 ++++++++++++++++++++-------------------
   1 files changed, 2591 insertions(+), 2485 deletions(-)

Modified: sandbox/committee/LWG/0xCD1_Comments.html
==============================================================================
--- sandbox/committee/LWG/0xCD1_Comments.html (original)
+++ sandbox/committee/LWG/0xCD1_Comments.html 2009-03-03 08:32:09 EST (Tue, 03 Mar 2009)
@@ -19,13 +19,13 @@
 </style>
 
 <table border="1" bordercolor="#000000" cellpadding="7"
- cellspacing="0" style="border-collapse: collapse" width="1627">
+ cellspacing="0" style="border-collapse: collapse" width="1628">
     
     <tr valign="top">
       <td width="29">
         <p><b>MB</b><b><br></b><br>
 
- <td width="117">
+ <td width="118">
         <p><b>Clause No./<br>
         Subclause No./<br>
         Annex<br></b>(e.g. 3.1)
@@ -35,13 +35,13 @@
         Figure/<br>Table/<br>Note</b><td width="62">
         <p><b>Type </b>
 
- <td width="604">
+ <td width="514">
         <p><b>Comment (justification for change) by the MB</b>
 
- <td width="535">
+ <td width="536">
         <p><b>Proposed change by the MB</b>
 
- <td width="89">
+ <td width="178">
         <p align="center" style=
         "margin-top: 0.07in; margin-bottom: 0.04in; page-break-inside: avoid">
         <b>Disposition</b>
@@ -52,7 +52,7 @@
       <td width="29">
         <p>FR 1
 
- <td width="117">
+ <td width="118">
         <p>General<br>
         Comment
 
@@ -62,7 +62,7 @@
       <td width="62">
         <p>ge
 
- <td width="604">
+ <td width="514">
         <p>Interactions between several
         new features appear obscure, and very few examples are
         offered to guide understanding of the formal text on
@@ -71,17 +71,17 @@
         <p>We worry about the complexity
         of the programming model so created.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 1
 
- <td width="117">
+ <td width="118">
         <p align="left">1-16
 
       <td width="85">
@@ -90,7 +90,7 @@
       <td width="62">
         <p align="left">ge/te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         active issues identified in WG21 N2803, C++ Standard Core
         Language Active Issues, must be addressed and appropriate
@@ -104,7 +104,7 @@
         "http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html">
         http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html></u></font>
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Appropriate action would include making changes to the CD,
         identifying an issue as not requiring a change to the CD,
@@ -112,14 +112,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>CA-1
 
- <td width="117">
+ <td width="118">
         <p>
 
       <td width="85">
@@ -128,22 +128,22 @@
       <td width="62">
         <p>Ge
 
- <td width="604">
+ <td width="514">
         <p>There are quite a number of defects for the current CD
         recorded in SC22/WG21-N2803 and N2806
 
- <td width="535">
+ <td width="536">
         <p>Consider these comments and update ISO/IEC CD 14882
         accordingly
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-1
 
- <td width="117">
+ <td width="118">
         <p>1 through 16
 
       <td width="85">
@@ -152,7 +152,7 @@
       <td width="62">
         <p>ge/te
 
- <td width="604">
+ <td width="514">
         <p>DE-1 Consider addressing a significant part of the
         unresolved core language issues presented in WG21 document
         N2791 "C++ Standard Core Language Active Issues, Revision
@@ -160,17 +160,17 @@
         
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
         .
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>CH 2
 
- <td width="117">
+ <td width="118">
         <p>all
 
       <td width="85">
@@ -179,21 +179,21 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The issues on the issues lists shall be addressed before
         the standard becomes final.
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 3
 
- <td width="117">
+ <td width="118">
         <p align="left">all
 
       <td width="85">
@@ -202,24 +202,24 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p>Latin abbreviations are presented incorrectly.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Italicize all
         Latin abbreviations, append commas after each occurrence of
         <i>i.e</i>. and <i>e.g.</i>, and remove extraneous space
         after each such abbreviation.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 3
 
- <td width="117">
+ <td width="118">
         <p>1 [intro.scope]
 
       <td width="85">
@@ -228,16 +228,16 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>C++ is split at the end of line.
 
- <td width="535">
- <p align="left">&nbsp;<td width="89">
+ <td width="536">
+ <p align="left">&nbsp;<td width="178">
         <p align="left">&nbsp;<tr valign="top">
       <td width="29">
         <p align="left">US 4
 
- <td width="117">
+ <td width="118">
         <p align="left">1.1
 
       <td width="85">
@@ -246,17 +246,17 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">There is a bad line break in
         "C++".
 
- <td width="535">
- <p align="left">&nbsp;<td width="89">
+ <td width="536">
+ <p align="left">&nbsp;<td width="178">
         <p align="left">&nbsp;<tr valign="top">
       <td width="29">
         <p>UK 1
 
- <td width="117">
+ <td width="118">
         <p align="justify">1.1
 
       <td width="85">
@@ -265,24 +265,24 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">List of additional facilities over C has
         been extended with this standard, so should be mentioned in
         the introductory material.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the following to the list in 1.1p2:
         atomic operations concurrency alignment control
         user-defined literals attributes
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 4
 
- <td width="117">
+ <td width="118">
         <p>1.2 [intro.refs]
 
       <td width="85">
@@ -291,21 +291,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>Is the lack of reference to ISO/CEI 9899/AC3:2007
         voluntary?
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>UK 2
 
- <td width="117">
+ <td width="118">
         <p align="justify">1.2
 
       <td width="85">
@@ -314,24 +314,24 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         <span lang="en-US">We recommend taking the latest update to
         each listed standard, yet the C standard is quite
         deliberately held back to the 1990 version without
         comment.+</span>
 
- <td width="535">
+ <td width="536">
         <p align="left">... not sure ...
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>UK 3
 
- <td width="117">
+ <td width="118">
         <p align="justify">1.3.1
 
       <td width="85">
@@ -340,12 +340,12 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The definition of an argument does not seem
         to cover many assumed use cases, and we believe that is not
         intentional.
 
- <td width="535">
+ <td width="536">
         <p align="left">Revise the
         definition of argument to answer question such as: Are
         lambda-captures arguments? Are type names in a throw-spec
@@ -360,14 +360,14 @@
         instantiations? What about user-defined literals where
         parens are not used?
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>UK 4
 
- <td width="117">
+ <td width="118">
         <p align="justify">1.3.3
 
       <td width="85">
@@ -376,26 +376,26 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This definition is essentially worthless,
         as it says nothing about what distinguished a diagnostic
         message from other output messages provided by the
         implementation
 
- <td width="535">
+ <td width="536">
         <p align="left">... add
         something about the diagnostic message being a message
         issues by the implementation when translating a program
         that violates the rules of the standard. ...
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 5
 
- <td width="117">
+ <td width="118">
         <p>1.3.4<br>
         [defns.<br>
         dynamic.type]
@@ -406,21 +406,21 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>"The dynamic type of an rvalue expression is its static
         type." Is this true with rvalue references?
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 5
 
- <td width="117">
+ <td width="118">
         <p>1.3.5
 
       <td width="85">
@@ -429,22 +429,22 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The wording is unclear as to whether it is the input or
         the implementation "that is not a well-formed program".
 
- <td width="535">
+ <td width="536">
         <p>Reword to clarify that it is the input that is here
         considered not well-formed.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 6
 
- <td width="117">
+ <td width="118">
         <p>1.3.6<br>
         [defns.<br>
         impl.defined]
@@ -455,21 +455,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>There is a page break between the title and the
         paragraph.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 7
 
- <td width="117">
+ <td width="118">
         <p>1.3.13<br>
         [defns.<br>
         undefined]
@@ -480,22 +480,22 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>[intro.execution]/5 explicitly allows non causal
         undefined behaviour,
 
- <td width="535">
+ <td width="536">
         <p>Adding it to the note outlying possible undefined
         behaviours.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 6
 
- <td width="117">
+ <td width="118">
         <p align="left">1.3.14
 
       <td width="85">
@@ -504,7 +504,7 @@
       <td width="62">
         <p align="left">ge
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Unspecified behavior does not clearly state whether or not
         undefined behavior is permitted. (The standard says that
@@ -512,18 +512,18 @@
         but what happens if the range is not delineated? Is a
         crash, or worse, allowed?) <br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Clearly state whether or not
         Unspecified behavior includes undefined behavior.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 8
 
- <td width="117">
+ <td width="118">
         <p>1.4<br>
         [intro.<br>
         compliance]
@@ -534,23 +534,23 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The paragraph as its stands seems to require that
         violations of the ODR (which make a program ill-formed) are
         required to be diagnosed if the program also uses an
         extension which defines some cases of ODR.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>UK 5
 
- <td width="117">
+ <td width="118">
         <p align="justify">1.5
 
       <td width="85">
@@ -559,22 +559,22 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">Missing checklist of implementation defined
         behaviour (see ISO/IEC TR 10176, 4.1.1p6)
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide a new annex with the missing
         checklist
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>UK 6
 
- <td width="117">
+ <td width="118">
         <p align="justify">1.5
 
       <td width="85">
@@ -583,23 +583,23 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">Missing annex describing potential
         incompatibility to previous edition of the standard (see
         ISO/IEC TR 10176, 4.1.1p9)
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide a new annex with the missing
         documentation. See n2733(08-0243) for a starting point
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 7
 
- <td width="117">
+ <td width="118">
         <p>1.5
 
       <td width="85">
@@ -608,21 +608,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>There is no mention of Clause 17.
 
- <td width="535">
+ <td width="536">
         <p>Include Clause 17 among the list of Clauses that specify
         the Standard Library.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 8
 
- <td width="117">
+ <td width="118">
         <p>1.5
 
       <td width="85">
@@ -631,24 +631,24 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">The paragraph
         omits to mention concepts and concept maps among its list
         of entities defined in the Standard Library. <br>
 
- <td width="535">
+ <td width="536">
         <p>Mention concepts and concept maps among the list of
         entities.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 9
 
- <td width="117">
+ <td width="118">
         <p align="left">1.6
 
       <td width="85">
@@ -657,21 +657,21 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         syntax description does not account for lines that wrap.<br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 10
 
- <td width="117">
+ <td width="118">
         <p align="left">1.7
 
       <td width="85">
@@ -680,22 +680,22 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The term thread is used before
         defined.
 
- <td width="535">
+ <td width="536">
         <p align="left"><font color=
         "#000000">R</font>eference 1.10 [intro.multithread].
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>US 11
 
- <td width="117">
+ <td width="118">
         <p>1.7
 
       <td width="85">
@@ -704,21 +704,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The phrase &#8220;threads of execution&#8221; should be
         accompanied by a reference to [intro.multithread].
 
- <td width="535">
+ <td width="536">
         <p>Insert the recommended reference.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 12
 
- <td width="117">
+ <td width="118">
         <p>1.7
 
       <td width="85">
@@ -727,22 +727,22 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>A memory location is not an object as the sentence
         claims.
 
- <td width="535">
+ <td width="536">
         <p>Clarify that a memory location &#8220;holds&#8221; an
         object rather than that it &#8220;is&#8221; an object.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 13
 
- <td width="117">
+ <td width="118">
         <p>1.7
 
       <td width="85">
@@ -751,24 +751,24 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>It is unclear what is meant by memory locations that are
         "separate": are they distinct? non-overlapping? how much
         "separation" is needed?
 
- <td width="535">
+ <td width="536">
         <p>Provide either a better definition of
         &#8220;separate&#8221; or reword (this and subsequent
         paragraphs) to avoid this term.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 14
 
- <td width="117">
+ <td width="118">
         <p>1.7
 
       <td width="85">
@@ -777,23 +777,23 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The phrase "no matter what the sizes of the intervening
         bit-fields happen to be" contradicts the claim of
         separation "by a zero-length bit-field declaration".
 
- <td width="535">
+ <td width="536">
         <p>Delete the &#8220;no matter&#8230;&#8221; phrase, or
         resolve the contradiction in a different way.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 15
 
- <td width="117">
+ <td width="118">
         <p>1.7
 
       <td width="85">
@@ -802,22 +802,22 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>A struct does not &#8220;contain&#8221; memory
         locations.
 
- <td width="535">
+ <td width="536">
         <p>Reword so that a struct is &#8220;held in&#8221; one or
         more memory locations.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 16
 
- <td width="117">
+ <td width="118">
         <p>1.9
 
       <td width="85">
@@ -826,23 +826,23 @@
       <td width="62">
         <p>
 
- <td width="604">
+ <td width="514">
         <p>The discussion of observable behavior in 1.9 is not
         consistent with the addition of threads to the language.
         Volatile reads and writes and other observable actions no
         longer occur in a single "sequence&#8221;.
 
- <td width="535">
+ <td width="536">
         <p>Remove/replace various occurrences of "sequence" in 1.9.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>UK 8
 
- <td width="117">
+ <td width="118">
         <p align="justify">1.9
 
       <td width="85">
@@ -851,13 +851,13 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">With parallel execution there is no longer
         the idea of a single execution sequence for a program.
         Instead, a program may be considered a set of exectution
         sequences.
 
- <td width="535">
+ <td width="536">
         <p align="left">Update first sentance as: A conforming
         implementation executing a well-formed program shall
         produce the same observable behavior as one of the possible
@@ -865,14 +865,14 @@
         of the abstract machine CONFORMING TO THE MEMORY MODEL
         (1.10) with the same program and the same input.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>UK 7
 
- <td width="117">
+ <td width="118">
         <p align="justify">1.9
 
       <td width="85">
@@ -881,7 +881,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Does the term 'sequence' imply all
         reads/writes through volatile memory much be serialized,
         and cannot occur in parallel on truly parallel hardware?
@@ -890,17 +890,17 @@
         multiple sequences are constrained by the memory model and
         happens-before relationships defined in 1.10
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace 'sequence' with 'sequences'.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 9
 
- <td width="117">
+ <td width="118">
         <p>1.9<br>
         [intro.execution]
 
@@ -910,21 +910,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>This example use int *v while the other examples seems
         to use notation like int* v.
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 17
 
- <td width="117">
+ <td width="118">
         <p>1.10
 
       <td width="85">
@@ -933,14 +933,14 @@
       <td width="62">
         <p>Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">This definition of
         &#8220;thread&#8221; is poor, and assumes the user already
         knows what multi-threaded means (probably true!). In
         particular, it does not deal adequately with the concept
         that all threads share the same address space.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Replace first
         sentence of para 1 as follows:
@@ -957,14 +957,14 @@
         functions, and automatic variables, are accessible to all
         threads in the same program.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>UK 9
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.1
 
       <td width="85">
@@ -973,14 +973,14 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Undefined behaviour is a drastic way to
         silently ignore minor issues. The cases in this paragraph
         could be easily defined. In this case opt for conditionally
         supported behaviour, which mandates a diagnostic if the
         compiler is not prepared to handle the syntax consistently.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace
         undefined behaviour with conditionally supported behavior.
         Conditional behaviour may be implementation defined,
@@ -991,14 +991,14 @@
         implictly added, with an empty line to follow if the last
         character was a back-slash.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>UK 10
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.1
 
       <td width="85">
@@ -1007,26 +1007,26 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Implementation
         defined seems unnecessarily burdensome for negligible gain.
         I am yet to see code that depended on whether non-empty
         sequences of whitespace were concatenated. Better left
         unspecified.
 
- <td width="535">
+ <td width="536">
         <p align="left">How the compiler treats non-empty sequences
         of whitespace should be left unspecified, rather than
         implementation-defined.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 10
 
- <td width="117">
+ <td width="118">
         <p>2.1 [lex.phases]/5<br>
         and<br>
         2.2 [lex.charset]/3
@@ -1037,7 +1037,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>[defns.multibyte] "the
         extended character set."
 
@@ -1064,10 +1064,10 @@
         different locale. During phase 5, they are using an
         implementation defined char set.
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -1077,7 +1077,7 @@
 
         <p>11
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.3
 
       <td width="85">
@@ -1086,18 +1086,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Trigraphs are a complicated solution to an
         old problem, that cause more problems than they solve in
         the modern environment. Unexpected trigraphs in string
         literals and occasionally in comments can be very confusing
         for the non-expert.
 
- <td width="535">
+ <td width="536">
         <p align="left">Deprecate the whole of 2.3 and move it to
         appendix D.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -1107,7 +1107,7 @@
 
         <p>12
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.4, 2.8
 
       <td width="85">
@@ -1116,7 +1116,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This undefined
         behaviour in token concatenation is worrying and we believe
         hard to justify. An implementation should either support
@@ -1125,19 +1125,19 @@
         implementations, although unconditionally requiring a
         diagnostic would lead to more portable programs.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace undefined behaviour with
         conditionally supported behaviour with implementation
         defined semantics.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 18
 
- <td width="117">
+ <td width="118">
         <p>2.4
 
       <td width="85">
@@ -1146,20 +1146,20 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The paragraph begins with an empty line.
 
- <td width="535">
+ <td width="536">
         <p>Delete the empty line.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 11
 
- <td width="117">
+ <td width="118">
         <p>2.4<br>
 &nbsp;[lex.pptokens]
 
@@ -1169,20 +1169,20 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>There are spurious empty lines.
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 12
 
- <td width="117">
+ <td width="118">
         <p>2.5 [lex.digraph]<br>
 &nbsp;and 2.11<br>
 &nbsp;[lex.key]/2
@@ -1193,21 +1193,21 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The alternative representations are reserved as such
         even in attribute. Is that what is wanted?
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FI 2
 
- <td width="117">
+ <td width="118">
         <p>2.5
 
       <td width="85">
@@ -1216,14 +1216,14 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Add eq, for spelling out == in order to distinguish it
         from the assignment operator.
 
- <td width="535">
+ <td width="536">
         <p>See eq-keyword.doc, eq-keyword.ppt
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -1233,7 +1233,7 @@
 
         <p>13
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.9
 
       <td width="85">
@@ -1242,17 +1242,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This text is confusing in isolation, as it
         implies pp-numbers do not have a value in translation phase
         4 when evaluating #if preprocessor expressions.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a note with a cross-refernce to 16.1
         that a pp-number may briefly acquire a value during
         translation phase 4 while evaluating #if expressions.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -1262,7 +1262,7 @@
 
         <p>14
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.11
 
       <td width="85">
@@ -1271,22 +1271,22 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The table is
         nearly sorted, but not quite. It was sorted in previous
         versions of the standard.
 
- <td width="535">
+ <td width="536">
         <p align="left">Sort the table.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 1
 
- <td width="117">
+ <td width="118">
         <p>2.11
 
       <td width="85">
@@ -1295,22 +1295,22 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>Keywords in the table are listed disorderly. Also, a
         part of a frame of the table is not drawn.
 
- <td width="535">
+ <td width="536">
         <p align="left">Sort it in alphabetical order.
         Complete the table frame.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 19
 
- <td width="117">
+ <td width="118">
         <p>2.13.1
 
       <td width="85">
@@ -1322,22 +1322,22 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The final entry in the last column (&#8220;unsigned long
         int&#8221;) is incorrect.
 
- <td width="535">
+ <td width="536">
         <p>Replace the incorrect entries by &#8220;unsigned long
         long int&#8221;.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 20
 
- <td width="117">
+ <td width="118">
         <p align="left">2.13.1,<br>
         2.13.3
 
@@ -1347,12 +1347,12 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">Long strings of digits in
         literals are a continuing problem in the production and
         maintenance of programs.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Adopt the 1983 technology of Ada and use underscores to
         separate digits. <font color="#000080" size="2" style="font-size: 11pt"><u><a href=
@@ -1360,7 +1360,7 @@
         target=
         "_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html></u></font>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1370,7 +1370,7 @@
 
         <p>15
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.13.2
 
       <td width="85">
@@ -1379,18 +1379,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Inconsistency between definition of a
         multicharacter literal and a wide character literal
         containing multiple c-chars.
 
- <td width="535">
+ <td width="536">
         <p align="left">Define the term
         multicharacter wide literal for a wchar_t literal
         containing multiple elements, and specify its type is
         integer (or wider)
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1400,7 +1400,7 @@
 
         <p>16
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.13.2
 
       <td width="85">
@@ -1409,21 +1409,21 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Not immediately clear why the question mark
         needs escaping. A note would help.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a note
         explaining that the ? character may need escaping to avoid
- accidentally creating a trigraph.<td width="89">
+ accidentally creating a trigraph.<td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 2
 
- <td width="117">
+ <td width="118">
         <p align="left">2.13.4
 
       <td width="85">
@@ -1434,21 +1434,21 @@
         <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Typo, R"..." should be
         R"[...]"
 
- <td width="535">
+ <td width="536">
         <p>Correct typo.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 3
 
- <td width="117">
+ <td width="118">
         <p align="left">2.13.4
 
       <td width="85">
@@ -1456,11 +1456,11 @@
         style="font-size: 11pt">para</font><td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>We think that the explanation of d-char-sequence is not
         enough.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         the following.
 
@@ -1519,14 +1519,14 @@
         <p align="left" style=
         "text-indent: 0.69in; margin-bottom: 0in">- end note]
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 4
 
- <td width="117">
+ <td width="118">
         <p align="left">2.13.4
 
       <td width="85">
@@ -1538,7 +1538,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo. Lack of a necessary backslash in the first line of
         the example as follows:
@@ -1570,17 +1570,17 @@
 
         <p align="left">c]";
 
- <td width="535">
+ <td width="536">
         <p align="left">Correct typo.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 21
 
- <td width="117">
+ <td width="118">
         <p>2.13.4
 
       <td width="85">
@@ -1589,22 +1589,22 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The paragraph, marked as a Note, contains an embedded
         example not marked as such.
 
- <td width="535">
+ <td width="536">
         <p>Denote the code (and perhaps also its commentary) as an
         Example.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 22
 
- <td width="117">
+ <td width="118">
         <p>2.13.4
 
       <td width="85">
@@ -1613,21 +1613,21 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The code does not have the effect predicted by its
         accompanying narrative.
 
- <td width="535">
+ <td width="536">
         <p>Append a backslash to the first line of the code.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 5
 
- <td width="117">
+ <td width="118">
         <p align="left">2.13.4
 
       <td width="85">
@@ -1638,21 +1638,21 @@
         <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>It is not explicit how to combine raw-string and
         non-raw-string.
 
- <td width="535">
+ <td width="536">
         <p>Add rules containing raw-string in the table 7.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 13
 
- <td width="117">
+ <td width="118">
         <p>2.13.4<br>
         [lex.string]
 
@@ -1662,15 +1662,15 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>Shouldn't the assert be
 
         <p>assert(std::strcmp(p, "a\nb\nc") == 0);
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1680,7 +1680,7 @@
 
         <p>17
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.13.4
 
       <td width="85">
@@ -1689,7 +1689,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It would be
         preferred for attempts to modify string literals to be
         diagnosable errors. This is not possible due to the
@@ -1703,12 +1703,12 @@
         covered under the const_cast rules so needs no further
         detail here.
 
- <td width="535">
+ <td width="536">
         <p align="left">(asssuming deprecated conversion to
         non-const array is removed or can be turned off) Strike the
         sentence on undefined behaviour.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1718,7 +1718,7 @@
 
         <p>18
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.13.4
 
       <td width="85">
@@ -1727,7 +1727,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The addition of
         static_assert (7p4) to the language raises the need to
         concatenate string representations of integral constant
@@ -1740,7 +1740,7 @@
         required, although generalizing to other literal types
         would be useful.
 
- <td width="535">
+ <td width="536">
         <p align="left">Define a syntax to support string-ization
         of integral constant expressions in a form eligible for
         string literal concatenation, 2.13.4p6. Suggested syntax:
@@ -1748,7 +1748,7 @@
         although it could combine with type specifier in the same
         way that the R prefix does, supporting u8I, uI, UI and LI.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1758,7 +1758,7 @@
 
         <p>19
 
- <td width="117">
+ <td width="118">
         <p align="justify">2.13.4
 
       <td width="85">
@@ -1767,12 +1767,12 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The grammar for string literal is becoming
         unwieldy and could easily be refactored into the type
         optional specifier and the string contents.
 
- <td width="535">
+ <td width="536">
         <p align="left">Refactor
         string-literal grammar as: (note - current Drupal view
         loses formatting which is vital to clearly read the
@@ -1781,14 +1781,14 @@
         u8 u U L string-literal-body: " s-char-sequenceOPT " R
         raw-string
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 14
 
- <td width="117">
+ <td width="118">
         <p>3 [basic]
 
       <td width="85">
@@ -1797,12 +1797,12 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>"In general it is necessary to determine whether a name
         denotes one of these entities before parsing the program
         that contains it."
 
- <td width="535">
+ <td width="536">
         <p>Would prefer
 
         <p>"... before continuing to
@@ -1817,14 +1817,14 @@
         <p>as some names denotes entities declared after the first
         occurrence.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 15
 
- <td width="117">
+ <td width="118">
         <p>3 [basic]
 
       <td width="85">
@@ -1833,15 +1833,15 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>/operator-function-id/,
         /conversion-function-id/, /template-id/ are followed by a
         space and then a "s" while usually such production names
         aren't followed by a space when put in plural (see
- /identifier/).<td width="535">
+ /identifier/).<td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1851,7 +1851,7 @@
 
         <p>20
 
- <td width="117">
+ <td width="118">
         <p align="justify">3
 
       <td width="85">
@@ -1860,7 +1860,7 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">Chapter 3
         ("Basic concepts") provides common definitions used in the
         rest of the document. Now that we have concepts as a
@@ -1868,10 +1868,10 @@
         as it does not refer to the language feature but to
         definitions used in the document.
 
- <td width="535">
+ <td width="536">
         <p align="left">Change the title to "Basic definitions".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1881,7 +1881,7 @@
 
         <p>21
 
- <td width="117">
+ <td width="118">
         <p align="justify">3
 
       <td width="85">
@@ -1890,16 +1890,16 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Concepts is now the name of a specific
         feature of the language, the term now risks confusion and
         ambiguity when used in the more general sense.
 
- <td width="535">
+ <td width="536">
         <p align="left">Rename the chapter Basic ???. THe note in
         p2 specifically needs similar rewording
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1909,7 +1909,7 @@
 
         <p>22
 
- <td width="117">
+ <td width="118">
         <p align="justify">3
 
       <td width="85">
@@ -1918,16 +1918,16 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">References are
         frequently considered variables, but this definition only
         applies to objects.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add "or reference" after both uses of
         "object"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1937,7 +1937,7 @@
 
         <p>23
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.1
 
       <td width="85">
@@ -1946,16 +1946,16 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         alias-declarations are not definitions and should be added
         to the list
 
- <td width="535">
+ <td width="536">
         <p align="left">Add alias-declaration after typedef
         declaration.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1965,7 +1965,7 @@
 
         <p>24
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.1
 
       <td width="85">
@@ -1974,7 +1974,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The current
         words suggest the declaration of a static integral constant
         data member of a class cannot be a definition. Trying to
@@ -1982,13 +1982,13 @@
         more confusion than it solves, so suggest a footnote to
         call out the special case
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a footnote attached to the static data
         membmer rule: *static data member delcarations of intergral
         type may also be definitions if a constant integral
         expression is provided for an initializer.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -1998,7 +1998,7 @@
 
         <p>25
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.1
 
       <td width="85">
@@ -2007,7 +2007,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Example is
         misleading as implicitly defined default constructor uses
         default initialization, not value initialization, for
@@ -2015,13 +2015,13 @@
         makes no difference, but it makes a big difference for
         fundamental types and pointers.
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the : s() from the illustrated
         default constructor: struct C { std::string s; C() { }
         C(const C&amp; x): s(x.s) { } C&amp; operator=(const C&amp;
         x) { s = x.s; return *this; } ~C() { } };
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -2031,7 +2031,7 @@
 
         <p>26
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.2
 
       <td width="85">
@@ -2040,16 +2040,16 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">THe one
         definition rule should cover references, and unless the
         term 'variable' is extended to cover references the list in
- this paragraph is incomplete.<td width="535">
+ this paragraph is incomplete.<td width="536">
         <p align="left">Either include references in the definition
         of 'variable' (see earlier comment) or add reference to the
         list in this paragraph.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -2059,7 +2059,7 @@
 
         <p>27
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.2
 
       <td width="85">
@@ -2068,23 +2068,23 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">A class type
         must be complete when catching exceptions, even by
         reference or pointer. See 15.3.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add "when used in an exception-handler
         (15.3)" to the list.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 16
 
- <td width="117">
+ <td width="118">
         <p>3.3<br>
         [Declarative<br>
         regions and scopes.]
@@ -2095,15 +2095,15 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The scope of function
         parameters is defined, but what is the scope of template
         parameters?
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -2113,7 +2113,7 @@
 
         <p>28
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.3.1
 
       <td width="85">
@@ -2122,14 +2122,14 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Class templates
         are not classes, so we should include this case.
 
- <td width="535">
+ <td width="536">
         <p align="left">ammend "class" to "class or class template"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -2139,7 +2139,7 @@
 
         <p>29
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.3.10
 
       <td width="85">
@@ -2148,27 +2148,27 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">operators and conversion functions do not
         have names, yet are susceptible to 'name hiding' within a
         class - indeed we rely on this for the implicitly declared
         copy-assignment operator.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the
         additional phrase "The declaration of an operator or
         conversion function in a derived class (Clause 10) hides
         the declaration of an operator or conversion function of a
         base class of the same operator or type;"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 17
 
- <td width="117">
+ <td width="118">
         <p>3.5 [Program<br>
 &nbsp;and linkage]
 
@@ -2178,7 +2178,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>This section does not specify
         whether concept names have linkage.
 
@@ -2187,10 +2187,10 @@
         that would be a bit surprising and curious. What is the
         rationale?
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -2198,7 +2198,7 @@
         <p>UK<br>
         30
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.5
 
       <td width="85">
@@ -2207,17 +2207,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph implies concepts have no
         linkage (do they need it?) and that the entities behind
         names without linkage cannot be used in other scopes. This
         maybe a bigger problem for concept maps?
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a note to clarify that concepts don't
         need linkage.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -2225,7 +2225,7 @@
         <p>UK<br>
         31
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.5
 
       <td width="85">
@@ -2234,7 +2234,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">What is the linkage of names declared
         inside a namespace, in turn declared inside an anonymous
         namespace? It is not clear why such a namespace has no
@@ -2242,18 +2242,18 @@
         should lose linkage with it, which we assume is the
         intended consequence.
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify rules for namespaces inside nested
         namespaces, or remove the restriction.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 23
 
- <td width="117">
+ <td width="118">
         <p align="left">3.5
 
       <td width="85">
@@ -2262,21 +2262,21 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Bad
         paragraph break.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 18
 
- <td width="117">
+ <td width="118">
         <p>3.5<br>
         [basic.link]
 
@@ -2286,20 +2286,20 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The paragraph number is not aligned with the text.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 19
 
- <td width="117">
+ <td width="118">
         <p>3.6 [Start<br>
 &nbsp;and<br>
 &nbsp;termination]
@@ -2310,7 +2310,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>This section completely
         ignores the real world and practical case of dynamically
         linked or loaded libraries. In current computing
@@ -2324,10 +2324,10 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -2335,7 +2335,7 @@
         <p>UK<br>
         32
 
- <td width="117">
+ <td width="118">
         <p align="justify">3.6.1
 
       <td width="85">
@@ -2344,22 +2344,22 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Do we really want to allow: constexpr int
         main() { return 0; } as a valid program?
 
- <td width="535">
+ <td width="536">
         <p align="left">Add constexpr to
         the list of ill-formed things to annotate main <br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 24
 
- <td width="117">
+ <td width="118">
         <p align="left">3.6.1
 
       <td width="85">
@@ -2368,11 +2368,11 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">std::quick_exit is not
         referenced.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Reference std::quick_exit as well as std::exit in saying
         that automatic objects are not destroyed. It should
@@ -2381,14 +2381,14 @@
         from within destructors for static or thread duration
         objects.</font>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>US 25
 
- <td width="117">
+ <td width="118">
         <p>3.6.3
 
       <td width="85">
@@ -2397,21 +2397,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The parenthesized phrase, introduced via
         &#8220;i.e.&#8221; is in the nature of an example.
 
- <td width="535">
+ <td width="536">
         <p>Change &#8220;i.e.&#8221; to &#8220;e.g.&#8221;
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 6
 
- <td width="117">
+ <td width="118">
         <p align="left">3.7.4.1
 
       <td width="85">
@@ -2423,7 +2423,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo.
 
@@ -2463,17 +2463,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p>Correct typo.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-3
 
- <td width="117">
+ <td width="118">
         <p>3.7.4.3
 
       <td width="85">
@@ -2482,7 +2482,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-3 It is
         unclear whether the following code has well-defined
@@ -2495,18 +2495,18 @@
 
         <p align="left">delete &amp;i;
 
- <td width="535">
+ <td width="536">
         <p>Clarify that &amp;i is considered a safely-derived
         pointer value.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 26
 
- <td width="117">
+ <td width="118">
         <p align="left">3.8
 
       <td width="85">
@@ -2515,11 +2515,11 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">Use of object fields during
         destruction is excessively and erroneously constrained.
 
- <td width="535">
+ <td width="536">
         <p align="left">See
         the attached document "Issues with the C++ Standard" under
         Chapter 3 "Use of objects, especially from other threads,
@@ -2527,14 +2527,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>US 27
 
- <td width="117">
+ <td width="118">
         <p>3.9
 
       <td width="85">
@@ -2543,21 +2543,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>There is a superfluous/extraneous &#8220;and&#8221;.
 
- <td width="535">
+ <td width="536">
         <p>Delete &#8220;and&#8221; from the phrase &#8220;and
         std::nullptr_t&#8221;.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 20
 
- <td width="117">
+ <td width="118">
         <p>3.9 [Types]
 
       <td width="85">
@@ -2566,7 +2566,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The phrase 'effective type'
         is defined and used in a way that is incompatible with C99.
         Such a deliberate incompatible choice of terminology is
@@ -2575,17 +2575,17 @@
         strongly suggest that the phrase 'effective type' not be
         used in such an incompatible way.
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 7
 
- <td width="117">
+ <td width="118">
         <p align="left">3.9.2
 
       <td width="85">
@@ -2597,11 +2597,11 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>over-aligned type was added as new notion. So it is
         preferable to add the link after that.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         (3.11) after over-aligned type as the link.
 
@@ -2618,14 +2618,14 @@
         valid pointer value for an over-aligned type<font color=
         "#008000">(3.11)</font>.&#8212;end note ]</font>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 28
 
- <td width="117">
+ <td width="118">
         <p>3.9.3
 
       <td width="85">
@@ -2634,23 +2634,23 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">The closing
         braces of the first two sets are preceded by extraneous
         space.
 
- <td width="535">
+ <td width="536">
         <p>Delete the extra spaces.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE 4
 
- <td width="117">
+ <td width="118">
         <p>4.2
 
       <td width="85">
@@ -2659,14 +2659,14 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-4 The deprecated conversion from string literals to
         pointer to non-const character types should be limited to
         those conversions and types of string literals that were
         already present in ISO/IEC 14882:2003, or the deprecated
         conversions should be removed entirely.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Consider
         applying the proposed resolution presented in core issue
@@ -2677,14 +2677,14 @@
         "pointer to char32_t" in 4.2 paragraph 2 and 15.1 paragraph
         3.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>CH 1
 
- <td width="117">
+ <td width="118">
         <p>4.9 and 5.2.9
 
       <td width="85">
@@ -2693,12 +2693,12 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>With respect to the target type, pointer to members
         should behave like normal pointers (least surprise
         principle).
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">The standard
         should allow implicit conversions from ``pointer to member
@@ -2707,14 +2707,14 @@
         of class type and B is a public base of D, It should allow
         explicit conversion the other way around.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-5
 
- <td width="117">
+ <td width="118">
         <p>4.11,<br>
 &nbsp;5.3.1,<br>
 &nbsp;5.5
@@ -2725,18 +2725,18 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-5 Ref-qualification has not been integrated with
         pointer-to-members.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Review implicit
         conversions (4.11), forming pointer-to-members (5.3.1), and
         dereferencing pointer-to-members (5.5) for type-safety
         concerns in the presence of ref-qualifiers on the member.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -2744,7 +2744,7 @@
         <p>UK<br>
         33
 
- <td width="117">
+ <td width="118">
         <p align="justify">4.13
 
       <td width="85">
@@ -2753,20 +2753,20 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">We have: "No two signed integer types shall
         have the same rank ..." "the rank of char shall equal the
         rank of signed char" Can we therefore deduce that char may
         not be signed?
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace the
         first sentence with "No two signed integer types shall have
         the same rank, even if they have the same representation,
         except that signed char shall have the same rank as char
         even if char is signed (3.9.1/1)."
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -2774,7 +2774,7 @@
         <p>UK<br>
         34
 
- <td width="117">
+ <td width="118">
         <p align="justify">4.13
 
       <td width="85">
@@ -2783,15 +2783,15 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">6th bullet, "the
         rank of char" - first letter should be capitalised for
         consistency with the other bullets
 
- <td width="535">
+ <td width="536">
         <p align="left">The rank of char
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -2799,7 +2799,7 @@
         <p>UK<br>
         36
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1
 
       <td width="85">
@@ -2808,15 +2808,15 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Primary
         expressions are literals, names, names qualified by the
         scope resolution operator ::, and lambda expressions. The
         immediately following grammar flatly contradicts this -
- this and (e) are also lambda expressions.<td width="535">
+ this and (e) are also lambda expressions.<td width="536">
         <p align="left">Delete this paragraph.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -2824,7 +2824,7 @@
         <p>UK<br>
         37
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1
 
       <td width="85">
@@ -2833,16 +2833,16 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Member function
         templates are not member functions, so should also be
         listed in the 3rd bullet
 
- <td width="535">
+ <td width="536">
         <p align="left">Add member function templates to the 3rd
         bullet
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -2850,7 +2850,7 @@
         <p>UK<br>
         38
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1
 
       <td width="85">
@@ -2859,7 +2859,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">this might be useful in a few more places
         than it is permitted, specifically in decltype expressions
         within a class. Two examples that would be ill-formed at
@@ -2867,17 +2867,17 @@
         this_type; decltype( [this]{ return this-&gt;memfun(); } )
         my_lambda;
 
- <td width="535">
+ <td width="536">
         <p align="left">... words to follow ...
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 8
 
- <td width="117">
+ <td width="118">
         <p align="left">5.1
 
       <td width="85">
@@ -2887,7 +2887,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">In
         the current syntax definition, a scope operator(::) cannot
         be applied to decltype, but it should be. It would be
@@ -2900,7 +2900,7 @@
         <p align="left">decltype(v)::value_type i = 0;
         // int i = 0;
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         &#8220;decltype ( expression ) :: &#8220; to
         nested-name-specifier syntax like below.
@@ -2933,14 +2933,14 @@
         "text-indent: 0.13in; margin-bottom: 0in">decltype (
         expression ) ::
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 9
 
- <td width="117">
+ <td width="118">
         <p align="left">5.1.1
 
       <td width="85">
@@ -2949,7 +2949,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">It
         would be preferable that &#8220;&amp;&amp;&#8221; could be
         specified in a lambda expression to declare move capture.
@@ -3123,20 +3123,20 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         move capture in a lambda expression.
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 10
 
- <td width="117">
+ <td width="118">
         <p align="left">5.1.1
 
       <td width="85">
@@ -3145,7 +3145,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">In
         the current syntax definition, a returned type of a
         function object cannot be obtained by using result_of from
@@ -3181,21 +3181,21 @@
         function object without result_type. But it is preferable
         to be able to obtain it with template.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         result_type to the syntax of an unnamed function object
         generated by a lambda expression.
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 29
 
- <td width="117">
+ <td width="118">
         <p align="left">5.1.1
 
       <td width="85">
@@ -3204,22 +3204,22 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         standard does not state whether or not direct recursion of
         lambdas is possible.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 30
 
- <td width="117">
+ <td width="118">
         <p align="left">5.1.1
 
       <td width="85">
@@ -3228,7 +3228,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         <font color="#000000">The standard does not clarify the
         meaning of</font> <font size="2" style=
@@ -3237,17 +3237,17 @@
         lambdas. Does it mean this lambda, or this class within
         which the lambda is nested?</font></font>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 31
 
- <td width="117">
+ <td width="118">
         <p align="left">5.1.1
 
       <td width="85">
@@ -3256,7 +3256,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         <font color="#000000">The current wording does not specify
         how context capturing and name resolution</font>
@@ -3264,10 +3264,10 @@
         inner lambda refers to the outer lambda's locals variables
         and parameters.</font>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3275,7 +3275,7 @@
         <p>UK<br>
         45
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1.1
 
       <td width="85">
@@ -3284,13 +3284,13 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Lambda is a language feature with an
         apparent dependency on &lt;functional&gt;. This increases
         dependency of language on library, and is inconsistent with
         the definition of freestanding in 17.6.2.4.
 
- <td width="535">
+ <td width="536">
         <p align="left">Change the text
         "a closure object behaves as a function object" to "a
         closure object is a built-in object which behaves as a
@@ -3302,7 +3302,7 @@
         on library. (Marked as technical comment anyway because
         this clarity is technically important).
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3312,7 +3312,7 @@
 
         <p align="left"><br>
 
- <td width="117">
+ <td width="118">
         <p align="left">5.1.1
 
       <td width="85">
@@ -3321,15 +3321,15 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         final italic "this" in the paragraph should be a teletype
         "this".
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3337,7 +3337,7 @@
         <p>UK<br>
         39
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1.1
 
       <td width="85">
@@ -3346,16 +3346,16 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph lists all the special member
         functions for the class representing a lambda. But it omits
         the destructor, which is awkward.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add "F has an implicitly-declared
         destructor".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3363,7 +3363,7 @@
         <p>UK<br>
         40
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1.1
 
       <td width="85">
@@ -3372,7 +3372,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">If one or more
         names in the effective capture set are preceded by &amp;,
         the effect of invoking a closure object or a copy after the
@@ -3384,13 +3384,13 @@
         behaviour: int i; reference_closure&lt;void ()&gt; f; if
         (blah) { f = [&amp;i]() { }; } if (f) f();
 
- <td width="535">
+ <td width="536">
         <p align="left">If one or more names in the effective
         capture set are preceded by &amp;, the effect of invoking a
         closure object or a copy after the lifetime of any of the
         variables referenced has ended is undefined.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3398,7 +3398,7 @@
         <p>UK<br>
         41
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1.1
 
       <td width="85">
@@ -3407,7 +3407,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">For argument dependant lookup (3.4.2) the
         associated namespaces for a class include its bases, and
         associated namespaces of its bases. Requiring the result of
@@ -3418,11 +3418,11 @@
         relying on the idea of implicitly slicing objects is
         uncomfortable.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace inheritance with implicit
         conversion.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3430,7 +3430,7 @@
         <p>UK<br>
         42
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1.1
 
       <td width="85">
@@ -3439,14 +3439,14 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">A lambda with an empty capture list has
         identical semantics to a regular function type. By
         requiring this mapping we get an efficient lambda type with
         a known API that is also compatible with existing operating
         system and C library functions.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a new
         paragraph: "A lambda expression with an empty capture set
         shall be convertible to pointer to function type R(P),
@@ -3457,7 +3457,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3465,7 +3465,7 @@
         <p>UK<br>
         43
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1.1
 
       <td width="85">
@@ -3474,7 +3474,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The note spells
         out the intent that objects from lambda-expressions with an
         effective capture list of references should be implemented
@@ -3485,11 +3485,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">... provvide exceptions in the right places
         ...
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3497,7 +3497,7 @@
         <p>UK<br>
         44
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1.1
 
       <td width="85">
@@ -3506,7 +3506,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">There is a
         strong similarity between a [&amp;]{} lambda capturing a
         stack frame, and a [this]{} lambda binding a member
@@ -3519,12 +3519,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Extend reference_closure requirement to
         cover [this] lambdas. Consider a simple syntax for creating
         such bound expressions.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -3532,7 +3532,7 @@
         <p>UK<br>
         46
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.1.1
 
       <td width="85">
@@ -3541,7 +3541,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The requirement that a lambda meeting
         appropriate conditions be an object derived from
         reference_closure makes lambda the language feature
@@ -3549,7 +3549,7 @@
         of the language on the library and bloats the definition of
         freestanding C++.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace text "is
         publicly derived from" with "shall be implemented in a
         manner indistinguishable from". This places an ABI
@@ -3559,14 +3559,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-6
 
- <td width="117">
+ <td width="118">
         <p>5.1.1, 20.7.18
 
       <td width="85">
@@ -3575,7 +3575,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-6 Some uses of lambda expressions refer to
         specializations of the unconstrained class template
         std::reference_closure (5.1.1). If the lambda expression
@@ -3583,19 +3583,19 @@
         parameter type for the lambda depend on a template
         parameter (see 14.10), such a use is ill-formed.
 
- <td width="535">
+ <td width="536">
         <p>In 20.7.18, for the class template
         std::reference_closure, require Returnable for R and
         VariableType for each of the ArgTypes.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-7
 
- <td width="117">
+ <td width="118">
         <p>5.1.1
 
       <td width="85">
@@ -3604,21 +3604,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>DE-7 The note at the end of paragraph 10 appears to be
         garbled.
 
- <td width="535">
+ <td width="536">
         <p>Remove "or references" in the note.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-8
 
- <td width="117">
+ <td width="118">
         <p>5.1.1
 
       <td width="85">
@@ -3627,23 +3627,23 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-8 The construction of the function call operator
         signature is missing specifications for the ref-qualifier
         and the attribute-specifier.
 
- <td width="535">
+ <td width="536">
         <p>Add bullets that say that the ref-qualifier and the
         attribute-specifier are absent.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>US 33
 
- <td width="117">
+ <td width="118">
         <p>5.1.1
 
       <td width="85">
@@ -3652,11 +3652,11 @@
       <td width="62">
         <p>Ge
 
- <td width="604">
+ <td width="514">
         <p>There is no definition of &#8220;move constructor&#8221;
         or &#8220;move operation&#8221;
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Since this is
         the first place the terms are used, a definition should
@@ -3664,14 +3664,14 @@
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-9
 
- <td width="117">
+ <td width="118">
         <p>5.1.1
 
       <td width="85">
@@ -3680,7 +3680,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-9 There is not a single example of a
         lambda-expression in the standard. See also core issue 720
         in WG21 document N2791 "C++ Standard Core Language Active
@@ -3688,10 +3688,10 @@
         
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
         .
 
- <td width="535">
+ <td width="536">
         <p>Add a few well-chosen examples.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3699,7 +3699,7 @@
         <p>UK<br>
         52
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2
 
       <td width="85">
@@ -3708,14 +3708,14 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph seens out of place,
         assignment expressions are covered in 5.17
 
- <td width="535">
+ <td width="536">
         <p align="left">Move p3 to subsection 5.17
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3723,7 +3723,7 @@
         <p>UK<br>
         53
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.1
 
       <td width="85">
@@ -3732,7 +3732,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The definition in p1 makes no allowance for
         overloaded operator[] that treats the expression as a
         simple function call, and does not support the
@@ -3740,13 +3740,13 @@
         definition when describing the use of brace-init-lists
         inside [].
 
- <td width="535">
+ <td width="536">
         <p align="left">Insert a new p2 describing the changed
         semantics for overloaded operator[]. This should be a note
         to avoid introducing normative text that could potentially
         conflict with the later definiton of these semantics.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3754,7 +3754,7 @@
         <p>UK<br>
         59
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.2
 
       <td width="85">
@@ -3763,7 +3763,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">When there is no parameter for a given
         argument, the argument is passed in such a way that the
         receiving function can obtain the value of the argument by
@@ -3771,11 +3771,11 @@
         template &lt;class ... Types&gt; void f(Types ... pack);
         f(1, 2, 3);
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify that this sentence only applies
         where the ellipsis is used.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3783,7 +3783,7 @@
         <p>UK<br>
         60
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.5
 
       <td width="85">
@@ -3792,15 +3792,15 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">In the remainder of 5.2.5, cq represents
         either const or the absence of const vq represents either
         volatile or the absence of volatile.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add "and" before vq
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3808,7 +3808,7 @@
         <p>UK<br>
         61
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.5
 
       <td width="85">
@@ -3817,18 +3817,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Together with footnote 60 there may be
         confusion that the postfix expression is always evaluated -
         even when part of an unevaluated operand. We believe the
         standard does not require this, and a comment in the
         existing note would be a useful clarification.
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify in footnote 60 that this will not
         happen if the whole expression is an unevaluated operand.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3836,7 +3836,7 @@
         <p>UK<br>
         62
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.5
 
       <td width="85">
@@ -3845,24 +3845,24 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">In the final bullet, what does 'not an
         lvalue' mean? Does it imply rvalue, or are there other
         possible meanings? Should clauses that trigger on rvalues
         pick up on this?
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace 'not an lvalue' with 'is an
         rvalue'.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-10
 
- <td width="117">
+ <td width="118">
         <p>5.2.5
 
       <td width="85">
@@ -3871,16 +3871,16 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-10 If E1.E2 is referring to a non-static member
         function, the potential ref-qualification on E2 should be
         taken into account.
 
- <td width="535">
+ <td width="536">
         <p>Adjust the presentation of the types involved as
         appropriate.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3888,7 +3888,7 @@
         <p>UK<br>
         63
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.6
 
       <td width="85">
@@ -3897,13 +3897,13 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Paragraph 2 is missing its number.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add one.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3911,7 +3911,7 @@
         <p>UK<br>
         64
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.7
 
       <td width="85">
@@ -3920,11 +3920,11 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">A new name R is introduced for use in
         paragraphs 3 and 4. But R is the same as T.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace R with T
         and replace "the required result type (which, for
         convenience, will be called R in this description)" with
@@ -3932,7 +3932,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3940,7 +3940,7 @@
         <p>UK<br>
         65
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.7
 
       <td width="85">
@@ -3949,7 +3949,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">In the first two
         bullets we have "the result is a pointer (an lvalue
         referring) to". But para 2 makes clear that a dynamic_cast
@@ -3958,11 +3958,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace "an lvalue referring to" with
         "reference", twice.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3970,7 +3970,7 @@
         <p>UK<br>
         66
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.8
 
       <td width="85">
@@ -3979,18 +3979,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">typeid may
         return "an implementation-defined class derived from std ::
         type_info". The derivation must be public.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">an implementation-defined class publicly
         derived from std :: type_info
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -3998,7 +3998,7 @@
         <p>UK<br>
         67
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.9
 
       <td width="85">
@@ -4007,11 +4007,11 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Paragraph 1 specifies when the result of
         static_cast is an lvalue; repeating it is unnecessary.
 
- <td width="535">
+ <td width="536">
         <p align="left">In para 2,
         delete "It is an lvalue if the type cast to is an lvalue
         reference; otherwise, it is an rvalue." and "The result is
@@ -4021,7 +4021,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -4029,7 +4029,7 @@
         <p>UK<br>
         54
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.10
 
       <td width="85">
@@ -4038,13 +4038,13 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Para 3: "The mapping performed by
         reinterpret_cast is implementation-defined.". Para 6: "...
         the result of such a pointer conversion is unspecified."
         Which is it?
 
- <td width="535">
+ <td width="536">
         <p align="left">In para 6,
         replace unspecified with implementation-defined.
         Alternatively, delete paragraph 3, since individual cases
@@ -4052,7 +4052,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -4060,7 +4060,7 @@
         <p>UK<br>
         55
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.10
 
       <td width="85">
@@ -4069,13 +4069,13 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">dynamic_cast and reinterpret_cast
         crossreference 5.2.11 without creating an extra note. The
         second half of the note is unrelated to the crossrefernce,
         and would serve as well in normative text.
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the note
         about definition of casting away constness, preserve the
         cross-reference. The second sentance on reintrepret_cast to
@@ -4084,7 +4084,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -4092,7 +4092,7 @@
         <p>UK<br>
         56
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.10
 
       <td width="85">
@@ -4101,7 +4101,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The notion of
         safely derived pointers means this conversion may not be as
         safe in the revised standard as the original. It would be
@@ -4110,12 +4110,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add: [Note: the result of such a conversion
         will not be a safely-derived pointer value (3.7.4.3) -- end
         note]
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -4123,7 +4123,7 @@
         <p>UK<br>
         57
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.10
 
       <td width="85">
@@ -4132,19 +4132,19 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Conditionally supported behaviour gives a
         wide range or permission, so clarify relationship between
         safely-derived object pointers and function pointers in a
         note.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add: [Note: In such cases, the
         implementation shall also define whether a safely-derived
         object pointer cast to a function pointer can be safely
         cast back -- end note]
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -4152,7 +4152,7 @@
         <p>UK<br>
         58
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.2.11
 
       <td width="85">
@@ -4161,7 +4161,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Casting from an
         lvalue of type T1 to an lvalue of type T2 using a reference
         cast casts away constness if a cast from an rvalue of type
@@ -4171,11 +4171,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace lvalue with "lvalue or rvalue"
         twice.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -4185,7 +4185,7 @@
 
         <p align="left"><br>
 
- <td width="117">
+ <td width="118">
         <p align="left">5.3
 
       <td width="85">
@@ -4194,14 +4194,14 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The list of unary operator
         should be in teletype font.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4209,7 +4209,7 @@
         <p>UK<br>
         68
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.1
 
       <td width="85">
@@ -4218,18 +4218,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">All the unary operands other than * return
         rvalues - but this is not stated.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a paragraph
         1a "The following unary operators all produce results that
         are rvalues."
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4237,7 +4237,7 @@
         <p>UK<br>
         69
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.1
 
       <td width="85">
@@ -4246,7 +4246,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">If we cannot
         bind references/take address of functions in concept_maps,
         does that mean we cannot use generic bind in constrained
@@ -4260,10 +4260,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">... unknown ...
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4271,7 +4271,7 @@
         <p>UK<br>
         70
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.3
 
       <td width="85">
@@ -4280,7 +4280,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The sizeof
         operator shall not be applied to ... an enumeration type
         before all its enumerators have been declared We should
@@ -4288,11 +4288,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change "an enumeration type" to "an
         enumeration type whose underlying type is not fixed".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4300,7 +4300,7 @@
         <p>UK<br>
         71
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.4
 
       <td width="85">
@@ -4309,7 +4309,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The type of an allocated object wih the
         type specifier auto is determined by the rules of copy
         initialization, but the initialization applied will be
@@ -4318,10 +4318,10 @@
         consistency, use the same form of initiailization for the
         deduction as the new expression.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace T x = e; with T x(e);
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4329,7 +4329,7 @@
         <p>UK<br>
         72
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.4
 
       <td width="85">
@@ -4338,7 +4338,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The library
         headers have been carefully structured to limit the
         dependencies between core language and specific headers.
@@ -4351,11 +4351,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Throw std::bad_alloc instead of
         std::length_error.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4363,7 +4363,7 @@
         <p>UK<br>
         73
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.4
 
       <td width="85">
@@ -4372,7 +4372,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">A class type
         with conversion operator can only be used if the conversion
         type is constexpr and the class is a literal type. Adding
@@ -4381,10 +4381,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add 'literal' before 'class type'
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4392,7 +4392,7 @@
         <p>UK<br>
         74
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.4
 
       <td width="85">
@@ -4401,7 +4401,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">operators, like
         constructors and destructors, do not have names. However,
         in certain circumstances they can be treated as if they had
@@ -4410,12 +4410,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change "the allocation function&#8217;s
         name is operator new" to "the allocation function is named
         operator new" and similarly for operator delete.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4423,7 +4423,7 @@
         <p>UK<br>
         35
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.4
 
       <td width="85">
@@ -4432,17 +4432,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Missing period in middle of paragraph
         between "in the scope of T" and "If this lookup fails"
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a period
         between "in the scope of T" and "If this lookup fails"
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4450,7 +4450,7 @@
         <p>UK<br>
         75
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.3.5
 
       <td width="85">
@@ -4459,24 +4459,24 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">A paragraph
         strarting with [Note... is easily skipped when reading,
         missing the normative text at the end.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Swap order of the note and normative text.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 21
 
- <td width="117">
+ <td width="118">
         <p>5.3.6<br>
         [Alignof
 
@@ -4486,21 +4486,21 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Should not the type of alignof-expression be of type
         std::max_align_t?
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 35
 
- <td width="117">
+ <td width="118">
         <p align="left">5.8
 
       <td width="85">
@@ -4509,7 +4509,7 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         There is curious spacing in the expressions "E1 &lt;&lt;E2"
         and "E1 &gt;&gt;E2". This is a formatting change since
@@ -4517,10 +4517,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4528,7 +4528,7 @@
         <p>UK<br>
         47
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.14 / 5.15
 
       <td width="85">
@@ -4537,7 +4537,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Why are the
         descriptions of order of evaluation of expressions and side
         effects different between &amp;&amp; and || operators. The
@@ -4547,11 +4547,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Pick one form of wording as 'the best' and
         apply it in both places.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4559,7 +4559,7 @@
         <p>UK<br>
         48
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.18
 
       <td width="85">
@@ -4568,7 +4568,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The defining
         feature of the comma operator is the guaranteed sequencing
         of two expressions. This guarantee is lost when presented
@@ -4577,12 +4577,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add: [Note: There are no guarantees on the
         order of value computation for an overloaded comma operator
         -- end note]
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4590,7 +4590,7 @@
         <p>UK<br>
         49
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.19
 
       <td width="85">
@@ -4599,14 +4599,14 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Is an implementation permitted to reject
         this? constexpr int f() { return f(); } int a[f()]; AFAICT
         it is well-formed; f() seems to satisfy all the rules to
         make it a constant expression. I would hate compilation to
         become a potentially non-terminating experience.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add an escape
         clause to allow the implementation to reject excessively
         deep nesting of constexpr function evaluations. (This can
@@ -4618,7 +4618,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4626,7 +4626,7 @@
         <p>UK<br>
         50
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.19
 
       <td width="85">
@@ -4635,20 +4635,20 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The following should be valid: enum E { foo
         = 4}; const E c = foo; int a[c]; But currently it is not -
         c is not an lvalue of effective integral type (4th bullet).
         (See also 7.1.6.1/2)
 
- <td width="535">
+ <td width="536">
         <p align="left">Change
         "effective integral type" to "effective integral or
         enumeration type" in the 4th bullet, 1st sub-bullet.
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4656,7 +4656,7 @@
         <p>UK<br>
         51
 
- <td width="117">
+ <td width="118">
         <p align="justify">5.19
 
       <td width="85">
@@ -4665,7 +4665,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">typeid
         expressions can never be constant, whether or not the
         operand is a polymorphic class type. The result of the
@@ -4675,12 +4675,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the words "whose operand is of a
         polymorphic class type" on the bullet for typeid
         expressions.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4688,7 +4688,7 @@
         <p>UK<br>
         76
 
- <td width="117">
+ <td width="118">
         <p align="justify">6.3
 
       <td width="85">
@@ -4697,25 +4697,25 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Do we really need two different terms that
         say the same thing?
 
- <td width="535">
+ <td width="536">
         <p align="left">Pick either
         'block' or 'compound statement' as the preferred term and
         use it consistently throughout the standard.
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 22
 
- <td width="117">
+ <td width="118">
         <p>6.4.2<br>
 &nbsp;[The switch<br>
 &nbsp;statement]
@@ -4726,7 +4726,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The constant-expression in
 
         <p>
@@ -4744,10 +4744,10 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4755,7 +4755,7 @@
         <p>UK<br>
         77
 
- <td width="117">
+ <td width="118">
         <p align="justify">6.5
 
       <td width="85">
@@ -4764,7 +4764,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The terms i/o
         operation, synchronize operation and atomic operation have
         very specific meanings within the standard. The paragraph
@@ -4773,18 +4773,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Profide a cross-reference for the terms:
         i/o operation, synchronize operation and atomic operation
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 11
 
- <td width="117">
+ <td width="118">
         <p align="left">6.5.4
 
       <td width="85">
@@ -4796,12 +4796,12 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>There is no _RangeT type in the equivalent code to
         &#8220;range-base for&#8221; statement. It existed in
         N2049.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         a typedef for _RangeT in the example as follows:
 
@@ -4851,7 +4851,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4859,7 +4859,7 @@
         <p>UK<br>
         78
 
- <td width="117">
+ <td width="118">
         <p align="justify">6.5.4
 
       <td width="85">
@@ -4868,12 +4868,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Including the header
         &lt;iterator_concepts&gt; is far too unwieldy to enable an
         important and (expected to be) frequently used syntax.
 
- <td width="535">
+ <td width="536">
         <p align="left">Merge
         &lt;iterator_concepts&gt; into &lt;concepts&gt; and change
         6.5.4p2 to refer to &lt;concepts&gt;, or make the Range
@@ -4882,7 +4882,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4890,7 +4890,7 @@
         <p>UK<br>
         79
 
- <td width="117">
+ <td width="118">
         <p align="justify">6.5.4
 
       <td width="85">
@@ -4899,7 +4899,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The definition
         of for (for-range-declaration : expression) statement is
         expanded in terms which require a Range concept, and the
@@ -4912,7 +4912,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">When expression is an array a of length N
         whose length is known at compile time, expand range-for as
         'for (... p=a, p!=a+N, p++) ...' without requiring the
@@ -4920,14 +4920,14 @@
         expression is an initializer_list, expand range-for
         similarly without requiring &lt;iterator_concepts&gt;.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-11
 
- <td width="117">
+ <td width="118">
         <p>6.9
 
       <td width="85">
@@ -4936,7 +4936,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-11 A
         sentence in paragraph 1 reads: "Outside of a constrained
@@ -4947,11 +4947,11 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p>State that such a late-checked block has the same
         meaning as if the late_check keyword were absent.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4959,7 +4959,7 @@
         <p>UK<br>
         80
 
- <td width="117">
+ <td width="118">
         <p align="justify">7
 
       <td width="85">
@@ -4968,7 +4968,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Many of the
         sections and major subsections open with a sentence
         summarising the content. I'm not sure this is necessary;
@@ -4982,10 +4982,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the first sentence.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -4993,7 +4993,7 @@
         <p>UK<br>
         81
 
- <td width="117">
+ <td width="118">
         <p align="justify">7
 
       <td width="85">
@@ -5002,7 +5002,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">String literal
         concatenation happens in phase 6, before parsing, so it is
         legal and useful to use it for the string literal in a
@@ -5011,12 +5011,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a note: Multiple adjacent string
         literals may be used instead of a single /string-literal/;
         see [lex.phases].
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5024,7 +5024,7 @@
         <p>UK<br>
         82
 
- <td width="117">
+ <td width="118">
         <p align="justify">7
 
       <td width="85">
@@ -5033,7 +5033,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Paragraph 2
         talks about declarations that can have nested declarations
         within them. It doesn't mention scoped enumerations - but
@@ -5042,11 +5042,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add "scoped enumeration" to the list in the
         second sentence.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5054,7 +5054,7 @@
         <p>UK<br>
         83
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1
 
       <td width="85">
@@ -5063,7 +5063,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The longest
         sequence of decl-specifiers that could possibly be a type
         name is taken as the decl-specifier-seq of a declaration.
@@ -5072,11 +5072,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Not sure. I understand the rule, just not
         how to say it.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5084,7 +5084,7 @@
         <p>UK<br>
         84
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1
 
       <td width="85">
@@ -5093,7 +5093,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The grammar
         includes alignment-specifier as a production for
         decl-specifier, but there is no production for
@@ -5102,18 +5102,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Delete the production (including the
         duplicate in A6)
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FI 3
 
- <td width="117">
+ <td width="118">
         <p>7.1
 
       <td width="85">
@@ -5124,7 +5124,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">While
         it&#8217;s considered too late for this standard revision,
@@ -5134,10 +5134,10 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p>See restricted-auto.ppt
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5145,7 +5145,7 @@
         <p>UK<br>
         85
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.1
 
       <td width="85">
@@ -5154,7 +5154,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">... the
         init-declarator-list of the declaration shall not be empty
         (except for global anonymous unions, which shall be
@@ -5165,10 +5165,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace "global" with "namespace scope".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5176,7 +5176,7 @@
         <p>UK<br>
         86
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.1
 
       <td width="85">
@@ -5185,7 +5185,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The register
         keyword serves very little function, offering no more than
         a hint that a note says is typically ignored. It should be
@@ -5196,11 +5196,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Deprecate current usage of the register
         keyword.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5208,7 +5208,7 @@
         <p>UK<br>
         87
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.1
 
       <td width="85">
@@ -5217,7 +5217,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Why require two
         keywords, where one on its own becomes ill-formed?
         thread_local should imply 'static' in this case, and the
@@ -5227,19 +5227,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Drop requirement to combine static keyword
         with thread_local at block-scope inside a function
         definition.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 36
 
- <td width="117">
+ <td width="118">
         <p align="left">7.1.1
 
       <td width="85">
@@ -5248,25 +5248,25 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         permission to use thread_local static data members is
         missing.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the static members as a
         permitted use.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 23
 
- <td width="117">
+ <td width="118">
         <p>7.1.5<br>
         [constexpr]
 
@@ -5276,7 +5276,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>'constexpr' functions should
         be allowed to take const reference parameters, as long as
         their uses are in a context where a constant expression may
@@ -5298,17 +5298,17 @@
 
         <p style="margin-top: 0.04in"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 12
 
- <td width="117">
+ <td width="118">
         <p align="left">7.1.5
 
       <td width="85">
@@ -5317,7 +5317,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">It should be
         allowed to define constexpr recursively.
@@ -5448,20 +5448,20 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Allow constexpr recursion.
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 37
 
- <td width="117">
+ <td width="118">
         <p align="left">7.1.6.1
 
       <td width="85">
@@ -5470,7 +5470,7 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         There is a "Note: 3.9.3 describes how cv-qualifiers affect
         object and function types." So far as I can see, 3.9.3
@@ -5480,10 +5480,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5491,7 +5491,7 @@
         <p>UK<br>
         89
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.6.1
 
       <td width="85">
@@ -5500,7 +5500,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The two
         normative sentences in this paragraph appear to duplicate
         text elsewhere - but they aren't exact duplicates, which
@@ -5527,12 +5527,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Make the normative text in this section
         into one or more notes, with cross references, and correct
         the referenced text if necessary.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5540,7 +5540,7 @@
         <p>UK<br>
         90
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.6.2
 
       <td width="85">
@@ -5549,7 +5549,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The grammar in
         paragraph one makes "nested-name-specifier template
         simple-template-id" a simple-type-specifier, but unlike all
@@ -5557,12 +5557,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a row to table 9 mentioning
         simple-template-id and punting to clause 14 (cf
         decltype(expression)).
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5570,7 +5570,7 @@
         <p>UK<br>
         91
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.6.2
 
       <td width="85">
@@ -5579,7 +5579,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">5.1/5 says "[A]
         parenthesized expression can be used in exactly the same
         contexts as those where the enclosed expression can be
@@ -5597,13 +5597,13 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Insert "unparenthised" in the first bullet
         point - "if e is an *unparenthised* id-expression ...". In
         the second bullet point, move "(parentheses around e are
         ignored)" into a note.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5611,7 +5611,7 @@
         <p>UK<br>
         92
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.6.3
 
       <td width="85">
@@ -5620,7 +5620,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The note
         correctly indicates that, if T is a template type
         parameter, then "friend class T;" is ill-formed. It might
@@ -5629,11 +5629,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Either strike the note or add reference to
         11.4/3 and/or mention of "friend T;".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5641,7 +5641,7 @@
         <p>UK<br>
         93
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.6.3
 
       <td width="85">
@@ -5650,7 +5650,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">In the third
         production, "enum ::opt nested-name-specifieropt
         identifier", enum should not be in italics; its referring
@@ -5658,10 +5658,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change to keyword font
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5669,7 +5669,7 @@
         <p>UK<br>
         94
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.6.4
 
       <td width="85">
@@ -5678,14 +5678,14 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The auto type-specifier signifies that the
         type of an object being declared shall be deduced from its
         initializer or specified explicitly at the end of a
         function declarator. A function declarator does not declare
         an object.
 
- <td width="535">
+ <td width="536">
         <p align="left">The auto
         type-specifier signifies that the type of an object being
         declared shall be deduced from its initializer or that the
@@ -5694,7 +5694,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5702,7 +5702,7 @@
         <p>UK<br>
         95
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.1.6.4
 
       <td width="85">
@@ -5711,7 +5711,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">(See also
         c++std-core-13583) This paragraph allows auto "in the
         type-specifier-seq in a new-type-id (5.3.4)" (and nowhere
@@ -5725,18 +5725,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change "in a new-type-id" to "in a
         new-type-id or type-id in a new-expression".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 24
 
- <td width="117">
+ <td width="118">
         <p>7.1.6.4<br>
 &nbsp;[auto<br>
 &nbsp;specifier]
@@ -5747,7 +5747,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Now that 'auto' is finally
         used in its most obvious sense to state `deduce the type of
         this variable from initializer', it should also be allowed
@@ -5796,17 +5796,17 @@
 
         <p style="margin-top: 0.04in"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 38
 
- <td width="117">
+ <td width="118">
         <p align="left">7.2
 
       <td width="85">
@@ -5815,24 +5815,24 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         discussion of attribute specifiers should be a separate
         paragraph.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 39
 
- <td width="117">
+ <td width="118">
         <p align="left">7.2
 
       <td width="85">
@@ -5841,7 +5841,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         paragraph says in part "An opaque-enum-declaration
         declaring an unscoped enumeration shall not omit the
@@ -5852,19 +5852,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">As this implication leaves no
         representation, it should be either affirmed here or the
         statement should be expanded. Perhaps a note is warranted.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 13
 
- <td width="117">
+ <td width="118">
         <p align="left">7.2
 
       <td width="85">
@@ -5873,7 +5873,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">In
         the description for an unscoped enumeration, enum-base in
         redeclaration must be the same underlying type as in the
@@ -5883,11 +5883,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p>Replace the description, "same underlying type", with
         "same as underlying type of (previous) declaration."
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5895,7 +5895,7 @@
         <p>UK<br>
         96
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.2
 
       <td width="85">
@@ -5904,7 +5904,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">enum E { }; What
         are the values of E? It has neither a smallest nor largest
         enumerator, so paragraph 7 doesn't help. (Paragraph 6
@@ -5914,12 +5914,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a second sentence to paragraph 7
         (before "Otherwise"): "If the enumerator-list is empty, 0
         is the only value of the enumeration."
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5927,7 +5927,7 @@
         <p>UK<br>
         97
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.2
 
       <td width="85">
@@ -5936,7 +5936,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Missing
         punctuation after "blue" in: "The possible values of an
         object of type color are red, yellow, green, blue these
@@ -5944,12 +5944,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a semicolon: "The possible values of an
         object of type color are red, yellow, green, blue; these
         values can be converted ..."
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5957,7 +5957,7 @@
         <p>UK<br>
         98
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.2
 
       <td width="85">
@@ -5966,7 +5966,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It would be
         useful to be able to determine the underlying type of an
         arbitrary enumeration type. This would allow safe casting
@@ -5977,11 +5977,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a TransformationTrait to 20.5.6 that
         returns the underlying type of an enumeration type.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -5989,7 +5989,7 @@
         <p>UK<br>
         99
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.2
 
       <td width="85">
@@ -5998,7 +5998,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is unclear
         whether an enumeration type is complete after an
         opaque-enum-declaration. This paragraph only says so in a
@@ -6008,19 +6008,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move "an enumeration declared by an
         opaque-enum-declaration ... is a complete type" from the
         note to normative text.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 14
 
- <td width="117">
+ <td width="118">
         <p align="left">7.3.1
 
       <td width="85">
@@ -6029,7 +6029,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-left: 0.2in; text-indent: -0.2in; margin-bottom: 0in">
         The description of the behavior when a member that was
@@ -6101,7 +6101,7 @@
         <p align="left" style="text-indent: 0.44in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style=
         "margin-left: 0.2in; text-indent: -0.2in; margin-bottom: 0in">
         Add the description of the behavior when a member that was
@@ -6109,7 +6109,7 @@
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6117,7 +6117,7 @@
         <p>UK<br>
         100
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.3.3
 
       <td width="85">
@@ -6126,7 +6126,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Para 10 says "A
         using-declaration is a declaration and can therefore be
         used repeatedly where (and only where) multiple
@@ -6138,11 +6138,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Delete para 10, moving its example into
         para 13.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6150,7 +6150,7 @@
         <p>UK<br>
         101
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.3.3
 
       <td width="85">
@@ -6159,7 +6159,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">If a
         using-declaration uses the keyword typename and specifies a
         dependent name (14.6.2), the name introduced by the
@@ -6171,18 +6171,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Allow typename for non-dependent names iff
         they refer to a type.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-12
 
- <td width="117">
+ <td width="118">
         <p>7.3.3
 
       <td width="85">
@@ -6191,7 +6191,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-12
         Overriding and hiding of member functions named in
@@ -6200,17 +6200,17 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 25
 
- <td width="117">
+ <td width="118">
         <p>7.3.3<br>
 &nbsp;[The using<br>
 &nbsp;declaration]
@@ -6221,11 +6221,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The syntax for concept map alias is unnecessarily both
         confused and verbose.
 
- <td width="535">
+ <td width="536">
         <p>We strongly suggest
         simplifications, e.g.
 
@@ -6237,7 +6237,7 @@
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6245,7 +6245,7 @@
         <p>UK<br>
         102
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.3.4
 
       <td width="85">
@@ -6254,7 +6254,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph
         says "If name lookup finds a declaration for a name in two
         different namespaces, and the declarations do not declare
@@ -6264,18 +6264,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the example to paragraph 7, and/or
         replace it with an appropriate example.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 40
 
- <td width="117">
+ <td width="118">
         <p align="left">7.6
 
       <td width="85">
@@ -6284,7 +6284,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         list of attributes is missing an attribute to indicate that
         a function with a <font size="2" style=
@@ -6296,17 +6296,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the attribute.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 41
 
- <td width="117">
+ <td width="118">
         <p align="left">7.6
 
       <td width="85">
@@ -6315,7 +6315,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">A
         common problem is unintentionally declaring a new virtual
         member function instead of overriding a base virtual member
@@ -6323,18 +6323,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">An attribute stating intent to
         override would enable better diagnostics.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 26
 
- <td width="117">
+ <td width="118">
         <p>7.6<p>&nbsp;[Attributes]
 
       <td width="85">
@@ -6343,24 +6343,24 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>Are they part of object types
         or not? The section does not appear to indicate that
         clearly.
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FI 1
 
- <td width="117">
+ <td width="118">
         <p>7.6
 
       <td width="85">
@@ -6369,21 +6369,21 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Add override-attribute for functions in order to avoid
         mistakes when overriding functions.
 
- <td width="535">
+ <td width="536">
         <p>See override&#173;-attribute.doc, override-attribute.ppt
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 27
 
- <td width="117">
+ <td width="118">
         <p>7.6.1
 
       <td width="85">
@@ -6392,7 +6392,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>This section specifies that
         no name lookup is performed on any identifier contained in
         an attribute-token. This in particular implies that, for
@@ -6410,10 +6410,10 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6421,7 +6421,7 @@
         <p>UK<br>
         103
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.6.1
 
       <td width="85">
@@ -6430,7 +6430,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Attributes should support pack expansion.
         For example, this would be extremely useful with the align
         attribute, directly supporting the (removed) functionality
@@ -6440,12 +6440,12 @@
         this support to attributes would remove the remaining need,
         and support similar attributes in the future.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add: attribute... to the grammar for
         attribute-list Add to list in 14.5.3p4: "In an
         attribute-list(7.6.1); the pattern is an attribute."
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6453,7 +6453,7 @@
         <p>UK<br>
         104
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.6.1
 
       <td width="85">
@@ -6462,7 +6462,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">It is helpful
         for each subclause to contain a short paragraph introducing
         its intent an purpose. 7.6 has such a paragraph, but it is
@@ -6470,11 +6470,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">7.6.1p1 should move up one level to become
         7.6p1. There grammar should remain under 7.6.1
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6482,7 +6482,7 @@
         <p>UK<br>
         105
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.6.1
 
       <td width="85">
@@ -6491,16 +6491,16 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Allowing only one level of namespaces in
         attributes seems unnecessarily limiting.
 
- <td width="535">
+ <td width="536">
         <p align="left">To: attribute-scoped-token:
         attribute-namespace :: identifier add attribute-namespace
         :: attribute-scoped-token
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6508,7 +6508,7 @@
         <p>UK<br>
         106
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.6.2
 
       <td width="85">
@@ -6517,23 +6517,23 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Extensive use of
         alignment and related terms without cross reference.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add cross-reference to 3.11.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 15
 
- <td width="117">
+ <td width="118">
         <p align="left">7.6.2
 
       <td width="85">
@@ -6542,7 +6542,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">An abbreviation
         of 7.6.2 should be &#8220;[decl.attr.align]&#8221; instead
@@ -6557,10 +6557,10 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p>Change "[dcl.align]" of 7.6.2 to "[decl.attr.align]".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6568,7 +6568,7 @@
         <p>UK<br>
         107
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.6.3
 
       <td width="85">
@@ -6577,7 +6577,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">While undefined
         behaviour might be the best we can guarantee, it would be
         helpful to encourage implementations to diagnose function
@@ -6585,13 +6585,13 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Adda a [Note : implementations are
         encouraged to issue a diagnostic where the definition of a
         function marked [[noreturn]] might execute a return
         statement -- end note]
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6599,7 +6599,7 @@
         <p>UK<br>
         108
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.6.4
 
       <td width="85">
@@ -6608,7 +6608,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is unclear
         why no diagnostic is required for an easily detectable
         violation. It is even more surprising that the associated
@@ -6616,18 +6616,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike "no diagnostic required" and the
         associated footnote.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 42
 
- <td width="117">
+ <td width="118">
         <p align="left">7.6.4
 
       <td width="85">
@@ -6636,7 +6636,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         meaning of the <font size="2" style=
         "font-size: 11pt"><code>[[final]]</code> attribute applied
@@ -6645,7 +6645,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Modify the semantics of <font size="2" style=
         "font-size: 11pt"><code>[[final]]</code> applied to
@@ -6656,7 +6656,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6664,7 +6664,7 @@
         <p>UK<br>
         109
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.6.5
 
       <td width="85">
@@ -6673,25 +6673,25 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The example code
         refers in comments to "Compilation unit" A and B. The term
         should be "Translation unit" (2/1)
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace "Compilation" with "Translation" in
         two places
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>
 
- <td width="117">
+ <td width="118">
         <p align="justify"><br>
 
       <td width="85">
@@ -6700,13 +6700,13 @@
       <td width="62">
         <p align="justify"><br>
 
- <td width="604">
+ <td width="514">
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6714,7 +6714,7 @@
         <p>UK<br>
         110
 
- <td width="117">
+ <td width="118">
         <p align="justify">7.6.5
 
       <td width="85">
@@ -6723,7 +6723,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The code in the
         example (compilation unit A) has:
         "foo_head[i].load(memory_order_consume)". foo_head[i] is of
@@ -6731,18 +6731,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change the type of foo_head to
         atomic&lt;foo *&gt;[].
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 43
 
- <td width="117">
+ <td width="118">
         <p align="left">8
 
       <td width="85">
@@ -6751,7 +6751,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         With the introduction of late-specified return types for
         functions and lambda expressions, we now have three
@@ -6763,10 +6763,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Some simplification is needed.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -6774,7 +6774,7 @@
         <p>UK<br>
         111
 
- <td width="117">
+ <td width="118">
         <p align="justify">8.3.5
 
       <td width="85">
@@ -6783,25 +6783,25 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Example missing
         closing bracket in template&lt;typename... T&gt; void f(T
         (* ...t)(int, int);
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add closing bracket like this:
         template&lt;typename... T&gt; void f(T (* ...t)(int, int));
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 44
 
- <td width="117">
+ <td width="118">
         <p align="left">8.3.5
 
       <td width="85">
@@ -6810,25 +6810,25 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">In
         the Example, "template void f(T (* ...t)(int, int);" is
         missing a close parenthesis.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">It presumably should read:
         "template void f(T (* ...t))(int, int);".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 45
 
- <td width="117">
+ <td width="118">
         <p align="left">8.3.5
 
       <td width="85">
@@ -6837,7 +6837,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">At present,
         function parameter packs can only occur at the end of a
         parameter-declaration-list. This restriction unnecessarily
@@ -6882,7 +6882,7 @@
         parameter-declaration-list should be considered non-deduced
         contexts.
 
- <td width="535">
+ <td width="536">
         <p align="left">In 8.3.5p13,
         remove the sentence &#8220;<span lang="">A function
         parameter pack, if present, shall occur at the end of the
@@ -6937,14 +6937,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-13
 
- <td width="117">
+ <td width="118">
         <p>8.4
 
       <td width="85">
@@ -6953,22 +6953,22 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-13 The second paragraph, quoting the grammar for the
         declarator of a function declaration, is not considering
         late-specified return types and attributes.
 
- <td width="535">
+ <td width="536">
         <p>Properly quote the grammar from 8.3.5.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 16
 
- <td width="117">
+ <td width="118">
         <p align="left">8.5
 
       <td width="85">
@@ -6981,24 +6981,24 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo, duplicated "in"
 
         <p align="left">"The initialization that
         occurs in in the forms"
 
- <td width="535">
+ <td width="536">
         <p>Remove one.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 46
 
- <td width="117">
+ <td width="118">
         <p align="left">8.5.3
 
       <td width="85">
@@ -7007,7 +7007,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The ability for
         an rvalue reference to bind to an lvalue opens a
         type-safety hole that becomes very dangerous with concepts.
@@ -7036,7 +7036,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Prohibit rvalue
         references from binding to lvalues.
 
@@ -7072,14 +7072,14 @@
         12.4, 12.8, but restricted to special functions in that
         comment. (See US NN).
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 49
 
- <td width="117">
+ <td width="118">
         <p align="left">8.5.4
 
       <td width="85">
@@ -7088,18 +7088,18 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">In the Example, the comments
         could be improved.
 
- <td width="535">
+ <td width="536">
         <p align="left">See
         the attached paper "Issues with the C++ Standard" under
         "Editorial Issues" and "8.5.4/6".
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -7107,7 +7107,7 @@
         <p>UK<br>
         112
 
- <td width="117">
+ <td width="118">
         <p align="justify">9
 
       <td width="85">
@@ -7116,7 +7116,7 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">We now have
         concepts that should (or should not?) map to the terms
         described in Clause 9 - these should be at least
@@ -7124,11 +7124,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add appropriate forward references to
         14.9.4
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -7136,7 +7136,7 @@
         <p>UK<br>
         113
 
- <td width="117">
+ <td width="118">
         <p align="justify">9.4.2
 
       <td width="85">
@@ -7145,23 +7145,23 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Mis-applied edit from the paper n2756
 
- <td width="535">
+ <td width="536">
         <p align="left">The term 'constant-initializer' should have
         been struck out when replaced by
         brace-or-equal-initializer. There are two occurrences in
         this paragraph
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 50
 
- <td width="117">
+ <td width="118">
         <p align="left">12.1,<br>
 &nbsp;12.4,<br>
 &nbsp;12.8
@@ -7172,7 +7172,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Implicitly-declared default constructors, destructors, copy
         constructors, and copy assignment operators are deleted
@@ -7203,7 +7203,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">In 12.1p5,
         remove the phrase &#8220;<span lang="">or inaccessible from
         the implicitly-declared default</span> <font size="3" face=
@@ -7235,14 +7235,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 28
 
- <td width="117">
+ <td width="118">
         <p>12.6.1<br>
 &nbsp;[Explicit<br>
 &nbsp;initialization]
@@ -7255,21 +7255,21 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>This section, in particular the example with `g' appears
         contradictory with the syntax for uniform initialization.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 51
 
- <td width="117">
+ <td width="118">
         <p align="left">12.6.2
 
       <td width="85">
@@ -7278,17 +7278,17 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         discussion of delegating constructors should be in its own
         paragraph.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -7296,7 +7296,7 @@
         <p>UK<br>
         114
 
- <td width="117">
+ <td width="118">
         <p align="justify">12.6.2
 
       <td width="85">
@@ -7305,7 +7305,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Despite all the attempts to unify
         initialization syntax, it is still not possible to
         copy-initialize base classes or non-static data members,
@@ -7315,7 +7315,7 @@
         mem-initializer-id and braced-init-list would allow the
         user to choose between copy and direct initialization
 
- <td width="535">
+ <td width="536">
         <p align="left">Ammend the
         grammar for mem-initializer: mem-initializer-id =OPT
         braced-init-list Extend p3 to allow for Copy Initialization
@@ -7330,14 +7330,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>US 52
 
- <td width="117">
+ <td width="118">
         <p>13.5.8
 
       <td width="85">
@@ -7346,13 +7346,13 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>A word is misspelled.
 
- <td width="535">
+ <td width="536">
         <p>Change &#8220;shal&#8221; to &#8220;shall&#8221;.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -7360,7 +7360,7 @@
         <p>UK<br>
         115
 
- <td width="117">
+ <td width="118">
         <p align="justify">14
 
       <td width="85">
@@ -7369,7 +7369,7 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">Exported
         templates were a great idea that is generally understood to
         have failed. In the decade since the standard was adopted,
@@ -7384,13 +7384,13 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Consider deprecating exported templates,
         but no action yet. Examine interaction with constrained
         templates, and see if other more appropriate mechanism will
         support compile-time optimization.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -7398,7 +7398,7 @@
         <p>UK<br>
         116
 
- <td width="117">
+ <td width="118">
         <p align="justify">14
 
       <td width="85">
@@ -7407,7 +7407,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Is it possible
         to export a concept map template? The current wording
         suggests it is possible, but it is not entirely clear what
@@ -7415,12 +7415,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Either prohibit exporting concept map
         templates, or more directly address what it means to export
         a concept map.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -7428,7 +7428,7 @@
         <p>UK<br>
         117
 
- <td width="117">
+ <td width="118">
         <p align="justify">14
 
       <td width="85">
@@ -7437,7 +7437,7 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">It would be nice
         to allow template alias within a function scope, and
         possibly a scoped concept map. As these affect name lookup
@@ -7447,11 +7447,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Allow template aliases to be declared
         inside a function scope, and consider scoped concept maps.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -7459,7 +7459,7 @@
         <p>UK<br>
         118
 
- <td width="117">
+ <td width="118">
         <p align="justify">14
 
       <td width="85">
@@ -7468,7 +7468,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Exported
         templates are a complicated feature with surprisingly
         little text. To make this important text more visible,
@@ -7476,11 +7476,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Create a new subclause [temp.export]
         containing 14p6-11. Move 14p12 ahead of this subclause.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -7488,7 +7488,7 @@
         <p>UK<br>
         119
 
- <td width="117">
+ <td width="118">
         <p align="justify">14
 
       <td width="85">
@@ -7497,7 +7497,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Does a concept
         map have linkage? Reading this paragraph and 3.5 suggests a
         concept map template has external linkage, but not a
@@ -7507,12 +7507,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add an exception that concept map templates
         have no linkage, or add concept maps to the list of
         entities with linkage in 3.5
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -7520,7 +7520,7 @@
         <p>UK<br>
         120
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.1
 
       <td width="85">
@@ -7529,7 +7529,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">As this is the
         first time the phrase &#8220;parameter pack&#8221; appears
         in Ch 14 I would like to see the section 8.3.5 referenced
@@ -7537,11 +7537,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Insert &#8220;(8.3.5)&#8221; after
         &#8220;parameter pack&#8221;
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -7549,7 +7549,7 @@
         <p>UK<br>
         121
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.1
 
       <td width="85">
@@ -7558,24 +7558,24 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The example
         (that follows the normative text) has no begin example
         marker
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Prefix the example code with "[ Example:"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 29
 
- <td width="117">
+ <td width="118">
         <p>14.3<br>
 &nbsp;[Template<br>
 &nbsp;arguments]
@@ -7588,21 +7588,21 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Constant expressions of any literal type should be
         allowed as template arguments.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 53
 
- <td width="117">
+ <td width="118">
         <p align="left">14.5.1
 
       <td width="85">
@@ -7611,7 +7611,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">If the
         requirements of a constrained member that is a copy
         constructor, copy assignment operator, or destructor are
@@ -7642,7 +7642,7 @@
         CopyConstructible, vector will get an implicitly-defined
         copy constructor that performs a copy of the pointers.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add to 14.5.1p5:
 
         <p align="left">If the constrained member is a copy
@@ -7654,7 +7654,7 @@
         template&#8217;s template arguments for its template
         parameters) will be declared as a deleted function (8.4).
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -7662,7 +7662,7 @@
         <p>UK<br>
         122
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.5.3
 
       <td width="85">
@@ -7671,7 +7671,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Variadic
         templates should be supported in axioms. There are axioms
         in the library that rely on this feature, such as the
@@ -7680,20 +7680,20 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add clarification in p2 that function
         parameter packs can be used to declare axioms, much like p1
         clarifies they can be used to declare concepts as well as
         templates.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 30
 
- <td width="117">
+ <td width="118">
         <p>14.5.7<br>
 &nbsp;[Template<br>
 &nbsp;aliases]
@@ -7704,7 +7704,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>When are two template alias
         names equivalent?
 
@@ -7743,17 +7743,17 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 17
 
- <td width="117">
+ <td width="118">
         <p align="left">14.7.2
 
       <td width="85">
@@ -7764,7 +7764,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo.
 
@@ -7789,17 +7789,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p>Replace "from" with "forming"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-14
 
- <td width="117">
+ <td width="118">
         <p>14.7.3
 
       <td width="85">
@@ -7808,22 +7808,22 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-14 The bulleted list neither addresses "member
         function template of a class" nor "member class template of
         a class".
 
- <td width="535">
+ <td width="536">
         <p>Add the respective bullets.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 18
 
- <td width="117">
+ <td width="118">
         <p align="left">14.7.3
 
       <td width="85">
@@ -7834,7 +7834,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo,
 
@@ -7857,17 +7857,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p>Replace "from" with "forming"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 19
 
- <td width="117">
+ <td width="118">
         <p align="left">14.8.2
 
       <td width="85">
@@ -7878,7 +7878,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo, duplicated "is"
 
@@ -7890,18 +7890,18 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Remove one
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 54
 
- <td width="117">
+ <td width="118">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">14.9<br>
 &nbsp;[concept],
@@ -7916,24 +7916,24 @@
       <td width="62">
         <p>ge
 
- <td width="604">
+ <td width="514">
         <p>Concepts is of course the largest new feature in C++0x
         (in terms of new text inserted into the wording), and
         already we have found some significant defects with it. So
         far nothing devastating has been found, but more time is
         needed to shake more bugs out.
 
- <td width="535">
+ <td width="536">
         <p>I propose no specific change here.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 55
 
- <td width="117">
+ <td width="118">
         <p>14.9.1
 
       <td width="85">
@@ -7942,23 +7942,23 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The paragraph number is in the wrong place, causing a
         grammar rule to be indented more than its fellows.
 
- <td width="535">
+ <td width="536">
         <p>Move the paragraph number so as to follow the grammar
         rules, thus numbering the single sentence, &#8220;The body
         of a concept &#8230; .&#8221;
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 56
 
- <td width="117">
+ <td width="118">
         <p>14.9.1
 
       <td width="85">
@@ -7967,22 +7967,22 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The sentence contains two references to 14.9.1.3
         [concept.req].
 
- <td width="535">
+ <td width="536">
         <p>Change the second such reference (at the end of the
         sentence) to 14.9.1.4 [concept.axiom].
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 57
 
- <td width="117">
+ <td width="118">
         <p>14.9.1.4
 
       <td width="85">
@@ -7991,21 +7991,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>A word is misplaced, changing the intended meaning.
 
- <td width="535">
+ <td width="536">
         <p>Change &#8220;only find &#8230; if&#8221; to &#8220;find
         &#8230; only if&#8221;.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 58
 
- <td width="117">
+ <td width="118">
         <p>14.9.1.4
 
       <td width="85">
@@ -8014,22 +8014,22 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The listed phrases are not grammatically parallel.
 
- <td width="535">
+ <td width="536">
         <p>Insert &#8220;in&#8221; before &#8220;one&#8221; so as
         to obtain &#8220;... in the concept, in one of its less
         refined concepts, or in an associated requirement.&#8221;
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 59
 
- <td width="117">
+ <td width="118">
         <p align="left">14.9.1.4
 
       <td width="85">
@@ -8038,7 +8038,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">Axioms are under-specified and provide
         little benefit to programmers, so they should be removed
         from the working paper. The optimizations permitted by
@@ -8053,7 +8053,7 @@
         that many axioms written by programmers (including those
         specified in the candidate draft) will be incorrect.
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove clause
         14.9.1.4 [concept.axiom]
 
@@ -8109,14 +8109,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 31
 
- <td width="117">
+ <td width="118">
         <p>14.9.1.4<br>
 &nbsp;[Axioms]
 
@@ -8126,7 +8126,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>This section states that an
         axiom-definition defines a new semantics axiom but is
         unusually vague as to what those semantics might be.
@@ -8151,17 +8151,17 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-15
 
- <td width="117">
+ <td width="118">
         <p>14.9.1.4
 
       <td width="85">
@@ -8170,7 +8170,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-15 There is no implementation experience for axioms.
         Use of axioms is an area of active scientific research. It
         is likely that syntax changes will become necessary to make
@@ -8180,12 +8180,12 @@
         EqualityComparable), but IEEE floating-point types have
         special values such as NaN violating the axioms.
 
- <td width="535">
+ <td width="536">
         <p>Remove section 14.9.1.4 and any reference to axioms in
         the rest of the proposed standard other than the keyword
         reservation in section 2.11.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -8193,7 +8193,7 @@
         <p>UK<br>
         123
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.9.1.4
 
       <td width="85">
@@ -8202,7 +8202,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">auto concepts
         and axioms are incompatible. An axiom defines the semantics
         of an operaton or set of operations that describes the run
@@ -8214,11 +8214,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a paragraph making axioms ill-formed
         inside an auto concept.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -8229,7 +8229,7 @@
 
         <p>
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.9.1.4
 
       <td width="85">
@@ -8238,13 +8238,13 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Spelling mistake, double-e in were.
 
- <td width="535">
+ <td width="536">
         <p align="left">weere -&gt; were
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -8252,7 +8252,7 @@
         <p>UK<br>
         125
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.9.1.4
 
       <td width="85">
@@ -8261,7 +8261,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The implicit
         equality comparison operator available to axioms has no
         semantic. It is not clear what expressing the condition if(
@@ -8273,12 +8273,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Define the semantics of the implicitly
         declared comparison operators, or restrict their usage to
         declaring equivalence between statements.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -8286,7 +8286,7 @@
         <p>UK<br>
         126
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.9.4
 
       <td width="85">
@@ -8295,18 +8295,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph
         contains the only definition of the underlying_type member
         - but it's a note, so not normative.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the second sentence to the Requires
         clause in paragraph 42.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -8314,7 +8314,7 @@
         <p>UK<br>
         127
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.9.4
 
       <td width="85">
@@ -8323,7 +8323,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Provide a
         diagram clearly showing refinement relationship between the
         different support concepts. Several were created during
@@ -8331,10 +8331,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide the diagram.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -8342,7 +8342,7 @@
         <p>UK<br>
         128
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.9.4
 
       <td width="85">
@@ -8351,13 +8351,13 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">It is surprising for many people that
         non-copyable move-only types can be used with a return
         statement, and so Returnable does not always imply
         CopyConstructible.
 
- <td width="535">
+ <td width="536">
         <p align="left">A non-normative
         note: [Note: 'move only' types that are constructible from
         rvalue references may be Returnable, but not
@@ -8365,14 +8365,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 20
 
- <td width="117">
+ <td width="118">
         <p align="left">14.9.4
 
       <td width="85">
@@ -8382,7 +8382,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-left: 0.2in; text-indent: -0.2in; margin-top: 0.04in; margin-bottom: 0.04in">
         Trivially copyable type was added in &#8220;3.9
@@ -8394,12 +8394,12 @@
         "margin-left: 0.2in; text-indent: -0.2in; margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         TriviallyCopyableType that is trivially copyable type as
         concept.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -8407,7 +8407,7 @@
         <p>UK<br>
         129
 
- <td width="117">
+ <td width="118">
         <p align="justify">14.10.1,<br>
 &nbsp;20.1.2
 
@@ -8417,7 +8417,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It should be
         possible to support boolean constant expressions as
         requirements without resorting to defining the True concept
@@ -8429,21 +8429,21 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the True concept and library
         subclause 20.1.2. Provide support in 14.10.1 for boolean
         constant expressions as constraints. This may involve
         overloading the true keyword to disambiguate but ideally
         would not.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 60
 
- <td width="117">
+ <td width="118">
         <p align="left">14.10.1
 
       <td width="85">
@@ -8452,7 +8452,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The use of &amp;&amp; as the separator for
         a list of requirements has shown itself to be a serious
         teachability problem. The mental model behind
@@ -8465,7 +8465,7 @@
         separator to &#8216;,&#8217; would eliminate a significant
         source of confusion.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace
 
         <p align="left">
@@ -8503,7 +8503,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -8511,7 +8511,7 @@
         <p>UK<br>
         130
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.1
 
       <td width="85">
@@ -8520,7 +8520,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">With the new
         crrent_exception API it is possible to capture a reference
         to an exception that will outlive its last active handler.
@@ -8532,11 +8532,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Update sentence to allow for exceptions
         held in excpetion_ptr objects.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8544,7 +8544,7 @@
         <p>UK<br>
         131
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.3
 
       <td width="85">
@@ -8553,18 +8553,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">A handler
         catching its parameter by rvalue-reference is syntactically
         valid, but will never be activated.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Disallow handlers catching by
         rvalue-reference.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8572,7 +8572,7 @@
         <p>UK<br>
         132
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.3
 
       <td width="85">
@@ -8581,7 +8581,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">There are
         obscure cases whrere a copy constructor is not usually the
         best match to copy-initialize an object, e.g. A converting
@@ -8593,11 +8593,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Rewite using copy-initialization rather
         than directly invoking the copy constructor
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8605,7 +8605,7 @@
         <p>UK<br>
         133
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.4
 
       <td width="85">
@@ -8614,18 +8614,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Template aliases
         have the same semantics as a typedef so should also be
         disallowed
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">add "or alias-declaration" after "shall not
         appear in a typedef declaration".
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8633,7 +8633,7 @@
         <p>UK<br>
         134
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.4
 
       <td width="85">
@@ -8642,19 +8642,19 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The sentance "An
         exception-specification can also include the class
         std::bad_exception (18.7.2.1)." is redundant.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Either strike the quoted sentance, or add a
         note explaining why it is worth calling special attention
         to this class.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8662,7 +8662,7 @@
         <p>UK<br>
         135
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.4
 
       <td width="85">
@@ -8671,17 +8671,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Unclear if std::unexpected is called before
         or after the function arguments have been destroyed
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify the sequence of calling unexpected
         with respect to interesting objects, such as function
         arguments or partially constructed bases and members when
         called from a constructor or destructor
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8689,7 +8689,7 @@
         <p>UK<br>
         136
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.4
 
       <td width="85">
@@ -8698,7 +8698,7 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">Exception specifications have proven close
         to worthless in practice, while adding a measurable
         overhead to programs. The feature should be deprecated. The
@@ -8707,7 +8707,7 @@
         requirement to call the runtime unexpected mechanism was
         relaxed in this case.
 
- <td width="535">
+ <td width="536">
         <p align="left">Move 15.4 and the parts of 15.5 that refer
         to it to Appendix D. Replace 15.4 with a simpler
         specification for empty throw specifications, where the
@@ -8716,7 +8716,7 @@
         checks. Ideally require vendors to provide a mode where the
         runtime checks are always disabled.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8724,7 +8724,7 @@
         <p>UK<br>
         137
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.5
 
       <td width="85">
@@ -8733,7 +8733,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">There is no
         mention of the current_exception API which can extend the
         lifetime of an exception object. There should at least be a
@@ -8741,12 +8741,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add another paragraph outlining 18.7.5 and
         the ability of an exception_ptr to extend the lifetime of
         an exception object
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8754,7 +8754,7 @@
         <p>UK<br>
         138
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.5.1
 
       <td width="85">
@@ -8763,18 +8763,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The third bullet
         is redundant with the first, as it is a subset of the same
         conditions.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Merge the third bullet into the first
         bullet as a note or example.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8782,7 +8782,7 @@
         <p>UK<br>
         139
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.5.1
 
       <td width="85">
@@ -8791,7 +8791,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">According to the
         first bullet it is perfectly alright for a library function
         to exit by throwing an exception during stack unwinding,
@@ -8799,11 +8799,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the word 'user' from the first
         bullet point.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8811,7 +8811,7 @@
         <p>UK<br>
         140
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.5.2
 
       <td width="85">
@@ -8820,7 +8820,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The detailed
         specification can fool people into thinking an exception
         will automatically be translated into bad_exception, where
@@ -8829,12 +8829,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a note highlighting the default
         behaviour of std::unexpected if the user does not supply a
         hander-function
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8842,7 +8842,7 @@
         <p>UK<br>
         141
 
- <td width="117">
+ <td width="118">
         <p align="justify">15.6
 
       <td width="85">
@@ -8851,16 +8851,16 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This whole
         subclause is redundant due to 15.1p5 and 15.3p17
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike 15.6
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8868,7 +8868,7 @@
         <p>UK<br>
         142
 
- <td width="117">
+ <td width="118">
         <p align="justify">16.3.5
 
       <td width="85">
@@ -8877,16 +8877,16 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph
         opens with "[ Note" but has no corresponding "end note ]"
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add "end note ]"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -8894,7 +8894,7 @@
         <p>UK<br>
         143
 
- <td width="117">
+ <td width="118">
         <p align="justify">16.3.5
 
       <td width="85">
@@ -8903,20 +8903,20 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Example uses #define t(x,y.z) x ## y ## z
 
- <td width="535">
+ <td width="536">
         <p align="left">Change "x,y.z" to "x,y,z"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 2
 
- <td width="117">
+ <td width="118">
         <p align="left">17-30
 
       <td width="85">
@@ -8925,7 +8925,7 @@
       <td width="62">
         <p align="left">ge/te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         active issues identified in WG21 N2806, C++ Standard
         Library Active Issues, must be addressed and appropriate
@@ -8941,20 +8941,20 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Appropriate action would
         include making changes to the CD, identifying an issue as
         not requiring a change to the CD, or deferring the issue to
         a later point in time.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Acknowledged<tr valign="top">
       <td width="29">
         <p>FR 2
 
- <td width="117">
+ <td width="118">
         <p>General<br>
 &nbsp;Comment
 
@@ -8964,21 +8964,19 @@
       <td width="62">
         <p>ge
 
- <td width="604">
+ <td width="514">
         <p>The adoption of the library `constexpr' proposal was not
         reflected in the draft, despite formal WG21 committee vote.
 
- <td width="535">
+ <td width="536">
         <p>FR 2
 
- <td width="89">
- <p>General Comment
-
- <tr valign="top">
+ <td width="178">
+ <p>Editorial; sent to Pete Becker<tr valign="top">
       <td width="29">
         <p align="left">US 61
 
- <td width="117">
+ <td width="118">
         <p align="left">17 onward
 
       <td width="85">
@@ -8987,12 +8985,12 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p>The concepts core language feature is applied to only
         some of the Standard Library clauses, and even then not
         always consistently.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Review all
         clauses of the Standard Library, and consistently apply
@@ -9002,14 +9000,14 @@
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agreed. Duplicates CA2<tr valign="top">
       <td width="29">
         <p>CA-2
 
- <td width="117">
+ <td width="118">
         <p style="margin-top: 0.04in">17 Library
 
       <td width="85">
@@ -9018,25 +9016,25 @@
       <td width="62">
         <p>Ge
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         &#8220;Concepts&#8221; are a significant new addition to
         the language, but are not exploited uniformly in the
         library as documented in CD 14882.
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Fix
         the standard library so that &#8220;Concepts&#8221; are
         used appropriately in the library.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agreed; We intend to address this.<tr valign="top">
       <td width="29">
         <p align="left">US 62
 
- <td width="117">
+ <td width="118">
         <p align="left">17-30
 
       <td width="85">
@@ -9045,23 +9043,23 @@
       <td width="62">
         <p align="left">ge
 
- <td width="604">
+ <td width="514">
         <p align="left">Provide concepts
         and requirements clauses for all standard library templates
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Agreed. Duplicates CA2<br>
 
     <tr valign="top">
       <td width="29">
         <p>US 63
 
- <td width="117">
+ <td width="118">
         <p style="margin-top: 0.04in; margin-bottom: 0.04in">17-30
 
         <p>
@@ -9072,7 +9070,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The behavior of the library in the presence of threads
         is incompletely specified.
 
@@ -9086,17 +9084,19 @@
         at() to different characters in the same non-const string
         really introduce a data race?
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ 17 SG: should go to threads group; misclassified in document<p>
+
+ Concurrency SG: Create an issue. Hans will look into it.<tr valign="top">
       <td width="29">
         <p>DE-2
 
- <td width="117">
+ <td width="118">
         <p>17 through 30
 
       <td width="85">
@@ -9105,7 +9105,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-2 Marking a constructor with "explicit" has semantics
         even for a constructor with zero or several parameters:
         Such a constructor cannot be used with list-initialization
@@ -9113,20 +9113,20 @@
         standard library apparently has not been reviewed for
         marking non-single-parameter constructors as "explicit".
 
- <td width="535">
+ <td width="536">
         <p>Consider marking zero-parameter and multi-parameter
         constructors "explicit" in classes that have at least one
         constructor marked "explicit" and that do not have an
         initializer-list constructor.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Robert Klarer to address this one<tr valign="top">
       <td width="29">
         <p>JP 21
 
- <td width="117">
+ <td width="118">
         <p align="left">
         <br>
 
@@ -9147,7 +9147,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Support of char16_t/char32_t is insufficient. The basic_xxx
         classes of &lt;iostream&gt;, &lt;fstream&gt;,
@@ -9158,7 +9158,7 @@
         Functions such as stoi, to_string in &#8216;21.4 Numeric
         Conversion&#8217; does not support char16_t/char32_t types.
 
- <td width="535">
+ <td width="536">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Add commented
         lines corresponding to char16_t, char32_t.
@@ -9958,15 +9958,17 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Previously considered; we decided not to do it. We believe it is not too
+ onerous to use wbuffer_convert and wstring_convert which were added as
+ intermediaries to avoid proliferation of types.<tr valign="top">
       <td width="29">
         <p>UK<br>
         144
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.1
 
       <td width="85">
@@ -9975,15 +9977,15 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">List of contents of library should be
         extened to cover new clauses
 
- <td width="535">
+ <td width="536">
         <p align="left">Add "regular expressions, atomic operations
         and threads"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -9991,7 +9993,7 @@
         <p>UK<br>
         145
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.1
 
       <td width="85">
@@ -10000,18 +10002,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         <span lang="en-US">Summary of numeric facilities should
         mention random numbers</span>
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add random number framework to the list of
         library facilities
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10019,7 +10021,7 @@
         <p>UK<br>
         146
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.1
 
       <td width="85">
@@ -10028,15 +10030,15 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Add a summary paragraph for regular
         expressions
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a summary paragraph for regular
         expressions
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10044,7 +10046,7 @@
         <p>UK<br>
         147
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.1
 
       <td width="85">
@@ -10053,13 +10055,13 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Add a summary paragraph for threads
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a summary paragraph for threads
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10067,7 +10069,7 @@
         <p>UK<br>
         148
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.2
 
       <td width="85">
@@ -10076,7 +10078,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Table 12 is
         mentioned in and relates to section 17.2, but has been
         pushed down to appear directly after the title of section
@@ -10084,11 +10086,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Make sure tables are rendered in the
         section to which they relate.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10096,7 +10098,7 @@
         <p>UK<br>
         149
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.3
 
       <td width="85">
@@ -10105,19 +10107,19 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">For consistency
         with narrow-oriented and wide-oriented streams, we should
         add terms for streams of Unicode character sequences
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Define Utf16-oriented stream classes and
         Uft32-oriented stream classes for streams of
         char16_t/char32_t values.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10125,7 +10127,7 @@
         <p>UK<br>
         150
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.3
 
       <td width="85">
@@ -10134,7 +10136,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The addition of move semantics to the
         language means that many library APIs leave an object in a
         safely-destructible state, where no other operations can
@@ -10144,7 +10146,7 @@
         with singular iterators suggest the term 'singular object'
         or 'the object is in a singular state'.
 
- <td width="535">
+ <td width="536">
         <p align="left">Define 'singular
         state' such that an object with a singular state can only
         be assigned to or safely destroyed. Assiging a new value
@@ -10159,7 +10161,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10167,7 +10169,7 @@
         <p>UK<br>
         151
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.3.1
 
       <td width="85">
@@ -10176,17 +10178,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Missing
         crossreference to 17.3.17 [defns.repositional.stream]
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add cross-reference in the existing empty
         brackets
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10194,7 +10196,7 @@
         <p>UK<br>
         152
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.3.12
 
       <td width="85">
@@ -10203,7 +10205,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Object state is
         using a definition of object (instance of a class) from
         outside the standard, rather than the 'region of storage'
@@ -10211,18 +10213,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify terms and usage
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ we think we're removing this; Howard to create LWG issue. Howard, see [func.referenceclosure.cons]<tr valign="top">
       <td width="29">
         <p>UK<br>
         153
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.3.17
 
       <td width="85">
@@ -10231,7 +10233,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">If a
         repositional stream can only seek to a position previously
         encountered, then an arbitrary-positional-stream cannot
@@ -10239,14 +10241,14 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the word 'only'. A note might be
         added to reinforce the intent
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ editorial; sent to Pete Becker<tr valign="top">
       <td width="29">
         <p align="justify" style=
         "margin-right: -0.18in; margin-bottom: 0in">UK<br>
@@ -10254,7 +10256,7 @@
 
         <p>
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.3.20
 
       <td width="85">
@@ -10263,14 +10265,14 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Missing definition of a stable partition
         algorithm
 
- <td width="535">
+ <td width="536">
         <p align="left">Add definition from 25.2.12p7
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10278,7 +10280,7 @@
         <p>UK<br>
         155
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.3.3
 
       <td width="85">
@@ -10287,15 +10289,15 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Add clause 28 to list that use this
         definition of character
 
- <td width="535">
+ <td width="536">
         <p align="left">Add clause 28 to list that use this
         definition of character
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10303,7 +10305,7 @@
         <p>UK<br>
         156
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.3.4
 
       <td width="85">
@@ -10312,18 +10314,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Add regular
         expressions to set of templates using character container
         type
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add regular expressions to set of templates
         using character container type
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10331,7 +10333,7 @@
         <p>UK<br>
         157
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.2.2
 
       <td width="85">
@@ -10340,7 +10342,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Add concepts to
         the ordered list of presentation
 
@@ -10348,10 +10350,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add concepts into the sequence
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10359,7 +10361,7 @@
         <p>UK<br>
         158
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.2.2
 
       <td width="85">
@@ -10368,17 +10370,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">templates are neither classes nor functions
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace
         'classes' and 'functions' with 'classes and class
         templates' and 'functions and function templates'
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10386,7 +10388,7 @@
         <p>UK<br>
         159
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.2.4
 
       <td width="85">
@@ -10395,18 +10397,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This informative
         footnote was relevant in 1998, not 2008. The term 'existing
         vendors' may imply something different now
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the footnote, or replace 'existing'
         with 'original' or similar
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10414,7 +10416,7 @@
         <p>UK<br>
         160
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.2.4
 
       <td width="85">
@@ -10423,7 +10425,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">requires is now
         a keyword with a specific meaning related to concepts, and
         its use in library specifcation may be confusing. Generally
@@ -10435,10 +10437,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace 'Requires' with 'Preconditions'
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10446,7 +10448,7 @@
         <p>UK<br>
         161
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.2.4
 
       <td width="85">
@@ -10455,7 +10457,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph
         is redundant as the definition of the term 'handler
         function' is already provided in 17.3. Are we in danger of
@@ -10464,10 +10466,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike 17.5.2.4p4
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10475,7 +10477,7 @@
         <p>UK<br>
         162
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.2.4
 
       <td width="85">
@@ -10484,7 +10486,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Clause 30 makes
         use of a 'Synchronization' semantic element, that
         frequently appears either between Effects: and
@@ -10492,12 +10494,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add 'Synchronization' to the list either
         between Effects: and Postconditions:, or between Returns:
         and Throws:.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10505,7 +10507,7 @@
         <p>UK<br>
         163
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.2.4
 
       <td width="85">
@@ -10514,7 +10516,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Many functions
         are defined as "Effects: Equivalent to a...", which seems
         to also define the preconditions, effects, etc. But this is
@@ -10522,19 +10524,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Introduce an explicit "Equivalent to",
         which defines all of the properties of the function.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Tom Plum to open LWG issue; we believe this is related to LWG625<tr valign="top">
       <td width="29">
         <p>UK<br>
         164
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.3.2.1
 
       <td width="85">
@@ -10543,13 +10545,13 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This phrasing predates concepts. While this
         kind of description is still used, the examples provided
         are now all concepts, and should be replaced with
         appropriate examples
 
- <td width="535">
+ <td width="536">
         <p align="left">Use better names
         for the examples. Ideally totally replace the need by
         constraining all templates in library, so that real
@@ -10558,7 +10560,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10566,7 +10568,7 @@
         <p>UK<br>
         165
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.3.2.2,<br>
 &nbsp;17.5.3.2.3
 
@@ -10576,7 +10578,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">constraints on
         bitmask and enumation types were supposed to be tightened
         up as part of the motivation for the constexpr feature -
@@ -10584,19 +10586,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Adopt wording in line with the motivation
         described in N2235
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Robert Klarer to review<tr valign="top">
       <td width="29">
         <p>UK<br>
         166
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.3.2.4.1,<br>
 &nbsp;17.5.3.3
 
@@ -10608,14 +10610,14 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">List of library clauses should go up to 30,
         not 27
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace initial refernce to ch27 with ch30
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10623,7 +10625,7 @@
         <p>UK<br>
         167
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.5.3.4<br>
 &nbsp;Private<br>
 &nbsp;members
@@ -10634,17 +10636,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Comment marker in wrong place.
 
- <td width="535">
+ <td width="536">
         <p align="left">Change: //
         streambuf* sb; exposition only to streambuf* sb; //
         exposition only To reflect actual usage.
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10652,7 +10654,7 @@
         <p>UK<br>
         168
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.2.2
 
       <td width="85">
@@ -10661,7 +10663,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">We should make
         it clear (either by note or normatively) that namespace std
         may contain inline namespaces, and that entities specified
@@ -10672,21 +10674,22 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace "namespace std or namespaces nested
         within namespace std" with "namespace std or namespaces
         nested within namespace std or inline namespaces nested
         directly or indirectly within namespace std"
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Howard will create issue to adopt UK words (some have reservations whether
+ it is correct)<tr valign="top">
       <td width="29">
         <p>UK<br>
         169
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.2.2
 
       <td width="85">
@@ -10695,7 +10698,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This phrasing
         contradicts later freedom to implement the C standard
         library portions in the global namespace as well as std.
@@ -10703,18 +10706,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Resolve conflict in either place
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Bill Plaugher to open issue. If the wording is too broad we need to add an
+ exception to the standard C library.<tr valign="top">
       <td width="29">
         <p>UK<br>
         170
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.2.3
 
       <td width="85">
@@ -10723,7 +10727,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">One of goals of
         C++0x is to make language easier to teach and for
         'incidental' programmers. The fine-grained headers of the
@@ -10735,22 +10739,25 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a new header &lt;std&gt; that has the
         effect of including everything in tables 13 and 14, except
         &lt;iosfwd&gt; and &lt;cassert&gt;. Add an additional
         header &lt;fwd&gt; that adds all declarations from
         &lt;std&gt; but no definitions.
 
- <td width="89">
+ <td width="178">
         <p>
 
+ Alisdair to open issue. We prefer
+ <std>only. </std>
+
     <tr valign="top">
       <td width="29">
         <p>UK<br>
         171
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.2.4
 
       <td width="85">
@@ -10759,7 +10766,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Does
         freestanding implementation require a full implementation
         of all listed headers? The reference to abort, at_exit and
@@ -10770,12 +10777,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Either strike the references to abort,
         at_exit and exit, or clarify which headers only require
         partial support.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10783,7 +10790,7 @@
         <p>UK<br>
         172
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.2.4
 
       <td width="85">
@@ -10792,25 +10799,26 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">No reference to
         new functions quick_exit and at_quick_exit
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add reference to quick_exit and
         at_quick_exit
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ NAD. We do not belive at_exit and at_quick_exit should be required by
+ freestanding implementations.<tr valign="top">
       <td width="29">
         <p>UK<br>
         173
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.2.4
 
       <td width="85">
@@ -10819,25 +10827,26 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         &lt;initializer_list&gt; is missing from headers required
         in freestanding implementations.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add 18.8, initializer lists,
         &lt;initializer_list&gt;, to the end of the table.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ LWG is interested in N2814, but we're concerned whether CWG will accept
+ language recommendations.<tr valign="top">
       <td width="29">
         <p>JP 23
 
- <td width="117">
+ <td width="118">
         <p align="left">17.6.2.4
 
       <td width="85">
@@ -10847,7 +10856,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">There is a
         freestanding implementation including &lt;type_traits&gt;,
@@ -10861,20 +10870,23 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         &lt;type_traits&gt;, &lt;array&gt;, &lt;ration&gt; to Table
         15.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ LWG is interested in N2814, but we're concerned whether CWG will accept
+ language recommendations.<p>
+
+ add &lt;type_traits&gt; only. Alisdair will draft an issue.<tr valign="top">
       <td width="29">
         <p>UK<br>
         174
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.3.2
 
       <td width="85">
@@ -10883,7 +10895,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The phrasing is
         mildly ambiguous when using the word 'it' to refer back to
         the header - an unfotunate reading might confuse it with
@@ -10892,13 +10904,13 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace 'the first reference to any of the
         entities declared in that header by the translation unit'
         with 'the first reference to any of the entities that
         header declares in the translation unit'
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10906,7 +10918,7 @@
         <p>UK<br>
         175
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.4.2.1
 
       <td width="85">
@@ -10915,25 +10927,25 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Local types can
         now be used to instantiate templates, but don't have
         external linkage
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the reference to external linkage
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ we accept the proposed solution. Martin will draft an issue.<tr valign="top">
       <td width="29">
         <p>UK<br>
         176
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.4.3.3
 
       <td width="85">
@@ -10944,14 +10956,14 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Reference to namespace ::std should be
         17.6.4.2
 
- <td width="535">
+ <td width="536">
         <p align="left">Change referfence from 17.6.4.3 to 17.6.4.2
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10959,7 +10971,7 @@
         <p>UK<br>
         177
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.4.3.4
 
       <td width="85">
@@ -10968,17 +10980,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Sentence is
         redundant as double underscores are reserved in all
         contexts by 17.6.4.3.3
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the sentence
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -10986,7 +10998,7 @@
         <p>UK<br>
         178
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.4.8
 
       <td width="85">
@@ -10995,16 +11007,16 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The last sentence of the third bullet
         "Operations on such types can report a failure by throwing
         an exception unless otherwise specified" is redundant as
         behaviour is already undefined.
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the sentence
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11012,7 +11024,7 @@
         <p>UK<br>
         179
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.4.8
 
       <td width="85">
@@ -11021,7 +11033,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">According to the
         4th bullet there is a problem if "if any replacement
         function or handler function or destructor operation throws
@@ -11030,17 +11042,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace the word 'throws' with 'propogates'
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agreed. Alisdair will draft an issue.<tr valign="top">
       <td width="29">
         <p>JP 22
 
- <td width="117">
+ <td width="118">
         <p align="left">17.6.5.7
 
       <td width="85">
@@ -11051,7 +11063,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         statement below describes relation among two or more
         threads using words &#8220;between threads&#8221;:<br>
@@ -11065,7 +11077,7 @@
         such case, &#8220;among&#8221; is preferred instead of
         &#8220;between&#8221;.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Change "between threads" to "among threads".
 
@@ -11073,7 +11085,7 @@
         There are same cases in 17.6.1 paragraph 2, 17.6.5.7
         paragraph 6, 30.1 paragraph 1, 30.3.1 paragraph 1 also.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11081,7 +11093,7 @@
         <p>UK<br>
         180
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.5.10
 
       <td width="85">
@@ -11090,7 +11102,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It should not be
         possible to strengthen the exception specification for
         virtual functions as this could break user code. Note this
@@ -11101,19 +11113,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add restriction that exception
         specification of virtual functions cannot be tightened.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ NAD, the standard already has the desired restriction.<tr valign="top">
       <td width="29">
         <p>UK<br>
         181
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.5.10
 
       <td width="85">
@@ -11122,7 +11134,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This footnote is
         wrong. C library functions do not have any exception
         specification, but might be treated as if they had an empty
@@ -11130,20 +11142,21 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify that this note does not mean the
         functions are genuinely declared with the specification,
         but are treated as-if.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ We agree that the footnote is wrong and it will be removed. Pete will handle
+ as editorial.<tr valign="top">
       <td width="29">
         <p>UK<br>
         182
 
- <td width="117">
+ <td width="118">
         <p align="justify">17.6.5.10
 
       <td width="85">
@@ -11152,7 +11165,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is very
         helpful to assume all exceptions thrown by the standard
         library derive from std::exception. The 'encouragement' of
@@ -11160,18 +11173,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Make this footnote normative
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ NAD. We cannot mandate all standard-library functions that might use some
+ third-party library.<tr valign="top">
       <td width="29">
         <p>UK<br>
         184
 
- <td width="117">
+ <td width="118">
         <p align="justify">18 -&gt; 30
 
       <td width="85">
@@ -11180,7 +11194,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The new
         alias-declaration syntax is generally easier to read than a
         typedef declaration. This is especially true for complex
@@ -11188,19 +11202,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace all typedef declarations in the
         standard library with alias-declarations, except in the
         standard C library.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 24
 
- <td width="117">
+ <td width="118">
         <p align="left">18
 
       <td width="85">
@@ -11210,7 +11224,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Subclauses are listed in Table 16 as:
 
@@ -11226,7 +11240,7 @@
         "text-indent: 0.06in; margin-top: 0.04in">"18.7 Exception
         handling &#8230;".
 
- <td width="535">
+ <td width="536">
         <p align="left" style=
         "margin-left: 0.06in; text-indent: -0.06in; margin-bottom: 0in">
         Sort them in the increasing order<br>
@@ -11243,14 +11257,14 @@
         <p align="left" style=
         "text-indent: 0.06in; margin-top: 0.04in"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 25
 
- <td width="117">
+ <td width="118">
         <p align="left">18.1
 
       <td width="85">
@@ -11263,24 +11277,24 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         max_align_t is described in 18.1, so add 3.11 Alignment as
         the reference.
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         "<u>3.11, Alignment</u><font color="#000000">" to</font>
         <font size="2" style="font-size: 11pt">SEE ALSO.</font>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 32
 
- <td width="117">
+ <td width="118">
         <p>18.2.1<br>
 &nbsp;[Numeric<br>
 &nbsp;limits]
@@ -11291,7 +11305,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The definition of
         numeric_limits&lt;&gt; as requiring a regular type is both
         conceptually wrong and operationally illogical. As we
@@ -11304,21 +11318,21 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p>We suggest that a more pragmatic approach, in the spirit
         of C and C++, be taken so that calls to constrained
         function templates are interpreted as assertions on
         *values*, not necessarily semantics assertions on the
         carrier type.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-16
 
- <td width="117">
+ <td width="118">
         <p>18.2.1
 
       <td width="85">
@@ -11327,7 +11341,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-16 The class
         template numeric_limits should not specify the Regular
@@ -11342,18 +11356,18 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p>Specify a concept requirement with fewer constraints as
         appropriate, for example SemiRegular.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 26
 
- <td width="117">
+ <td width="118">
         <p align="left">18.2.1.1
 
       <td width="85">
@@ -11362,11 +11376,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         numeric_limits does not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -11408,14 +11422,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-17
 
- <td width="117">
+ <td width="118">
         <p>18.2.6
 
       <td width="85">
@@ -11424,7 +11438,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-17 The class
         type_index should be removed; it provides no additional
@@ -11432,12 +11446,12 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p>Specify concept maps for "const type_info *" as required
         by the ordered and unordered containers and remove the
         class type_index.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11445,7 +11459,7 @@
         <p>UK<br>
         185
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.3.1
 
       <td width="85">
@@ -11454,24 +11468,24 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">There is no
         header &lt;stdint&gt;, it should either be &lt;stdint.h&gt;
         or &lt;cstdint&gt;
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace &lt;stdint&gt; with &lt;cstdint&gt;
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-18
 
- <td width="117">
+ <td width="118">
         <p>18.4
 
       <td width="85">
@@ -11480,7 +11494,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-18 The
         proposed C++ standard makes a considerable number of
@@ -11502,14 +11516,14 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p>Consider applying the changes proposed in WG21 document
         N2693 "Requirements on programs and backwards
         compatibility", available at
         http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html
         .
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11517,7 +11531,7 @@
         <p>UK<br>
         186
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.4
 
       <td width="85">
@@ -11526,7 +11540,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">What is the
         purpose of this comment? The standard stream objects (cin,
         cerr etc.) have a peculiar lifetime that extends beyond the
@@ -11535,10 +11549,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the footnote
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11546,7 +11560,7 @@
         <p>UK<br>
         187
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.4
 
       <td width="85">
@@ -11555,18 +11569,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The term "thread
         safe" is not defined nor used in this context anywhere else
         in the standard.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify the intended meaing of "thread
         safe"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11574,7 +11588,7 @@
         <p>UK<br>
         188
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.4
 
       <td width="85">
@@ -11583,7 +11597,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The function
         _Exit does not appear to be defined in this standard.
         Should it be added to the table of functions
@@ -11591,10 +11605,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Depends on where _Exit comes from
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11602,7 +11616,7 @@
         <p>UK<br>
         189
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.4, 18.7
 
       <td width="85">
@@ -11611,12 +11625,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The addition of the [[noreturn]] attribute
         to the language will be an important aid for static
         analysis tools.
 
- <td width="535">
+ <td width="536">
         <p align="left">The following
         functions should be declared in C++ with the [[noreturn]]
         attribute: abort exit quick_exit terminate unexpected
@@ -11624,14 +11638,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 27
 
- <td width="117">
+ <td width="118">
         <p align="left">18.4, 18.9,<br>
 &nbsp;18.7.2.2,<br>
 &nbsp;18.7.3.1
@@ -11642,13 +11656,13 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         There are Standard library functions that never return to
         the caller. They are explained so in the Standard but not
         declared explicitly.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Consider to add the attribute [[noreturn]] to such
         functions,
@@ -11673,7 +11687,7 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11681,7 +11695,7 @@
         <p>UK<br>
         190
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.5.1
 
       <td width="85">
@@ -11690,19 +11704,19 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is not entirely clear how the current
         specification acts in the presence of a garbage collected
         implementation.
 
- <td width="535">
+ <td width="536">
         <p align="left">All deallocation
         functions taking a pointer parameter should have a
         Precondition : ptr is a safely-derived pointer value.
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11710,7 +11724,7 @@
         <p>UK<br>
         191
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.5.1.1
 
       <td width="85">
@@ -11719,12 +11733,12 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">According to the second bullet, behaviour
         becomes undefined (for lack of a specification) if the user
         has not yet called set_new_handler.
 
- <td width="535">
+ <td width="536">
         <p align="left">Rephrase the
         second bullet in terms of a new handler being installed,
         and update any definition of handler function necessary to
@@ -11732,7 +11746,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11740,7 +11754,7 @@
         <p>UK<br>
         192
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.5.1.2
 
       <td width="85">
@@ -11749,7 +11763,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The declared
         signature is not compatible with the current requirement to
         throw std::length_error. It is too late to weaken the
@@ -11759,11 +11773,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Fix 5.3.4p7 by required std::bad_alloc
         rather than std::length_error
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11771,7 +11785,7 @@
         <p>UK<br>
         193
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.5.2.2
 
       <td width="85">
@@ -11780,18 +11794,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">quick_exit has
         been added as a new valid way to terminate a program in a
         well defined way
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change 3rd bullet: call either abort(),
         exit() or quick_exit();
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11799,7 +11813,7 @@
         <p>UK<br>
         194
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.6
 
       <td width="85">
@@ -11808,7 +11822,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The inclusion of
         type_index and hash&lt;type_index&gt; in &lt;typeinfo&gt;
         brings dependencies into &lt;typeinfo&gt; which are
@@ -11817,19 +11831,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move type_index and hash&lt;type_index&gt;
         out of &lt;typeinfo&gt; and into a new header,
         &lt;typeindex&gt;.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 28
 
- <td width="117">
+ <td width="118">
         <p align="left">18.6,<br>
 &nbsp;18.7,<br>
 &nbsp;19.1
@@ -11840,7 +11854,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Errors reported by Exception classes are of types char or
         std::string only. For example, std::exception is declared
@@ -11850,18 +11864,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Consider other types.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 29
 
- <td width="117">
+ <td width="118">
         <p align="left">18.7.6
 
       <td width="85">
@@ -11870,11 +11884,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         throw_with_nested does not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -11897,14 +11911,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 30
 
- <td width="117">
+ <td width="118">
         <p align="left">18.7.6
 
       <td width="85">
@@ -11913,25 +11927,25 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">To
         handle nested exceptions strictly, error information of
         tree structure will be required though, the
         nested_exception does not support tree structure. It is
         insufficient as error handling.
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Consider nested_exception to support tree structure.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 31
 
- <td width="117">
+ <td width="118">
         <p align="left">18.7.6
 
       <td width="85">
@@ -11940,12 +11954,12 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">It
         is difficult to understand in which case nested_exception
         is applied.
 
- <td width="535">
+ <td width="536">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Consider to add
         a sample program which rethrows exception.
@@ -11953,7 +11967,7 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11961,7 +11975,7 @@
         <p>UK<br>
         195
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.8
 
       <td width="85">
@@ -11970,7 +11984,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The class
         definition of std::initializer_list contains concept-maps
         to Range which should be out of the class, and in
@@ -11980,11 +11994,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Delete the two concept maps from
         std::initializer_list.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -11992,7 +12006,7 @@
         <p>UK<br>
         196
 
- <td width="117">
+ <td width="118">
         <p align="justify">18.8.3
 
       <td width="85">
@@ -12001,12 +12015,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Concept maps for initializer_list to Range
         should not be in language support headers, but instead in
         iterator concepts.
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove section
         18.8.3 and put it in 24.1.8.1 instead, so that the
         concept_maps from initializer_list to Range are specified
@@ -12016,7 +12030,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -12024,7 +12038,7 @@
         <p>UK<br>
         197
 
- <td width="117">
+ <td width="118">
         <p align="justify">19
 
       <td width="85">
@@ -12033,13 +12047,13 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">All the exception classes in this clause
         take a std::string argument by const reference. They should
         all be overloaded to accept std::string by rvalue rerefence
         for an efficient move as well.
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide a
         constructor for every exception class in clause 19
         accepting a std::string by rvalue reference, with the
@@ -12047,14 +12061,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 32
 
- <td width="117">
+ <td width="118">
         <p align="left">19.1
 
       <td width="85">
@@ -12063,7 +12077,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Messages returned by the member function what() of standard
         exception classes seem difficult to judge.
@@ -12104,19 +12118,19 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Consider to add footnote that recommends what() returns
         message easy to recognize what exception was thrown.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 64
 
- <td width="117">
+ <td width="118">
         <p>19.3
 
       <td width="85">
@@ -12125,13 +12139,13 @@
       <td width="62">
         <p>Ge
 
- <td width="604">
+ <td width="514">
         <p><font color="#000000">&#8220;</font> See also: ISO C
         7.1.4, 7.2, Amendment 1 4.3.<font color="#000000">&#8221;
         It is unclear why this cross reference is here. Amendment 1
         was to C89, not C99.</font>
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Delete this
         cross reference. If necessary, expand the main text to
@@ -12139,14 +12153,17 @@
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ The statement made in the comment was already aired prior to the last vote.
+ Without further input, the committee cannot remove a feature that was voted
+ into the draft. We will look at this comment in the light of N2829, which
+ attempts to make scoped allocators less intrusive.<tr valign="top">
       <td width="29">
         <p align="left">US 65
 
- <td width="117">
+ <td width="118">
         <p align="left">20
 
       <td width="85">
@@ -12155,7 +12172,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">Scoped allocators and
         allocator propagation traits add a small amount of utility
         at the cost of a great deal of machinery. The machinery is
@@ -12163,7 +12180,7 @@
         don't have any obvious connection to allocators, including
         basic concepts and simple components like pair and tuple.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Sketch of proposed resolution: Eliminate scoped allocators,
         replace allocator propagation traits with a simple uniform
@@ -12189,7 +12206,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -12197,7 +12214,7 @@
         <p>UK<br>
         198
 
- <td width="117">
+ <td width="118">
         <p align="justify">20
 
       <td width="85">
@@ -12206,12 +12223,12 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The organization of clause 20 could be
         improved to better group related items, making the standard
         easier to navigate.
 
- <td width="535">
+ <td width="536">
         <p align="left">20.6.7, 20.6.8,
         20.6.9 and 20.6.10 should be grouped under a section called
         "operator wrappers" or similar. The goal of all 4
@@ -12244,15 +12261,16 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree that this is editorial -- forward to project editor. (effective
+ duplicate of US 69)<tr valign="top">
       <td width="29">
         <p>UK<br>
         199
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.1.1, 20.1.2
 
       <td width="85">
@@ -12261,7 +12279,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The requirement
         that programs do not supply concept_maps should probably be
         users do not supply their own concept_map specializations.
@@ -12273,18 +12291,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace the term 'program' with 'user'.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree change 'program' to 'user' in clauses 20.1.1 and 20.1.2<tr valign="top">
       <td width="29">
         <p>UK<br>
         200
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.1.4
 
       <td width="85">
@@ -12293,12 +12311,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">All standard library use expects Predicates
         to be CopyConstructible, and this should be recognised
         easily without reatedly stating on every use-case.
 
- <td width="535">
+ <td width="536">
         <p align="left">Either require
         CopyConstructible&lt;F&gt; as part of Predicate, or create
         a refined concept, StdPredicate, used throughout the
@@ -12307,15 +12325,20 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ We agree that adding constraints to predicate is a good idea. Predicate
+ should be further constrained, rather than creating a new StdPredicate to
+ avoid the need users to constantly choose between them. At a minimum,
+ Predicate should refine MoveConstructible. However, upon review of existing
+ library components, CopyConstructible or even SemiRegular might be more
+ appropriate for Predicate.<tr valign="top">
       <td width="29">
         <p>UK<br>
         201
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.1.5
 
       <td width="85">
@@ -12324,11 +12347,11 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The Consistency axiom for
         LessThanComparable will not compile.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a requires
         clause to the Consistency axiomL requires
         HasLessEquals&lt;T&gt; &amp;&amp;
@@ -12338,14 +12361,15 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ After consultation with the submitter, we agreed that the suggestion was in
+ error and there is nothing else to be done.<tr valign="top">
       <td width="29">
         <p>JP 33
 
- <td width="117">
+ <td width="118">
         <p align="left">20.1.5
 
       <td width="85">
@@ -12354,12 +12378,12 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         LessThanComparable and EqualityComparable don't correspond
         to NaN.
 
- <td width="535">
+ <td width="536">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Apply
         concept_map to these concepts at FloatingPointType
@@ -12367,14 +12391,17 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ We believe that no change is necessary, but it should be reviewed by a group
+ devoted to numeric issues. Not every possible state for a type must
+ participate in the axioms. For example, pointers are dereferenceable even if
+ some pointers (e.g. the null pointer) should not be dereferenced.<tr valign="top">
       <td width="29">
         <p>US 66
 
- <td width="117">
+ <td width="118">
         <p>20.1.10
 
       <td width="85">
@@ -12383,23 +12410,23 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Application of the "Regular" concept to floating-point
         types appears to be controversial (see long discussion on
         std-lib reflector).
 
- <td width="535">
+ <td width="536">
         <p>State that the &#8220;Regular&#8221; concept does not
         apply to floating-point types.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Recommend that we handle the same as JP 33.<tr valign="top">
       <td width="29">
         <p>JP 34
 
- <td width="117">
+ <td width="118">
         <p align="left">20.2
 
       <td width="85">
@@ -12412,26 +12439,33 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         Though N2672 pointed at adding
         "#include&lt;initializer_list&gt;", it isn't reflected.
 
- <td width="535">
+ <td width="536">
         <p align="left">add
         followings
 
         <p align="left" style="margin-top: 0.04in">
         #include &lt;initializer_list&gt; // for concept_map
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree that the omission of <code>#include
+ <initializer_list></initializer_list>
+ </code>was not agreed to in a vote and that the editor should reinstate it.
+ There is some disagreement as to whether it actually <em>should</em> be
+ there. Some believed it did not belong because we do not guarantee that one
+ header includes another anywhere else in the standard. However, the paper
+ that was voted in explicitly did make that guarantee. Removing that
+ guarantee is beyond the scope of this review.<tr valign="top">
       <td width="29">
         <p>US 67
 
- <td width="117">
+ <td width="118">
         <p>20.2.1
 
       <td width="85">
@@ -12440,21 +12474,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>Some connective words are missing.
 
- <td width="535">
+ <td width="536">
         <p>Insert &#8220;corresponding to&#8221; before &#8220;an
         lvalue reference type.&#8221;
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
       <td width="29">
         <p>JP 35
 
- <td width="117">
+ <td width="118">
         <p align="left">20.2.3
 
       <td width="85">
@@ -12467,25 +12501,25 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo,
 
         <p align="left">"stdforward" should be
         "std::forward"
 
- <td width="535">
+ <td width="536">
         <p align="left">Correct typo.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
       <td width="29">
         <p>UK<br>
         202
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.2.4
 
       <td width="85">
@@ -12494,7 +12528,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The references
         to pair in the tuple-like access to pair functions qualify
         pair with std::pair even though they are in a namespace std
@@ -12502,18 +12536,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the std:: qualification from these
         references to pair.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
       <td width="29">
         <p>US 68
 
- <td width="117">
+ <td width="118">
         <p>20.2.12
 
       <td width="85">
@@ -12522,24 +12556,25 @@
       <td width="62">
         <p>te/ed
 
- <td width="604">
+ <td width="514">
         <p>The code defining the context is syntactically
         incorrect.
 
- <td width="535">
+ <td width="536">
         <p>Insert a comma in two places: at the end of the third
         line of refinements, and at the end of the fourth line of
         refinements.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Editorial. The correct section is 20.1.12, not 20.2.12. Forward to project
+ editor.<tr valign="top">
       <td width="29">
         <p>UK<br>
         203
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.3.2
 
       <td width="85">
@@ -12548,7 +12583,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The ratio_xyz
         types have a misplaced '}'. For example: template &lt;class
         R1, class R2&gt; struct ratio_add { typedef see below}
@@ -12556,19 +12591,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the '}' to after the typedef: template
         &lt;class R1, class R2&gt; struct ratio_add { typedef see
         below type; };
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
       <td width="29">
         <p>JP 36
 
- <td width="117">
+ <td width="118">
         <p align="left">20.4.2.1
 
       <td width="85">
@@ -12581,26 +12616,26 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo.
 
         <p align="left" style="margin-top: 0.04in">"it
         it" should be "it is"
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Correct typo.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
       <td width="29">
         <p>UK<br>
         204
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.5
 
       <td width="85">
@@ -12609,7 +12644,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is not
         possible to create a variant union based on a parameter
         pack expansion, e.g. to implement a classic discriminated
@@ -12617,18 +12652,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Restore aligned_union template that was
         removed by LWG issue 856.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree that aligned_union is not completely redundant. We are investigating
+ whether the need for aligned_union is compelling enough to reinstate.<tr valign="top">
       <td width="29">
         <p>US 69
 
- <td width="117">
+ <td width="118">
         <p>20.5
 
       <td width="85">
@@ -12637,23 +12673,23 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>This section, dealing with tuple&lt;&gt;, should be in
         the same section as the similar utility pair&lt;&gt;.
 
- <td width="535">
+ <td width="536">
         <p>Restructure Clause 20 so as to bring these similar
         components together.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Editorial (effective duplicate of UK 198). Forward to project editor.<tr valign="top">
       <td width="29">
         <p>UK<br>
         205
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.5.3
 
       <td width="85">
@@ -12662,7 +12698,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         integral_constant objects should be usable in
         integral-constant-expressions. The addition to the language
@@ -12671,20 +12707,21 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a constexpr conversion operator to
         class tempalate integral_constant: constexpr operator
         value_type() { return value; }
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree: Add a constexpr conversion operator to class template
+ integral_constant: <code>constexpr operator value_type() { return value; }</code><tr valign="top">
       <td width="29">
         <p>UK<br>
         206
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.5.5
 
       <td width="85">
@@ -12693,7 +12730,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Currently the
         std says: "In order to instantiate the template
         is_convertible&lt;From, To&gt;, the following code shall be
@@ -12703,7 +12740,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change: "In order to instantiate the
         template is_convertible&lt;From, To&gt;, the following code
         shall be well formed:" To: "The template
@@ -12711,15 +12748,18 @@
         indirectly from true_type if the following code is well
         formed:"
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree with the proposed resolution: Section 20.5.5, Change: &quot;In order to
+ instantiate the template is_convertible&lt;From, To&gt;, the following code shall
+ be well formed:&quot; To: &quot;The template is_convertible&lt;From, To&gt; inherits either
+ directly or indirectly from true_type if the following code is well formed:&quot;<tr valign="top">
       <td width="29">
         <p>UK<br>
         207
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.5.6.1
 
       <td width="85">
@@ -12728,11 +12768,11 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">suffix "::type" is missing from the some of
         the examples.
 
- <td width="535">
+ <td width="536">
         <p align="left">Change:
         Example:remove_const&lt;const volatile int&gt;::type
         evaluates to volatile int, whereas remove_const&lt;const
@@ -12756,14 +12796,15 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ We tend to agree. Forward to project editor. Also recommend that the word
+ &quot;is&quot; be replaced with &quot;evaluates to&quot; in the same text.<tr valign="top">
       <td width="29">
         <p>JP 37
 
- <td width="117">
+ <td width="118">
         <p align="left">20.5.7
 
       <td width="85">
@@ -12772,7 +12813,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo.
 
@@ -12802,18 +12843,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         &#8221;.&#8221;
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree. Forward to project editor.<tr valign="top">
       <td width="29">
         <p>US 70
 
- <td width="117">
+ <td width="118">
         <p>20.6
 
       <td width="85">
@@ -12822,11 +12863,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Specifications now expressed via narrative text are more
         accurately and clearly expressed via executable code.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Wherever
         concepts are available that directly match this
@@ -12838,14 +12879,17 @@
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ (The correct reference is section 20.5, not 20.6) We think that this is a
+ good idea, but it requires a lot of work. If someone submits a paper
+ proposing specific changes, we would be happy to review it at the next
+ meeting.<tr valign="top">
       <td width="29">
         <p>US 71
 
- <td width="117">
+ <td width="118">
         <p>20.6.7
 
       <td width="85">
@@ -12854,21 +12898,22 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The grammar is incorrect.
 
- <td width="535">
+ <td width="536">
         <p>Change &#8220;conversion are&#8221; to &#8220;conversion
         is&#8221;.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ (The correct reference is section 20.5.7, table 41, last row). Agree:
+ Forward to project editor. There are several ways to fix the grammar.<tr valign="top">
       <td width="29">
         <p>JP 38
 
- <td width="117">
+ <td width="118">
         <p align="left">20.6.12.1.3
 
       <td width="85">
@@ -12877,7 +12922,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-left: 0.19in; text-indent: -0.19in; margin-bottom: 0in">
         add the move requirement for bind's return type.<br>
@@ -12911,7 +12956,7 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         the following requirements.<br>
         "<font color="#000000">it has a public move constructor
@@ -12920,14 +12965,21 @@
         <p align="left" style="margin-top: 0.04in">Add
         the MoveConstructible.
 
- <td width="89">
+ <td width="178">
         <p>
 
+ We were not clear about what the submitter really intended. Requiring that
+ the result of bind be <span class="twikiNewLink">MoveConstructible?</span>
+ and/or <span class="twikiNewLink">CopyConstructible?</span>
+ might be a start, but we would like to communicate with the submitter.
+ [NOTE: We would like to see a clarification of the wording for Returnable<t>
+ that makes it clear that move-only types can be Returnable.] </t>
+
     <tr valign="top">
       <td width="29">
         <p>JP 39
 
- <td width="117">
+ <td width="118">
         <p align="left">20.6.16.2
 
       <td width="85">
@@ -12936,11 +12988,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         There are no requires corresponding to F of std::function.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -12991,14 +13043,17 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree with one correction: <span class="twikiNewLink">CopyConstructible?</span>
+ should be <span class="twikiNewLink">ConstructibleWithAllocator?</span>
+ . Pablo to supply wording. Also check with Howard that omission was not
+ deliberate.<tr valign="top">
       <td width="29">
         <p>JP 40
 
- <td width="117">
+ <td width="118">
         <p align="left">20.6.16.2
 
       <td width="85">
@@ -13007,13 +13062,13 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         Thougn it's "Allocator Aloc" at other places, it's
         "Allocator A" only std::function constructor template
         parameter.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -13047,14 +13102,14 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Agree, though minor. Forward to project editor (who may disregard).<tr valign="top">
       <td width="29">
         <p>JP 41
 
- <td width="117">
+ <td width="118">
         <p align="left">20.6.16.2
 
       <td width="85">
@@ -13063,12 +13118,12 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         There are no requires corresponding to R and Args of
         UsesAllocator.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -13106,14 +13161,15 @@
 
         <p align="left" style="margin-top: 0.04in">}
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ This change would be redundant because function&lt;&gt; is already sufficiently
+ constrained. No actions necessary.<tr valign="top">
       <td width="29">
         <p>JP 42
 
- <td width="117">
+ <td width="118">
         <p align="left">20.6.16.2
 
       <td width="85">
@@ -13122,7 +13178,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">The requires
         are wrong.
@@ -13132,7 +13188,7 @@
         by a definition of function, then it's a mistake to
         designate followings by MoveConstructible.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -13232,15 +13288,17 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ As with JP 41, these constraints are redundant given that function&lt;&gt; is
+ already constrained. So we recommend changing each occurence of &quot;MoveConstructible&quot;
+ to &quot;class&quot;. Note: this issue is also present in func.wrap.func.nullptr.<tr valign="top">
       <td width="29">
         <p>UK<br>
         208
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.6.17
 
       <td width="85">
@@ -13249,25 +13307,26 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">std::hash should
         be implemented for much more of the standard library. In
         particular for pair, tuple and all the standard containers.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Consensus is that this is an expansion of the scope of C++0X and so we
+ recommend no action.<tr valign="top">
       <td width="29">
         <p>UK<br>
         209
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.7
 
       <td width="85">
@@ -13276,11 +13335,11 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Smart pointers cannot be used in
         constrained templates
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide
         constraints for smart pointers
 
@@ -13288,15 +13347,16 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ We look forward to a paper on this topic. We recommend no action until a
+ paper is available. We understand that a paper is forthcoming.<tr valign="top">
       <td width="29">
         <p>UK<br>
         213
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.7.6
 
       <td width="85">
@@ -13305,7 +13365,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">std::allocator
         should be constrained to simplify its use on constrained
         contexts. This library component models allocation from
@@ -13317,13 +13377,13 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">The primary allocator template should be
         constrained to require ObjectType&lt;T&gt; and
         FreeStoreAllocatable&lt;T&gt;. Further operations to be
         constrained as required.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -13331,7 +13391,7 @@
         <p>UK<br>
         214
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.7.8
 
       <td width="85">
@@ -13340,25 +13400,26 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         raw_storage_iterator needs constraining as an iterator
         adaptor to be safely used in constrained templates
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Constrain the raw_storage_iterator template
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ We look forward to a paper on this topic. We recommend no action until a
+ paper is available.<tr valign="top">
       <td width="29">
         <p>UK<br>
         210
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.7.11
 
       <td width="85">
@@ -13367,12 +13428,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Specialized algorithms for memory
         managenment need requirements to be easily usable in
         constrained templates
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide
         constraints for all algorithms in 20.7.11
 
@@ -13380,14 +13441,15 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ We look forward to a paper on this topic. We recommend no action until a
+ paper is available.<tr valign="top">
       <td width="29">
         <p>DE-20
 
- <td width="117">
+ <td width="118">
         <p>20.7.12
 
       <td width="85">
@@ -13396,25 +13458,25 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>DE-20 The section heading and the first sentence use the
         term "template function", which is undefined.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Replace
         "template function" by "function template".
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 72
 
- <td width="117">
+ <td width="118">
         <p align="left">20.7.12
 
       <td width="85">
@@ -13423,23 +13485,23 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         bind should support move-only functors and bound arguments.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-21
 
- <td width="117">
+ <td width="118">
         <p>20.7.12.1.3
 
       <td width="85">
@@ -13448,18 +13510,18 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-21 The specification for bind claims twice that "the
         values and types for the bound arguments v1, v2, ..., vN
         are determined as specified below". No such specification
         appears to exist.
 
- <td width="535">
+ <td width="536">
         <p>Add the missing specification in the same section, or
         add a cross-reference indicating the section where the
         specification appears.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -13467,7 +13529,7 @@
         <p>UK<br>
         211
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.7.12.2.3
 
       <td width="85">
@@ -13476,7 +13538,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The nullptr_t
         type was introduced to resolve the null pointer literal
         problem. It should be used for the assignemnt operator, as
@@ -13484,12 +13546,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change signature here and in the synopsis
         to: unique_ptr&amp; operator=(nullptr_t); Strike the
         sentance an note before the Effects clause.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -13497,7 +13559,7 @@
         <p>UK<br>
         212
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.7.13.7
 
       <td width="85">
@@ -13506,7 +13568,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         pointer-safety API is nothing to do with smart pointers, so
         does not belong in 20.7.13. In fact it is a set of language
@@ -13516,18 +13578,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move this specification to 18.5. Move the
         declarations into the header &lt;new&gt;.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>DE-22
 
- <td width="117">
+ <td width="118">
         <p>20.7.16.2
 
       <td width="85">
@@ -13536,26 +13598,26 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>DE-22 The conditions for deriving from
         std::unary_function and std::binary_function are unclear:
         The condition would also be satisfied if ArgTypes were
         std::vector&lt;T1&gt;, because it (arguably) "contains" T1.
 
- <td width="535">
+ <td width="536">
         <p>Consider stating the conditions in normative prose
         instead of in comments in the class definition. Use
         "consists of" instead of "contains". Consider using "if and
         only if" instead of "iff".
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 73
 
- <td width="117">
+ <td width="118">
         <p align="left">20.7.18
 
       <td width="85">
@@ -13564,7 +13626,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         std::reference_closure template is redundant with
         std::function and should be removed.
@@ -13597,7 +13659,7 @@
 
         <p align="left" style="margin-left: 0.25in"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove 20.7.18
         [func.referenceclosure].
 
@@ -13605,14 +13667,14 @@
 
         <p align="left">Remove 5.1.1 paragraph 12.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 74
 
- <td width="117">
+ <td width="118">
         <p align="left">20.8
 
       <td width="85">
@@ -13621,7 +13683,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">Scoped
         allocators represent a poor trade-off for standardization,
         since (1) scoped-allocator--aware containers can be
@@ -13649,7 +13711,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove support
         for scoped allocators from the working paper. This includes
         at least the following changes:
@@ -13679,14 +13741,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>US 74
 
- <td width="117">
+ <td width="118">
         <p>20.8.2.2
 
       <td width="85">
@@ -13695,21 +13757,21 @@
       <td width="62">
         <p>te/ed
 
- <td width="604">
+ <td width="514">
         <p>A concept name is twice misspelled.
 
- <td width="535">
+ <td width="536">
         <p>Change &#8220;Hasconstructor&#8221; to
         &#8220;HasConstructor&#8221; (twice).
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>US 75
 
- <td width="117">
+ <td width="118">
         <p>20.8.2.2
 
       <td width="85">
@@ -13718,24 +13780,24 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Allocator concepts are incomplete
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">See paper:
         http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 43
 
- <td width="117">
+ <td width="118">
         <p align="left">20.8.3
 
       <td width="85">
@@ -13744,14 +13806,14 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo.
 
         <p align="left" style="margin-top: 0.04in">
         "alloc" should be "Alloc"
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -13791,7 +13853,7 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -13799,7 +13861,7 @@
         <p>UK<br>
         215
 
- <td width="117">
+ <td width="118">
         <p align="justify">20.8.3.3
 
       <td width="85">
@@ -13808,24 +13870,24 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Extra pair of
         {}, presumably some formatting code gone awry :
         duration&amp; operator-{-}();
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the {} or fix formatting
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 77
 
- <td width="117">
+ <td width="118">
         <p align="left">20.8.4
 
       <td width="85">
@@ -13834,7 +13896,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Allocator-specific move and copy behavior for containers
         (N2525) complicates a little-used and already-complicated
@@ -13858,7 +13920,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove 20.8.4.
 
         <p align="left"><br>
@@ -13870,14 +13932,14 @@
         <p align="left">Remove all references to the facilities in
         20.8.4 and 20.8.5 from clause 23.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 78
 
- <td width="117">
+ <td width="118">
         <p align="left">20.8.12,<br>
         20.8.13.2
 
@@ -13887,13 +13949,13 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">There is presently no way to
         convert directly from a <font size="2" style=
         "font-size: 11pt"><code>shared_ptr</code> to a
         <code>unique_ptr</code>.</font>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         an interface that performs the conversion. See the
         attached, Issues with the C++ Standard" paper under Chapter
@@ -13903,14 +13965,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 79
 
- <td width="117">
+ <td width="118">
         <p align="left">20.8.12.2.1
 
       <td width="85">
@@ -13919,7 +13981,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         [unique.ptr.single.ctor]/5 no longer requires for D not to
         be a pointer type. &nbsp;This restriction needs to be put
@@ -13942,17 +14004,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 44
 
- <td width="117">
+ <td width="118">
         <p align="left">20.8.13.6
 
       <td width="85">
@@ -13961,7 +14023,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         1st parameter p and 2nd parameter v is now
         shared_ptr&lt;T&gt; *.
@@ -13971,19 +14033,19 @@
         shared_ptr&lt;T&gt;* then add the "p shall not be a null
         pointer" at the requires.
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Change shared_ptr&lt;T&gt;&amp; or add the "p shall not be
         a null pionter" at the requires.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 45
 
- <td width="117">
+ <td width="118">
         <p align="left">20.9
 
       <td width="85">
@@ -13992,7 +14054,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Rep, Period, Clock and Duration don't correspond to
         concept.
@@ -14009,20 +14071,20 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Make concept for Rep, Period, Clock and Duration, and fix
         20.9 and wait_until and wait_for's template parameter at
         30.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>US 80
 
- <td width="117">
+ <td width="118">
         <p>20.9.2.1
 
       <td width="85">
@@ -14031,10 +14093,10 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The section heading does not describe the contents.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Change the
         heading &#8220;<span lang=
@@ -14045,14 +14107,14 @@
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 81
 
- <td width="117">
+ <td width="118">
         <p align="left">20.9.3
 
       <td width="85">
@@ -14061,7 +14123,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         chrono::duration is missing the modulous operator for both
         member and non-member arithmetic. This operator is useful
@@ -14102,7 +14164,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add:
 
         <p align="left"><br>
@@ -14162,14 +14224,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>US 82
 
- <td width="117">
+ <td width="118">
         <p>20.9.5.3
 
       <td width="85">
@@ -14178,14 +14240,14 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>The code synopsis has a minor alignment error.
 
- <td width="535">
+ <td width="536">
         <p>Align &#8220;rep&#8221; with the other symbols defined
         in this synopsis.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -14193,7 +14255,7 @@
         <p>UK<br>
         216
 
- <td width="117">
+ <td width="118">
         <p align="justify">21
 
       <td width="85">
@@ -14202,22 +14264,24 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">All the containers use concepts for their
         iterator usage, exect for basic_string. This needs fixing.
 
- <td width="535">
+ <td width="536">
         <p align="left">Use concepts for iterator template
         parameters throughout the chapter.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ NB comments to be handled by Dave Abrahams and Howard Hinnant with advice
+ from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies extensive
+ proposed wording; start there.<tr valign="top">
       <td width="29">
         <p>JP 46
 
- <td width="117">
+ <td width="118">
         <p align="left">21.2, 21.3
 
       <td width="85">
@@ -14226,11 +14290,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">The
         basic_string does not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">The
         "class Alloc" is changed to "Allocator Alloc".
 
@@ -15224,14 +15288,14 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ See UK 216<tr valign="top">
       <td width="29">
         <p>JP 47
 
- <td width="117">
+ <td width="118">
         <p align="left">21.3
 
       <td width="85">
@@ -15240,7 +15304,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo. Missing &#8221;&gt;&#8221;
 
@@ -15261,18 +15325,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Correct typo.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 48
 
- <td width="117">
+ <td width="118">
         <p align="left">21.3
 
       <td width="85">
@@ -15281,7 +15345,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         char_traits does not use concept.
 
@@ -15305,19 +15369,19 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         a concept for char_traits.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ See UK 216<tr valign="top">
       <td width="29">
         <p>UK<br>
         217
 
- <td width="117">
+ <td width="118">
         <p align="justify">21.3
 
       <td width="85">
@@ -15326,12 +15390,12 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">basic_string refers to
         constructible_with_allocator_suffix, which I thought was
         removed?
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the
         lines: template &lt;class charT, class traits, class Alloc
         struct constructible_with_allocator_suffix&lt;
@@ -15340,7 +15404,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -15348,7 +15412,7 @@
         <p>UK<br>
         218
 
- <td width="117">
+ <td width="118">
         <p align="justify">21.3.1
 
       <td width="85">
@@ -15357,7 +15421,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The identity
         "&amp;*(s.begin() + n) == &amp;*s.begin() + n" relies on
         operator&amp; doing the "right thing", which (AFAICS) there
@@ -15368,19 +15432,21 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">See my recommendations for "23.2.1,
         23.2.6".
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ NAD, we think. basic_string elements have to be POD and PODs may not have
+ overloaded operator&amp;. Need to check whether this is true in light of relaxed
+ POD constraints.<tr valign="top">
       <td width="29">
         <p>UK<br>
         219
 
- <td width="117">
+ <td width="118">
         <p align="justify">21.3.6.6<br>
         [string.<br>
         replace]
@@ -15391,15 +15457,15 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Effects refers to "whose first begin() - i1
         elements" However i1 is greater than begin()...
 
- <td width="535">
+ <td width="536">
         <p align="left">Effects refers to "whose first i1 - begin()
         elements"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -15407,7 +15473,7 @@
         <p>UK<br>
         220
 
- <td width="117">
+ <td width="118">
         <p align="justify">21.3.8.9
 
       <td width="85">
@@ -15416,7 +15482,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         operator&lt;&lt; for basic_string takes the output stream
         by r-value reference. This is different from the same
@@ -15426,20 +15492,22 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Use the same reference type for the all the
         library types. This should be the r-value reference. There
         are other places in the standard where TR1, and new
         classes, did not receive an 'R-value' update.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ We did it differently for basic_string because otherwise rvalue strreaming
+ was producing confusing results with strings, but this difference will be
+ fixed by N2831 if it's accepted.<tr valign="top">
       <td width="29">
         <p>FR 33
 
- <td width="117">
+ <td width="118">
         <p>22.1.1<br>
 &nbsp;[locale]
 
@@ -15449,7 +15517,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>ios_base::iostate err = 0;
 
         <p>
@@ -15459,17 +15527,17 @@
 
         <p>goodbit is the solution.
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 49
 
- <td width="117">
+ <td width="118">
         <p align="left">22.1.3.2.2
 
       <td width="85">
@@ -15478,7 +15546,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         codecvt does not use concept. For example, create
         CodeConvert concept and change as follows.
@@ -15487,18 +15555,18 @@
         template&lt;<u>CodeConvert</u> Codecvt, class Elem =
         wchar_t&gt; class wstring_convert {
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         a concept for codecvt.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
       <td width="29">
         <p>JP 50
 
- <td width="117">
+ <td width="118">
         <p align="left">22.1.3.2.2
 
       <td width="85">
@@ -15507,12 +15575,12 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">Add
         custom allocator parameter to wstring_convert, since we
         cannot allocate memory for strings from a custom allocator.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -15566,14 +15634,14 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ to be handled by PJ Plaugher<tr valign="top">
       <td width="29">
         <p>FI 4
 
- <td width="117">
+ <td width="118">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">22.2.1.4.1
 
@@ -15585,21 +15653,21 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p><tt>to_end and to_limit are both used. Only one is
         needed.</tt>
 
- <td width="535">
+ <td width="536">
         <p>Change to_limit to to_end.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FI 5
 
- <td width="117">
+ <td width="118">
         <p><tt>22.2.1.4.2</tt>
 
       <td width="85">
@@ -15608,7 +15676,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in"><tt>[ Note: As
         a result of operations on state, it can return ok or
@@ -15635,21 +15703,21 @@
         from_next is unaltered, to_next is advanced, state is
         altered and return value is partial.</tt>
 
- <td width="535">
+ <td width="536">
         <p><tt>[ Note: As a result of operations on state, do_in
         and do_out can return</tt><br>
         <tt>ok or partial and set from_next == from and/or to_next
         != to. &#8212;end</tt><br>
         <tt>note ]</tt>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FI 6
 
- <td width="117">
+ <td width="118">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">22.2.1.5
 
@@ -15663,7 +15731,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">
         <tt>codecvt_byname is only specified to work with locale
@@ -15681,18 +15749,20 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p><tt>There should be a built-in means to find a codecvt
         with a pair of character set names.</tt>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Martin Sebor interested in solving this problem (also POSIX group), but
+ addressing it controversial because it's probably too late in the process
+ for what looks like a new feature.<tr valign="top">
       <td width="29">
         <p>FI 7
 
- <td width="117">
+ <td width="118">
         <p>22.2.1.4
 
       <td width="85">
@@ -15701,7 +15771,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">The word
         "codeset" is used, whereas the word "character set" is used
@@ -15711,17 +15781,17 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p>Change "codeset" to "character set."
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 51
 
- <td width="117">
+ <td width="118">
         <p align="left">22.2.5.1.1
 
       <td width="85">
@@ -15732,7 +15802,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">A
         parameter `end&#8217; should be `fmtend&#8217;.<br>
         get() function had two `end&#8217; parameters at N2321.
@@ -15750,7 +15820,7 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -15770,14 +15840,14 @@
         <p align="left" style="margin-top: 0.04in">
         Requires: [fmt,fmtend) shall be a valid range.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 52
 
- <td width="117">
+ <td width="118">
         <p align="left">22.2.5.1,<br>
         22.2.5.2,<br>
         22.2.6.1
@@ -15788,11 +15858,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         InputIterator does not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -15961,14 +16031,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
       <td width="29">
         <p>JP 53
 
- <td width="117">
+ <td width="118">
         <p align="left">22.2.5.3 ,<br>
         22.2.5.4
 
@@ -15978,11 +16048,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         OutputIterator does not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -16095,14 +16165,14 @@
         <p align="left">typedef <u>OutputIter</u>
         iter_type;
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
       <td width="29">
         <p>JP 54
 
- <td width="117">
+ <td width="118">
         <p align="left">23
 
       <td width="85">
@@ -16115,16 +16185,16 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         There is not &lt;forward_list&gt; in Table 79.
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         &lt;forward_list&gt; between &lt;deque&gt; and
         &lt;list&gt;.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16132,7 +16202,7 @@
         <p>UK<br>
         221
 
- <td width="117">
+ <td width="118">
         <p align="justify">23
 
       <td width="85">
@@ -16141,11 +16211,11 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The table is missing the new
         &lt;forward_list&gt; header.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         &lt;forward_list&gt; to the table for sequence containers.
         Alternative (technical) solution might be to merge
@@ -16153,7 +16223,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16161,7 +16231,7 @@
         <p>UK<br>
         222
 
- <td width="117">
+ <td width="118">
         <p align="justify">23
 
       <td width="85">
@@ -16170,7 +16240,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is not clear
         what purpose the Requirement tables serve in the Containers
         clause. Are they the definition of a library Container? Or
@@ -16187,7 +16257,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify all the tables in 23.1 are there as
         a convenience for documentation, rather than a strict set
         of requirements. Containers should be allowed to relax
@@ -16198,14 +16268,14 @@
         not provide the required size operation as it cannot be
         implemented efficiently.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 55
 
- <td width="117">
+ <td width="118">
         <p align="left">23.1.1
 
       <td width="85">
@@ -16218,18 +16288,18 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">It
         seems that &#8220;the MinimalAllocator concep&#8221; is the
         typo of &#8220;the MinimalAllocator concept&#8221;.
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Change to &#8230; models the MinimalAllocator
         concep<font color="#339966">t</font><font size="2" style=
         "font-size: 11pt">.</font>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16237,7 +16307,7 @@
         <p>UK<br>
         223
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.1
 
       <td width="85">
@@ -16246,7 +16316,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The library does
         not define the MinimalAllocator or ScopedAllocator
         concepts, these were part of an earlier Allocators proposal
@@ -16254,12 +16324,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the references to MinimalAllocator
         and ScopedAllocator, or add definitions for these concepts
         to clause 20.7.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16267,7 +16337,7 @@
         <p>UK<br>
         224
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.1
 
       <td width="85">
@@ -16276,12 +16346,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph implicitly requires all
         containers in clause 23 to support allocators, which
         std::array does not.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add an 'unless
         otherwise specified' rider somewhere in p8, or move the
         whole array container from clause 23 [containers] to clause
@@ -16289,7 +16359,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16297,7 +16367,7 @@
         <p>UK<br>
         225
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.1
 
       <td width="85">
@@ -16306,7 +16376,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Inconsistent
         words used to say the same thing. Table 80 describes
         iterator/const_iterator typedef as returning an "iterator
@@ -16317,12 +16387,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change return types for
         X::(const)_reverse_iterator to say "iterator type whose
         value type is (const) T".
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16330,7 +16400,7 @@
         <p>UK<br>
         226
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.1
 
       <td width="85">
@@ -16339,7 +16409,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">&lt;array&gt;
         must be added to this list. In particular it doesn't
         satisfy: - no swap() function invalidates any references,
@@ -16349,12 +16419,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">If &lt;array&gt; remains a container, this
         will have to also reference array, which will then have to
         say which of these points it satisfies.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16362,7 +16432,7 @@
         <p>UK<br>
         227
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.1
 
       <td width="85">
@@ -16371,19 +16441,19 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The post-condition for a = rv uses the word
         &#8220;construction&#8221; when it means
         &#8220;assignment&#8221;
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace the word
         &#8220;construction&#8221; with the word
         &#8220;assignment&#8221;
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16391,7 +16461,7 @@
         <p>UK<br>
         228
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.1
 
       <td width="85">
@@ -16400,17 +16470,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Line 4 contains
         a spelling mistake in the fragment "MinimalAllocator
         concep."
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace "concep" with "concept"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16418,7 +16488,7 @@
         <p>UK<br>
         229
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.1
 
       <td width="85">
@@ -16427,12 +16497,12 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The fragment "A container may directly call
         constructors" is not technically correct as constructors
         are not callable.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace "A
         container may directly call constructors and destructors
         for its stored objects" with something similar to "A
@@ -16441,7 +16511,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16449,7 +16519,7 @@
         <p>UK<br>
         230
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.2
 
       <td width="85">
@@ -16458,7 +16528,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         &#8220;implementations shall consider the following
         functions to be const&#8221; - what does this mean? I don't
@@ -16468,18 +16538,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Clarify what is meant and what requirements
         an implementation must satisfy.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 56
 
- <td width="117">
+ <td width="118">
         <p align="left">23.1.3
 
       <td width="85">
@@ -16489,12 +16559,12 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         `array&#8217; is unstated in Table 84 - Optional sequence
         container operations.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         `array&#8217; to Container field for the following
         Expression.
@@ -16511,7 +16581,7 @@
         <p align="left" style=
         "text-indent: 0.15in; margin-top: 0.04in">a.at(n)
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16519,7 +16589,7 @@
         <p>UK<br>
         231
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.3
 
       <td width="85">
@@ -16528,19 +16598,19 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">These paragraphs
         are redundant now that Concepts define what it means to be
         an Iterator and guide overload resolution accordingly.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike 23.1.3p9-11. Make sure
         std::basic_string has constraints similar to std::vector to
         meet this old guarantee.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16548,7 +16618,7 @@
         <p>UK<br>
         232
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.3
 
       <td width="85">
@@ -16557,18 +16627,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">match_results
         may follow the requirements but is not listed a general
         purpose library container.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove reference to match_results against
         a[n] operation
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16576,7 +16646,7 @@
         <p>UK<br>
         233
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.3
 
       <td width="85">
@@ -16585,10 +16655,10 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Add references to the new containers.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add reference to
         array to the rows for: a.front(), a. back(), a[n] a.at(n).
         Add reference to forward_list to the rows for: a.front(),
@@ -16598,7 +16668,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16606,7 +16676,7 @@
         <p>UK<br>
         234
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.3
 
       <td width="85">
@@ -16615,7 +16685,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Ther reference
         to iterator in semantics for back should also allow for
         const_iterator when called on a const-qualified container.
@@ -16624,11 +16694,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace iterator with auto in semantics for
         back: { auto tmp = a.end(); --tmp; return *tmp; }
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16636,7 +16706,7 @@
         <p>UK<br>
         235
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.3
 
       <td width="85">
@@ -16645,13 +16715,13 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">&#8220;The library provides three basic
         kinds of sequence containers: vector, list, and
         deque&#8221; - text appears to be out of date re addition
         of array and forward_list
 
- <td width="535">
+ <td width="536">
         <p align="left">Change the text
         to read: &#8220;The library provides five basic kinds of
         sequence containers: array, deque, forward_list, list and
@@ -16659,7 +16729,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16667,7 +16737,7 @@
         <p>UK<br>
         236
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.3
 
       <td width="85">
@@ -16676,7 +16746,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">[ I've moved (1)
         into a separate comment because I believe it is editorial
         in the simple sense, whereas (2) and (3) are not so
@@ -16693,10 +16763,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove this paragraph
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16704,7 +16774,7 @@
         <p>UK<br>
         237
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.3
 
       <td width="85">
@@ -16713,12 +16783,12 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">vector, list, and deque offer the
         programmer different complexity trade-offs and should be
         used accordingly - this ignores array and forward_list
 
- <td width="535">
+ <td width="536">
         <p align="left">Modify the text
         to read: "array, deque, forward_list, list and vector offer
         the programmer different complexity trade-offs and should
@@ -16726,7 +16796,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16734,7 +16804,7 @@
         <p>UK<br>
         238
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.4
 
       <td width="85">
@@ -16743,7 +16813,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Leaving it
         unspecified whether or not iterator and const_iterator are
         the same type is dangerous, as user code may or may not
@@ -16756,7 +16826,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change 'unspecified' to 'implementation
         defined'. Add "[Note: As itererator and const_iterator have
         identical semantics in this case, and iterator is
@@ -16764,7 +16834,7 @@
         the One Definition Rule by always using const_iterator in
         their function parameter lists -- end note]
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16772,7 +16842,7 @@
         <p>UK<br>
         239
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.4
 
       <td width="85">
@@ -16781,12 +16851,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is not possible to take a move-only key
         out of an unordered container, such as (multi)set or
         (multi)map, or the new hashed containers.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add below
         a.erase(q), a.extract(q), with the following notation:
         a.extract(q), Return type pair&lt;key, iterator&gt;
@@ -16798,7 +16868,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16806,7 +16876,7 @@
         <p>UK<br>
         240
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.1.6.1
 
       <td width="85">
@@ -16815,7 +16885,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The axiom
         EmplacePushEquivalence should be asserting the stronger
         contract that emplace and insert return the same iterator
@@ -16830,7 +16900,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the * to deference the returned
         iterator either side of the == in the
         EmplacePushEquivalence axiom, rename the axiom
@@ -16841,14 +16911,14 @@
         position, Args... args) { emplace(c, position, args...) ==
         insert(c, position, value_type(args...)); }
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 57
 
- <td width="117">
+ <td width="118">
         <p align="left">23.1.6.3
 
       <td width="85">
@@ -16861,18 +16931,18 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo, duplicated "to"
 
         <p align="left" style="margin-top: 0.04in">
         "<u>to to</u> model insertion container concepts."
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Remove one.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16880,7 +16950,7 @@
         <p>UK<br>
         241
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.2.1
 
       <td width="85">
@@ -16889,17 +16959,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">std::array does
         not have an allocator, so need to document an exception to
         the requirements of 23.1.1p3
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">add exception to 23.1.1p3
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16907,7 +16977,7 @@
         <p>UK<br>
         242
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.2.1
 
       <td width="85">
@@ -16916,18 +16986,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">std:: qualification no longer needed for
         reverse_iterator.
 
- <td width="535">
+ <td width="536">
         <p align="left">remove std::
         qualification from std::reverse_iterator&lt;iterator&gt;
         and std::reverse_iterator&lt;const_iterator&gt;
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16935,7 +17005,7 @@
         <p>UK<br>
         243
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.2.1
 
       <td width="85">
@@ -16944,7 +17014,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Most containers,
         and types in general have 3 swaps: swap(T&amp;, T&amp;)
         swap(T&amp;&amp;, T&amp;) swap(T&amp;, T&amp;&amp;) But
@@ -16952,10 +17022,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">add the other two swaps.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -16963,7 +17033,7 @@
         <p>UK<br>
         244
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.2.1,<br>
 &nbsp;23.2.6
 
@@ -16973,7 +17043,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The validity of
         the expression &amp;a[n] == &amp;a[0] + n is contingent on
         operator&amp; doing the &#8220;right thing&#8221; (as
@@ -16986,7 +17056,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Define a ContiguousStrorage and apply it to
         vector,array and string. The Concept (supplied by Alisdair
         M) looks like this: Concept&lt; typename C &gt;
@@ -16995,7 +17065,7 @@
         Contiguous { C c; true = equal_ranges( data( c), data(c) +
         size(c), begin(c)); } };
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -17003,7 +17073,7 @@
         <p>UK<br>
         245
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.2.3
 
       <td width="85">
@@ -17012,7 +17082,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The predicate types used in special member
         function of forward_list should be CopyConstructible, as
         per the algorithms of the same name. Note: an alternate
@@ -17021,7 +17091,7 @@
         library specification in general. See earlier comment for
         details, that would render this one redundant.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         CopyConstructible requirement to the following signatures:
         template &lt;Predicate&lt;auto, T&gt; Pred&gt; requires
@@ -17041,14 +17111,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 58
 
- <td width="117">
+ <td width="118">
         <p align="left">23.2.3.2
 
       <td width="85">
@@ -17061,23 +17131,23 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         Unnecessary "{" exists before a word iterator like
         "{iterator before_begin()".
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Remove "{"
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>JP 59
 
- <td width="117">
+ <td width="118">
         <p align="left">23.2.4.4
 
       <td width="85">
@@ -17086,14 +17156,14 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         Types of the third and forth parameter of splice() are
         iterator at 23.2.4.4, though types of them are
         const_iterator at 23.2.4. (They are both const_iterator on
         N2350)
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -17132,14 +17202,14 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 83
 
- <td width="117">
+ <td width="118">
         <p align="left">23.2.6.2
 
       <td width="85">
@@ -17148,7 +17218,7 @@
       <td width="62">
         <p align="left">ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         "shrink_to_fint" should be "shrink_to_fit".
 
@@ -17157,10 +17227,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17168,7 +17238,7 @@
         <p>UK<br>
         246
 
- <td width="117">
+ <td width="118">
         <p align="justify">23.3.2.2
 
       <td width="85">
@@ -17177,7 +17247,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The content of
         this sub-clause is purely trying to describe in words the
         effect of the requires clauses on these operations, now
@@ -17188,12 +17258,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike 23.3.2.2 entirely. (but do NOT
         strike these signatures from the class template
         definition!)
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17201,7 +17271,7 @@
         <p>UK<br>
         247
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1
 
       <td width="85">
@@ -17210,7 +17280,7 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">Iterator
         concepts are not extensive enough to merit a whole new
         header, and should be merged into &lt;concpts&gt;. This is
@@ -17222,13 +17292,13 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the concepts of
         &lt;iterator_concepts&gt; into the &lt;concepts&gt; header.
         We take no position on moving the text from Clause 24 to
         Clause 20 though.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17236,7 +17306,7 @@
         <p>UK<br>
         248
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1
 
       <td width="85">
@@ -17245,7 +17315,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The text "so for
         any iterator type there is an iterator value that points
         past the last element of a corresponding container" is
@@ -17255,11 +17325,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace the reference to container with a
         more appropriate concept
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17267,7 +17337,7 @@
         <p>UK<br>
         250
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.1
 
       <td width="85">
@@ -17276,17 +17346,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">A default implementation should be supplied
         for the post-increment operator to simplify implementation
         of iterators by users.
 
- <td width="535">
+ <td width="536">
         <p align="left">Copy the Effects clause into the concept
         description as the default implementation. Assumes a
         default value for postincrement_result
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17294,7 +17364,7 @@
         <p>UK<br>
         251
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.1
 
       <td width="85">
@@ -17303,7 +17373,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         post-increment operator is dangerous for a general
         InputIterator. The multi-pass guarantees that make it
@@ -17317,12 +17387,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move declaration of postincrement operator
         and postincrement_result type from Interator concept to the
         ForwardIterator concept
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17333,7 +17403,7 @@
 
         <p>
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.2
 
       <td width="85">
@@ -17342,15 +17412,15 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">istream_iterator is not a class, but a
         class template
 
- <td width="535">
+ <td width="536">
         <p align="left">Change 'class' to 'class template' in the
         note.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17358,7 +17428,7 @@
         <p>UK<br>
         253
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.3
 
       <td width="85">
@@ -17367,7 +17437,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">First sentance
         does not make gramatical sense, Seems to be missing the
         words 'if it' by comparison with similar sentance in other
@@ -17375,12 +17445,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the words 'if it' : "X satisfies the
         requirements of an output iterator IF IT meets the
         syntactic and semantic requirements"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17388,7 +17458,7 @@
         <p>UK<br>
         254
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.3
 
       <td width="85">
@@ -17397,18 +17467,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This
         postcondition for pre-increment operator should be written
         as an axiom
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the postcondition into the concept
         definition as an axiom
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17416,7 +17486,7 @@
         <p>UK<br>
         255
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.4
 
       <td width="85">
@@ -17425,18 +17495,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This
         postcondition for pre-increment operator should be written
         as an axiom
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the postcondition into the concept
         definition as an axiom
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17444,7 +17514,7 @@
         <p>UK<br>
         256
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.5
 
       <td width="85">
@@ -17453,18 +17523,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The relationship between pre- and post-
         decrement should be expressed as an axiom.
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the text
         specification of pre/post-conditions and behaviour into an
         axiom within the BidirectionalIterator concept
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17472,7 +17542,7 @@
         <p>UK<br>
         257
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.5
 
       <td width="85">
@@ -17481,7 +17551,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">There is a
         reasonable default for postdecrement_result type, which is
         X. X is required to be regular, therefore CopyConstructible
@@ -17490,11 +17560,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the default : typename
         postincrement_result = X;
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17502,7 +17572,7 @@
         <p>UK<br>
         258
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.5
 
       <td width="85">
@@ -17511,19 +17581,19 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">A default
         implementation should be supplied for the post-decrement
         operator to simplify implementation of iterators by users.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Copy the Effects clause into the concept
         description as the default implementation. Assumes a
         default value for postincrement_result
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17531,7 +17601,7 @@
         <p>UK<br>
         259
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.5
 
       <td width="85">
@@ -17540,7 +17610,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         postdecrement_result is effectively returning a copy of the
         original iterator value, so should have similar
@@ -17550,11 +17620,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the requirement: requires Iterator&lt;
         postdecrement_result &gt;;
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17562,7 +17632,7 @@
         <p>UK<br>
         260
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.5
 
       <td width="85">
@@ -17571,13 +17641,13 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The effects clause for post-decrement
         iterator should be available as an axiom and a default
         implementation, where the compiler can make better use of
         it.
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the Effects
         clause into the BidirectionalIterator concept definition as
         an axiom, and as the default implementation for the
@@ -17585,7 +17655,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17593,7 +17663,7 @@
         <p>UK<br>
         249
 
- <td width="117">
+ <td width="118">
         <p align="justify"><span lang=
         "en-US">24.1.6</span>
 
@@ -17603,7 +17673,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The semantic for
         operator+= should also be provided as a default
         implementation to simplify implementation of user-defined
@@ -17611,12 +17681,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Copy the text from the effects clause into
         the RandomAccessIterator concept as the default
         implementaiton.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17624,7 +17694,7 @@
         <p>UK<br>
         261
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.6
 
       <td width="85">
@@ -17633,17 +17703,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">To simplify user
         defined random access iterator types, the
         subscript_reference type should default to reference
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">typename subscript_reference = reference;
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17651,7 +17721,7 @@
         <p>UK<br>
         262
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.6
 
       <td width="85">
@@ -17660,12 +17730,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Effects and post-conditions for operator+
         are more useful if expressed as axioms, and supplied as
         default implementations.
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the effects
         and Postcondition definitions into the RandomAccessIterator
         concept and copy the code in the specification as the
@@ -17673,7 +17743,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17681,7 +17751,7 @@
         <p>UK<br>
         263
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.6
 
       <td width="85">
@@ -17690,12 +17760,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This requirement on operator-= would be
         better expressed as a default implementation in the
         concept, with a matching axiom
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the
         specification for operator-= from the returns clause into
         an axiom and default implementation within the
@@ -17703,7 +17773,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17711,7 +17781,7 @@
         <p>UK<br>
         264
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.6
 
       <td width="85">
@@ -17720,18 +17790,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Effects clauses are better expressed as
         axioms where possible.
 
- <td width="535">
+ <td width="536">
         <p align="left">Move code in
         operator- effects clause into RandomAccessIterator concept
         as both a default implementation and an axiom
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17739,7 +17809,7 @@
         <p>UK<br>
         265
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.6
 
       <td width="85">
@@ -17748,7 +17818,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This effects
         clause is nonesense. It looks more like an axiom stating
         equivalence, and certainly an effects clause cannot change
@@ -17756,10 +17826,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the Effects clause
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17767,7 +17837,7 @@
         <p>UK<br>
         266
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.6
 
       <td width="85">
@@ -17776,11 +17846,11 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">This sentance should be provided as a
         default definition, along with a matching axiom
 
- <td width="535">
+ <td width="536">
         <p align="left">Move the Returns
         clause into the spefication for RandomAccessIterator
         operator- as a default implementation. Move the Effects
@@ -17788,7 +17858,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17796,7 +17866,7 @@
         <p>UK<br>
         267
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.6
 
       <td width="85">
@@ -17805,18 +17875,18 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The code in the
         Requires clause for RandomAccessIterator operator[] would
         be better expressed as an axiom.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Rewrite the Requires clause as an axiom in
         the RandomAccessIterator concept
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -17824,7 +17894,7 @@
         <p>UK<br>
         268
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.1.6
 
       <td width="85">
@@ -17833,7 +17903,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This note is
         potentialy confusing as __far enters the syntax as a clear
         language extension, but the note treats it as a regular
@@ -17842,19 +17912,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Clean up the note to either avoid using
         language extension, or spell out this is a constraint to
         support extensions.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 60
 
- <td width="117">
+ <td width="118">
         <p align="left">24.1.8
 
       <td width="85">
@@ -17864,7 +17934,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Capability of an iterator is too much restricted by
         concept.
@@ -18036,12 +18106,12 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         InputRange, OutputRange, ForwardRange, BidirectionalRange
         and RandomAccessRange.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18049,7 +18119,7 @@
         <p>UK<br>
         269
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.3
 
       <td width="85">
@@ -18058,17 +18128,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">'decrements for
         negative n' seems to imply a negative number of decrement
         operations, which is odd.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Need simple, clearer wording
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18076,7 +18146,7 @@
         <p>UK<br>
         270
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.3
 
       <td width="85">
@@ -18085,19 +18155,19 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The reachability
         constraint in p5 means that a negavite result, implying
         decrements operations in p4, is not possible
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Split the two overloads into separate
         descriptions, where reachability is permitted to be in
         either direction for RandomAccessIterator
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18105,7 +18175,7 @@
         <p>UK<br>
         271
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.3
 
       <td width="85">
@@ -18114,7 +18184,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">next/prev return
         an incremented iterator without changing the value of the
         original iterator. However, even this may invalidate an
@@ -18123,11 +18193,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace InputIterator constraint with
         FOrwardIterator in next and prev function templates.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18135,7 +18205,7 @@
         <p>UK<br>
         272
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4
 
       <td width="85">
@@ -18144,7 +18214,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">reverse_iterator
         and move_iterator use different formulations for their
         comparison operations. move_iterator merely requires the
@@ -18163,12 +18233,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Rephrase the reverse_iterator comparison
         operations using only operators &lt; and ==, as per the
         move_iterator specification.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18176,7 +18246,7 @@
         <p>UK<br>
         274
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4, 24.5
 
       <td width="85">
@@ -18185,7 +18255,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The subclauses
         for standard iterator adaptors could be better organised.
         There are essentially 3 kinds of iterator wrappers
@@ -18198,13 +18268,13 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Promote 24.4.2 [insert.iterators] up one
         level to 24.6. Emphasize that insert iterators adapt
         containers Retarget 24.4 [predef.iterators] as iterator
         adapters for iterator templates that wrap other iterators.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18212,7 +18282,7 @@
         <p>UK<br>
         275
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.1.1
 
       <td width="85">
@@ -18221,7 +18291,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The constructor
         template taking a single Iterator argument will be selected
         for Copy Initialization instead of the non-template
@@ -18230,11 +18300,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">The reverse_iterator template constructor
         taking a single Iterator argument should be explicit.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18242,7 +18312,7 @@
         <p>UK<br>
         276
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.1.1
 
       <td width="85">
@@ -18251,7 +18321,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">It is odd to
         have a mix of declaration stlyes for operator+ overloads.
         Prefer if either all are member functions, or all are
@@ -18259,11 +18329,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Make the member operators taking a
         difference_type argument non-member operators
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18271,7 +18341,7 @@
         <p>UK<br>
         277
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.1.2.1
 
       <td width="85">
@@ -18280,7 +18350,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The default
         constructor default-initializes current, rather than
         value-initializes. This means that when Iterator
@@ -18293,7 +18363,7 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">i/ Specify value initialization rather than
         default intialization or ii/ specify = default; rather than
         spell out the semantic. This will at least allow users to
@@ -18301,7 +18371,7 @@
         iii/ Add a note to the description emphasizing the singular
         nature of a value-initialized reserve iterator.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18309,7 +18379,7 @@
         <p>UK<br>
         278
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.1.2.1
 
       <td width="85">
@@ -18318,7 +18388,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">There is an
         inconsistency between the constructor taking an iterator
         and the constructor template taking a reverse_iterator
@@ -18328,11 +18398,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change the const reverse_iterator&lt;U&gt;
         &amp; parameter to pass-by-value
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18340,7 +18410,7 @@
         <p>UK<br>
         279
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.1.2.12,<br>
         24.4.3.2.12
 
@@ -18350,7 +18420,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The reason the
         return type became unspecified is LWG issue 386. This
         reasoning no longer applies as there are at least two ways
@@ -18359,11 +18429,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Specify the return type using either
         decltype or the Iter concept map
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18371,7 +18441,7 @@
         <p>UK<br>
         280
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.1.2.4
 
       <td width="85">
@@ -18380,7 +18450,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The presence of
         the second iterator value is surprising for many readers
         who underestimate the size of a reverse_iterator object.
@@ -18389,11 +18459,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add reverse_iterator expsoition only member
         tmp as a comment to class declaration, as a private member
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18401,7 +18471,7 @@
         <p>UK<br>
         281
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.1.2.5
 
       <td width="85">
@@ -18410,7 +18480,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The current
         specification for return value will always be a true
         pointer type, but reverse_iterator supports proxy iterators
@@ -18418,12 +18488,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace the existing returns specification
         with a copy of the operator* specification that returns
         this-&gt;tmp.operator-&gt;
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18431,7 +18501,7 @@
         <p>UK<br>
         282
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.2.1,<br>
         24.4.2.2.2,<br>
         24.4.2.3,<br>
@@ -18445,17 +18515,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Insert iterators of move-only types will
         move from lvalues
 
- <td width="535">
+ <td width="536">
         <p align="left">Add an additional constrained overload for
         operator= that requires
         !CopyConstructible&lt;Cont::value_type&gt; and mark it
         =delete.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18463,7 +18533,7 @@
         <p>UK<br>
         283
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.4.2.5,<br>
         24.4.2.6.4
 
@@ -18473,7 +18543,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">postincrement operator overloads
         traditionally return by value - insert_iterator is declared
         as return by reference. The change is harmless in this
@@ -18481,19 +18551,19 @@
         matching change for consistency, or this function should
         return-by-value
 
- <td width="535">
+ <td width="536">
         <p align="left">change operator++(int) overload to return
         by value, not reference. Affects both class summary and
         operator definition in p
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 61
 
- <td width="117">
+ <td width="118">
         <p align="left">24.4.3.2.1
 
       <td width="85">
@@ -18504,18 +18574,18 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo.
 
         <p align="left" style="margin-top: 0.04in">
         "intializing" should be "in<u>i</u>tializing"
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         "i"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18523,7 +18593,7 @@
         <p>UK<br>
         284
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5
 
       <td width="85">
@@ -18532,17 +18602,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The stream
         iterators need constraining with concepts/requrires
         clauses.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide constraints
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18550,7 +18620,7 @@
         <p>UK<br>
         285
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.1
 
       <td width="85">
@@ -18559,18 +18629,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Much of the
         content of p1 and the whole of p2 is a redundant
         redefinition of InputIterator. It should be simplified
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike p2. Simplify p1 and add a
         cross-reference to the definition of InputIterator concept.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18578,7 +18648,7 @@
         <p>UK<br>
         286
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.1
 
       <td width="85">
@@ -18587,7 +18657,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">To the casual
         reader it is not clear if it is intended to be able to
         assign to istream_iterator objects. Specifying the copy
@@ -18596,12 +18666,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Either provide a similar definition to the
         copy-assign operator as for the copy constructor, or strike
         the copy constructor
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18609,7 +18679,7 @@
         <p>UK<br>
         287
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.1.1
 
       <td width="85">
@@ -18618,7 +18688,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is not clear
         what the intial state of an istream_iterator should be. Is
         _value_ initialized by reading the stream, or default/value
@@ -18630,12 +18700,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Specify _value_ is initialized by reading
         the stream, or the iterator takes on the end-of-stream
         value if the stream is empty
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18643,7 +18713,7 @@
         <p>UK<br>
         288
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.1.1
 
       <td width="85">
@@ -18652,18 +18722,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The provided specification is vacuous,
         offering no useful information.
 
- <td width="535">
+ <td width="536">
         <p align="left">Either strike
         the specification of the copy constructor, or simply
         replace it with an = default definition.
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18671,7 +18741,7 @@
         <p>UK<br>
         289
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.1.2
 
       <td width="85">
@@ -18680,7 +18750,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">It is very hard
         to pick up the correct specification for
         istream_iterator::operator== as the complete specification
@@ -18692,12 +18762,12 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Merge 24.5.1p3, equality comparison of
         end-of-stream-iterators, into 24.5.1.2p6, the specification
         of the equality operator for istream_iterator.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18705,7 +18775,7 @@
         <p>UK<br>
         290
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.2
 
       <td width="85">
@@ -18714,7 +18784,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The character
         type of a string delimiter for an ostream_iterator should
         be const charT *, the type of the elements, not char *, a
@@ -18722,10 +18792,10 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace char * with const charT *
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18733,7 +18803,7 @@
         <p>UK<br>
         291
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.2.2
 
       <td width="85">
@@ -18742,7 +18812,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">ostream_iterator
         postincrement operator returns by reference rather than by
         value. This may be a small efficiency gain, but it is
@@ -18750,17 +18820,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">ostream_iterator operator++(int);
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 34
 
- <td width="117">
+ <td width="118">
         <p>24.5.3<br>
         [istreambuf.<br>
         iterator]
@@ -18771,17 +18841,17 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>There are two public
         sections, and the content of the second one is indented
         with respect to the first. I don't it should be.
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18789,7 +18859,7 @@
         <p>UK<br>
         292
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.3
 
       <td width="85">
@@ -18798,18 +18868,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Prefer the use
         of the new nullptr constant to the zero literal when using
         a null pointer in text.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change istreambuf_iterator(0) to
         istreambuf_iterator(nullptr)
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18817,7 +18887,7 @@
         <p>UK<br>
         293
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.3
 
       <td width="85">
@@ -18826,12 +18896,12 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The listed paragraphs redundantly redefine
         an input iterator, and redundancy can be a dangerous thing
         in a specification. Suggest a simpler phrasing below.
 
- <td width="535">
+ <td width="536">
         <p align="left">2. The result of
         operator*() on an end of stream is undefined. For any other
         iterator value a char_type value is returned. 3. Two end of
@@ -18844,7 +18914,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18852,7 +18922,7 @@
         <p>UK<br>
         294
 
- <td width="117">
+ <td width="118">
         <p align="justify">24.5.3.2
 
       <td width="85">
@@ -18861,12 +18931,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Implicit converting constructors can be
         invoked at surprising times, so there should always be a
         good reason for declaring one.
 
- <td width="535">
+ <td width="536">
         <p align="left">Mark the two
         single-argument constructors take a stream or stream buffer
         as explicit. The proxy constructor should remain implicit.
@@ -18878,7 +18948,7 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18886,7 +18956,7 @@
         <p>UK<br>
         295
 
- <td width="117">
+ <td width="118">
         <p align="justify">25
 
       <td width="85">
@@ -18895,7 +18965,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">THere is a level
         of redundancy in the library specification for many
         algorithms that can be eliminated with the combination of
@@ -18905,17 +18975,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Adopt n2743, or an update of that paper.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 62
 
- <td width="117">
+ <td width="118">
         <p align="left">25, 25.3.1.5,<br>
         26.3.6.5
 
@@ -18925,7 +18995,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-left: 0.2in; text-indent: -0.2in; margin-bottom: 0in">
         The return types of is_sorted_until function and
@@ -18941,14 +19011,14 @@
         <p align="left" style=
         "text-indent: 0.2in; margin-top: 0.04in"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Change "is_sorted_until" to "sorted_bound"
 
         <p align="left" style="margin-top: 0.04in">
         Change "is_heap" to "heap_bound"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18956,7 +19026,7 @@
         <p>UK<br>
         296
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.1.8
 
       <td width="85">
@@ -18965,7 +19035,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The 'Returns' of
         adjacent_find requires only HasEqualTo, or a Predicate.
         Requiring EqualityComparable or EquivalenceRelation seems
@@ -18973,11 +19043,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change EqualityComparable to HasEqualTo and
         EquivalnceRelation to Predicate
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -18985,7 +19055,7 @@
         <p>UK<br>
         297
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.2.11
 
       <td width="85">
@@ -18994,19 +19064,19 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The definition
         of rotate_copy is very complicated. It is equivalent to:
         return copy(first, middle, copy(middle, last, result));
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change 'effects' to, returns, requires,
         complexity to: effects: equivalent to: return copy(first,
         middle, copy(middle, last, result));
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19014,7 +19084,7 @@
         <p>UK<br>
         298
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.2.13
 
       <td width="85">
@@ -19023,15 +19093,15 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">partition_point requires a partitioned
         array
 
- <td width="535">
+ <td width="536">
         <p align="left">requires: is_partitioned(first, last, pred)
         != false;
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19039,7 +19109,7 @@
         <p>UK<br>
         299
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.2.2
 
       <td width="85">
@@ -19048,19 +19118,19 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Should be consistent in style use of
         concepts in template parameter lists. The
         auto-OutputIterator sytle used in std::copy is probably
         preferred.
 
- <td width="535">
+ <td width="536">
         <p align="left">Change way signature is declared:
         template&lt;InputIterator InIter, OutputIterator&lt;auto,
         RvalueOf&lt;InIter::reference&gt;::type&gt; OutIter&gt;
         OutIter move(InIter first, InIter last, OutIter result);
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19068,7 +19138,7 @@
         <p>UK<br>
         300
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.2.3
 
       <td width="85">
@@ -19077,7 +19147,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Since publishing
         the original standard, we have learned that swap is a
         fundamental operation, and several common idioms rely on it
@@ -19093,14 +19163,14 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move primary swap template from
         &lt;algorithm&gt; into &lt;utility&gt;. Move 25.2.3 to
         somewhere under 20.2. Require &lt;algorithm&gt; to #include
         &lt;utility&gt; to access pair and provide legacy support
         for finding swap.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19108,7 +19178,7 @@
         <p>UK<br>
         301
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.2.5
 
       <td width="85">
@@ -19117,7 +19187,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">replace and
         replace_if have the requirement: OutputIterator&lt;Iter,
         Iter::reference&gt; Which implies they need to copy some
@@ -19128,11 +19198,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove OutputIterator&lt;Iter,
         Iter::reference&gt; from replace and replace_if
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19140,7 +19210,7 @@
         <p>UK<br>
         302
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.3
 
       <td width="85">
@@ -19149,18 +19219,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">the concept
         StrictWeakOrder covers the definition of a strict weak
         ordering, described in paragraph 4.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove 4, and mention StrictWeakOrder in
         paragraph 1.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19168,7 +19238,7 @@
         <p>UK<br>
         303
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.3
 
       <td width="85">
@@ -19177,18 +19247,18 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">This paragraph just describes
         is_partitioned
 
- <td width="535">
+ <td width="536">
         <p align="left">6 A sequence
         [start,finish) is partitioned with respect to an expression
         f(e) if is_partitioned(start, finish, e) != false
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19196,7 +19266,7 @@
         <p>UK<br>
         304
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.3.6
 
       <td width="85">
@@ -19205,17 +19275,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The requires
         clauses of push_heap, pop_heap and make_heap are
         inconsistently formatted, dispite being identical
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Format them identically.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19223,7 +19293,7 @@
         <p>UK<br>
         305
 
- <td width="117">
+ <td width="118">
         <p align="justify">25.3.7
 
       <td width="85">
@@ -19232,23 +19302,23 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The negative requirement on IsSameType is a
         hold-over from an earlier draught with a variadic template
         form of min/max algorith. It is no longer necessary.
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike the !IsSameType&lt;T, Compare&gt;
         constraint on min/max/minmax algorithms
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 84
 
- <td width="117">
+ <td width="118">
         <p align="left">26
 
       <td width="85">
@@ -19257,23 +19327,23 @@
       <td width="62">
         <p align="left">ge
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Parts of the numerics chapter are not concept enabled.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 35
 
- <td width="117">
+ <td width="118">
         <p>26.3<br>
         [Complex<br>
 &nbsp;numbers]
@@ -19284,7 +19354,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>Instantiations of the class
         template complex&lt;&gt; have to be allowed for integral
         types, to reflect existing practice and ISO standards
@@ -19292,10 +19362,10 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19303,7 +19373,7 @@
         <p>UK<br>
         306
 
- <td width="117">
+ <td width="118">
         <p align="justify">26.4
 
       <td width="85">
@@ -19312,24 +19382,24 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Random number
         library component cannot be used in constrained templates
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide constraints for the random number
         library
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 63
 
- <td width="117">
+ <td width="118">
         <p align="left">26.4.8.5.1
 
       <td width="85">
@@ -19338,7 +19408,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left">No
         constructor of discrete_distribution that accepts
         initializer_list.
@@ -19369,21 +19439,21 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         the following constructer.
 
         <p align="left" style="margin-top: 0.04in">
         <u>discrete_distribution(initializer_list&lt;result_type&gt;);</u>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 64
 
- <td width="117">
+ <td width="118">
         <p align="left">26.5.2
 
       <td width="85">
@@ -19392,7 +19462,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">
         &#8220;valarray&lt;T&gt;&amp; operator+=
@@ -19401,12 +19471,12 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         valarray&lt;T&gt;&amp; operator+=
         (initializer_list&lt;T&gt;);
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19414,7 +19484,7 @@
         <p>UK<br>
         307
 
- <td width="117">
+ <td width="118">
         <p align="justify">26.7
 
       <td width="85">
@@ -19423,7 +19493,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">The footnote
         refers to TR1, which is not a defined term in this
         standard. Drop the reference to TR1, those templates are a
@@ -19432,17 +19502,17 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Drop the reference to TR1.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 85
 
- <td width="117">
+ <td width="118">
         <p align="left">27
 
       <td width="85">
@@ -19451,16 +19521,16 @@
       <td width="62">
         <p align="left">ge
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         input/output chapter is not concept enabled.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -19468,7 +19538,7 @@
         <p>UK<br>
         308
 
- <td width="117">
+ <td width="118">
         <p align="justify">27
 
       <td width="85">
@@ -19477,25 +19547,25 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         <span lang="en-US">iostreams library cannot be used from
         constrained templates</span>
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide constraints for the iostreams
         library, clause 27
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 65
 
- <td width="117">
+ <td width="118">
         <p align="left">27.4.4
 
       <td width="85">
@@ -19504,7 +19574,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Switch from
         &#8220;unspecified-bool-type&#8221; to<span lang=
@@ -19514,19 +19584,19 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Replace "operator <i>unspecified-bool-type</i>() const;"
         with "explicit operator bool() const;"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 66
 
- <td width="117">
+ <td width="118">
         <p align="left">27.4.4.3
 
       <td width="85">
@@ -19536,7 +19606,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Switch from
         &#8220;unspecified-bool-type&#8221; to<span lang=
@@ -19546,19 +19616,19 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Replace "operator <i>unspecified-bool-type</i>() const;"
         with "explicit operator bool() const;"
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 36
 
- <td width="117">
+ <td width="118">
         <p>27.6.1.2.2<br>
 &nbsp;[istream.<br>
         formatted.<br>
@@ -19570,7 +19640,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>iostate err = 0;
 
         <p>
@@ -19582,17 +19652,17 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>FR 37
 
- <td width="117">
+ <td width="118">
         <p>27.6.1.2.2<br>
 &nbsp;[istream.<br>
         formatted.<br>
@@ -19604,7 +19674,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>else if (lval &lt;
         numeric_limits&lt;int&gt;::min()
 
@@ -19618,17 +19688,17 @@
 
         <p>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 67
 
- <td width="117">
+ <td width="118">
         <p align="left">27.7.1
 
       <td width="85">
@@ -19637,11 +19707,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         basic_stringbuf dose not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Replace &#8220;class Allocator&#8221; to &#8220;Allocator
         Alloc&#8221;.
@@ -19767,14 +19837,14 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 68
 
- <td width="117">
+ <td width="118">
         <p align="left">27.7.2
 
       <td width="85">
@@ -19783,11 +19853,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         basic_istringstream dose not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Replace &#8220;class Allocator&#8221; to &#8220;Allocator
         Alloc&#8221;.
@@ -19944,14 +20014,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 69
 
- <td width="117">
+ <td width="118">
         <p align="left">27.7.3
 
       <td width="85">
@@ -19960,11 +20030,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         basic_ostringstream dose not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Replace &#8220;class Allocator&#8221; to &#8220;Allocator
         Alloc&#8221;.
@@ -20122,14 +20192,14 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 71
 
- <td width="117">
+ <td width="118">
         <p align="left">27.7.3
 
       <td width="85">
@@ -20138,14 +20208,14 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo.
 
         <p align="left">"template" is missing in
         "class basic_ostringstream" of the title of the chapter.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -20164,14 +20234,14 @@
         <p align="left">27.7.3 Class <u>template</u>
         basic_ostringstream
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 72
 
- <td width="117">
+ <td width="118">
         <p align="left">27.7.4
 
       <td width="85">
@@ -20180,11 +20250,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         basic_stringstream dose not use concept.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Replace "class Allocator" to "Allocator Alloc".
 
@@ -20336,14 +20406,14 @@
 
         <p align="left" style="margin-top: 0.04in">}
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 73
 
- <td width="117">
+ <td width="118">
         <p align="left">27.8.1.14
 
       <td width="85">
@@ -20352,7 +20422,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">It is a problem
         from C++98, fstream cannot appoint a filename of wide
@@ -20361,18 +20431,18 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         interface corresponding to wchar_t, char16_t and char32_t.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 86
 
- <td width="117">
+ <td width="118">
         <p align="left">28
 
       <td width="85">
@@ -20381,16 +20451,16 @@
       <td width="62">
         <p align="left">ge
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         regular expressions chapter is not concept enabled.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -20398,7 +20468,7 @@
         <p>UK<br>
         309
 
- <td width="117">
+ <td width="118">
         <p align="justify">28
 
       <td width="85">
@@ -20407,17 +20477,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Regular
         expressions cannot be used in constrained templates
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide constraints for the regular
         expression library, clause 28
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -20425,7 +20495,7 @@
         <p>UK<br>
         310
 
- <td width="117">
+ <td width="118">
         <p align="justify">28
 
       <td width="85">
@@ -20434,16 +20504,16 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The regex chapter uses iterators in the old
         pre-concept style, it should be changed to use concepts
         instead.
 
- <td width="535">
+ <td width="536">
         <p align="left">Use concepts for iterator template
         arguments throughout.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -20451,7 +20521,7 @@
         <p>UK<br>
         314
 
- <td width="117">
+ <td width="118">
         <p align="justify">28.4
 
       <td width="85">
@@ -20460,7 +20530,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The swap
         overloads for regex classes are only supplied for l-value
         references. Other sections of the library (eg 21 strings or
@@ -20470,13 +20540,13 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the missing overloads to 28.4 and the
         corresponding later sections in 28 for each swap function.
         We want to accept AMs paper which proposes a single
         overload with two r-value references
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -20484,7 +20554,7 @@
         <p>UK<br>
         315
 
- <td width="117">
+ <td width="118">
         <p align="justify">28.4
 
       <td width="85">
@@ -20493,7 +20563,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">6 Effects:
         string_type str(first, last); return
         use_facet&lt;collate&lt;charT&gt; &gt;(
@@ -20502,11 +20572,11 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Reword to effect clause to use legal
         iterator dereferences
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -20514,7 +20584,7 @@
         <p>UK<br>
         316
 
- <td width="117">
+ <td width="118">
         <p align="justify">28.4 ff
 
       <td width="85">
@@ -20523,17 +20593,17 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The constructors
         for regex classes do not have an r-value overload.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add the missing r-value constructors to
         regex classes.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -20541,7 +20611,7 @@
         <p>UK<br>
         317
 
- <td width="117">
+ <td width="118">
         <p align="justify">28.8
 
       <td width="85">
@@ -20550,12 +20620,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">basic_string has both a constructor and an
         assignment operator that accepts an initializer list,
         basic_regex should have the same.
 
- <td width="535">
+ <td width="536">
         <p align="left">In the
         basic_regex synopsis, after: basic_regex&amp;
         operator=(const charT* ptr); add: basic_regex&amp;
@@ -20566,14 +20636,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 74
 
- <td width="117">
+ <td width="118">
         <p align="left">28.8
 
       <td width="85">
@@ -20582,7 +20652,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">
         &#8220;basic_regx &amp; operator=
@@ -20591,11 +20661,11 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         basic_regx &amp; operator= (initializer_list&lt;T&gt;);
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -20603,7 +20673,7 @@
         <p>UK<br>
         318
 
- <td width="117">
+ <td width="118">
         <p align="justify">28.8.2
 
       <td width="85">
@@ -20612,17 +20682,17 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Constructor
         definition should appear with the other constructors not
         after assignment ops.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Move para 22 to just after para 17.
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
@@ -20630,7 +20700,7 @@
         <p>UK<br>
         319
 
- <td width="117">
+ <td width="118">
         <p align="justify">28.12.2
 
       <td width="85">
@@ -20639,7 +20709,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It was always expected that
         regex_token_iterator would be constructible from an array
         literal: indeed ideally this is the prefered method of
@@ -20652,7 +20722,7 @@
         initializer_lists we should use them to remove this
         particular wart.
 
- <td width="535">
+ <td width="536">
         <p align="left">To the synopsis
         for regex_token_iterator, after template &lt;std::size_t
         N&gt; regex_token_iterator(BidirectionalIterator a,
@@ -20675,14 +20745,14 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p align="left"><br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 87
 
- <td width="117">
+ <td width="118">
         <p align="left">29
 
       <td width="85">
@@ -20691,25 +20761,26 @@
       <td width="62">
         <p align="left">ge
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         atomics chapter is not concept enabled. The adopted paper,
         N2427, did have those concepts.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Create an issue for concepts in the atomics chapter. See
+ N2427. Needs to also consider issues 923 and 924.<br>
 
     <tr valign="top">
       <td width="29">
         <p>UK<br>
         311
 
- <td width="117">
+ <td width="118">
         <p align="justify">29
 
       <td width="85">
@@ -20718,25 +20789,25 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Atomic types
         cannot be used generically in a constrained template
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide constraints for the atomics
         library, clause 29
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Duplicate of US 87.<br>
 
     <tr valign="top">
       <td width="29">
         <p>UK<br>
         312
 
- <td width="117">
+ <td width="118">
         <p align="justify">29
 
       <td width="85">
@@ -20745,14 +20816,14 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The contents of the &lt;stdatomic.h&gt;
         header are not listed anywhere, and &lt;cstdatomic&gt; is
         listed as a C99 header in chapter 17. If we intend to use
         these for compatibility with a future C standard, we should
         not use them now.
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove &lt;cstdatomic&gt; from the C99
         headers in table 14. Add a new header &lt;atomic&gt; to the
         headers in table 13. Update chapter 29 to remove reference
@@ -20761,14 +20832,16 @@
         adds atomic operations to C we can add corresponding
         headers to table 14 with a TR.
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Create an issue. Assigned to Lawrence Crowl. May be
+ resolvable with a footnote for clarity stating that the header is
+ defined where it exists.<br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 75
 
- <td width="117">
+ <td width="118">
         <p align="left">29
 
       <td width="85">
@@ -20777,12 +20850,12 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">A
         definition of enum or struct is the style of C using
         typedef.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Change to a style of C++.
 
@@ -21010,15 +21083,17 @@
 
         <p align="left">}
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Recommend to reject the comment: We believe the current
+ syntax is most appropriate for an interface that is intended to be
+ highly compatible with C.<br>
 
     <tr valign="top">
       <td width="29">
         <p>UK<br>
         313
 
- <td width="117">
+ <td width="118">
         <p align="justify">29.1
 
       <td width="85">
@@ -21027,12 +21102,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">seq_cst fences don't necessarily guarantee
         ordering
         http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a new
         paragraph after 29.1 [atomics.order]p5 that says For atomic
         operations A and B on an atomic object M, where A and B
@@ -21043,14 +21118,14 @@
 
         <p align="left"><br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Hans to make proposal. See LWG Issue 926.<br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 88
 
- <td width="117">
+ <td width="118">
         <p align="left">29.2
 
       <td width="85">
@@ -21059,11 +21134,11 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The "lockfree" facilities do
         not tell the programmer enough.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Expand the "lockfree" facilities. See the attached paper
         "Issues with the C++ Standard" under Chapter 29,
@@ -21071,14 +21146,16 @@
 
         <p align="left"><br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Create an issue, will require more discussion. Assigned
+ to Lawrence. Description of issue should be based on what is in the
+ additional notes for US 88.<br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 89
 
- <td width="117">
+ <td width="118">
         <p align="left">29.3.1
 
       <td width="85">
@@ -21087,7 +21164,7 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         types in the table "Atomics for standard typedef types"
         should be typedefs, not classes. These semantics are
@@ -21095,18 +21172,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Change the classes to
         typedefs.
 
- <td width="89">
- <p align="left">Google
-
- <tr valign="top">
+ <td width="178">
+ <p align="left">LWG Issue 937. Direct the editor to turn the types into
+ typedefs as proposed in the comment. Paper approved by committee used
+ typedefs, this appears to have been introduced as an editorial change.
+ Rationale: for compatibility with C.<tr valign="top">
       <td width="29">
         <p align="left">US 90
 
- <td width="117">
+ <td width="118">
         <p align="left">29.4
 
       <td width="85">
@@ -21115,11 +21193,11 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">Are atomic functions allowed
         to have non-volatile overloads?
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Allow non-volatile overloads. See the attached paper
         "Issues with the C++ Standard, under Chapter 29, "Are
@@ -21127,14 +21205,15 @@
 
         <p align="left"><br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Create an issue. Assigned to Lawrence Crowl. Should
+ explicitly consider the process shared issue.<br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 91
 
- <td width="117">
+ <td width="118">
         <p align="left">29.4
 
       <td width="85">
@@ -21143,12 +21222,12 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">Whether or not a failed
         compare_exchange is a RMW operation (as used in 1.10
         [intro.multithread]) is unclear.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Make failing compare_exchange operations <font size="2"
         style="font-size: 11pt"><strong>not</strong> be RMW. See
@@ -21157,14 +21236,16 @@
 
         <p align="left"><br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Create an issue, goes to review. Attention: Howard.
+ Group agrees with the resolution as proposed by Anthony Williams in the
+ attached note.<br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 92
 
- <td width="117">
+ <td width="118">
         <p align="left">29.4
 
       <td width="85">
@@ -21173,11 +21254,11 @@
       <td width="62">
         <p align="left">te
 
- <td width="604">
+ <td width="514">
         <p align="left">The effect of
         memory_order_consume with atomic RMW operations is unclear.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Follow the lead of fences [atomics.fences], and promote
         memory_order_consume to memory_order_acquire with RMW
@@ -21185,14 +21266,15 @@
 
         <p align="left"><br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Create an issue. Assigned to Lawrence. Resolution
+ requires proposed wording.<br>
 
     <tr valign="top">
       <td width="29">
         <p>JP 76
 
- <td width="117">
+ <td width="118">
         <p align="left">30
 
       <td width="85">
@@ -21201,7 +21283,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">A
         description for "<i>Throws:</i> Nothing." are not unified.
 
@@ -21209,7 +21291,7 @@
         the part without throw, "<i>Throws:</i> Nothing." should be
         described.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add
         "<i>Throws:</i> Nothing." to the following.
 
@@ -21238,14 +21320,14 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Pass on to editor.<br>
 
     <tr valign="top">
       <td width="29">
         <p align="left">US 93
 
- <td width="117">
+ <td width="118">
         <p align="left">30
 
       <td width="85">
@@ -21254,17 +21336,18 @@
       <td width="62">
         <p align="left">ge
 
- <td width="604">
+ <td width="514">
         <p align="left">The
         thread chapter is not concept enabled.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left"><br>
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Create an issue. Need to find volunteers to work on
+ this.<br>
 
     <tr valign="top">
       <td width="29">
@@ -21274,7 +21357,7 @@
 
         <p>
 
- <td width="117">
+ <td width="118">
         <p align="justify">30
 
       <td width="85">
@@ -21283,23 +21366,23 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Threads library cannot be used in
         constrained templates
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide constraints for the threads
         library, clause 30
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Duplicate of US 93.<br>
 
     <tr valign="top">
       <td width="29">
         <p>UK<br>
         321
 
- <td width="117">
+ <td width="118">
         <p align="justify">30
 
       <td width="85">
@@ -21308,7 +21391,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">Throughout this
         clause, the term Requires: is used to introduce compile
         time requirements, which we expect to be replaced with
@@ -21322,18 +21405,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Decument Preconditions: paragraphs in
         17.5.2.4, and use consistently through rest of the library.
 
- <td width="89">
- <p align="left"><br>
+ <td width="178">
+ <p align="left">Pass on to editor.<br>
 
     <tr valign="top">
       <td width="29">
         <p>US 94
 
- <td width="117">
+ <td width="118">
         <p>30.1.2
 
       <td width="85">
@@ -21342,12 +21425,12 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>The first sentence of para 1 suggests that no other
         library function is permitted to call operating system or
         low level APIs.
 
- <td width="535">
+ <td width="536">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Rewrite para 1
         as: &#8220; <font color="#000000">Some functions described
@@ -21361,14 +21444,14 @@
 
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Reclassify as editorial. Pass on to editor, wording roughly as proposed.<tr valign="top">
       <td width="29">
         <p>US 95
 
- <td width="117">
+ <td width="118">
         <p>30.1.3
 
       <td width="85">
@@ -21377,11 +21460,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>&#8220;native_handle_type&#8221; is a typedef, not a
         class member.
 
- <td width="535">
+ <td width="536">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Several classes
         described in this Clause have a member native_handle (of
@@ -21398,14 +21481,15 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Not a defect. native_handle_type is a typedef, but it is also a member of
+ the classes in question.<tr valign="top">
       <td width="29">
         <p>US 96
 
- <td width="117">
+ <td width="118">
         <p>30.1.4
 
       <td width="85">
@@ -21414,10 +21498,10 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>There is no definition here for monotonic clock.
 
- <td width="535">
+ <td width="536">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">Implementations
         should use a <i>monotonic clock</i> to measure time for
@@ -21427,15 +21511,16 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue, together with UK 322. Detlef will write the issue, but not
+ proposed wording. Refer also to sections [time.clock.req] and [time.clock.monotonic].<tr valign="top">
       <td width="29">
         <p>UK<br>
         322
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.1.4
 
       <td width="85">
@@ -21444,26 +21529,29 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Not all systms
         can provide a monotonic clock. How are they expected to
         treat a _for function?
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add at least a note explaining the intent
         for systems that do not support a monotonic clock.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue, together with UK 96. Note that the specification as is
+ already allows a non-monotonic clock due to the word &quot;should&quot; rather than
+ &quot;shall&quot;. If this wording is kept, a footnote should be added to make the
+ meaning clear.<tr valign="top">
       <td width="29">
         <p>UK<br>
         323
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.2.1
 
       <td width="85">
@@ -21472,7 +21560,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The presence of
         a non-explicit variadic template constructor alongside an
         explicit single-argument constructor can lead to behaviour
@@ -21485,21 +21573,22 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Mark constructor template &lt;class F,
         class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;...
         args); as explicit and remove the single-argument
         constructor.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue, goes to review. Attention: Howard. Group agrees with the
+ proposed resolution.<tr valign="top">
       <td width="29">
         <p>UK<br>
         324
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.2.1.1
 
       <td width="85">
@@ -21508,14 +21597,14 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">thread::id
         objects should be as useable in hashing containers as they
         are in ordered associative containers.
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add thread::id
         support for std::hash
 
@@ -21525,14 +21614,15 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Not a defect. See [unord.hash], where std::thread:id is already listed as a
+ required specialization for std::hash().<tr valign="top">
       <td width="29">
         <p>JP 77
 
- <td width="117">
+ <td width="118">
         <p align="left">30.2.1.2
 
       <td width="85">
@@ -21541,7 +21631,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style=
         "margin-top: 0.04in; margin-bottom: 0.04in">
         "CopyConstructible" and "MoveConstructible" in
@@ -21552,18 +21642,18 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">Add
         a concept for constructor of thread.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
       <td width="29">
         <p>JP 78
 
- <td width="117">
+ <td width="118">
         <p align="left">30.2.1.2
 
       <td width="85">
@@ -21576,22 +21666,22 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">In
         "F and each Ti in Args", 'Ti' is not clear.
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Replace "Ti" with "args"
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Pass on to editor.<tr valign="top">
       <td width="29">
         <p>US 97
 
- <td width="117">
+ <td width="118">
         <p>30.2.1.3
 
       <td width="85">
@@ -21600,22 +21690,22 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p>detach-on-destruction may result in
         &#8220;escaped&#8221; threads accessing objects with
         bounded lifetime after the end of their lifetime.
 
- <td width="535">
+ <td width="536">
         <p>See document WG21 N2802=08-0312 written by Hans Boehm.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. To be discussed in full library group.<tr valign="top">
       <td width="29">
         <p align="left">US 98
 
- <td width="117">
+ <td width="118">
         <p align="left">30.2.1.3,<br>
         30.2.1.4
 
@@ -21625,13 +21715,13 @@
       <td width="62">
         <p align="left"><br>
 
- <td width="604">
+ <td width="514">
         <p align="left">The current defined behavior
         for the std::thread destructor is to detach the thread.
         Unfortunately, this behavior exposes programmers to tricky,
         hard-to-diagnose, undefined behavior.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Change destruction behavior to undefined behavior, with a
         note strongly encouraging termination. See the attached
@@ -21640,15 +21730,15 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Duplicate of US 97.<tr valign="top">
       <td width="29">
         <p>UK<br>
         325
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.3.3
 
       <td width="85">
@@ -21657,13 +21747,13 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">We believe constexpr literal values should
         be a more natural expression of empty tag types than extern
         objects as it should improve the compilers ability to
         optimize the empty object away completely.
 
- <td width="535">
+ <td width="536">
         <p align="left">Replace the
         extern declarations: extern const defer_lock_t defer_lock;
         extern const try_to_lock_t try_to_lock; extern const
@@ -21673,15 +21763,17 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. The current
+ specification is a &quot;hack&quot;, and the proposed specification is a better
+ &quot;hack&quot;.<tr valign="top">
       <td width="29">
         <p>UK<br>
         326
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.3.3.2.1
 
       <td width="85">
@@ -21690,7 +21782,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The precondition
         that the mutex is not owned by this thread offers
         introduces the risk of un-necessary undefined behaviour
@@ -21704,18 +21796,19 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike 30.3.3.2.1p7
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.<tr valign="top">
       <td width="29">
         <p>UK<br>
         327
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.3.3.2.2
 
       <td width="85">
@@ -21724,7 +21817,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Not clear what
         the specification for error condition
         resource_deadlock_would_occur means. It is perfectly
@@ -21743,20 +21836,23 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a precondition !owns. Change the 'i.e.'
         in the error condition to be 'e.g.' to allow for this
         condition to propogate deadlock detection by the host OS.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock
+ means for recursive locks when you are the owner. POSIX has language on
+ this, which should ideally be followed. Proposed fix is not quite right, for
+ example, try_lock should have different wording from lock.<tr valign="top">
       <td width="29">
         <p>UK<br>
         328
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.3.3.2.2
 
       <td width="85">
@@ -21765,27 +21861,28 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">There is a missing precondition that owns
         is true, or an if(owns) test is missing from the effect
         clause
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a
         precondition that owns == true. Add an error condition to
         detect a violation, rather than yield undefined behaviour.
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Handle in same issue as UK 327. Also uncertain that the proposed resolution
+ is the correct one.<tr valign="top">
       <td width="29">
         <p>UK<br>
         329
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5
 
       <td width="85">
@@ -21794,14 +21891,14 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">future, promise and packaged_task provide a
         framework for creating future values, but a simple function
         to tie all three components together is missing. Note that
         we only need a *simple* facility for C++0x. Advanced thread
         pools are to be left for TR2.
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide a simple
         function along the lines of: template&lt; typename F,
         typename ... Args &gt; requires Callable&lt; F, Args...
@@ -21824,15 +21921,16 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Not a defect. This class of feature has been rejected by the committee as a
+ whole multiple times.<tr valign="top">
       <td width="29">
         <p>UK<br>
         330
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.1
 
       <td width="85">
@@ -21841,28 +21939,29 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">30.5.1 (and then 30.5.7) refer to a
         specialisation of
         constructible_with_allocator_prefix&lt;&gt; However this
         trait is not in the CD, so references to it should be
         removed.
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the
         reference to constructible_with_allocator_prefix in 30.5.1
         Remove paragraph 30.5.7
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Related to JP 79 and therefore subset of US 93. Should be addressed under
+ the issue corresponding to US 93.<tr valign="top">
       <td width="29">
         <p>JP 79
 
- <td width="117">
+ <td width="118">
         <p align="left">30.5.1
 
       <td width="85">
@@ -21871,11 +21970,11 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">The
         concept of UsesAllocator and Allocator should be used.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -21915,15 +22014,15 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
       <td width="29">
         <p>UK<br>
         331
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.3
 
       <td width="85">
@@ -21932,7 +22031,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Not clear what
         it means for a public constructor to be 'exposition only'.
         If the intent is purely to support the library calling this
@@ -21942,20 +22041,21 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Declare the constructor as private with a
         note about intended friendship, or remove the
         exposition-only comment and document the semantics.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Assigned to Detlef. Suggested resolution probably makes
+ sense.<tr valign="top">
       <td width="29">
         <p>UK<br>
         332
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.4
 
       <td width="85">
@@ -21964,7 +22064,7 @@
       <td width="62">
         <p align="justify">Ed
 
- <td width="604">
+ <td width="514">
         <p align="left">It is not clear
         without reference to the original proposal how to use a
         future. In particular, the only way for the user to
@@ -21975,21 +22075,21 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Provide a small introductory paragraph,
         docuenting intended purpose of the future class template
         and the way futures can only be created via the promise
         API.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Pass on to editor. Detlef has volunteered to provide some wording.<tr valign="top">
       <td width="29">
         <p>UK<br>
         333
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.4
 
       <td width="85">
@@ -21998,24 +22098,24 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">We expect the complicated 3-signature
         specifcation for future::get() to be simplified to a single
         signature with a requires clause by the application of
         concepts.
 
- <td width="535">
+ <td width="536">
         <p align="left">Requires fully baked concepts for clause 30
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
       <td width="29">
         <p>UK<br>
         334
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.4
 
       <td width="85">
@@ -22024,7 +22124,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Behaviour of
         get() is undefined if calling get() while not is_ready().
         The intent is that get() is a blocking call, and will wait
@@ -22032,19 +22132,20 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Effects: If is_ready() would return false,
         block on the asynchronous result associated with *this.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.<tr valign="top">
       <td width="29">
         <p>UK<br>
         335
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.4
 
       <td width="85">
@@ -22053,7 +22154,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">
         std::unique_future is MoveConstructible, so you can
         transfer the association with an asynchronous result from
@@ -22067,22 +22168,22 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a "waitable()" function to
         unique_future (and shared_future) akin to
         std::thread::joinable(), which returns true if there is an
         associated result to wait for (whether or not it is ready).
         Then we can say: if(uf.waitable()) uf.wait();
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Requires input from Howard. Probably NAD.<tr valign="top">
       <td width="29">
         <p>UK<br>
         336
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.4
 
       <td width="85">
@@ -22091,7 +22192,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">It is possible
         to transfer ownership of the asynchronous result from one
         unique_future instance to another via the move-constructor.
@@ -22105,20 +22206,20 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a default constructor with the
         semantics that it creates a unique_future with no
         associated asynchronous result. Add a move-assignment
         operator which transfers ownership.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Detlef will look into it.<tr valign="top">
       <td width="29">
         <p>JP 80
 
- <td width="117">
+ <td width="118">
         <p align="left">30.5.4 ,<br>
         30.5.5
 
@@ -22128,7 +22229,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left">
         Typo, duplicated "&gt;"
 
@@ -22139,19 +22240,19 @@
         <p align="left" style="margin-top: 0.04in">
         <br>
 
- <td width="535">
+ <td width="536">
         <p align="left" style="margin-top: 0.04in">
         Remove one
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Pass on to editor.<tr valign="top">
       <td width="29">
         <p>UK<br>
         337
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.5
 
       <td width="85">
@@ -22160,7 +22261,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">shared_future
         should support an efficient move constructor that can avoid
         unnecessary manipulation of a reference count, much like
@@ -22168,18 +22269,18 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a move constructor
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Detlef will look into it.<tr valign="top">
       <td width="29">
         <p>UK<br>
         338
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.5
 
       <td width="85">
@@ -22188,7 +22289,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">shared_future is currently
         CopyConstructible, but not CopyAssignable. This is
         inconsistent with shared_ptr, and will surprise users.
@@ -22201,7 +22302,7 @@
         retained by declaring such an instance as "const
         shared_future".
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove "=delete"
         from the copy-assignment operator of shared_future. Add a
         move-constructor shared_future(shared_future&amp;&amp;
@@ -22216,15 +22317,15 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Detlef will look into it.<tr valign="top">
       <td width="29">
         <p>UK<br>
         339
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.6
 
       <td width="85">
@@ -22233,12 +22334,12 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">Move assignment is goiing in the wrong
         direction, assigning from *this to the passed rvalue, and
         then returning a reference to an unusable *this
 
- <td width="535">
+ <td width="536">
         <p align="left">Strike 6. 7
         Postcondition: associated state of *this is the same as the
         associated state of rhs before the call. rhs has no
@@ -22246,15 +22347,16 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.<tr valign="top">
       <td width="29">
         <p>UK<br>
         340
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.6
 
       <td width="85">
@@ -22263,7 +22365,7 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">There is an
         implied postcondition that the state of the promise is
         transferred into the future leaving the promise with no
@@ -22271,19 +22373,20 @@
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Postcondition: *this has no associated
         state.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.<tr valign="top">
       <td width="29">
         <p>UK<br>
         341
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.6
 
       <td width="85">
@@ -22292,25 +22395,25 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">promise::swap accepts its parameter by
         lvalue reference. This is inconsistent with other types
         that provide a swap member function, where those swap
         functions accept an rvalue reference
 
- <td width="535">
+ <td width="536">
         <p align="left">Change promise::swap to take an rvalue
         reference.
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Detlef will look into it. Probably ready as it.<tr valign="top">
       <td width="29">
         <p>UK<br>
         342
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.6
 
       <td width="85">
@@ -22319,26 +22422,27 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">std::promise is
         missing a non-member overload of swap. This is inconsistent
         with other types that provide a swap member function
 
         <p align="left"><br>
 
- <td width="535">
+ <td width="536">
         <p align="left">Add a non-member overload void
         swap(promise&amp;&amp; x,promise&amp;&amp; y){ x.swap(y); }
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Detlef will also look
+ into it.<tr valign="top">
       <td width="29">
         <p>UK<br>
         343
 
- <td width="117">
+ <td width="118">
         <p align="justify">30.5.6
 
       <td width="85">
@@ -22347,13 +22451,13 @@
       <td width="62">
         <p align="justify">Te
 
- <td width="604">
+ <td width="514">
         <p align="left">The move constructor of a std::promise
         object does not need to allocate any memory, so the
         move-construct-with-allocator overload of the constructor
         is superfluous.
 
- <td width="535">
+ <td width="536">
         <p align="left">Remove the
         constructor with the signature template &lt;class
         Allocator&gt; promise(allocator_arg_t, const Allocator&amp;
@@ -22361,14 +22465,15 @@
 
         <p align="left"><br>
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Create an issue. Detlef will look into it. Will solicit feedback from Pablo.
+ Note that &quot;rhs&quot; argument should also be an rvalue reference in any case.<tr valign="top">
       <td width="29">
         <p>JP 81
 
- <td width="117">
+ <td width="118">
         <p align="left">30.5.8
 
       <td width="85">
@@ -22377,12 +22482,12 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p align="left" style="margin-top: 0.04in">
         There are not requirements for F and a concept of Allocator
         dose not use.
 
- <td width="535">
+ <td width="536">
         <p align="left">
         Correct as follows.
 
@@ -22492,14 +22597,15 @@
         packaged_task(allocator_arg_t, const <u>Alloc</u>&amp; a,
         F&amp;&amp; f);
 
- <td width="89">
+ <td width="178">
         <p>
 
- <tr valign="top">
+ Subset of US 93. Should be addressed under the issue corresponding to US 93.
+ We do not consider this to be an editorial change.<tr valign="top">
       <td width="29">
         <p>DE-23
 
- <td width="117">
+ <td width="118">
         <p>Annex B
 
       <td width="85">
@@ -22508,7 +22614,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-23 Recursive
         use of constexpr functions appears to be permitted. Since
@@ -22516,18 +22622,18 @@
         compile-time, Annex B "implementation quantities" should
         specify a maximum depth of recursion.
 
- <td width="535">
+ <td width="536">
         <p>In Annex B, specify a recursion depth of 256 or a larger
         value.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-24
 
- <td width="117">
+ <td width="118">
         <p>Annex B
 
       <td width="85">
@@ -22536,23 +22642,23 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-24 The
         number of placeholders for "bind" is implementation-defined
         in 20.7.12.1.4, but no minimum is suggested in Annex B.<br>
 
- <td width="535">
+ <td width="536">
         <p>Add a miminum of 10 placeholders to Annex B.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>DE-25
 
- <td width="117">
+ <td width="118">
         <p>Annex B
 
       <td width="85">
@@ -22561,7 +22667,7 @@
       <td width="62">
         <p>te
 
- <td width="604">
+ <td width="514">
         <p style=
         "margin-top: 0.04in; margin-bottom: 0.04in">DE-25
         Specifying a minimum of 17 recursively nested template
@@ -22572,18 +22678,18 @@
         . The conclusion is that the metric "number of recursively
         nested template instantiations" is inapposite.
 
- <td width="535">
+ <td width="536">
         <p>Remove the bullet "Recursively nested template
         instantiations [17]".
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 38
 
- <td width="117">
+ <td width="118">
         <p>C.2<br>
         [diffs.library]
 
@@ -22593,7 +22699,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>What is ISO/IEC 1990:9899/DAM
         1? My guess is that's a typo for ISO/IEC
 
@@ -22603,13 +22709,13 @@
         <p>make reference to things
         which were introduced by Amd.1).
 
- <td width="535">
+ <td width="536">
         <p>One need probably a reference
         to the document which introduce char16_t and
 
         <p>char32_t in C (ISO/IEC TR 19769:2004?).
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
@@ -22617,7 +22723,7 @@
         <p>UK<br>
         344
 
- <td width="117">
+ <td width="118">
         <p align="justify">Appendix D
 
       <td width="85">
@@ -22626,27 +22732,27 @@
       <td width="62">
         <p align="justify">Ge
 
- <td width="604">
+ <td width="514">
         <p align="left">It is desirable to allow some mechanism to
         support phasing out of deprecated features in the future.
         Allowing compilers to implement a mode where deprecated
         features are not available is a good first step.
 
- <td width="535">
+ <td width="536">
         <p align="left">Add to the definition of deprecated
         features permission for compilers to maintain a
         conditionally supported mode where deprecated features can
         be disabled, so long as they also default to a mode where
         all deprecated features are supported.
 
- <td width="89">
+ <td width="178">
         <p>
 
     <tr valign="top">
       <td width="29">
         <p>FR 39
 
- <td width="117">
+ <td width="118">
         <p>Index
 
       <td width="85">
@@ -22655,7 +22761,7 @@
       <td width="62">
         <p>ed
 
- <td width="604">
+ <td width="514">
         <p>Some definitions seem not
         indexed (such as /trivially copyable/ or
 
@@ -22665,10 +22771,10 @@
         increase the usefulness; having a separate index of all
         definitions is something which could also be considered).
 
- <td width="535">
+ <td width="536">
         <p>
 
- <td width="89">
+ <td width="178">
         <p>
 
       </table><hr>
\ No newline at end of file


Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk