Boost-Commit :

Date view	Thread view	Subject view	Author view

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

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51567 - sandbox/committee/LWG"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51565 - sandbox/committee/LWG"

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">
 MB 

- <td width="117">
+ <td width="118">
 Clause No./ 
 Subclause No./ 
 Annex (e.g. 3.1)
@@ -35,13 +35,13 @@
 Figure/ Table/ Note<td width="62">
 Type 

- <td width="604">
+ <td width="514">
 Comment (justification for change) by the MB

- <td width="535">
+ <td width="536">
 Proposed change by the MB

- <td width="89">
+ <td width="178">
 
 Disposition
@@ -52,7 +52,7 @@
 <td width="29">
 FR 1

- <td width="117">
+ <td width="118">
 General 
 Comment

@@ -62,7 +62,7 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 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 @@
 We worry about the complexity
 of the programming model so created.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 1

- <td width="117">
+ <td width="118">
 1-16

 <td width="85">
@@ -90,7 +90,7 @@
 <td width="62">
 ge/te

- <td width="604">
+ <td width="514">
 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>

- <td width="535">
+ <td width="536">
 
 Appropriate action would include making changes to the CD,
 identifying an issue as not requiring a change to the CD,
@@ -112,14 +112,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 CA-1

- <td width="117">
+ <td width="118">
 

 <td width="85">
@@ -128,22 +128,22 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 There are quite a number of defects for the current CD
 recorded in SC22/WG21-N2803 and N2806

- <td width="535">
+ <td width="536">
 Consider these comments and update ISO/IEC CD 14882
 accordingly

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-1

- <td width="117">
+ <td width="118">
 1 through 16

 <td width="85">
@@ -152,7 +152,7 @@
 <td width="62">
 ge/te

- <td width="604">
+ <td width="514">
 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">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 CH 2

- <td width="117">
+ <td width="118">
 all

 <td width="85">
@@ -179,21 +179,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The issues on the issues lists shall be addressed before
 the standard becomes final.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 3

- <td width="117">
+ <td width="118">
 all

 <td width="85">
@@ -202,24 +202,24 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 Latin abbreviations are presented incorrectly.

- <td width="535">
+ <td width="536">
 Italicize all
 Latin abbreviations, append commas after each occurrence of
 i.e. and e.g., and remove extraneous space
 after each such abbreviation.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 3

- <td width="117">
+ <td width="118">
 1 [intro.scope]

 <td width="85">
@@ -228,16 +228,16 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 C++ is split at the end of line.

- <td width="535">
-  <td width="89">
+ <td width="536">
+  <td width="178">
  <tr valign="top">
 <td width="29">
 US 4

- <td width="117">
+ <td width="118">
 1.1

 <td width="85">
@@ -246,17 +246,17 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 There is a bad line break in
 "C++".

- <td width="535">
-  <td width="89">
+ <td width="536">
+  <td width="178">
  <tr valign="top">
 <td width="29">
 UK 1

- <td width="117">
+ <td width="118">
 1.1

 <td width="85">
@@ -265,24 +265,24 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Add the following to the list in 1.1p2:
 atomic operations concurrency alignment control
 user-defined literals attributes

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 4

- <td width="117">
+ <td width="118">
 1.2 [intro.refs]

 <td width="85">
@@ -291,21 +291,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 Is the lack of reference to ISO/CEI 9899/AC3:2007
 voluntary?

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 UK 2

- <td width="117">
+ <td width="118">
 1.2

 <td width="85">
@@ -314,24 +314,24 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 
 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.+

- <td width="535">
+ <td width="536">
 ... not sure ...

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 UK 3

- <td width="117">
+ <td width="118">
 1.3.1

 <td width="85">
@@ -340,12 +340,12 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 UK 4

- <td width="117">
+ <td width="118">
 1.3.3

 <td width="85">
@@ -376,26 +376,26 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 ... 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">
 

 <tr valign="top">
 <td width="29">
 FR 5

- <td width="117">
+ <td width="118">
 1.3.4 
 [defns. 
 dynamic.type]
@@ -406,21 +406,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 "The dynamic type of an rvalue expression is its static
 type." Is this true with rvalue references?

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 5

- <td width="117">
+ <td width="118">
 1.3.5

 <td width="85">
@@ -429,22 +429,22 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Reword to clarify that it is the input that is here
 considered not well-formed.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 6

- <td width="117">
+ <td width="118">
 1.3.6 
 [defns. 
 impl.defined]
@@ -455,21 +455,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 There is a page break between the title and the
 paragraph.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 7

- <td width="117">
+ <td width="118">
 1.3.13 
 [defns. 
 undefined]
@@ -480,22 +480,22 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 [intro.execution]/5 explicitly allows non causal
 undefined behaviour,

- <td width="535">
+ <td width="536">
 Adding it to the note outlying possible undefined
 behaviours.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 6

- <td width="117">
+ <td width="118">
 1.3.14

 <td width="85">
@@ -504,7 +504,7 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 
 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?) 

- <td width="535">
+ <td width="536">
 Clearly state whether or not
 Unspecified behavior includes undefined behavior.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 8

- <td width="117">
+ <td width="118">
 1.4 
 [intro. 
 compliance]
@@ -534,23 +534,23 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 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">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 UK 5

- <td width="117">
+ <td width="118">
 1.5

 <td width="85">
@@ -559,22 +559,22 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 Missing checklist of implementation defined
 behaviour (see ISO/IEC TR 10176, 4.1.1p6)

- <td width="535">
+ <td width="536">
 Provide a new annex with the missing
 checklist

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 UK 6

- <td width="117">
+ <td width="118">
 1.5

 <td width="85">
@@ -583,23 +583,23 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 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">
 Provide a new annex with the missing
 documentation. See n2733(08-0243) for a starting point

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 7

- <td width="117">
+ <td width="118">
 1.5

 <td width="85">
@@ -608,21 +608,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 There is no mention of Clause 17.

- <td width="535">
+ <td width="536">
 Include Clause 17 among the list of Clauses that specify
 the Standard Library.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 8

- <td width="117">
+ <td width="118">
 1.5

 <td width="85">
@@ -631,24 +631,24 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The paragraph
 omits to mention concepts and concept maps among its list
 of entities defined in the Standard Library. 

- <td width="535">
+ <td width="536">
 Mention concepts and concept maps among the list of
 entities.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 9

- <td width="117">
+ <td width="118">
 1.6

 <td width="85">
@@ -657,21 +657,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The
 syntax description does not account for lines that wrap. 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 10

- <td width="117">
+ <td width="118">
 1.7

 <td width="85">
@@ -680,22 +680,22 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The term thread is used before
 defined.

- <td width="535">
+ <td width="536">
 Reference 1.10 [intro.multithread].

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 11

- <td width="117">
+ <td width="118">
 1.7

 <td width="85">
@@ -704,21 +704,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The phrase “threads of execution” should be
 accompanied by a reference to [intro.multithread].

- <td width="535">
+ <td width="536">
 Insert the recommended reference.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 12

- <td width="117">
+ <td width="118">
 1.7

 <td width="85">
@@ -727,22 +727,22 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 A memory location is not an object as the sentence
 claims.

- <td width="535">
+ <td width="536">
 Clarify that a memory location “holds” an
 object rather than that it “is” an object.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 13

- <td width="117">
+ <td width="118">
 1.7

 <td width="85">
@@ -751,24 +751,24 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Provide either a better definition of
 “separate” or reword (this and subsequent
 paragraphs) to avoid this term.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 14

- <td width="117">
+ <td width="118">
 1.7

 <td width="85">
@@ -777,23 +777,23 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Delete the “no matter…” phrase, or
 resolve the contradiction in a different way.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 15

- <td width="117">
+ <td width="118">
 1.7

 <td width="85">
@@ -802,22 +802,22 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 A struct does not “contain” memory
 locations.

- <td width="535">
+ <td width="536">
 Reword so that a struct is “held in” one or
 more memory locations.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 16

- <td width="117">
+ <td width="118">
 1.9

 <td width="85">
@@ -826,23 +826,23 @@
 <td width="62">
 

- <td width="604">
+ <td width="514">
 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”.

- <td width="535">
+ <td width="536">
 Remove/replace various occurrences of "sequence" in 1.9.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 UK 8

- <td width="117">
+ <td width="118">
 1.9

 <td width="85">
@@ -851,13 +851,13 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 UK 7

- <td width="117">
+ <td width="118">
 1.9

 <td width="85">
@@ -881,7 +881,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Replace 'sequence' with 'sequences'.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 9

- <td width="117">
+ <td width="118">
 1.9 
 [intro.execution]

@@ -910,21 +910,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 This example use int *v while the other examples seems
 to use notation like int* v.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 17

- <td width="117">
+ <td width="118">
 1.10

 <td width="85">
@@ -933,14 +933,14 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 This definition of
 “thread” 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">
 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">
 

 <tr valign="top">
 <td width="29">
 UK 9

- <td width="117">
+ <td width="118">
 2.1

 <td width="85">
@@ -973,14 +973,14 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 UK 10

- <td width="117">
+ <td width="118">
 2.1

 <td width="85">
@@ -1007,26 +1007,26 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 How the compiler treats non-empty sequences
 of whitespace should be left unspecified, rather than
 implementation-defined.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 10

- <td width="117">
+ <td width="118">
 2.1 [lex.phases]/5 
 and 
 2.2 [lex.charset]/3
@@ -1037,7 +1037,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 [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">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1077,7 +1077,7 @@

 11

- <td width="117">
+ <td width="118">
 2.3

 <td width="85">
@@ -1086,18 +1086,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Deprecate the whole of 2.3 and move it to
 appendix D.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1107,7 +1107,7 @@

 12

- <td width="117">
+ <td width="118">
 2.4, 2.8

 <td width="85">
@@ -1116,7 +1116,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Replace undefined behaviour with
 conditionally supported behaviour with implementation
 defined semantics.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 18

- <td width="117">
+ <td width="118">
 2.4

 <td width="85">
@@ -1146,20 +1146,20 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The paragraph begins with an empty line.

- <td width="535">
+ <td width="536">
 Delete the empty line.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 11

- <td width="117">
+ <td width="118">
 2.4 
 [lex.pptokens]

@@ -1169,20 +1169,20 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 There are spurious empty lines.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 12

- <td width="117">
+ <td width="118">
 2.5 [lex.digraph] 
 and 2.11 
 [lex.key]/2
@@ -1193,21 +1193,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The alternative representations are reserved as such
 even in attribute. Is that what is wanted?

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FI 2

- <td width="117">
+ <td width="118">
 2.5

 <td width="85">
@@ -1216,14 +1216,14 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Add eq, for spelling out == in order to distinguish it
 from the assignment operator.

- <td width="535">
+ <td width="536">
 See eq-keyword.doc, eq-keyword.ppt

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1233,7 +1233,7 @@

 13

- <td width="117">
+ <td width="118">
 2.9

 <td width="85">
@@ -1242,17 +1242,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -1262,7 +1262,7 @@

 14

- <td width="117">
+ <td width="118">
 2.11

 <td width="85">
@@ -1271,22 +1271,22 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The table is
 nearly sorted, but not quite. It was sorted in previous
 versions of the standard.

- <td width="535">
+ <td width="536">
 Sort the table.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 1

- <td width="117">
+ <td width="118">
 2.11

 <td width="85">
@@ -1295,22 +1295,22 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 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">
 Sort it in alphabetical order.
 Complete the table frame.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 19

- <td width="117">
+ <td width="118">
 2.13.1

 <td width="85">
@@ -1322,22 +1322,22 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The final entry in the last column (“unsigned long
 int”) is incorrect.

- <td width="535">
+ <td width="536">
 Replace the incorrect entries by “unsigned long
 long int”.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 20

- <td width="117">
+ <td width="118">
 2.13.1, 
 2.13.3

@@ -1347,12 +1347,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Long strings of digits in
 literals are a continuing problem in the production and
 maintenance of programs.

- <td width="535">
+ <td width="536">
 
 Adopt the 1983 technology of Ada and use underscores to
 separate digits. <a href=
@@ -1360,7 +1360,7 @@
 target=
 "_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html>

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1370,7 +1370,7 @@

 15

- <td width="117">
+ <td width="118">
 2.13.2

 <td width="85">
@@ -1379,18 +1379,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Inconsistency between definition of a
 multicharacter literal and a wide character literal
 containing multiple c-chars.

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -1400,7 +1400,7 @@

 16

- <td width="117">
+ <td width="118">
 2.13.2

 <td width="85">
@@ -1409,21 +1409,21 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Not immediately clear why the question mark
 needs escaping. A note would help.

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 JP 2

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1434,21 +1434,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 Typo, R"..." should be
 R"[...]"

- <td width="535">
+ <td width="536">
 Correct typo.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 3

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1456,11 +1456,11 @@
 style="font-size: 11pt">para<td width="62">
 te

- <td width="604">
+ <td width="514">
 We think that the explanation of d-char-sequence is not
 enough.

- <td width="535">
+ <td width="536">
 Add
 the following.

@@ -1519,14 +1519,14 @@
 - end note]

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 4

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1538,7 +1538,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo. Lack of a necessary backslash in the first line of
 the example as follows:
@@ -1570,17 +1570,17 @@

 c]";

- <td width="535">
+ <td width="536">
 Correct typo.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 21

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1589,22 +1589,22 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The paragraph, marked as a Note, contains an embedded
 example not marked as such.

- <td width="535">
+ <td width="536">
 Denote the code (and perhaps also its commentary) as an
 Example.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 22

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1613,21 +1613,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The code does not have the effect predicted by its
 accompanying narrative.

- <td width="535">
+ <td width="536">
 Append a backslash to the first line of the code.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 5

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1638,21 +1638,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 It is not explicit how to combine raw-string and
 non-raw-string.

- <td width="535">
+ <td width="536">
 Add rules containing raw-string in the table 7.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 13

- <td width="117">
+ <td width="118">
 2.13.4 
 [lex.string]

@@ -1662,15 +1662,15 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 Shouldn't the assert be

 assert(std::strcmp(p, "a\nb\nc") == 0);

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1680,7 +1680,7 @@

 17

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1689,7 +1689,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 (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">
 

 <tr valign="top">
@@ -1718,7 +1718,7 @@

 18

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1727,7 +1727,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -1758,7 +1758,7 @@

 19

- <td width="117">
+ <td width="118">
 2.13.4

 <td width="85">
@@ -1767,12 +1767,12 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 FR 14

- <td width="117">
+ <td width="118">
 3 [basic]

 <td width="85">
@@ -1797,12 +1797,12 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 "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">
 Would prefer

 "... before continuing to
@@ -1817,14 +1817,14 @@
 as some names denotes entities declared after the first
 occurrence.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 15

- <td width="117">
+ <td width="118">
 3 [basic]

 <td width="85">
@@ -1833,15 +1833,15 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 /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">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1851,7 +1851,7 @@

 20

- <td width="117">
+ <td width="118">
 3

 <td width="85">
@@ -1860,7 +1860,7 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 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">
 Change the title to "Basic definitions".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1881,7 +1881,7 @@

 21

- <td width="117">
+ <td width="118">
 3

 <td width="85">
@@ -1890,16 +1890,16 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Rename the chapter Basic ???. THe note in
 p2 specifically needs similar rewording

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1909,7 +1909,7 @@

 22

- <td width="117">
+ <td width="118">
 3

 <td width="85">
@@ -1918,16 +1918,16 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 References are
 frequently considered variables, but this definition only
 applies to objects.

- <td width="535">
+ <td width="536">
 Add "or reference" after both uses of
 "object"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1937,7 +1937,7 @@

 23

- <td width="117">
+ <td width="118">
 3.1

 <td width="85">
@@ -1946,16 +1946,16 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 
 alias-declarations are not definitions and should be added
 to the list

- <td width="535">
+ <td width="536">
 Add alias-declaration after typedef
 declaration.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -1965,7 +1965,7 @@

 24

- <td width="117">
+ <td width="118">
 3.1

 <td width="85">
@@ -1974,7 +1974,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -1998,7 +1998,7 @@

 25

- <td width="117">
+ <td width="118">
 3.1

 <td width="85">
@@ -2007,7 +2007,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Remove the : s() from the illustrated
 default constructor: struct C { std::string s; C() { }
 C(const C& x): s(x.s) { } C& operator=(const C&
 x) { s = x.s; return *this; } ~C() { } };

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2031,7 +2031,7 @@

 26

- <td width="117">
+ <td width="118">
 3.2

 <td width="85">
@@ -2040,16 +2040,16 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -2059,7 +2059,7 @@

 27

- <td width="117">
+ <td width="118">
 3.2

 <td width="85">
@@ -2068,23 +2068,23 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 A class type
 must be complete when catching exceptions, even by
 reference or pointer. See 15.3.

- <td width="535">
+ <td width="536">
 Add "when used in an exception-handler
 (15.3)" to the list.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 16

- <td width="117">
+ <td width="118">
 3.3 
 [Declarative 
 regions and scopes.]
@@ -2095,15 +2095,15 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The scope of function
 parameters is defined, but what is the scope of template
 parameters?

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2113,7 +2113,7 @@

 28

- <td width="117">
+ <td width="118">
 3.3.1

 <td width="85">
@@ -2122,14 +2122,14 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Class templates
 are not classes, so we should include this case.

- <td width="535">
+ <td width="536">
 ammend "class" to "class or class template"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2139,7 +2139,7 @@

 29

- <td width="117">
+ <td width="118">
 3.3.10

 <td width="85">
@@ -2148,27 +2148,27 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 FR 17

- <td width="117">
+ <td width="118">
 3.5 [Program 
 and linkage]

@@ -2178,7 +2178,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2198,7 +2198,7 @@
 UK 
 30

- <td width="117">
+ <td width="118">
 3.5

 <td width="85">
@@ -2207,17 +2207,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Add a note to clarify that concepts don't
 need linkage.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2225,7 +2225,7 @@
 UK 
 31

- <td width="117">
+ <td width="118">
 3.5

 <td width="85">
@@ -2234,7 +2234,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Clarify rules for namespaces inside nested
 namespaces, or remove the restriction.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 23

- <td width="117">
+ <td width="118">
 3.5

 <td width="85">
@@ -2262,21 +2262,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 Bad
 paragraph break.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 18

- <td width="117">
+ <td width="118">
 3.5 
 [basic.link]

@@ -2286,20 +2286,20 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The paragraph number is not aligned with the text.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 19

- <td width="117">
+ <td width="118">
 3.6 [Start 
 and 
 termination]
@@ -2310,7 +2310,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 This section completely
 ignores the real world and practical case of dynamically
 linked or loaded libraries. In current computing
@@ -2324,10 +2324,10 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2335,7 +2335,7 @@
 UK 
 32

- <td width="117">
+ <td width="118">
 3.6.1

 <td width="85">
@@ -2344,22 +2344,22 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Do we really want to allow: constexpr int
 main() { return 0; } as a valid program?

- <td width="535">
+ <td width="536">
 Add constexpr to
 the list of ill-formed things to annotate main 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 24

- <td width="117">
+ <td width="118">
 3.6.1

 <td width="85">
@@ -2368,11 +2368,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 std::quick_exit is not
 referenced.

- <td width="535">
+ <td width="536">
 
 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.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 25

- <td width="117">
+ <td width="118">
 3.6.3

 <td width="85">
@@ -2397,21 +2397,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The parenthesized phrase, introduced via
 “i.e.” is in the nature of an example.

- <td width="535">
+ <td width="536">
 Change “i.e.” to “e.g.”

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 6

- <td width="117">
+ <td width="118">
 3.7.4.1

 <td width="85">
@@ -2423,7 +2423,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo.

@@ -2463,17 +2463,17 @@

 

- <td width="535">
+ <td width="536">
 Correct typo.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-3

- <td width="117">
+ <td width="118">
 3.7.4.3

 <td width="85">
@@ -2482,7 +2482,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 DE-3 It is
 unclear whether the following code has well-defined
@@ -2495,18 +2495,18 @@

 delete &i;

- <td width="535">
+ <td width="536">
 Clarify that &i is considered a safely-derived
 pointer value.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 26

- <td width="117">
+ <td width="118">
 3.8

 <td width="85">
@@ -2515,11 +2515,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Use of object fields during
 destruction is excessively and erroneously constrained.

- <td width="535">
+ <td width="536">
 See
 the attached document "Issues with the C++ Standard" under
 Chapter 3 "Use of objects, especially from other threads,
@@ -2527,14 +2527,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 27

- <td width="117">
+ <td width="118">
 3.9

 <td width="85">
@@ -2543,21 +2543,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 There is a superfluous/extraneous “and”.

- <td width="535">
+ <td width="536">
 Delete “and” from the phrase “and
 std::nullptr_t”.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 20

- <td width="117">
+ <td width="118">
 3.9 [Types]

 <td width="85">
@@ -2566,7 +2566,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 7

- <td width="117">
+ <td width="118">
 3.9.2

 <td width="85">
@@ -2597,11 +2597,11 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 over-aligned type was added as new notion. So it is
 preferable to add the link after that.

- <td width="535">
+ <td width="536">
 Add
 (3.11) after over-aligned type as the link.

@@ -2618,14 +2618,14 @@
 valid pointer value for an over-aligned type(3.11).—end note ]

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 28

- <td width="117">
+ <td width="118">
 3.9.3

 <td width="85">
@@ -2634,23 +2634,23 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The closing
 braces of the first two sets are preceded by extraneous
 space.

- <td width="535">
+ <td width="536">
 Delete the extra spaces.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE 4

- <td width="117">
+ <td width="118">
 4.2

 <td width="85">
@@ -2659,14 +2659,14 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 CH 1

- <td width="117">
+ <td width="118">
 4.9 and 5.2.9

 <td width="85">
@@ -2693,12 +2693,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 With respect to the target type, pointer to members
 should behave like normal pointers (least surprise
 principle).

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 DE-5

- <td width="117">
+ <td width="118">
 4.11, 
 5.3.1, 
 5.5
@@ -2725,18 +2725,18 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 DE-5 Ref-qualification has not been integrated with
 pointer-to-members.

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -2744,7 +2744,7 @@
 UK 
 33

- <td width="117">
+ <td width="118">
 4.13

 <td width="85">
@@ -2753,20 +2753,20 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -2774,7 +2774,7 @@
 UK 
 34

- <td width="117">
+ <td width="118">
 4.13

 <td width="85">
@@ -2783,15 +2783,15 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 6th bullet, "the
 rank of char" - first letter should be capitalised for
 consistency with the other bullets

- <td width="535">
+ <td width="536">
 The rank of char

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2799,7 +2799,7 @@
 UK 
 36

- <td width="117">
+ <td width="118">
 5.1

 <td width="85">
@@ -2808,15 +2808,15 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Delete this paragraph.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2824,7 +2824,7 @@
 UK 
 37

- <td width="117">
+ <td width="118">
 5.1

 <td width="85">
@@ -2833,16 +2833,16 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Member function
 templates are not member functions, so should also be
 listed in the 3rd bullet

- <td width="535">
+ <td width="536">
 Add member function templates to the 3rd
 bullet

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -2850,7 +2850,7 @@
 UK 
 38

- <td width="117">
+ <td width="118">
 5.1

 <td width="85">
@@ -2859,7 +2859,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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->memfun(); } )
 my_lambda;

- <td width="535">
+ <td width="536">
 ... words to follow ...

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 8

- <td width="117">
+ <td width="118">
 5.1

 <td width="85">
@@ -2887,7 +2887,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 In
 the current syntax definition, a scope operator(::) cannot
 be applied to decltype, but it should be. It would be
@@ -2900,7 +2900,7 @@
 decltype(v)::value_type i = 0;
 // int i = 0;

- <td width="535">
+ <td width="536">
 Add
 “decltype ( expression ) :: “ 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">
 

 <tr valign="top">
 <td width="29">
 JP 9

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -2949,7 +2949,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 It
 would be preferable that “&&” could be
 specified in a lambda expression to declare move capture.
@@ -3123,20 +3123,20 @@

 

- <td width="535">
+ <td width="536">
 Add
 move capture in a lambda expression.

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 10

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3145,7 +3145,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Add
 result_type to the syntax of an unnamed function object
 generated by a lambda expression.

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 29

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3204,22 +3204,22 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 standard does not state whether or not direct recursion of
 lambdas is possible.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 30

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3228,7 +3228,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 The standard does not clarify the
 meaning of 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 31

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3256,7 +3256,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 The current wording does not specify
 how context capturing and name resolution
@@ -3264,10 +3264,10 @@
 inner lambda refers to the outer lambda's locals variables
 and parameters.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3275,7 +3275,7 @@
 UK 
 45

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3284,13 +3284,13 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Lambda is a language feature with an
 apparent dependency on <functional>. 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">
 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">
 

 <tr valign="top">
@@ -3312,7 +3312,7 @@

 

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3321,15 +3321,15 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The
 final italic "this" in the paragraph should be a teletype
 "this".

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3337,7 +3337,7 @@
 UK 
 39

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3346,16 +3346,16 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Add "F has an implicitly-declared
 destructor".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3363,7 +3363,7 @@
 UK 
 40

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3372,7 +3372,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 If one or more
 names in the effective capture set are preceded by &,
 the effect of invoking a closure object or a copy after the
@@ -3384,13 +3384,13 @@
 behaviour: int i; reference_closure<void ()> f; if
 (blah) { f = [&i]() { }; } if (f) f();

- <td width="535">
+ <td width="536">
 If one or more names in the effective
 capture set are preceded by &, 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">
 

 <tr valign="top">
@@ -3398,7 +3398,7 @@
 UK 
 41

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3407,7 +3407,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Replace inheritance with implicit
 conversion.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3430,7 +3430,7 @@
 UK 
 42

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3439,14 +3439,14 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3465,7 +3465,7 @@
 UK 
 43

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3474,7 +3474,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 ... provvide exceptions in the right places
 ...

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3497,7 +3497,7 @@
 UK 
 44

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3506,7 +3506,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 There is a
 strong similarity between a [&]{} lambda capturing a
 stack frame, and a [this]{} lambda binding a member
@@ -3519,12 +3519,12 @@

 

- <td width="535">
+ <td width="536">
 Extend reference_closure requirement to
 cover [this] lambdas. Consider a simple syntax for creating
 such bound expressions.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3532,7 +3532,7 @@
 UK 
 46

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3541,7 +3541,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Replace text "is
 publicly derived from" with "shall be implemented in a
 manner indistinguishable from". This places an ABI
@@ -3559,14 +3559,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-6

- <td width="117">
+ <td width="118">
 5.1.1, 20.7.18

 <td width="85">
@@ -3575,7 +3575,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 DE-7

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3604,21 +3604,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 DE-7 The note at the end of paragraph 10 appears to be
 garbled.

- <td width="535">
+ <td width="536">
 Remove "or references" in the note.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-8

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3627,23 +3627,23 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Add bullets that say that the ref-qualifier and the
 attribute-specifier are absent.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 33

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3652,11 +3652,11 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 There is no definition of “move constructor”
 or “move operation”

- <td width="535">
+ <td width="536">
 Since this is
 the first place the terms are used, a definition should
@@ -3664,14 +3664,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-9

- <td width="117">
+ <td width="118">
 5.1.1

 <td width="85">
@@ -3680,7 +3680,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Add a few well-chosen examples.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3699,7 +3699,7 @@
 UK 
 52

- <td width="117">
+ <td width="118">
 5.2

 <td width="85">
@@ -3708,14 +3708,14 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 This paragraph seens out of place,
 assignment expressions are covered in 5.17

- <td width="535">
+ <td width="536">
 Move p3 to subsection 5.17

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3723,7 +3723,7 @@
 UK 
 53

- <td width="117">
+ <td width="118">
 5.2.1

 <td width="85">
@@ -3732,7 +3732,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -3754,7 +3754,7 @@
 UK 
 59

- <td width="117">
+ <td width="118">
 5.2.2

 <td width="85">
@@ -3763,7 +3763,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 <class ... Types> void f(Types ... pack);
 f(1, 2, 3);

- <td width="535">
+ <td width="536">
 Clarify that this sentence only applies
 where the ellipsis is used.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3783,7 +3783,7 @@
 UK 
 60

- <td width="117">
+ <td width="118">
 5.2.5

 <td width="85">
@@ -3792,15 +3792,15 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Add "and" before vq

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3808,7 +3808,7 @@
 UK 
 61

- <td width="117">
+ <td width="118">
 5.2.5

 <td width="85">
@@ -3817,18 +3817,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Clarify in footnote 60 that this will not
 happen if the whole expression is an unevaluated operand.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3836,7 +3836,7 @@
 UK 
 62

- <td width="117">
+ <td width="118">
 5.2.5

 <td width="85">
@@ -3845,24 +3845,24 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Replace 'not an lvalue' with 'is an
 rvalue'.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-10

- <td width="117">
+ <td width="118">
 5.2.5

 <td width="85">
@@ -3871,16 +3871,16 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Adjust the presentation of the types involved as
 appropriate.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3888,7 +3888,7 @@
 UK 
 63

- <td width="117">
+ <td width="118">
 5.2.6

 <td width="85">
@@ -3897,13 +3897,13 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Paragraph 2 is missing its number.

- <td width="535">
+ <td width="536">
 Add one.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3911,7 +3911,7 @@
 UK 
 64

- <td width="117">
+ <td width="118">
 5.2.7

 <td width="85">
@@ -3920,11 +3920,11 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3940,7 +3940,7 @@
 UK 
 65

- <td width="117">
+ <td width="118">
 5.2.7

 <td width="85">
@@ -3949,7 +3949,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Replace "an lvalue referring to" with
 "reference", twice.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3970,7 +3970,7 @@
 UK 
 66

- <td width="117">
+ <td width="118">
 5.2.8

 <td width="85">
@@ -3979,18 +3979,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 typeid may
 return "an implementation-defined class derived from std ::
 type_info". The derivation must be public.

 

- <td width="535">
+ <td width="536">
 an implementation-defined class publicly
 derived from std :: type_info

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -3998,7 +3998,7 @@
 UK 
 67

- <td width="117">
+ <td width="118">
 5.2.9

 <td width="85">
@@ -4007,11 +4007,11 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Paragraph 1 specifies when the result of
 static_cast is an lvalue; repeating it is unnecessary.

- <td width="535">
+ <td width="536">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4029,7 +4029,7 @@
 UK 
 54

- <td width="117">
+ <td width="118">
 5.2.10

 <td width="85">
@@ -4038,13 +4038,13 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 In para 6,
 replace unspecified with implementation-defined.
 Alternatively, delete paragraph 3, since individual cases
@@ -4052,7 +4052,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4060,7 +4060,7 @@
 UK 
 55

- <td width="117">
+ <td width="118">
 5.2.10

 <td width="85">
@@ -4069,13 +4069,13 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Strike the note
 about definition of casting away constness, preserve the
 cross-reference. The second sentance on reintrepret_cast to
@@ -4084,7 +4084,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4092,7 +4092,7 @@
 UK 
 56

- <td width="117">
+ <td width="118">
 5.2.10

 <td width="85">
@@ -4101,7 +4101,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -4123,7 +4123,7 @@
 UK 
 57

- <td width="117">
+ <td width="118">
 5.2.10

 <td width="85">
@@ -4132,19 +4132,19 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -4152,7 +4152,7 @@
 UK 
 58

- <td width="117">
+ <td width="118">
 5.2.11

 <td width="85">
@@ -4161,7 +4161,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Replace lvalue with "lvalue or rvalue"
 twice.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4185,7 +4185,7 @@

 

- <td width="117">
+ <td width="118">
 5.3

 <td width="85">
@@ -4194,14 +4194,14 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The list of unary operator
 should be in teletype font.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4209,7 +4209,7 @@
 UK 
 68

- <td width="117">
+ <td width="118">
 5.3.1

 <td width="85">
@@ -4218,18 +4218,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 All the unary operands other than * return
 rvalues - but this is not stated.

- <td width="535">
+ <td width="536">
 Add a paragraph
 1a "The following unary operators all produce results that
 are rvalues."

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4237,7 +4237,7 @@
 UK 
 69

- <td width="117">
+ <td width="118">
 5.3.1

 <td width="85">
@@ -4246,7 +4246,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 ... unknown ...

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4271,7 +4271,7 @@
 UK 
 70

- <td width="117">
+ <td width="118">
 5.3.3

 <td width="85">
@@ -4280,7 +4280,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The sizeof
 operator shall not be applied to ... an enumeration type
 before all its enumerators have been declared We should
@@ -4288,11 +4288,11 @@

 

- <td width="535">
+ <td width="536">
 Change "an enumeration type" to "an
 enumeration type whose underlying type is not fixed".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4300,7 +4300,7 @@
 UK 
 71

- <td width="117">
+ <td width="118">
 5.3.4

 <td width="85">
@@ -4309,7 +4309,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Replace T x = e; with T x(e);

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4329,7 +4329,7 @@
 UK 
 72

- <td width="117">
+ <td width="118">
 5.3.4

 <td width="85">
@@ -4338,7 +4338,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The library
 headers have been carefully structured to limit the
 dependencies between core language and specific headers.
@@ -4351,11 +4351,11 @@

 

- <td width="535">
+ <td width="536">
 Throw std::bad_alloc instead of
 std::length_error.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4363,7 +4363,7 @@
 UK 
 73

- <td width="117">
+ <td width="118">
 5.3.4

 <td width="85">
@@ -4372,7 +4372,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Add 'literal' before 'class type'

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4392,7 +4392,7 @@
 UK 
 74

- <td width="117">
+ <td width="118">
 5.3.4

 <td width="85">
@@ -4401,7 +4401,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Change "the allocation function’s
 name is operator new" to "the allocation function is named
 operator new" and similarly for operator delete.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4423,7 +4423,7 @@
 UK 
 35

- <td width="117">
+ <td width="118">
 5.3.4

 <td width="85">
@@ -4432,17 +4432,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Missing period in middle of paragraph
 between "in the scope of T" and "If this lookup fails"

- <td width="535">
+ <td width="536">
 Add a period
 between "in the scope of T" and "If this lookup fails"

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4450,7 +4450,7 @@
 UK 
 75

- <td width="117">
+ <td width="118">
 5.3.5

 <td width="85">
@@ -4459,24 +4459,24 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 A paragraph
 strarting with [Note... is easily skipped when reading,
 missing the normative text at the end.

 

- <td width="535">
+ <td width="536">
 Swap order of the note and normative text.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 21

- <td width="117">
+ <td width="118">
 5.3.6 
 [Alignof

@@ -4486,21 +4486,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Should not the type of alignof-expression be of type
 std::max_align_t?

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 35

- <td width="117">
+ <td width="118">
 5.8

 <td width="85">
@@ -4509,7 +4509,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 There is curious spacing in the expressions "E1 <<E2"
 and "E1 >>E2". This is a formatting change since
@@ -4517,10 +4517,10 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4528,7 +4528,7 @@
 UK 
 47

- <td width="117">
+ <td width="118">
 5.14 / 5.15

 <td width="85">
@@ -4537,7 +4537,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Why are the
 descriptions of order of evaluation of expressions and side
 effects different between && and || operators. The
@@ -4547,11 +4547,11 @@

 

- <td width="535">
+ <td width="536">
 Pick one form of wording as 'the best' and
 apply it in both places.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4559,7 +4559,7 @@
 UK 
 48

- <td width="117">
+ <td width="118">
 5.18

 <td width="85">
@@ -4568,7 +4568,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The defining
 feature of the comma operator is the guaranteed sequencing
 of two expressions. This guarantee is lost when presented
@@ -4577,12 +4577,12 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -4590,7 +4590,7 @@
 UK 
 49

- <td width="117">
+ <td width="118">
 5.19

 <td width="85">
@@ -4599,14 +4599,14 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Add an escape
 clause to allow the implementation to reject excessively
 deep nesting of constexpr function evaluations. (This can
@@ -4618,7 +4618,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4626,7 +4626,7 @@
 UK 
 50

- <td width="117">
+ <td width="118">
 5.19

 <td width="85">
@@ -4635,20 +4635,20 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Change
 "effective integral type" to "effective integral or
 enumeration type" in the 4th bullet, 1st sub-bullet.

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4656,7 +4656,7 @@
 UK 
 51

- <td width="117">
+ <td width="118">
 5.19

 <td width="85">
@@ -4665,7 +4665,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 typeid
 expressions can never be constant, whether or not the
 operand is a polymorphic class type. The result of the
@@ -4675,12 +4675,12 @@

 

- <td width="535">
+ <td width="536">
 Strike the words "whose operand is of a
 polymorphic class type" on the bullet for typeid
 expressions.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4688,7 +4688,7 @@
 UK 
 76

- <td width="117">
+ <td width="118">
 6.3

 <td width="85">
@@ -4697,25 +4697,25 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Do we really need two different terms that
 say the same thing?

- <td width="535">
+ <td width="536">
 Pick either
 'block' or 'compound statement' as the preferred term and
 use it consistently throughout the standard.

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 22

- <td width="117">
+ <td width="118">
 6.4.2 
 [The switch 
 statement]
@@ -4726,7 +4726,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The constant-expression in

 
@@ -4744,10 +4744,10 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4755,7 +4755,7 @@
 UK 
 77

- <td width="117">
+ <td width="118">
 6.5

 <td width="85">
@@ -4764,7 +4764,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The terms i/o
 operation, synchronize operation and atomic operation have
 very specific meanings within the standard. The paragraph
@@ -4773,18 +4773,18 @@

 

- <td width="535">
+ <td width="536">
 Profide a cross-reference for the terms:
 i/o operation, synchronize operation and atomic operation

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 11

- <td width="117">
+ <td width="118">
 6.5.4

 <td width="85">
@@ -4796,12 +4796,12 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 There is no _RangeT type in the equivalent code to
 “range-base for” statement. It existed in
 N2049.

- <td width="535">
+ <td width="536">
 Add
 a typedef for _RangeT in the example as follows:

@@ -4851,7 +4851,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4859,7 +4859,7 @@
 UK 
 78

- <td width="117">
+ <td width="118">
 6.5.4

 <td width="85">
@@ -4868,12 +4868,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Including the header
 <iterator_concepts> is far too unwieldy to enable an
 important and (expected to be) frequently used syntax.

- <td width="535">
+ <td width="536">
 Merge
 <iterator_concepts> into <concepts> and change
 6.5.4p2 to refer to <concepts>, or make the Range
@@ -4882,7 +4882,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4890,7 +4890,7 @@
 UK 
 79

- <td width="117">
+ <td width="118">
 6.5.4

 <td width="85">
@@ -4899,7 +4899,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The definition
 of for (for-range-declaration : expression) statement is
 expanded in terms which require a Range concept, and the
@@ -4912,7 +4912,7 @@

 

- <td width="535">
+ <td width="536">
 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 <iterator_concepts>.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-11

- <td width="117">
+ <td width="118">
 6.9

 <td width="85">
@@ -4936,7 +4936,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 DE-11 A
 sentence in paragraph 1 reads: "Outside of a constrained
@@ -4947,11 +4947,11 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -4959,7 +4959,7 @@
 UK 
 80

- <td width="117">
+ <td width="118">
 7

 <td width="85">
@@ -4968,7 +4968,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Strike the first sentence.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -4993,7 +4993,7 @@
 UK 
 81

- <td width="117">
+ <td width="118">
 7

 <td width="85">
@@ -5002,7 +5002,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -5024,7 +5024,7 @@
 UK 
 82

- <td width="117">
+ <td width="118">
 7

 <td width="85">
@@ -5033,7 +5033,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Paragraph 2
 talks about declarations that can have nested declarations
 within them. It doesn't mention scoped enumerations - but
@@ -5042,11 +5042,11 @@

 

- <td width="535">
+ <td width="536">
 Add "scoped enumeration" to the list in the
 second sentence.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5054,7 +5054,7 @@
 UK 
 83

- <td width="117">
+ <td width="118">
 7.1

 <td width="85">
@@ -5063,7 +5063,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Not sure. I understand the rule, just not
 how to say it.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5084,7 +5084,7 @@
 UK 
 84

- <td width="117">
+ <td width="118">
 7.1

 <td width="85">
@@ -5093,7 +5093,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The grammar
 includes alignment-specifier as a production for
 decl-specifier, but there is no production for
@@ -5102,18 +5102,18 @@

 

- <td width="535">
+ <td width="536">
 Delete the production (including the
 duplicate in A6)

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FI 3

- <td width="117">
+ <td width="118">
 7.1

 <td width="85">
@@ -5124,7 +5124,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 While
 it’s considered too late for this standard revision,
@@ -5134,10 +5134,10 @@

 

- <td width="535">
+ <td width="536">
 See restricted-auto.ppt

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5145,7 +5145,7 @@
 UK 
 85

- <td width="117">
+ <td width="118">
 7.1.1

 <td width="85">
@@ -5154,7 +5154,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 ... the
 init-declarator-list of the declaration shall not be empty
 (except for global anonymous unions, which shall be
@@ -5165,10 +5165,10 @@

 

- <td width="535">
+ <td width="536">
 Replace "global" with "namespace scope".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5176,7 +5176,7 @@
 UK 
 86

- <td width="117">
+ <td width="118">
 7.1.1

 <td width="85">
@@ -5185,7 +5185,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Deprecate current usage of the register
 keyword.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5208,7 +5208,7 @@
 UK 
 87

- <td width="117">
+ <td width="118">
 7.1.1

 <td width="85">
@@ -5217,7 +5217,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Drop requirement to combine static keyword
 with thread_local at block-scope inside a function
 definition.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 36

- <td width="117">
+ <td width="118">
 7.1.1

 <td width="85">
@@ -5248,25 +5248,25 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 permission to use thread_local static data members is
 missing.

 

- <td width="535">
+ <td width="536">
 Add the static members as a
 permitted use.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 23

- <td width="117">
+ <td width="118">
 7.1.5 
 [constexpr]

@@ -5276,7 +5276,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 '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 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 12

- <td width="117">
+ <td width="118">
 7.1.5

 <td width="85">
@@ -5317,7 +5317,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 It should be
 allowed to define constexpr recursively.
@@ -5448,20 +5448,20 @@
 
 

- <td width="535">
+ <td width="536">
 
 Allow constexpr recursion.

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 37

- <td width="117">
+ <td width="118">
 7.1.6.1

 <td width="85">
@@ -5470,7 +5470,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 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 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5491,7 +5491,7 @@
 UK 
 89

- <td width="117">
+ <td width="118">
 7.1.6.1

 <td width="85">
@@ -5500,7 +5500,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The two
 normative sentences in this paragraph appear to duplicate
 text elsewhere - but they aren't exact duplicates, which
@@ -5527,12 +5527,12 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -5540,7 +5540,7 @@
 UK 
 90

- <td width="117">
+ <td width="118">
 7.1.6.2

 <td width="85">
@@ -5549,7 +5549,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The grammar in
 paragraph one makes "nested-name-specifier template
 simple-template-id" a simple-type-specifier, but unlike all
@@ -5557,12 +5557,12 @@

 

- <td width="535">
+ <td width="536">
 Add a row to table 9 mentioning
 simple-template-id and punting to clause 14 (cf
 decltype(expression)).

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5570,7 +5570,7 @@
 UK 
 91

- <td width="117">
+ <td width="118">
 7.1.6.2

 <td width="85">
@@ -5579,7 +5579,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -5611,7 +5611,7 @@
 UK 
 92

- <td width="117">
+ <td width="118">
 7.1.6.3

 <td width="85">
@@ -5620,7 +5620,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Either strike the note or add reference to
 11.4/3 and/or mention of "friend T;".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5641,7 +5641,7 @@
 UK 
 93

- <td width="117">
+ <td width="118">
 7.1.6.3

 <td width="85">
@@ -5650,7 +5650,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 In the third
 production, "enum ::opt nested-name-specifieropt
 identifier", enum should not be in italics; its referring
@@ -5658,10 +5658,10 @@

 

- <td width="535">
+ <td width="536">
 Change to keyword font

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5669,7 +5669,7 @@
 UK 
 94

- <td width="117">
+ <td width="118">
 7.1.6.4

 <td width="85">
@@ -5678,14 +5678,14 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5702,7 +5702,7 @@
 UK 
 95

- <td width="117">
+ <td width="118">
 7.1.6.4

 <td width="85">
@@ -5711,7 +5711,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 (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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 FR 24

- <td width="117">
+ <td width="118">
 7.1.6.4 
 [auto 
 specifier]
@@ -5747,7 +5747,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 38

- <td width="117">
+ <td width="118">
 7.2

 <td width="85">
@@ -5815,24 +5815,24 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The
 discussion of attribute specifiers should be a separate
 paragraph.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 39

- <td width="117">
+ <td width="118">
 7.2

 <td width="85">
@@ -5841,7 +5841,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 paragraph says in part "An opaque-enum-declaration
 declaring an unscoped enumeration shall not omit the
@@ -5852,19 +5852,19 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 JP 13

- <td width="117">
+ <td width="118">
 7.2

 <td width="85">
@@ -5873,7 +5873,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 In
 the description for an unscoped enumeration, enum-base in
 redeclaration must be the same underlying type as in the
@@ -5883,11 +5883,11 @@

 

- <td width="535">
+ <td width="536">
 Replace the description, "same underlying type", with
 "same as underlying type of (previous) declaration."

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5895,7 +5895,7 @@
 UK 
 96

- <td width="117">
+ <td width="118">
 7.2

 <td width="85">
@@ -5904,7 +5904,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -5927,7 +5927,7 @@
 UK 
 97

- <td width="117">
+ <td width="118">
 7.2

 <td width="85">
@@ -5936,7 +5936,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Missing
 punctuation after "blue" in: "The possible values of an
 object of type color are red, yellow, green, blue these
@@ -5944,12 +5944,12 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -5957,7 +5957,7 @@
 UK 
 98

- <td width="117">
+ <td width="118">
 7.2

 <td width="85">
@@ -5966,7 +5966,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Add a TransformationTrait to 20.5.6 that
 returns the underlying type of an enumeration type.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -5989,7 +5989,7 @@
 UK 
 99

- <td width="117">
+ <td width="118">
 7.2

 <td width="85">
@@ -5998,7 +5998,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 JP 14

- <td width="117">
+ <td width="118">
 7.3.1

 <td width="85">
@@ -6029,7 +6029,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 The description of the behavior when a member that was
@@ -6101,7 +6101,7 @@
 
 

- <td width="535">
+ <td width="536">
 
 Add the description of the behavior when a member that was
@@ -6109,7 +6109,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6117,7 +6117,7 @@
 UK 
 100

- <td width="117">
+ <td width="118">
 7.3.3

 <td width="85">
@@ -6126,7 +6126,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Para 10 says "A
 using-declaration is a declaration and can therefore be
 used repeatedly where (and only where) multiple
@@ -6138,11 +6138,11 @@

 

- <td width="535">
+ <td width="536">
 Delete para 10, moving its example into
 para 13.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6150,7 +6150,7 @@
 UK 
 101

- <td width="117">
+ <td width="118">
 7.3.3

 <td width="85">
@@ -6159,7 +6159,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Allow typename for non-dependent names iff
 they refer to a type.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-12

- <td width="117">
+ <td width="118">
 7.3.3

 <td width="85">
@@ -6191,7 +6191,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 DE-12
 Overriding and hiding of member functions named in
@@ -6200,17 +6200,17 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 25

- <td width="117">
+ <td width="118">
 7.3.3 
 [The using 
 declaration]
@@ -6221,11 +6221,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The syntax for concept map alias is unnecessarily both
 confused and verbose.

- <td width="535">
+ <td width="536">
 We strongly suggest
 simplifications, e.g.

@@ -6237,7 +6237,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6245,7 +6245,7 @@
 UK 
 102

- <td width="117">
+ <td width="118">
 7.3.4

 <td width="85">
@@ -6254,7 +6254,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Move the example to paragraph 7, and/or
 replace it with an appropriate example.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 40

- <td width="117">
+ <td width="118">
 7.6

 <td width="85">
@@ -6284,7 +6284,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 list of attributes is missing an attribute to indicate that
 a function with a 

- <td width="535">
+ <td width="536">
 Add the attribute.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 41

- <td width="117">
+ <td width="118">
 7.6

 <td width="85">
@@ -6315,7 +6315,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 A
 common problem is unintentionally declaring a new virtual
 member function instead of overriding a base virtual member
@@ -6323,18 +6323,18 @@

 

- <td width="535">
+ <td width="536">
 An attribute stating intent to
 override would enable better diagnostics.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 26

- <td width="117">
+ <td width="118">
 7.6 [Attributes]

 <td width="85">
@@ -6343,24 +6343,24 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 Are they part of object types
 or not? The section does not appear to indicate that
 clearly.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FI 1

- <td width="117">
+ <td width="118">
 7.6

 <td width="85">
@@ -6369,21 +6369,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Add override-attribute for functions in order to avoid
 mistakes when overriding functions.

- <td width="535">
+ <td width="536">
 See override-attribute.doc, override-attribute.ppt

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 27

- <td width="117">
+ <td width="118">
 7.6.1

 <td width="85">
@@ -6392,7 +6392,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6421,7 +6421,7 @@
 UK 
 103

- <td width="117">
+ <td width="118">
 7.6.1

 <td width="85">
@@ -6430,7 +6430,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -6453,7 +6453,7 @@
 UK 
 104

- <td width="117">
+ <td width="118">
 7.6.1

 <td width="85">
@@ -6462,7 +6462,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -6482,7 +6482,7 @@
 UK 
 105

- <td width="117">
+ <td width="118">
 7.6.1

 <td width="85">
@@ -6491,16 +6491,16 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Allowing only one level of namespaces in
 attributes seems unnecessarily limiting.

- <td width="535">
+ <td width="536">
 To: attribute-scoped-token:
 attribute-namespace :: identifier add attribute-namespace
 :: attribute-scoped-token

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6508,7 +6508,7 @@
 UK 
 106

- <td width="117">
+ <td width="118">
 7.6.2

 <td width="85">
@@ -6517,23 +6517,23 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Extensive use of
 alignment and related terms without cross reference.

 

- <td width="535">
+ <td width="536">
 Add cross-reference to 3.11.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 15

- <td width="117">
+ <td width="118">
 7.6.2

 <td width="85">
@@ -6542,7 +6542,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 An abbreviation
 of 7.6.2 should be “[decl.attr.align]” instead
@@ -6557,10 +6557,10 @@

 

- <td width="535">
+ <td width="536">
 Change "[dcl.align]" of 7.6.2 to "[decl.attr.align]".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6568,7 +6568,7 @@
 UK 
 107

- <td width="117">
+ <td width="118">
 7.6.3

 <td width="85">
@@ -6577,7 +6577,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 While undefined
 behaviour might be the best we can guarantee, it would be
 helpful to encourage implementations to diagnose function
@@ -6585,13 +6585,13 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -6599,7 +6599,7 @@
 UK 
 108

- <td width="117">
+ <td width="118">
 7.6.4

 <td width="85">
@@ -6608,7 +6608,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Strike "no diagnostic required" and the
 associated footnote.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 42

- <td width="117">
+ <td width="118">
 7.6.4

 <td width="85">
@@ -6636,7 +6636,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 meaning of the <code>[[final]]</code> attribute applied
@@ -6645,7 +6645,7 @@

 

- <td width="535">
+ <td width="536">
 
 Modify the semantics of <code>[[final]]</code> applied to
@@ -6656,7 +6656,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6664,7 +6664,7 @@
 UK 
 109

- <td width="117">
+ <td width="118">
 7.6.5

 <td width="85">
@@ -6673,25 +6673,25 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The example code
 refers in comments to "Compilation unit" A and B. The term
 should be "Translation unit" (2/1)

 

- <td width="535">
+ <td width="536">
 Replace "Compilation" with "Translation" in
 two places

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 

- <td width="117">
+ <td width="118">
 

 <td width="85">
@@ -6700,13 +6700,13 @@
 <td width="62">
 

- <td width="604">
+ <td width="514">
 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6714,7 +6714,7 @@
 UK 
 110

- <td width="117">
+ <td width="118">
 7.6.5

 <td width="85">
@@ -6723,7 +6723,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Change the type of foo_head to
 atomic<foo *>[].

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 43

- <td width="117">
+ <td width="118">
 8

 <td width="85">
@@ -6751,7 +6751,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 With the introduction of late-specified return types for
 functions and lambda expressions, we now have three
@@ -6763,10 +6763,10 @@

 

- <td width="535">
+ <td width="536">
 Some simplification is needed.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -6774,7 +6774,7 @@
 UK 
 111

- <td width="117">
+ <td width="118">
 8.3.5

 <td width="85">
@@ -6783,25 +6783,25 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Example missing
 closing bracket in template<typename... T> void f(T
 (* ...t)(int, int);

 

- <td width="535">
+ <td width="536">
 Add closing bracket like this:
 template<typename... T> void f(T (* ...t)(int, int));

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 44

- <td width="117">
+ <td width="118">
 8.3.5

 <td width="85">
@@ -6810,25 +6810,25 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 In
 the Example, "template void f(T (* ...t)(int, int);" is
 missing a close parenthesis.

 

- <td width="535">
+ <td width="536">
 It presumably should read:
 "template void f(T (* ...t))(int, int);".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 45

- <td width="117">
+ <td width="118">
 8.3.5

 <td width="85">
@@ -6837,7 +6837,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 In 8.3.5p13,
 remove the sentence “A function
 parameter pack, if present, shall occur at the end of the
@@ -6937,14 +6937,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-13

- <td width="117">
+ <td width="118">
 8.4

 <td width="85">
@@ -6953,22 +6953,22 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Properly quote the grammar from 8.3.5.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 16

- <td width="117">
+ <td width="118">
 8.5

 <td width="85">
@@ -6981,24 +6981,24 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo, duplicated "in"

 "The initialization that
 occurs in in the forms"

- <td width="535">
+ <td width="536">
 Remove one.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 46

- <td width="117">
+ <td width="118">
 8.5.3

 <td width="85">
@@ -7007,7 +7007,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 US 49

- <td width="117">
+ <td width="118">
 8.5.4

 <td width="85">
@@ -7088,18 +7088,18 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 In the Example, the comments
 could be improved.

- <td width="535">
+ <td width="536">
 See
 the attached paper "Issues with the C++ Standard" under
 "Editorial Issues" and "8.5.4/6".

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7107,7 +7107,7 @@
 UK 
 112

- <td width="117">
+ <td width="118">
 9

 <td width="85">
@@ -7116,7 +7116,7 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Add appropriate forward references to
 14.9.4

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7136,7 +7136,7 @@
 UK 
 113

- <td width="117">
+ <td width="118">
 9.4.2

 <td width="85">
@@ -7145,23 +7145,23 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Mis-applied edit from the paper n2756

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 US 50

- <td width="117">
+ <td width="118">
 12.1, 
 12.4, 
 12.8
@@ -7172,7 +7172,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 Implicitly-declared default constructors, destructors, copy
 constructors, and copy assignment operators are deleted
@@ -7203,7 +7203,7 @@

 

- <td width="535">
+ <td width="536">
 In 12.1p5,
 remove the phrase “or inaccessible from
 the implicitly-declared default 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 28

- <td width="117">
+ <td width="118">
 12.6.1 
 [Explicit 
 initialization]
@@ -7255,21 +7255,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 This section, in particular the example with `g' appears
 contradictory with the syntax for uniform initialization.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 51

- <td width="117">
+ <td width="118">
 12.6.2

 <td width="85">
@@ -7278,17 +7278,17 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The
 discussion of delegating constructors should be in its own
 paragraph.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7296,7 +7296,7 @@
 UK 
 114

- <td width="117">
+ <td width="118">
 12.6.2

 <td width="85">
@@ -7305,7 +7305,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Ammend the
 grammar for mem-initializer: mem-initializer-id =OPT
 braced-init-list Extend p3 to allow for Copy Initialization
@@ -7330,14 +7330,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 52

- <td width="117">
+ <td width="118">
 13.5.8

 <td width="85">
@@ -7346,13 +7346,13 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 A word is misspelled.

- <td width="535">
+ <td width="536">
 Change “shal” to “shall”.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7360,7 +7360,7 @@
 UK 
 115

- <td width="117">
+ <td width="118">
 14

 <td width="85">
@@ -7369,7 +7369,7 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -7398,7 +7398,7 @@
 UK 
 116

- <td width="117">
+ <td width="118">
 14

 <td width="85">
@@ -7407,7 +7407,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Either prohibit exporting concept map
 templates, or more directly address what it means to export
 a concept map.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7428,7 +7428,7 @@
 UK 
 117

- <td width="117">
+ <td width="118">
 14

 <td width="85">
@@ -7437,7 +7437,7 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Allow template aliases to be declared
 inside a function scope, and consider scoped concept maps.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7459,7 +7459,7 @@
 UK 
 118

- <td width="117">
+ <td width="118">
 14

 <td width="85">
@@ -7468,7 +7468,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Exported
 templates are a complicated feature with surprisingly
 little text. To make this important text more visible,
@@ -7476,11 +7476,11 @@

 

- <td width="535">
+ <td width="536">
 Create a new subclause [temp.export]
 containing 14p6-11. Move 14p12 ahead of this subclause.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7488,7 +7488,7 @@
 UK 
 119

- <td width="117">
+ <td width="118">
 14

 <td width="85">
@@ -7497,7 +7497,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -7520,7 +7520,7 @@
 UK 
 120

- <td width="117">
+ <td width="118">
 14.1

 <td width="85">
@@ -7529,7 +7529,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 As this is the
 first time the phrase “parameter pack” appears
 in Ch 14 I would like to see the section 8.3.5 referenced
@@ -7537,11 +7537,11 @@

 

- <td width="535">
+ <td width="536">
 Insert “(8.3.5)” after
 “parameter pack”

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7549,7 +7549,7 @@
 UK 
 121

- <td width="117">
+ <td width="118">
 14.1

 <td width="85">
@@ -7558,24 +7558,24 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The example
 (that follows the normative text) has no begin example
 marker

 

- <td width="535">
+ <td width="536">
 Prefix the example code with "[ Example:"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 29

- <td width="117">
+ <td width="118">
 14.3 
 [Template 
 arguments]
@@ -7588,21 +7588,21 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Constant expressions of any literal type should be
 allowed as template arguments.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 53

- <td width="117">
+ <td width="118">
 14.5.1

 <td width="85">
@@ -7611,7 +7611,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Add to 14.5.1p5:

 If the constrained member is a copy
@@ -7654,7 +7654,7 @@
 template’s template arguments for its template
 parameters) will be declared as a deleted function (8.4).

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -7662,7 +7662,7 @@
 UK 
 122

- <td width="117">
+ <td width="118">
 14.5.3

 <td width="85">
@@ -7671,7 +7671,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 FR 30

- <td width="117">
+ <td width="118">
 14.5.7 
 [Template 
 aliases]
@@ -7704,7 +7704,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 When are two template alias
 names equivalent?

@@ -7743,17 +7743,17 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 17

- <td width="117">
+ <td width="118">
 14.7.2

 <td width="85">
@@ -7764,7 +7764,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo.

@@ -7789,17 +7789,17 @@

 

- <td width="535">
+ <td width="536">
 Replace "from" with "forming"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-14

- <td width="117">
+ <td width="118">
 14.7.3

 <td width="85">
@@ -7808,22 +7808,22 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Add the respective bullets.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 18

- <td width="117">
+ <td width="118">
 14.7.3

 <td width="85">
@@ -7834,7 +7834,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo,

@@ -7857,17 +7857,17 @@

 

- <td width="535">
+ <td width="536">
 Replace "from" with "forming"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 19

- <td width="117">
+ <td width="118">
 14.8.2

 <td width="85">
@@ -7878,7 +7878,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo, duplicated "is"

@@ -7890,18 +7890,18 @@
 
 

- <td width="535">
+ <td width="536">
 
 Remove one

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 54

- <td width="117">
+ <td width="118">
 14.9 
 [concept],
@@ -7916,24 +7916,24 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 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">
 I propose no specific change here.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 55

- <td width="117">
+ <td width="118">
 14.9.1

 <td width="85">
@@ -7942,23 +7942,23 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 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">
 Move the paragraph number so as to follow the grammar
 rules, thus numbering the single sentence, “The body
 of a concept … .”

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 56

- <td width="117">
+ <td width="118">
 14.9.1

 <td width="85">
@@ -7967,22 +7967,22 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The sentence contains two references to 14.9.1.3
 [concept.req].

- <td width="535">
+ <td width="536">
 Change the second such reference (at the end of the
 sentence) to 14.9.1.4 [concept.axiom].

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 57

- <td width="117">
+ <td width="118">
 14.9.1.4

 <td width="85">
@@ -7991,21 +7991,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 A word is misplaced, changing the intended meaning.

- <td width="535">
+ <td width="536">
 Change “only find … if” to “find
 … only if”.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 58

- <td width="117">
+ <td width="118">
 14.9.1.4

 <td width="85">
@@ -8014,22 +8014,22 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The listed phrases are not grammatically parallel.

- <td width="535">
+ <td width="536">
 Insert “in” before “one” so as
 to obtain “... in the concept, in one of its less
 refined concepts, or in an associated requirement.”

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 59

- <td width="117">
+ <td width="118">
 14.9.1.4

 <td width="85">
@@ -8038,7 +8038,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Remove clause
 14.9.1.4 [concept.axiom]

@@ -8109,14 +8109,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 31

- <td width="117">
+ <td width="118">
 14.9.1.4 
 [Axioms]

@@ -8126,7 +8126,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-15

- <td width="117">
+ <td width="118">
 14.9.1.4

 <td width="85">
@@ -8170,7 +8170,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -8193,7 +8193,7 @@
 UK 
 123

- <td width="117">
+ <td width="118">
 14.9.1.4

 <td width="85">
@@ -8202,7 +8202,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Add a paragraph making axioms ill-formed
 inside an auto concept.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8229,7 +8229,7 @@

 

- <td width="117">
+ <td width="118">
 14.9.1.4

 <td width="85">
@@ -8238,13 +8238,13 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Spelling mistake, double-e in were.

- <td width="535">
+ <td width="536">
 weere -> were

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8252,7 +8252,7 @@
 UK 
 125

- <td width="117">
+ <td width="118">
 14.9.1.4

 <td width="85">
@@ -8261,7 +8261,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The implicit
 equality comparison operator available to axioms has no
 semantic. It is not clear what expressing the condition if(
@@ -8273,12 +8273,12 @@

 

- <td width="535">
+ <td width="536">
 Define the semantics of the implicitly
 declared comparison operators, or restrict their usage to
 declaring equivalence between statements.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8286,7 +8286,7 @@
 UK 
 126

- <td width="117">
+ <td width="118">
 14.9.4

 <td width="85">
@@ -8295,18 +8295,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 This paragraph
 contains the only definition of the underlying_type member
 - but it's a note, so not normative.

 

- <td width="535">
+ <td width="536">
 Move the second sentence to the Requires
 clause in paragraph 42.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8314,7 +8314,7 @@
 UK 
 127

- <td width="117">
+ <td width="118">
 14.9.4

 <td width="85">
@@ -8323,7 +8323,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Provide a
 diagram clearly showing refinement relationship between the
 different support concepts. Several were created during
@@ -8331,10 +8331,10 @@

 

- <td width="535">
+ <td width="536">
 Provide the diagram.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8342,7 +8342,7 @@
 UK 
 128

- <td width="117">
+ <td width="118">
 14.9.4

 <td width="85">
@@ -8351,13 +8351,13 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 A non-normative
 note: [Note: 'move only' types that are constructible from
 rvalue references may be Returnable, but not
@@ -8365,14 +8365,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 20

- <td width="117">
+ <td width="118">
 14.9.4

 <td width="85">
@@ -8382,7 +8382,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 Trivially copyable type was added in “3.9
@@ -8394,12 +8394,12 @@
 "margin-left: 0.2in; text-indent: -0.2in; margin-top: 0.04in">
 

- <td width="535">
+ <td width="536">
 Add
 TriviallyCopyableType that is trivially copyable type as
 concept.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8407,7 +8407,7 @@
 UK 
 129

- <td width="117">
+ <td width="118">
 14.10.1, 
 20.1.2

@@ -8417,7 +8417,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 It should be
 possible to support boolean constant expressions as
 requirements without resorting to defining the True concept
@@ -8429,21 +8429,21 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 US 60

- <td width="117">
+ <td width="118">
 14.10.1

 <td width="85">
@@ -8452,7 +8452,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The use of && 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 ‘,’ would eliminate a significant
 source of confusion.

- <td width="535">
+ <td width="536">
 Replace

 
@@ -8503,7 +8503,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8511,7 +8511,7 @@
 UK 
 130

- <td width="117">
+ <td width="118">
 15.1

 <td width="85">
@@ -8520,7 +8520,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Update sentence to allow for exceptions
 held in excpetion_ptr objects.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8544,7 +8544,7 @@
 UK 
 131

- <td width="117">
+ <td width="118">
 15.3

 <td width="85">
@@ -8553,18 +8553,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 A handler
 catching its parameter by rvalue-reference is syntactically
 valid, but will never be activated.

 

- <td width="535">
+ <td width="536">
 Disallow handlers catching by
 rvalue-reference.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8572,7 +8572,7 @@
 UK 
 132

- <td width="117">
+ <td width="118">
 15.3

 <td width="85">
@@ -8581,7 +8581,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Rewite using copy-initialization rather
 than directly invoking the copy constructor

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8605,7 +8605,7 @@
 UK 
 133

- <td width="117">
+ <td width="118">
 15.4

 <td width="85">
@@ -8614,18 +8614,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Template aliases
 have the same semantics as a typedef so should also be
 disallowed

 

- <td width="535">
+ <td width="536">
 add "or alias-declaration" after "shall not
 appear in a typedef declaration".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8633,7 +8633,7 @@
 UK 
 134

- <td width="117">
+ <td width="118">
 15.4

 <td width="85">
@@ -8642,19 +8642,19 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The sentance "An
 exception-specification can also include the class
 std::bad_exception (18.7.2.1)." is redundant.

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -8662,7 +8662,7 @@
 UK 
 135

- <td width="117">
+ <td width="118">
 15.4

 <td width="85">
@@ -8671,17 +8671,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Unclear if std::unexpected is called before
 or after the function arguments have been destroyed

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -8689,7 +8689,7 @@
 UK 
 136

- <td width="117">
+ <td width="118">
 15.4

 <td width="85">
@@ -8698,7 +8698,7 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -8724,7 +8724,7 @@
 UK 
 137

- <td width="117">
+ <td width="118">
 15.5

 <td width="85">
@@ -8733,7 +8733,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -8754,7 +8754,7 @@
 UK 
 138

- <td width="117">
+ <td width="118">
 15.5.1

 <td width="85">
@@ -8763,18 +8763,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The third bullet
 is redundant with the first, as it is a subset of the same
 conditions.

 

- <td width="535">
+ <td width="536">
 Merge the third bullet into the first
 bullet as a note or example.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8782,7 +8782,7 @@
 UK 
 139

- <td width="117">
+ <td width="118">
 15.5.1

 <td width="85">
@@ -8791,7 +8791,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Strike the word 'user' from the first
 bullet point.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8811,7 +8811,7 @@
 UK 
 140

- <td width="117">
+ <td width="118">
 15.5.2

 <td width="85">
@@ -8820,7 +8820,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The detailed
 specification can fool people into thinking an exception
 will automatically be translated into bad_exception, where
@@ -8829,12 +8829,12 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -8842,7 +8842,7 @@
 UK 
 141

- <td width="117">
+ <td width="118">
 15.6

 <td width="85">
@@ -8851,16 +8851,16 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 This whole
 subclause is redundant due to 15.1p5 and 15.3p17

 

- <td width="535">
+ <td width="536">
 Strike 15.6

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8868,7 +8868,7 @@
 UK 
 142

- <td width="117">
+ <td width="118">
 16.3.5

 <td width="85">
@@ -8877,16 +8877,16 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 This paragraph
 opens with "[ Note" but has no corresponding "end note ]"

 

- <td width="535">
+ <td width="536">
 Add "end note ]"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -8894,7 +8894,7 @@
 UK 
 143

- <td width="117">
+ <td width="118">
 16.3.5

 <td width="85">
@@ -8903,20 +8903,20 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Example uses #define t(x,y.z) x ## y ## z

- <td width="535">
+ <td width="536">
 Change "x,y.z" to "x,y,z"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 2

- <td width="117">
+ <td width="118">
 17-30

 <td width="85">
@@ -8925,7 +8925,7 @@
 <td width="62">
 ge/te

- <td width="604">
+ <td width="514">
 The
 active issues identified in WG21 N2806, C++ Standard
 Library Active Issues, must be addressed and appropriate
@@ -8941,20 +8941,20 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <tr valign="top">
+ Acknowledged<tr valign="top">
 <td width="29">
 FR 2

- <td width="117">
+ <td width="118">
 General 
 Comment

@@ -8964,21 +8964,19 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 The adoption of the library `constexpr' proposal was not
 reflected in the draft, despite formal WG21 committee vote.

- <td width="535">
+ <td width="536">
 FR 2

- <td width="89">
- General Comment
-
- <tr valign="top">
+ <td width="178">
+ Editorial; sent to Pete Becker<tr valign="top">
 <td width="29">
 US 61

- <td width="117">
+ <td width="118">
 17 onward

 <td width="85">
@@ -8987,12 +8985,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Review all
 clauses of the Standard Library, and consistently apply
@@ -9002,14 +9000,14 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Agreed. Duplicates CA2<tr valign="top">
 <td width="29">
 CA-2

- <td width="117">
+ <td width="118">
 17 Library

 <td width="85">
@@ -9018,25 +9016,25 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 
 “Concepts” 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">
 Fix
 the standard library so that “Concepts” are
 used appropriately in the library.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Agreed; We intend to address this.<tr valign="top">
 <td width="29">
 US 62

- <td width="117">
+ <td width="118">
 17-30

 <td width="85">
@@ -9045,23 +9043,23 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 Provide concepts
 and requirements clauses for all standard library templates

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
- 
+ <td width="178">
+ Agreed. Duplicates CA2 

 <tr valign="top">
 <td width="29">
 US 63

- <td width="117">
+ <td width="118">
 17-30

 
@@ -9072,7 +9070,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ 17 SG: should go to threads group; misclassified in document
+
+ Concurrency SG: Create an issue. Hans will look into it.<tr valign="top">
 <td width="29">
 DE-2

- <td width="117">
+ <td width="118">
 17 through 30

 <td width="85">
@@ -9105,7 +9105,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 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">
 

- <tr valign="top">
+ Robert Klarer to address this one<tr valign="top">
 <td width="29">
 JP 21

- <td width="117">
+ <td width="118">
 
 

@@ -9147,7 +9147,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 Support of char16_t/char32_t is insufficient. The basic_xxx
 classes of <iostream>, <fstream>,
@@ -9158,7 +9158,7 @@
 Functions such as stoi, to_string in ‘21.4 Numeric
 Conversion’ does not support char16_t/char32_t types.

- <td width="535">
+ <td width="536">
 Add commented
 lines corresponding to char16_t, char32_t.
@@ -9958,15 +9958,17 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 144

- <td width="117">
+ <td width="118">
 17.1

 <td width="85">
@@ -9975,15 +9977,15 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 List of contents of library should be
 extened to cover new clauses

- <td width="535">
+ <td width="536">
 Add "regular expressions, atomic operations
 and threads"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -9991,7 +9993,7 @@
 UK 
 145

- <td width="117">
+ <td width="118">
 17.1

 <td width="85">
@@ -10000,18 +10002,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 
 Summary of numeric facilities should
 mention random numbers

 

- <td width="535">
+ <td width="536">
 Add random number framework to the list of
 library facilities

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10019,7 +10021,7 @@
 UK 
 146

- <td width="117">
+ <td width="118">
 17.1

 <td width="85">
@@ -10028,15 +10030,15 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Add a summary paragraph for regular
 expressions

- <td width="535">
+ <td width="536">
 Add a summary paragraph for regular
 expressions

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10044,7 +10046,7 @@
 UK 
 147

- <td width="117">
+ <td width="118">
 17.1

 <td width="85">
@@ -10053,13 +10055,13 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Add a summary paragraph for threads

- <td width="535">
+ <td width="536">
 Add a summary paragraph for threads

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10067,7 +10069,7 @@
 UK 
 148

- <td width="117">
+ <td width="118">
 17.2

 <td width="85">
@@ -10076,7 +10078,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Make sure tables are rendered in the
 section to which they relate.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10096,7 +10098,7 @@
 UK 
 149

- <td width="117">
+ <td width="118">
 17.3

 <td width="85">
@@ -10105,19 +10107,19 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 For consistency
 with narrow-oriented and wide-oriented streams, we should
 add terms for streams of Unicode character sequences

 

- <td width="535">
+ <td width="536">
 Define Utf16-oriented stream classes and
 Uft32-oriented stream classes for streams of
 char16_t/char32_t values.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10125,7 +10127,7 @@
 UK 
 150

- <td width="117">
+ <td width="118">
 17.3

 <td width="85">
@@ -10134,7 +10136,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10167,7 +10169,7 @@
 UK 
 151

- <td width="117">
+ <td width="118">
 17.3.1

 <td width="85">
@@ -10176,17 +10178,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Missing
 crossreference to 17.3.17 [defns.repositional.stream]

 

- <td width="535">
+ <td width="536">
 Add cross-reference in the existing empty
 brackets

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10194,7 +10196,7 @@
 UK 
 152

- <td width="117">
+ <td width="118">
 17.3.12

 <td width="85">
@@ -10203,7 +10205,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Clarify terms and usage

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 153

- <td width="117">
+ <td width="118">
 17.3.17

 <td width="85">
@@ -10231,7 +10233,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 If a
 repositional stream can only seek to a position previously
 encountered, then an arbitrary-positional-stream cannot
@@ -10239,14 +10241,14 @@

 

- <td width="535">
+ <td width="536">
 Strike the word 'only'. A note might be
 added to reinforce the intent

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ editorial; sent to Pete Becker<tr valign="top">
 <td width="29">
 UK 
@@ -10254,7 +10256,7 @@

 

- <td width="117">
+ <td width="118">
 17.3.20

 <td width="85">
@@ -10263,14 +10265,14 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Missing definition of a stable partition
 algorithm

- <td width="535">
+ <td width="536">
 Add definition from 25.2.12p7

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10278,7 +10280,7 @@
 UK 
 155

- <td width="117">
+ <td width="118">
 17.3.3

 <td width="85">
@@ -10287,15 +10289,15 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Add clause 28 to list that use this
 definition of character

- <td width="535">
+ <td width="536">
 Add clause 28 to list that use this
 definition of character

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10303,7 +10305,7 @@
 UK 
 156

- <td width="117">
+ <td width="118">
 17.3.4

 <td width="85">
@@ -10312,18 +10314,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Add regular
 expressions to set of templates using character container
 type

 

- <td width="535">
+ <td width="536">
 Add regular expressions to set of templates
 using character container type

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10331,7 +10333,7 @@
 UK 
 157

- <td width="117">
+ <td width="118">
 17.5.2.2

 <td width="85">
@@ -10340,7 +10342,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Add concepts to
 the ordered list of presentation

@@ -10348,10 +10350,10 @@

 

- <td width="535">
+ <td width="536">
 Add concepts into the sequence

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10359,7 +10361,7 @@
 UK 
 158

- <td width="117">
+ <td width="118">
 17.5.2.2

 <td width="85">
@@ -10368,17 +10370,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 templates are neither classes nor functions

- <td width="535">
+ <td width="536">
 Replace
 'classes' and 'functions' with 'classes and class
 templates' and 'functions and function templates'

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10386,7 +10388,7 @@
 UK 
 159

- <td width="117">
+ <td width="118">
 17.5.2.4

 <td width="85">
@@ -10395,18 +10397,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 This informative
 footnote was relevant in 1998, not 2008. The term 'existing
 vendors' may imply something different now

 

- <td width="535">
+ <td width="536">
 Strike the footnote, or replace 'existing'
 with 'original' or similar

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10414,7 +10416,7 @@
 UK 
 160

- <td width="117">
+ <td width="118">
 17.5.2.4

 <td width="85">
@@ -10423,7 +10425,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Replace 'Requires' with 'Preconditions'

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10446,7 +10448,7 @@
 UK 
 161

- <td width="117">
+ <td width="118">
 17.5.2.4

 <td width="85">
@@ -10455,7 +10457,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Strike 17.5.2.4p4

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10475,7 +10477,7 @@
 UK 
 162

- <td width="117">
+ <td width="118">
 17.5.2.4

 <td width="85">
@@ -10484,7 +10486,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Clause 30 makes
 use of a 'Synchronization' semantic element, that
 frequently appears either between Effects: and
@@ -10492,12 +10494,12 @@

 

- <td width="535">
+ <td width="536">
 Add 'Synchronization' to the list either
 between Effects: and Postconditions:, or between Returns:
 and Throws:.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10505,7 +10507,7 @@
 UK 
 163

- <td width="117">
+ <td width="118">
 17.5.2.4

 <td width="85">
@@ -10514,7 +10516,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Introduce an explicit "Equivalent to",
 which defines all of the properties of the function.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Tom Plum to open LWG issue; we believe this is related to LWG625<tr valign="top">
 <td width="29">
 UK 
 164

- <td width="117">
+ <td width="118">
 17.5.3.2.1

 <td width="85">
@@ -10543,13 +10545,13 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Use better names
 for the examples. Ideally totally replace the need by
 constraining all templates in library, so that real
@@ -10558,7 +10560,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10566,7 +10568,7 @@
 UK 
 165

- <td width="117">
+ <td width="118">
 17.5.3.2.2, 
 17.5.3.2.3

@@ -10576,7 +10578,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Adopt wording in line with the motivation
 described in N2235

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Robert Klarer to review<tr valign="top">
 <td width="29">
 UK 
 166

- <td width="117">
+ <td width="118">
 17.5.3.2.4.1, 
 17.5.3.3

@@ -10608,14 +10610,14 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 List of library clauses should go up to 30,
 not 27

- <td width="535">
+ <td width="536">
 Replace initial refernce to ch27 with ch30

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10623,7 +10625,7 @@
 UK 
 167

- <td width="117">
+ <td width="118">
 17.5.3.4 
 Private 
 members
@@ -10634,17 +10636,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Comment marker in wrong place.

- <td width="535">
+ <td width="536">
 Change: //
 streambuf* sb; exposition only to streambuf* sb; //
 exposition only To reflect actual usage.

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10652,7 +10654,7 @@
 UK 
 168

- <td width="117">
+ <td width="118">
 17.6.2.2

 <td width="85">
@@ -10661,7 +10663,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <tr valign="top">
+ Howard will create issue to adopt UK words (some have reservations whether
+ it is correct)<tr valign="top">
 <td width="29">
 UK 
 169

- <td width="117">
+ <td width="118">
 17.6.2.2

 <td width="85">
@@ -10695,7 +10698,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 This phrasing
 contradicts later freedom to implement the C standard
 library portions in the global namespace as well as std.
@@ -10703,18 +10706,19 @@

 

- <td width="535">
+ <td width="536">
 Resolve conflict in either place

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 170

- <td width="117">
+ <td width="118">
 17.6.2.3

 <td width="85">
@@ -10723,7 +10727,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Add a new header <std> that has the
 effect of including everything in tables 13 and 14, except
 <iosfwd> and <cassert>. Add an additional
 header <fwd> that adds all declarations from
 <std> but no definitions.

- <td width="89">
+ <td width="178">
 

+ Alisdair to open issue. We prefer
+ <std>only. </std>
+
 <tr valign="top">
 <td width="29">
 UK 
 171

- <td width="117">
+ <td width="118">
 17.6.2.4

 <td width="85">
@@ -10759,7 +10766,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Does
 freestanding implementation require a full implementation
 of all listed headers? The reference to abort, at_exit and
@@ -10770,12 +10777,12 @@

 

- <td width="535">
+ <td width="536">
 Either strike the references to abort,
 at_exit and exit, or clarify which headers only require
 partial support.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10783,7 +10790,7 @@
 UK 
 172

- <td width="117">
+ <td width="118">
 17.6.2.4

 <td width="85">
@@ -10792,25 +10799,26 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 No reference to
 new functions quick_exit and at_quick_exit

 

- <td width="535">
+ <td width="536">
 Add reference to quick_exit and
 at_quick_exit

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 173

- <td width="117">
+ <td width="118">
 17.6.2.4

 <td width="85">
@@ -10819,25 +10827,26 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 
 <initializer_list> is missing from headers required
 in freestanding implementations.

 

- <td width="535">
+ <td width="536">
 Add 18.8, initializer lists,
 <initializer_list>, to the end of the table.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ LWG is interested in N2814, but we're concerned whether CWG will accept
+ language recommendations.<tr valign="top">
 <td width="29">
 JP 23

- <td width="117">
+ <td width="118">
 17.6.2.4

 <td width="85">
@@ -10847,7 +10856,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 There is a
 freestanding implementation including <type_traits>,
@@ -10861,20 +10870,23 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 <type_traits>, <array>, <ration> to Table
 15.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ LWG is interested in N2814, but we're concerned whether CWG will accept
+ language recommendations.
+
+ add <type_traits> only. Alisdair will draft an issue.<tr valign="top">
 <td width="29">
 UK 
 174

- <td width="117">
+ <td width="118">
 17.6.3.2

 <td width="85">
@@ -10883,7 +10895,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -10906,7 +10918,7 @@
 UK 
 175

- <td width="117">
+ <td width="118">
 17.6.4.2.1

 <td width="85">
@@ -10915,25 +10927,25 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Local types can
 now be used to instantiate templates, but don't have
 external linkage

 

- <td width="535">
+ <td width="536">
 Remove the reference to external linkage

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ we accept the proposed solution. Martin will draft an issue.<tr valign="top">
 <td width="29">
 UK 
 176

- <td width="117">
+ <td width="118">
 17.6.4.3.3

 <td width="85">
@@ -10944,14 +10956,14 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Reference to namespace ::std should be
 17.6.4.2

- <td width="535">
+ <td width="536">
 Change referfence from 17.6.4.3 to 17.6.4.2

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10959,7 +10971,7 @@
 UK 
 177

- <td width="117">
+ <td width="118">
 17.6.4.3.4

 <td width="85">
@@ -10968,17 +10980,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Sentence is
 redundant as double underscores are reserved in all
 contexts by 17.6.4.3.3

 

- <td width="535">
+ <td width="536">
 Strike the sentence

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -10986,7 +10998,7 @@
 UK 
 178

- <td width="117">
+ <td width="118">
 17.6.4.8

 <td width="85">
@@ -10995,16 +11007,16 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Strike the sentence

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11012,7 +11024,7 @@
 UK 
 179

- <td width="117">
+ <td width="118">
 17.6.4.8

 <td width="85">
@@ -11021,7 +11033,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Replace the word 'throws' with 'propogates'

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Agreed. Alisdair will draft an issue.<tr valign="top">
 <td width="29">
 JP 22

- <td width="117">
+ <td width="118">
 17.6.5.7

 <td width="85">
@@ -11051,7 +11063,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The
 statement below describes relation among two or more
 threads using words “between threads”: 
@@ -11065,7 +11077,7 @@
 such case, “among” is preferred instead of
 “between”.

- <td width="535">
+ <td width="536">
 
 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">
 

 <tr valign="top">
@@ -11081,7 +11093,7 @@
 UK 
 180

- <td width="117">
+ <td width="118">
 17.6.5.10

 <td width="85">
@@ -11090,7 +11102,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Add restriction that exception
 specification of virtual functions cannot be tightened.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ NAD, the standard already has the desired restriction.<tr valign="top">
 <td width="29">
 UK 
 181

- <td width="117">
+ <td width="118">
 17.6.5.10

 <td width="85">
@@ -11122,7 +11134,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <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">
 UK 
 182

- <td width="117">
+ <td width="118">
 17.6.5.10

 <td width="85">
@@ -11152,7 +11165,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 It is very
 helpful to assume all exceptions thrown by the standard
 library derive from std::exception. The 'encouragement' of
@@ -11160,18 +11173,19 @@

 

- <td width="535">
+ <td width="536">
 Make this footnote normative

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ NAD. We cannot mandate all standard-library functions that might use some
+ third-party library.<tr valign="top">
 <td width="29">
 UK 
 184

- <td width="117">
+ <td width="118">
 18 -> 30

 <td width="85">
@@ -11180,7 +11194,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The new
 alias-declaration syntax is generally easier to read than a
 typedef declaration. This is especially true for complex
@@ -11188,19 +11202,19 @@

 

- <td width="535">
+ <td width="536">
 Replace all typedef declarations in the
 standard library with alias-declarations, except in the
 standard C library.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 24

- <td width="117">
+ <td width="118">
 18

 <td width="85">
@@ -11210,7 +11224,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Subclauses are listed in Table 16 as:

@@ -11226,7 +11240,7 @@
 "text-indent: 0.06in; margin-top: 0.04in">"18.7 Exception
 handling …".

- <td width="535">
+ <td width="536">
 
 Sort them in the increasing order 
@@ -11243,14 +11257,14 @@
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 25

- <td width="117">
+ <td width="118">
 18.1

 <td width="85">
@@ -11263,24 +11277,24 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 max_align_t is described in 18.1, so add 3.11 Alignment as
 the reference.

- <td width="535">
+ <td width="536">
 Add
 "3.11, Alignment" to
 SEE ALSO.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 32

- <td width="117">
+ <td width="118">
 18.2.1 
 [Numeric 
 limits]
@@ -11291,7 +11305,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The definition of
 numeric_limits<> as requiring a regular type is both
 conceptually wrong and operationally illogical. As we
@@ -11304,21 +11318,21 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 DE-16

- <td width="117">
+ <td width="118">
 18.2.1

 <td width="85">
@@ -11327,7 +11341,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 DE-16 The class
 template numeric_limits should not specify the Regular
@@ -11342,18 +11356,18 @@

 

- <td width="535">
+ <td width="536">
 Specify a concept requirement with fewer constraints as
 appropriate, for example SemiRegular.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 26

- <td width="117">
+ <td width="118">
 18.2.1.1

 <td width="85">
@@ -11362,11 +11376,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 numeric_limits does not use concept.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -11408,14 +11422,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-17

- <td width="117">
+ <td width="118">
 18.2.6

 <td width="85">
@@ -11424,7 +11438,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 DE-17 The class
 type_index should be removed; it provides no additional
@@ -11432,12 +11446,12 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -11445,7 +11459,7 @@
 UK 
 185

- <td width="117">
+ <td width="118">
 18.3.1

 <td width="85">
@@ -11454,24 +11468,24 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 There is no
 header <stdint>, it should either be <stdint.h>
 or <cstdint>

 

- <td width="535">
+ <td width="536">
 Replace <stdint> with <cstdint>

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-18

- <td width="117">
+ <td width="118">
 18.4

 <td width="85">
@@ -11480,7 +11494,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 DE-18 The
 proposed C++ standard makes a considerable number of
@@ -11502,14 +11516,14 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -11517,7 +11531,7 @@
 UK 
 186

- <td width="117">
+ <td width="118">
 18.4

 <td width="85">
@@ -11526,7 +11540,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Remove the footnote

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11546,7 +11560,7 @@
 UK 
 187

- <td width="117">
+ <td width="118">
 18.4

 <td width="85">
@@ -11555,18 +11569,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The term "thread
 safe" is not defined nor used in this context anywhere else
 in the standard.

 

- <td width="535">
+ <td width="536">
 Clarify the intended meaing of "thread
 safe"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11574,7 +11588,7 @@
 UK 
 188

- <td width="117">
+ <td width="118">
 18.4

 <td width="85">
@@ -11583,7 +11597,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Depends on where _Exit comes from

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11602,7 +11616,7 @@
 UK 
 189

- <td width="117">
+ <td width="118">
 18.4, 18.7

 <td width="85">
@@ -11611,12 +11625,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The addition of the [[noreturn]] attribute
 to the language will be an important aid for static
 analysis tools.

- <td width="535">
+ <td width="536">
 The following
 functions should be declared in C++ with the [[noreturn]]
 attribute: abort exit quick_exit terminate unexpected
@@ -11624,14 +11638,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 27

- <td width="117">
+ <td width="118">
 18.4, 18.9, 
 18.7.2.2, 
 18.7.3.1
@@ -11642,13 +11656,13 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 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">
 
 Consider to add the attribute [[noreturn]] to such
 functions,
@@ -11673,7 +11687,7 @@
 
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11681,7 +11695,7 @@
 UK 
 190

- <td width="117">
+ <td width="118">
 18.5.1

 <td width="85">
@@ -11690,19 +11704,19 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 It is not entirely clear how the current
 specification acts in the presence of a garbage collected
 implementation.

- <td width="535">
+ <td width="536">
 All deallocation
 functions taking a pointer parameter should have a
 Precondition : ptr is a safely-derived pointer value.

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11710,7 +11724,7 @@
 UK 
 191

- <td width="117">
+ <td width="118">
 18.5.1.1

 <td width="85">
@@ -11719,12 +11733,12 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11740,7 +11754,7 @@
 UK 
 192

- <td width="117">
+ <td width="118">
 18.5.1.2

 <td width="85">
@@ -11749,7 +11763,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Fix 5.3.4p7 by required std::bad_alloc
 rather than std::length_error

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11771,7 +11785,7 @@
 UK 
 193

- <td width="117">
+ <td width="118">
 18.5.2.2

 <td width="85">
@@ -11780,18 +11794,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 quick_exit has
 been added as a new valid way to terminate a program in a
 well defined way

 

- <td width="535">
+ <td width="536">
 Change 3rd bullet: call either abort(),
 exit() or quick_exit();

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11799,7 +11813,7 @@
 UK 
 194

- <td width="117">
+ <td width="118">
 18.6

 <td width="85">
@@ -11808,7 +11822,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The inclusion of
 type_index and hash<type_index> in <typeinfo>
 brings dependencies into <typeinfo> which are
@@ -11817,19 +11831,19 @@

 

- <td width="535">
+ <td width="536">
 Move type_index and hash<type_index>
 out of <typeinfo> and into a new header,
 <typeindex>.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 28

- <td width="117">
+ <td width="118">
 18.6, 
 18.7, 
 19.1
@@ -11840,7 +11854,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 Errors reported by Exception classes are of types char or
 std::string only. For example, std::exception is declared
@@ -11850,18 +11864,18 @@

 

- <td width="535">
+ <td width="536">
 
 Consider other types.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 29

- <td width="117">
+ <td width="118">
 18.7.6

 <td width="85">
@@ -11870,11 +11884,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 throw_with_nested does not use concept.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -11897,14 +11911,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 30

- <td width="117">
+ <td width="118">
 18.7.6

 <td width="85">
@@ -11913,25 +11927,25 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 
 Consider nested_exception to support tree structure.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 31

- <td width="117">
+ <td width="118">
 18.7.6

 <td width="85">
@@ -11940,12 +11954,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 It
 is difficult to understand in which case nested_exception
 is applied.

- <td width="535">
+ <td width="536">
 Consider to add
 a sample program which rethrows exception.
@@ -11953,7 +11967,7 @@
 
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11961,7 +11975,7 @@
 UK 
 195

- <td width="117">
+ <td width="118">
 18.8

 <td width="85">
@@ -11970,7 +11984,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Delete the two concept maps from
 std::initializer_list.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -11992,7 +12006,7 @@
 UK 
 196

- <td width="117">
+ <td width="118">
 18.8.3

 <td width="85">
@@ -12001,12 +12015,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -12024,7 +12038,7 @@
 UK 
 197

- <td width="117">
+ <td width="118">
 19

 <td width="85">
@@ -12033,13 +12047,13 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Provide a
 constructor for every exception class in clause 19
 accepting a std::string by rvalue reference, with the
@@ -12047,14 +12061,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 32

- <td width="117">
+ <td width="118">
 19.1

 <td width="85">
@@ -12063,7 +12077,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 Messages returned by the member function what() of standard
 exception classes seem difficult to judge.
@@ -12104,19 +12118,19 @@
 
 

- <td width="535">
+ <td width="536">
 
 Consider to add footnote that recommends what() returns
 message easy to recognize what exception was thrown.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 64

- <td width="117">
+ <td width="118">
 19.3

 <td width="85">
@@ -12125,13 +12139,13 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 “ See also: ISO C
 7.1.4, 7.2, Amendment 1 4.3.”
 It is unclear why this cross reference is here. Amendment 1
 was to C89, not C99.

- <td width="535">
+ <td width="536">
 Delete this
 cross reference. If necessary, expand the main text to
@@ -12139,14 +12153,17 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 US 65

- <td width="117">
+ <td width="118">
 20

 <td width="85">
@@ -12155,7 +12172,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 
 Sketch of proposed resolution: Eliminate scoped allocators,
 replace allocator propagation traits with a simple uniform
@@ -12189,7 +12206,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -12197,7 +12214,7 @@
 UK 
 198

- <td width="117">
+ <td width="118">
 20

 <td width="85">
@@ -12206,12 +12223,12 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Agree that this is editorial -- forward to project editor. (effective
+ duplicate of US 69)<tr valign="top">
 <td width="29">
 UK 
 199

- <td width="117">
+ <td width="118">
 20.1.1, 20.1.2

 <td width="85">
@@ -12261,7 +12279,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Replace the term 'program' with 'user'.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Agree change 'program' to 'user' in clauses 20.1.1 and 20.1.2<tr valign="top">
 <td width="29">
 UK 
 200

- <td width="117">
+ <td width="118">
 20.1.4

 <td width="85">
@@ -12293,12 +12311,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Either require
 CopyConstructible<F> as part of Predicate, or create
 a refined concept, StdPredicate, used throughout the
@@ -12307,15 +12325,20 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 201

- <td width="117">
+ <td width="118">
 20.1.5

 <td width="85">
@@ -12324,11 +12347,11 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The Consistency axiom for
 LessThanComparable will not compile.

- <td width="535">
+ <td width="536">
 Add a requires
 clause to the Consistency axiomL requires
 HasLessEquals<T> &&
@@ -12338,14 +12361,15 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 JP 33

- <td width="117">
+ <td width="118">
 20.1.5

 <td width="85">
@@ -12354,12 +12378,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 LessThanComparable and EqualityComparable don't correspond
 to NaN.

- <td width="535">
+ <td width="536">
 Apply
 concept_map to these concepts at FloatingPointType
@@ -12367,14 +12391,17 @@
 
 

- <td width="89">
+ <td width="178">
 

- <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">
 US 66

- <td width="117">
+ <td width="118">
 20.1.10

 <td width="85">
@@ -12383,23 +12410,23 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 State that the “Regular” concept does not
 apply to floating-point types.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Recommend that we handle the same as JP 33.<tr valign="top">
 <td width="29">
 JP 34

- <td width="117">
+ <td width="118">
 20.2

 <td width="85">
@@ -12412,26 +12439,33 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Though N2672 pointed at adding
 "#include<initializer_list>", it isn't reflected.

- <td width="535">
+ <td width="536">
 add
 followings

 
 #include <initializer_list> // for concept_map

- <td width="89">
+ <td width="178">
 

- <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 should 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">
 US 67

- <td width="117">
+ <td width="118">
 20.2.1

 <td width="85">
@@ -12440,21 +12474,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 Some connective words are missing.

- <td width="535">
+ <td width="536">
 Insert “corresponding to” before “an
 lvalue reference type.”

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
 <td width="29">
 JP 35

- <td width="117">
+ <td width="118">
 20.2.3

 <td width="85">
@@ -12467,25 +12501,25 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo,

 "stdforward" should be
 "std::forward"

- <td width="535">
+ <td width="536">
 Correct typo.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
 <td width="29">
 UK 
 202

- <td width="117">
+ <td width="118">
 20.2.4

 <td width="85">
@@ -12494,7 +12528,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Remove the std:: qualification from these
 references to pair.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
 <td width="29">
 US 68

- <td width="117">
+ <td width="118">
 20.2.12

 <td width="85">
@@ -12522,24 +12556,25 @@
 <td width="62">
 te/ed

- <td width="604">
+ <td width="514">
 The code defining the context is syntactically
 incorrect.

- <td width="535">
+ <td width="536">
 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">
 

- <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">
 UK 
 203

- <td width="117">
+ <td width="118">
 20.3.2

 <td width="85">
@@ -12548,7 +12583,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The ratio_xyz
 types have a misplaced '}'. For example: template <class
 R1, class R2> struct ratio_add { typedef see below}
@@ -12556,19 +12591,19 @@

 

- <td width="535">
+ <td width="536">
 Move the '}' to after the typedef: template
 <class R1, class R2> struct ratio_add { typedef see
 below type; };

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
 <td width="29">
 JP 36

- <td width="117">
+ <td width="118">
 20.4.2.1

 <td width="85">
@@ -12581,26 +12616,26 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo.

 "it
 it" should be "it is"

- <td width="535">
+ <td width="536">
 
 Correct typo.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Yes. Forward to project editor.<tr valign="top">
 <td width="29">
 UK 
 204

- <td width="117">
+ <td width="118">
 20.5

 <td width="85">
@@ -12609,7 +12644,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Restore aligned_union template that was
 removed by LWG issue 856.

- <td width="89">
+ <td width="178">
 

- <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">
 US 69

- <td width="117">
+ <td width="118">
 20.5

 <td width="85">
@@ -12637,23 +12673,23 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 This section, dealing with tuple<>, should be in
 the same section as the similar utility pair<>.

- <td width="535">
+ <td width="536">
 Restructure Clause 20 so as to bring these similar
 components together.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Editorial (effective duplicate of UK 198). Forward to project editor.<tr valign="top">
 <td width="29">
 UK 
 205

- <td width="117">
+ <td width="118">
 20.5.3

 <td width="85">
@@ -12662,7 +12698,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 
 integral_constant objects should be usable in
 integral-constant-expressions. The addition to the language
@@ -12671,20 +12707,21 @@

 

- <td width="535">
+ <td width="536">
 Add a constexpr conversion operator to
 class tempalate integral_constant: constexpr operator
 value_type() { return value; }

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 206

- <td width="117">
+ <td width="118">
 20.5.5

 <td width="85">
@@ -12693,7 +12730,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Currently the
 std says: "In order to instantiate the template
 is_convertible<From, To>, the following code shall be
@@ -12703,7 +12740,7 @@

 

- <td width="535">
+ <td width="536">
 Change: "In order to instantiate the
 template is_convertible<From, To>, 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">
 

- <tr valign="top">
+ Agree with the proposed resolution: Section 20.5.5, Change: "In order to
+ instantiate the template is_convertible<From, To>, the following code shall
+ be well formed:" To: "The template is_convertible<From, To> inherits either
+ directly or indirectly from true_type if the following code is well formed:"<tr valign="top">
 <td width="29">
 UK 
 207

- <td width="117">
+ <td width="118">
 20.5.6.1

 <td width="85">
@@ -12728,11 +12768,11 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 suffix "::type" is missing from the some of
 the examples.

- <td width="535">
+ <td width="536">
 Change:
 Example:remove_const<const volatile int>::type
 evaluates to volatile int, whereas remove_const<const
@@ -12756,14 +12796,15 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ We tend to agree. Forward to project editor. Also recommend that the word
+ "is" be replaced with "evaluates to" in the same text.<tr valign="top">
 <td width="29">
 JP 37

- <td width="117">
+ <td width="118">
 20.5.7

 <td width="85">
@@ -12772,7 +12813,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo.

@@ -12802,18 +12843,18 @@

 

- <td width="535">
+ <td width="536">
 Add
 ”.”

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Agree. Forward to project editor.<tr valign="top">
 <td width="29">
 US 70

- <td width="117">
+ <td width="118">
 20.6

 <td width="85">
@@ -12822,11 +12863,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Specifications now expressed via narrative text are more
 accurately and clearly expressed via executable code.

- <td width="535">
+ <td width="536">
 Wherever
 concepts are available that directly match this
@@ -12838,14 +12879,17 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 US 71

- <td width="117">
+ <td width="118">
 20.6.7

 <td width="85">
@@ -12854,21 +12898,22 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The grammar is incorrect.

- <td width="535">
+ <td width="536">
 Change “conversion are” to “conversion
 is”.

- <td width="89">
+ <td width="178">
 

- <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">
 JP 38

- <td width="117">
+ <td width="118">
 20.6.12.1.3

 <td width="85">
@@ -12877,7 +12922,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 add the move requirement for bind's return type. 
@@ -12911,7 +12956,7 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 the following requirements. 
 "it has a public move constructor
@@ -12920,14 +12965,21 @@
 Add
 the MoveConstructible.

- <td width="89">
+ <td width="178">
 

+ We were not clear about what the submitter really intended. Requiring that
+ the result of bind be MoveConstructible?
+ and/or CopyConstructible?
+ 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">
 JP 39

- <td width="117">
+ <td width="118">
 20.6.16.2

 <td width="85">
@@ -12936,11 +12988,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 There are no requires corresponding to F of std::function.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -12991,14 +13043,17 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Agree with one correction: CopyConstructible?
+ should be ConstructibleWithAllocator?
+ . Pablo to supply wording. Also check with Howard that omission was not
+ deliberate.<tr valign="top">
 <td width="29">
 JP 40

- <td width="117">
+ <td width="118">
 20.6.16.2

 <td width="85">
@@ -13007,13 +13062,13 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Thougn it's "Allocator Aloc" at other places, it's
 "Allocator A" only std::function constructor template
 parameter.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -13047,14 +13102,14 @@
 
 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Agree, though minor. Forward to project editor (who may disregard).<tr valign="top">
 <td width="29">
 JP 41

- <td width="117">
+ <td width="118">
 20.6.16.2

 <td width="85">
@@ -13063,12 +13118,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 There are no requires corresponding to R and Args of
 UsesAllocator.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -13106,14 +13161,15 @@

 }

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ This change would be redundant because function<> is already sufficiently
+ constrained. No actions necessary.<tr valign="top">
 <td width="29">
 JP 42

- <td width="117">
+ <td width="118">
 20.6.16.2

 <td width="85">
@@ -13122,7 +13178,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 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">
 
 Correct as follows.

@@ -13232,15 +13288,17 @@
 
 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ As with JP 41, these constraints are redundant given that function<> is
+ already constrained. So we recommend changing each occurence of "MoveConstructible"
+ to "class". Note: this issue is also present in func.wrap.func.nullptr.<tr valign="top">
 <td width="29">
 UK 
 208

- <td width="117">
+ <td width="118">
 20.6.17

 <td width="85">
@@ -13249,25 +13307,26 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 std::hash should
 be implemented for much more of the standard library. In
 particular for pair, tuple and all the standard containers.

 

- <td width="535">
+ <td width="536">
 .

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 209

- <td width="117">
+ <td width="118">
 20.7

 <td width="85">
@@ -13276,11 +13335,11 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Smart pointers cannot be used in
 constrained templates

- <td width="535">
+ <td width="536">
 Provide
 constraints for smart pointers

@@ -13288,15 +13347,16 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 213

- <td width="117">
+ <td width="118">
 20.7.6

 <td width="85">
@@ -13305,7 +13365,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 std::allocator
 should be constrained to simplify its use on constrained
 contexts. This library component models allocation from
@@ -13317,13 +13377,13 @@

 

- <td width="535">
+ <td width="536">
 The primary allocator template should be
 constrained to require ObjectType<T> and
 FreeStoreAllocatable<T>. Further operations to be
 constrained as required.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -13331,7 +13391,7 @@
 UK 
 214

- <td width="117">
+ <td width="118">
 20.7.8

 <td width="85">
@@ -13340,25 +13400,26 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 
 raw_storage_iterator needs constraining as an iterator
 adaptor to be safely used in constrained templates

 

- <td width="535">
+ <td width="536">
 Constrain the raw_storage_iterator template

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 210

- <td width="117">
+ <td width="118">
 20.7.11

 <td width="85">
@@ -13367,12 +13428,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Specialized algorithms for memory
 managenment need requirements to be easily usable in
 constrained templates

- <td width="535">
+ <td width="536">
 Provide
 constraints for all algorithms in 20.7.11

@@ -13380,14 +13441,15 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 DE-20

- <td width="117">
+ <td width="118">
 20.7.12

 <td width="85">
@@ -13396,25 +13458,25 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 DE-20 The section heading and the first sentence use the
 term "template function", which is undefined.

- <td width="535">
+ <td width="536">
 Replace
 "template function" by "function template".

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 72

- <td width="117">
+ <td width="118">
 20.7.12

 <td width="85">
@@ -13423,23 +13485,23 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 bind should support move-only functors and bound arguments.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-21

- <td width="117">
+ <td width="118">
 20.7.12.1.3

 <td width="85">
@@ -13448,18 +13510,18 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
@@ -13467,7 +13529,7 @@
 UK 
 211

- <td width="117">
+ <td width="118">
 20.7.12.2.3

 <td width="85">
@@ -13476,7 +13538,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Change signature here and in the synopsis
 to: unique_ptr& operator=(nullptr_t); Strike the
 sentance an note before the Effects clause.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -13497,7 +13559,7 @@
 UK 
 212

- <td width="117">
+ <td width="118">
 20.7.13.7

 <td width="85">
@@ -13506,7 +13568,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Move this specification to 18.5. Move the
 declarations into the header <new>.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-22

- <td width="117">
+ <td width="118">
 20.7.16.2

 <td width="85">
@@ -13536,26 +13598,26 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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<T1>, because it (arguably) "contains" T1.

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 US 73

- <td width="117">
+ <td width="118">
 20.7.18

 <td width="85">
@@ -13564,7 +13626,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 std::reference_closure template is redundant with
 std::function and should be removed.
@@ -13597,7 +13659,7 @@

 

- <td width="535">
+ <td width="536">
 Remove 20.7.18
 [func.referenceclosure].

@@ -13605,14 +13667,14 @@

 Remove 5.1.1 paragraph 12.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 74

- <td width="117">
+ <td width="118">
 20.8

 <td width="85">
@@ -13621,7 +13683,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Scoped
 allocators represent a poor trade-off for standardization,
 since (1) scoped-allocator--aware containers can be
@@ -13649,7 +13711,7 @@

 

- <td width="535">
+ <td width="536">
 Remove support
 for scoped allocators from the working paper. This includes
 at least the following changes:
@@ -13679,14 +13741,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 74

- <td width="117">
+ <td width="118">
 20.8.2.2

 <td width="85">
@@ -13695,21 +13757,21 @@
 <td width="62">
 te/ed

- <td width="604">
+ <td width="514">
 A concept name is twice misspelled.

- <td width="535">
+ <td width="536">
 Change “Hasconstructor” to
 “HasConstructor” (twice).

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 75

- <td width="117">
+ <td width="118">
 20.8.2.2

 <td width="85">
@@ -13718,24 +13780,24 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Allocator concepts are incomplete

- <td width="535">
+ <td width="536">
 See paper:
 http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 43

- <td width="117">
+ <td width="118">
 20.8.3

 <td width="85">
@@ -13744,14 +13806,14 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo.

 
 "alloc" should be "Alloc"

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -13791,7 +13853,7 @@
 
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -13799,7 +13861,7 @@
 UK 
 215

- <td width="117">
+ <td width="118">
 20.8.3.3

 <td width="85">
@@ -13808,24 +13870,24 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Extra pair of
 {}, presumably some formatting code gone awry :
 duration& operator-{-}();

 

- <td width="535">
+ <td width="536">
 Remove the {} or fix formatting

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 77

- <td width="117">
+ <td width="118">
 20.8.4

 <td width="85">
@@ -13834,7 +13896,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 Allocator-specific move and copy behavior for containers
 (N2525) complicates a little-used and already-complicated
@@ -13858,7 +13920,7 @@

 

- <td width="535">
+ <td width="536">
 Remove 20.8.4.

 
@@ -13870,14 +13932,14 @@
 Remove all references to the facilities in
 20.8.4 and 20.8.5 from clause 23.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 78

- <td width="117">
+ <td width="118">
 20.8.12, 
 20.8.13.2

@@ -13887,13 +13949,13 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 There is presently no way to
 convert directly from a <code>shared_ptr</code> to a
 <code>unique_ptr</code>.

- <td width="535">
+ <td width="536">
 Add
 an interface that performs the conversion. See the
 attached, Issues with the C++ Standard" paper under Chapter
@@ -13903,14 +13965,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 79

- <td width="117">
+ <td width="118">
 20.8.12.2.1

 <td width="85">
@@ -13919,7 +13981,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 [unique.ptr.single.ctor]/5 no longer requires for D not to
 be a pointer type.  This restriction needs to be put
@@ -13942,17 +14004,17 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 44

- <td width="117">
+ <td width="118">
 20.8.13.6

 <td width="85">
@@ -13961,7 +14023,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 1st parameter p and 2nd parameter v is now
 shared_ptr<T> *.
@@ -13971,19 +14033,19 @@
 shared_ptr<T>* then add the "p shall not be a null
 pointer" at the requires.

- <td width="535">
+ <td width="536">
 
 Change shared_ptr<T>& or add the "p shall not be
 a null pionter" at the requires.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 45

- <td width="117">
+ <td width="118">
 20.9

 <td width="85">
@@ -13992,7 +14054,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 Rep, Period, Clock and Duration don't correspond to
 concept.
@@ -14009,20 +14071,20 @@
 
 

- <td width="535">
+ <td width="536">
 
 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">
 

 <tr valign="top">
 <td width="29">
 US 80

- <td width="117">
+ <td width="118">
 20.9.2.1

 <td width="85">
@@ -14031,10 +14093,10 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The section heading does not describe the contents.

- <td width="535">
+ <td width="536">
 Change the
 heading “

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 81

- <td width="117">
+ <td width="118">
 20.9.3

 <td width="85">
@@ -14061,7 +14123,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 chrono::duration is missing the modulous operator for both
 member and non-member arithmetic. This operator is useful
@@ -14102,7 +14164,7 @@

 

- <td width="535">
+ <td width="536">
 Add:

 
@@ -14162,14 +14224,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 82

- <td width="117">
+ <td width="118">
 20.9.5.3

 <td width="85">
@@ -14178,14 +14240,14 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The code synopsis has a minor alignment error.

- <td width="535">
+ <td width="536">
 Align “rep” with the other symbols defined
 in this synopsis.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -14193,7 +14255,7 @@
 UK 
 216

- <td width="117">
+ <td width="118">
 21

 <td width="85">
@@ -14202,22 +14264,24 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 All the containers use concepts for their
 iterator usage, exect for basic_string. This needs fixing.

- <td width="535">
+ <td width="536">
 Use concepts for iterator template
 parameters throughout the chapter.

- <td width="89">
+ <td width="178">
 

- <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">
 JP 46

- <td width="117">
+ <td width="118">
 21.2, 21.3

 <td width="85">
@@ -14226,11 +14290,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 basic_string does not use concept.

- <td width="535">
+ <td width="536">
 The
 "class Alloc" is changed to "Allocator Alloc".

@@ -15224,14 +15288,14 @@
 
 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ See UK 216<tr valign="top">
 <td width="29">
 JP 47

- <td width="117">
+ <td width="118">
 21.3

 <td width="85">
@@ -15240,7 +15304,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo. Missing ”>”

@@ -15261,18 +15325,18 @@

 

- <td width="535">
+ <td width="536">
 
 Correct typo.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 48

- <td width="117">
+ <td width="118">
 21.3

 <td width="85">
@@ -15281,7 +15345,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 char_traits does not use concept.

@@ -15305,19 +15369,19 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 a concept for char_traits.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ See UK 216<tr valign="top">
 <td width="29">
 UK 
 217

- <td width="117">
+ <td width="118">
 21.3

 <td width="85">
@@ -15326,12 +15390,12 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 basic_string refers to
 constructible_with_allocator_suffix, which I thought was
 removed?

- <td width="535">
+ <td width="536">
 Remove the
 lines: template <class charT, class traits, class Alloc
 struct constructible_with_allocator_suffix<
@@ -15340,7 +15404,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -15348,7 +15412,7 @@
 UK 
 218

- <td width="117">
+ <td width="118">
 21.3.1

 <td width="85">
@@ -15357,7 +15421,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The identity
 "&*(s.begin() + n) == &*s.begin() + n" relies on
 operator& doing the "right thing", which (AFAICS) there
@@ -15368,19 +15432,21 @@

 

- <td width="535">
+ <td width="536">
 See my recommendations for "23.2.1,
 23.2.6".

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ NAD, we think. basic_string elements have to be POD and PODs may not have
+ overloaded operator&. Need to check whether this is true in light of relaxed
+ POD constraints.<tr valign="top">
 <td width="29">
 UK 
 219

- <td width="117">
+ <td width="118">
 21.3.6.6 
 [string. 
 replace]
@@ -15391,15 +15457,15 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Effects refers to "whose first begin() - i1
 elements" However i1 is greater than begin()...

- <td width="535">
+ <td width="536">
 Effects refers to "whose first i1 - begin()
 elements"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -15407,7 +15473,7 @@
 UK 
 220

- <td width="117">
+ <td width="118">
 21.3.8.9

 <td width="85">
@@ -15416,7 +15482,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The
 operator<< for basic_string takes the output stream
 by r-value reference. This is different from the same
@@ -15426,20 +15492,22 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <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">
 FR 33

- <td width="117">
+ <td width="118">
 22.1.1 
 [locale]

@@ -15449,7 +15517,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 ios_base::iostate err = 0;

 
@@ -15459,17 +15527,17 @@

 goodbit is the solution.

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 49

- <td width="117">
+ <td width="118">
 22.1.3.2.2

 <td width="85">
@@ -15478,7 +15546,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 codecvt does not use concept. For example, create
 CodeConvert concept and change as follows.
@@ -15487,18 +15555,18 @@
 template<CodeConvert Codecvt, class Elem =
 wchar_t> class wstring_convert {

- <td width="535">
+ <td width="536">
 Add
 a concept for codecvt.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
 <td width="29">
 JP 50

- <td width="117">
+ <td width="118">
 22.1.3.2.2

 <td width="85">
@@ -15507,12 +15575,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Add
 custom allocator parameter to wstring_convert, since we
 cannot allocate memory for strings from a custom allocator.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -15566,14 +15634,14 @@
 
 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ to be handled by PJ Plaugher<tr valign="top">
 <td width="29">
 FI 4

- <td width="117">
+ <td width="118">
 22.2.1.4.1

@@ -15585,21 +15653,21 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 <tt>to_end and to_limit are both used. Only one is
 needed.</tt>

- <td width="535">
+ <td width="536">
 Change to_limit to to_end.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FI 5

- <td width="117">
+ <td width="118">
 <tt>22.2.1.4.2</tt>

 <td width="85">
@@ -15608,7 +15676,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 <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">
 <tt>[ Note: As a result of operations on state, do_in
 and do_out can return</tt> 
 <tt>ok or partial and set from_next == from and/or to_next
 != to. —end</tt> 
 <tt>note ]</tt>

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FI 6

- <td width="117">
+ <td width="118">
 22.2.1.5

@@ -15663,7 +15731,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 <tt>codecvt_byname is only specified to work with locale
@@ -15681,18 +15749,20 @@

 

- <td width="535">
+ <td width="536">
 <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">
 

- <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">
 FI 7

- <td width="117">
+ <td width="118">
 22.2.1.4

 <td width="85">
@@ -15701,7 +15771,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 The word
 "codeset" is used, whereas the word "character set" is used
@@ -15711,17 +15781,17 @@

 

- <td width="535">
+ <td width="536">
 Change "codeset" to "character set."

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 51

- <td width="117">
+ <td width="118">
 22.2.5.1.1

 <td width="85">
@@ -15732,7 +15802,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 A
 parameter `end’ should be `fmtend’. 
 get() function had two `end’ parameters at N2321.
@@ -15750,7 +15820,7 @@
 
 

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -15770,14 +15840,14 @@
 
 Requires: [fmt,fmtend) shall be a valid range.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 52

- <td width="117">
+ <td width="118">
 22.2.5.1, 
 22.2.5.2, 
 22.2.6.1
@@ -15788,11 +15858,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 InputIterator does not use concept.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -15961,14 +16031,14 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
 <td width="29">
 JP 53

- <td width="117">
+ <td width="118">
 22.2.5.3 , 
 22.2.5.4

@@ -15978,11 +16048,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 OutputIterator does not use concept.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -16095,14 +16165,14 @@
 typedef OutputIter
 iter_type;

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
 <td width="29">
 JP 54

- <td width="117">
+ <td width="118">
 23

 <td width="85">
@@ -16115,16 +16185,16 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 There is not <forward_list> in Table 79.

- <td width="535">
+ <td width="536">
 Add
 <forward_list> between <deque> and
 <list>.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16132,7 +16202,7 @@
 UK 
 221

- <td width="117">
+ <td width="118">
 23

 <td width="85">
@@ -16141,11 +16211,11 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The table is missing the new
 <forward_list> header.

- <td width="535">
+ <td width="536">
 Add
 <forward_list> to the table for sequence containers.
 Alternative (technical) solution might be to merge
@@ -16153,7 +16223,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16161,7 +16231,7 @@
 UK 
 222

- <td width="117">
+ <td width="118">
 23

 <td width="85">
@@ -16170,7 +16240,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 JP 55

- <td width="117">
+ <td width="118">
 23.1.1

 <td width="85">
@@ -16218,18 +16288,18 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 It
 seems that “the MinimalAllocator concep” is the
 typo of “the MinimalAllocator concept”.

- <td width="535">
+ <td width="536">
 
 Change to … models the MinimalAllocator
 concept.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16237,7 +16307,7 @@
 UK 
 223

- <td width="117">
+ <td width="118">
 23.1.1

 <td width="85">
@@ -16246,7 +16316,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The library does
 not define the MinimalAllocator or ScopedAllocator
 concepts, these were part of an earlier Allocators proposal
@@ -16254,12 +16324,12 @@

 

- <td width="535">
+ <td width="536">
 Remove the references to MinimalAllocator
 and ScopedAllocator, or add definitions for these concepts
 to clause 20.7.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16267,7 +16337,7 @@
 UK 
 224

- <td width="117">
+ <td width="118">
 23.1.1

 <td width="85">
@@ -16276,12 +16346,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 This paragraph implicitly requires all
 containers in clause 23 to support allocators, which
 std::array does not.

- <td width="535">
+ <td width="536">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16297,7 +16367,7 @@
 UK 
 225

- <td width="117">
+ <td width="118">
 23.1.1

 <td width="85">
@@ -16306,7 +16376,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Inconsistent
 words used to say the same thing. Table 80 describes
 iterator/const_iterator typedef as returning an "iterator
@@ -16317,12 +16387,12 @@

 

- <td width="535">
+ <td width="536">
 Change return types for
 X::(const)_reverse_iterator to say "iterator type whose
 value type is (const) T".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16330,7 +16400,7 @@
 UK 
 226

- <td width="117">
+ <td width="118">
 23.1.1

 <td width="85">
@@ -16339,7 +16409,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 <array>
 must be added to this list. In particular it doesn't
 satisfy: - no swap() function invalidates any references,
@@ -16349,12 +16419,12 @@

 

- <td width="535">
+ <td width="536">
 If <array> 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">
 

 <tr valign="top">
@@ -16362,7 +16432,7 @@
 UK 
 227

- <td width="117">
+ <td width="118">
 23.1.1

 <td width="85">
@@ -16371,19 +16441,19 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The post-condition for a = rv uses the word
 “construction” when it means
 “assignment”

- <td width="535">
+ <td width="536">
 Replace the word
 “construction” with the word
 “assignment”

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16391,7 +16461,7 @@
 UK 
 228

- <td width="117">
+ <td width="118">
 23.1.1

 <td width="85">
@@ -16400,17 +16470,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Line 4 contains
 a spelling mistake in the fragment "MinimalAllocator
 concep."

 

- <td width="535">
+ <td width="536">
 Replace "concep" with "concept"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16418,7 +16488,7 @@
 UK 
 229

- <td width="117">
+ <td width="118">
 23.1.1

 <td width="85">
@@ -16427,12 +16497,12 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The fragment "A container may directly call
 constructors" is not technically correct as constructors
 are not callable.

- <td width="535">
+ <td width="536">
 Replace "A
 container may directly call constructors and destructors
 for its stored objects" with something similar to "A
@@ -16441,7 +16511,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16449,7 +16519,7 @@
 UK 
 230

- <td width="117">
+ <td width="118">
 23.1.2

 <td width="85">
@@ -16458,7 +16528,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 
 “implementations shall consider the following
 functions to be const” - what does this mean? I don't
@@ -16468,18 +16538,18 @@

 

- <td width="535">
+ <td width="536">
 Clarify what is meant and what requirements
 an implementation must satisfy.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 56

- <td width="117">
+ <td width="118">
 23.1.3

 <td width="85">
@@ -16489,12 +16559,12 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 `array’ is unstated in Table 84 - Optional sequence
 container operations.

- <td width="535">
+ <td width="536">
 Add
 `array’ to Container field for the following
 Expression.
@@ -16511,7 +16581,7 @@
 a.at(n)

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16519,7 +16589,7 @@
 UK 
 231

- <td width="117">
+ <td width="118">
 23.1.3

 <td width="85">
@@ -16528,19 +16598,19 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 These paragraphs
 are redundant now that Concepts define what it means to be
 an Iterator and guide overload resolution accordingly.

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -16548,7 +16618,7 @@
 UK 
 232

- <td width="117">
+ <td width="118">
 23.1.3

 <td width="85">
@@ -16557,18 +16627,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 match_results
 may follow the requirements but is not listed a general
 purpose library container.

 

- <td width="535">
+ <td width="536">
 Remove reference to match_results against
 a[n] operation

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16576,7 +16646,7 @@
 UK 
 233

- <td width="117">
+ <td width="118">
 23.1.3

 <td width="85">
@@ -16585,10 +16655,10 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Add references to the new containers.

- <td width="535">
+ <td width="536">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16606,7 +16676,7 @@
 UK 
 234

- <td width="117">
+ <td width="118">
 23.1.3

 <td width="85">
@@ -16615,7 +16685,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Replace iterator with auto in semantics for
 back: { auto tmp = a.end(); --tmp; return *tmp; }

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16636,7 +16706,7 @@
 UK 
 235

- <td width="117">
+ <td width="118">
 23.1.3

 <td width="85">
@@ -16645,13 +16715,13 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 “The library provides three basic
 kinds of sequence containers: vector, list, and
 deque” - text appears to be out of date re addition
 of array and forward_list

- <td width="535">
+ <td width="536">
 Change the text
 to read: “The library provides five basic kinds of
 sequence containers: array, deque, forward_list, list and
@@ -16659,7 +16729,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16667,7 +16737,7 @@
 UK 
 236

- <td width="117">
+ <td width="118">
 23.1.3

 <td width="85">
@@ -16676,7 +16746,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 [ 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 @@

 

- <td width="535">
+ <td width="536">
 Remove this paragraph

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16704,7 +16774,7 @@
 UK 
 237

- <td width="117">
+ <td width="118">
 23.1.3

 <td width="85">
@@ -16713,12 +16783,12 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16734,7 +16804,7 @@
 UK 
 238

- <td width="117">
+ <td width="118">
 23.1.4

 <td width="85">
@@ -16743,7 +16813,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -16772,7 +16842,7 @@
 UK 
 239

- <td width="117">
+ <td width="118">
 23.1.4

 <td width="85">
@@ -16781,12 +16851,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Add below
 a.erase(q), a.extract(q), with the following notation:
 a.extract(q), Return type pair<key, iterator>
@@ -16798,7 +16868,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16806,7 +16876,7 @@
 UK 
 240

- <td width="117">
+ <td width="118">
 23.1.6.1

 <td width="85">
@@ -16815,7 +16885,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The axiom
 EmplacePushEquivalence should be asserting the stronger
 contract that emplace and insert return the same iterator
@@ -16830,7 +16900,7 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 JP 57

- <td width="117">
+ <td width="118">
 23.1.6.3

 <td width="85">
@@ -16861,18 +16931,18 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo, duplicated "to"

 
 "to to model insertion container concepts."

- <td width="535">
+ <td width="536">
 
 Remove one.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16880,7 +16950,7 @@
 UK 
 241

- <td width="117">
+ <td width="118">
 23.2.1

 <td width="85">
@@ -16889,17 +16959,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 std::array does
 not have an allocator, so need to document an exception to
 the requirements of 23.1.1p3

 

- <td width="535">
+ <td width="536">
 add exception to 23.1.1p3

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16907,7 +16977,7 @@
 UK 
 242

- <td width="117">
+ <td width="118">
 23.2.1

 <td width="85">
@@ -16916,18 +16986,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 std:: qualification no longer needed for
 reverse_iterator.

- <td width="535">
+ <td width="536">
 remove std::
 qualification from std::reverse_iterator<iterator>
 and std::reverse_iterator<const_iterator>

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16935,7 +17005,7 @@
 UK 
 243

- <td width="117">
+ <td width="118">
 23.2.1

 <td width="85">
@@ -16944,7 +17014,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Most containers,
 and types in general have 3 swaps: swap(T&, T&)
 swap(T&&, T&) swap(T&, T&&) But
@@ -16952,10 +17022,10 @@

 

- <td width="535">
+ <td width="536">
 add the other two swaps.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -16963,7 +17033,7 @@
 UK 
 244

- <td width="117">
+ <td width="118">
 23.2.1, 
 23.2.6

@@ -16973,7 +17043,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The validity of
 the expression &a[n] == &a[0] + n is contingent on
 operator& doing the “right thing” (as
@@ -16986,7 +17056,7 @@

 

- <td width="535">
+ <td width="536">
 Define a ContiguousStrorage and apply it to
 vector,array and string. The Concept (supplied by Alisdair
 M) looks like this: Concept< typename C >
@@ -16995,7 +17065,7 @@
 Contiguous { C c; true = equal_ranges( data( c), data(c) +
 size(c), begin(c)); } };

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17003,7 +17073,7 @@
 UK 
 245

- <td width="117">
+ <td width="118">
 23.2.3

 <td width="85">
@@ -17012,7 +17082,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Add
 CopyConstructible requirement to the following signatures:
 template <Predicate<auto, T> Pred> requires
@@ -17041,14 +17111,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 58

- <td width="117">
+ <td width="118">
 23.2.3.2

 <td width="85">
@@ -17061,23 +17131,23 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Unnecessary "{" exists before a word iterator like
 "{iterator before_begin()".

- <td width="535">
+ <td width="536">
 
 Remove "{"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 59

- <td width="117">
+ <td width="118">
 23.2.4.4

 <td width="85">
@@ -17086,14 +17156,14 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 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">
 
 Correct as follows.

@@ -17132,14 +17202,14 @@
 
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 83

- <td width="117">
+ <td width="118">
 23.2.6.2

 <td width="85">
@@ -17148,7 +17218,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 "shrink_to_fint" should be "shrink_to_fit".

@@ -17157,10 +17227,10 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17168,7 +17238,7 @@
 UK 
 246

- <td width="117">
+ <td width="118">
 23.3.2.2

 <td width="85">
@@ -17177,7 +17247,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Strike 23.3.2.2 entirely. (but do NOT
 strike these signatures from the class template
 definition!)

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17201,7 +17271,7 @@
 UK 
 247

- <td width="117">
+ <td width="118">
 24.1

 <td width="85">
@@ -17210,7 +17280,7 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 Iterator
 concepts are not extensive enough to merit a whole new
 header, and should be merged into <concpts>. This is
@@ -17222,13 +17292,13 @@

 

- <td width="535">
+ <td width="536">
 Move the concepts of
 <iterator_concepts> into the <concepts> header.
 We take no position on moving the text from Clause 24 to
 Clause 20 though.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17236,7 +17306,7 @@
 UK 
 248

- <td width="117">
+ <td width="118">
 24.1

 <td width="85">
@@ -17245,7 +17315,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Replace the reference to container with a
 more appropriate concept

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17267,7 +17337,7 @@
 UK 
 250

- <td width="117">
+ <td width="118">
 24.1.1

 <td width="85">
@@ -17276,17 +17346,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 A default implementation should be supplied
 for the post-increment operator to simplify implementation
 of iterators by users.

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -17294,7 +17364,7 @@
 UK 
 251

- <td width="117">
+ <td width="118">
 24.1.1

 <td width="85">
@@ -17303,7 +17373,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The
 post-increment operator is dangerous for a general
 InputIterator. The multi-pass guarantees that make it
@@ -17317,12 +17387,12 @@

 

- <td width="535">
+ <td width="536">
 Move declaration of postincrement operator
 and postincrement_result type from Interator concept to the
 ForwardIterator concept

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17333,7 +17403,7 @@

 

- <td width="117">
+ <td width="118">
 24.1.2

 <td width="85">
@@ -17342,15 +17412,15 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 istream_iterator is not a class, but a
 class template

- <td width="535">
+ <td width="536">
 Change 'class' to 'class template' in the
 note.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17358,7 +17428,7 @@
 UK 
 253

- <td width="117">
+ <td width="118">
 24.1.3

 <td width="85">
@@ -17367,7 +17437,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -17388,7 +17458,7 @@
 UK 
 254

- <td width="117">
+ <td width="118">
 24.1.3

 <td width="85">
@@ -17397,18 +17467,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 This
 postcondition for pre-increment operator should be written
 as an axiom

 

- <td width="535">
+ <td width="536">
 Move the postcondition into the concept
 definition as an axiom

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17416,7 +17486,7 @@
 UK 
 255

- <td width="117">
+ <td width="118">
 24.1.4

 <td width="85">
@@ -17425,18 +17495,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 This
 postcondition for pre-increment operator should be written
 as an axiom

 

- <td width="535">
+ <td width="536">
 Move the postcondition into the concept
 definition as an axiom

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17444,7 +17514,7 @@
 UK 
 256

- <td width="117">
+ <td width="118">
 24.1.5

 <td width="85">
@@ -17453,18 +17523,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The relationship between pre- and post-
 decrement should be expressed as an axiom.

- <td width="535">
+ <td width="536">
 Move the text
 specification of pre/post-conditions and behaviour into an
 axiom within the BidirectionalIterator concept

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17472,7 +17542,7 @@
 UK 
 257

- <td width="117">
+ <td width="118">
 24.1.5

 <td width="85">
@@ -17481,7 +17551,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 There is a
 reasonable default for postdecrement_result type, which is
 X. X is required to be regular, therefore CopyConstructible
@@ -17490,11 +17560,11 @@

 

- <td width="535">
+ <td width="536">
 Add the default : typename
 postincrement_result = X;

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17502,7 +17572,7 @@
 UK 
 258

- <td width="117">
+ <td width="118">
 24.1.5

 <td width="85">
@@ -17511,19 +17581,19 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 A default
 implementation should be supplied for the post-decrement
 operator to simplify implementation of iterators by users.

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -17531,7 +17601,7 @@
 UK 
 259

- <td width="117">
+ <td width="118">
 24.1.5

 <td width="85">
@@ -17540,7 +17610,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 
 postdecrement_result is effectively returning a copy of the
 original iterator value, so should have similar
@@ -17550,11 +17620,11 @@

 

- <td width="535">
+ <td width="536">
 Add the requirement: requires Iterator<
 postdecrement_result >;

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17562,7 +17632,7 @@
 UK 
 260

- <td width="117">
+ <td width="118">
 24.1.5

 <td width="85">
@@ -17571,13 +17641,13 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Move the Effects
 clause into the BidirectionalIterator concept definition as
 an axiom, and as the default implementation for the
@@ -17585,7 +17655,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17593,7 +17663,7 @@
 UK 
 249

- <td width="117">
+ <td width="118">
 24.1.6

@@ -17603,7 +17673,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The semantic for
 operator+= should also be provided as a default
 implementation to simplify implementation of user-defined
@@ -17611,12 +17681,12 @@

 

- <td width="535">
+ <td width="536">
 Copy the text from the effects clause into
 the RandomAccessIterator concept as the default
 implementaiton.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17624,7 +17694,7 @@
 UK 
 261

- <td width="117">
+ <td width="118">
 24.1.6

 <td width="85">
@@ -17633,17 +17703,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 To simplify user
 defined random access iterator types, the
 subscript_reference type should default to reference

 

- <td width="535">
+ <td width="536">
 typename subscript_reference = reference;

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17651,7 +17721,7 @@
 UK 
 262

- <td width="117">
+ <td width="118">
 24.1.6

 <td width="85">
@@ -17660,12 +17730,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Effects and post-conditions for operator+
 are more useful if expressed as axioms, and supplied as
 default implementations.

- <td width="535">
+ <td width="536">
 Move the effects
 and Postcondition definitions into the RandomAccessIterator
 concept and copy the code in the specification as the
@@ -17673,7 +17743,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17681,7 +17751,7 @@
 UK 
 263

- <td width="117">
+ <td width="118">
 24.1.6

 <td width="85">
@@ -17690,12 +17760,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Move the
 specification for operator-= from the returns clause into
 an axiom and default implementation within the
@@ -17703,7 +17773,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17711,7 +17781,7 @@
 UK 
 264

- <td width="117">
+ <td width="118">
 24.1.6

 <td width="85">
@@ -17720,18 +17790,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Effects clauses are better expressed as
 axioms where possible.

- <td width="535">
+ <td width="536">
 Move code in
 operator- effects clause into RandomAccessIterator concept
 as both a default implementation and an axiom

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17739,7 +17809,7 @@
 UK 
 265

- <td width="117">
+ <td width="118">
 24.1.6

 <td width="85">
@@ -17748,7 +17818,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 This effects
 clause is nonesense. It looks more like an axiom stating
 equivalence, and certainly an effects clause cannot change
@@ -17756,10 +17826,10 @@

 

- <td width="535">
+ <td width="536">
 Strike the Effects clause

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17767,7 +17837,7 @@
 UK 
 266

- <td width="117">
+ <td width="118">
 24.1.6

 <td width="85">
@@ -17776,11 +17846,11 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 This sentance should be provided as a
 default definition, along with a matching axiom

- <td width="535">
+ <td width="536">
 Move the Returns
 clause into the spefication for RandomAccessIterator
 operator- as a default implementation. Move the Effects
@@ -17788,7 +17858,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17796,7 +17866,7 @@
 UK 
 267

- <td width="117">
+ <td width="118">
 24.1.6

 <td width="85">
@@ -17805,18 +17875,18 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The code in the
 Requires clause for RandomAccessIterator operator[] would
 be better expressed as an axiom.

 

- <td width="535">
+ <td width="536">
 Rewrite the Requires clause as an axiom in
 the RandomAccessIterator concept

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -17824,7 +17894,7 @@
 UK 
 268

- <td width="117">
+ <td width="118">
 24.1.6

 <td width="85">
@@ -17833,7 +17903,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
 <td width="29">
 JP 60

- <td width="117">
+ <td width="118">
 24.1.8

 <td width="85">
@@ -17864,7 +17934,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 Capability of an iterator is too much restricted by
 concept.
@@ -18036,12 +18106,12 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 InputRange, OutputRange, ForwardRange, BidirectionalRange
 and RandomAccessRange.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18049,7 +18119,7 @@
 UK 
 269

- <td width="117">
+ <td width="118">
 24.3

 <td width="85">
@@ -18058,17 +18128,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 'decrements for
 negative n' seems to imply a negative number of decrement
 operations, which is odd.

 

- <td width="535">
+ <td width="536">
 Need simple, clearer wording

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18076,7 +18146,7 @@
 UK 
 270

- <td width="117">
+ <td width="118">
 24.3

 <td width="85">
@@ -18085,19 +18155,19 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The reachability
 constraint in p5 means that a negavite result, implying
 decrements operations in p4, is not possible

 

- <td width="535">
+ <td width="536">
 Split the two overloads into separate
 descriptions, where reachability is permitted to be in
 either direction for RandomAccessIterator

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18105,7 +18175,7 @@
 UK 
 271

- <td width="117">
+ <td width="118">
 24.3

 <td width="85">
@@ -18114,7 +18184,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 next/prev return
 an incremented iterator without changing the value of the
 original iterator. However, even this may invalidate an
@@ -18123,11 +18193,11 @@

 

- <td width="535">
+ <td width="536">
 Replace InputIterator constraint with
 FOrwardIterator in next and prev function templates.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18135,7 +18205,7 @@
 UK 
 272

- <td width="117">
+ <td width="118">
 24.4

 <td width="85">
@@ -18144,7 +18214,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 reverse_iterator
 and move_iterator use different formulations for their
 comparison operations. move_iterator merely requires the
@@ -18163,12 +18233,12 @@

 

- <td width="535">
+ <td width="536">
 Rephrase the reverse_iterator comparison
 operations using only operators < and ==, as per the
 move_iterator specification.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18176,7 +18246,7 @@
 UK 
 274

- <td width="117">
+ <td width="118">
 24.4, 24.5

 <td width="85">
@@ -18185,7 +18255,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The subclauses
 for standard iterator adaptors could be better organised.
 There are essentially 3 kinds of iterator wrappers
@@ -18198,13 +18268,13 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -18212,7 +18282,7 @@
 UK 
 275

- <td width="117">
+ <td width="118">
 24.4.1.1

 <td width="85">
@@ -18221,7 +18291,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The constructor
 template taking a single Iterator argument will be selected
 for Copy Initialization instead of the non-template
@@ -18230,11 +18300,11 @@

 

- <td width="535">
+ <td width="536">
 The reverse_iterator template constructor
 taking a single Iterator argument should be explicit.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18242,7 +18312,7 @@
 UK 
 276

- <td width="117">
+ <td width="118">
 24.4.1.1

 <td width="85">
@@ -18251,7 +18321,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Make the member operators taking a
 difference_type argument non-member operators

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18271,7 +18341,7 @@
 UK 
 277

- <td width="117">
+ <td width="118">
 24.4.1.2.1

 <td width="85">
@@ -18280,7 +18350,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The default
 constructor default-initializes current, rather than
 value-initializes. This means that when Iterator
@@ -18293,7 +18363,7 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -18309,7 +18379,7 @@
 UK 
 278

- <td width="117">
+ <td width="118">
 24.4.1.2.1

 <td width="85">
@@ -18318,7 +18388,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 There is an
 inconsistency between the constructor taking an iterator
 and the constructor template taking a reverse_iterator
@@ -18328,11 +18398,11 @@

 

- <td width="535">
+ <td width="536">
 Change the const reverse_iterator
 & parameter to pass-by-value

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18340,7 +18410,7 @@
 UK 
 279

- <td width="117">
+ <td width="118">
 24.4.1.2.12, 
 24.4.3.2.12

@@ -18350,7 +18420,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Specify the return type using either
 decltype or the Iter concept map

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18371,7 +18441,7 @@
 UK 
 280

- <td width="117">
+ <td width="118">
 24.4.1.2.4

 <td width="85">
@@ -18380,7 +18450,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Add reverse_iterator expsoition only member
 tmp as a comment to class declaration, as a private member

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18401,7 +18471,7 @@
 UK 
 281

- <td width="117">
+ <td width="118">
 24.4.1.2.5

 <td width="85">
@@ -18410,7 +18480,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The current
 specification for return value will always be a true
 pointer type, but reverse_iterator supports proxy iterators
@@ -18418,12 +18488,12 @@

 

- <td width="535">
+ <td width="536">
 Replace the existing returns specification
 with a copy of the operator* specification that returns
 this->tmp.operator->

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18431,7 +18501,7 @@
 UK 
 282

- <td width="117">
+ <td width="118">
 24.4.2.1, 
 24.4.2.2.2, 
 24.4.2.3, 
@@ -18445,17 +18515,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Insert iterators of move-only types will
 move from lvalues

- <td width="535">
+ <td width="536">
 Add an additional constrained overload for
 operator= that requires
 !CopyConstructible<Cont::value_type> and mark it
 =delete.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18463,7 +18533,7 @@
 UK 
 283

- <td width="117">
+ <td width="118">
 24.4.2.5, 
 24.4.2.6.4

@@ -18473,7 +18543,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 JP 61

- <td width="117">
+ <td width="118">
 24.4.3.2.1

 <td width="85">
@@ -18504,18 +18574,18 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo.

 
 "intializing" should be "initializing"

- <td width="535">
+ <td width="536">
 Add
 "i"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18523,7 +18593,7 @@
 UK 
 284

- <td width="117">
+ <td width="118">
 24.5

 <td width="85">
@@ -18532,17 +18602,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The stream
 iterators need constraining with concepts/requrires
 clauses.

 

- <td width="535">
+ <td width="536">
 Provide constraints

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18550,7 +18620,7 @@
 UK 
 285

- <td width="117">
+ <td width="118">
 24.5.1

 <td width="85">
@@ -18559,18 +18629,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Much of the
 content of p1 and the whole of p2 is a redundant
 redefinition of InputIterator. It should be simplified

 

- <td width="535">
+ <td width="536">
 Strike p2. Simplify p1 and add a
 cross-reference to the definition of InputIterator concept.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18578,7 +18648,7 @@
 UK 
 286

- <td width="117">
+ <td width="118">
 24.5.1

 <td width="85">
@@ -18587,7 +18657,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -18609,7 +18679,7 @@
 UK 
 287

- <td width="117">
+ <td width="118">
 24.5.1.1

 <td width="85">
@@ -18618,7 +18688,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -18643,7 +18713,7 @@
 UK 
 288

- <td width="117">
+ <td width="118">
 24.5.1.1

 <td width="85">
@@ -18652,18 +18722,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The provided specification is vacuous,
 offering no useful information.

- <td width="535">
+ <td width="536">
 Either strike
 the specification of the copy constructor, or simply
 replace it with an = default definition.

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18671,7 +18741,7 @@
 UK 
 289

- <td width="117">
+ <td width="118">
 24.5.1.2

 <td width="85">
@@ -18680,7 +18750,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 It is very hard
 to pick up the correct specification for
 istream_iterator::operator== as the complete specification
@@ -18692,12 +18762,12 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -18705,7 +18775,7 @@
 UK 
 290

- <td width="117">
+ <td width="118">
 24.5.2

 <td width="85">
@@ -18714,7 +18784,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Replace char * with const charT *

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18733,7 +18803,7 @@
 UK 
 291

- <td width="117">
+ <td width="118">
 24.5.2.2

 <td width="85">
@@ -18742,7 +18812,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 ostream_iterator operator++(int);

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 34

- <td width="117">
+ <td width="118">
 24.5.3 
 [istreambuf. 
 iterator]
@@ -18771,17 +18841,17 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 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.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18789,7 +18859,7 @@
 UK 
 292

- <td width="117">
+ <td width="118">
 24.5.3

 <td width="85">
@@ -18798,18 +18868,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Prefer the use
 of the new nullptr constant to the zero literal when using
 a null pointer in text.

 

- <td width="535">
+ <td width="536">
 Change istreambuf_iterator(0) to
 istreambuf_iterator(nullptr)

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18817,7 +18887,7 @@
 UK 
 293

- <td width="117">
+ <td width="118">
 24.5.3

 <td width="85">
@@ -18826,12 +18896,12 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18852,7 +18922,7 @@
 UK 
 294

- <td width="117">
+ <td width="118">
 24.5.3.2

 <td width="85">
@@ -18861,12 +18931,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Mark the two
 single-argument constructors take a stream or stream buffer
 as explicit. The proxy constructor should remain implicit.
@@ -18878,7 +18948,7 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18886,7 +18956,7 @@
 UK 
 295

- <td width="117">
+ <td width="118">
 25

 <td width="85">
@@ -18895,7 +18965,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Adopt n2743, or an update of that paper.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 62

- <td width="117">
+ <td width="118">
 25, 25.3.1.5, 
 26.3.6.5

@@ -18925,7 +18995,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 The return types of is_sorted_until function and
@@ -18941,14 +19011,14 @@
 

- <td width="535">
+ <td width="536">
 
 Change "is_sorted_until" to "sorted_bound"

 
 Change "is_heap" to "heap_bound"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18956,7 +19026,7 @@
 UK 
 296

- <td width="117">
+ <td width="118">
 25.1.8

 <td width="85">
@@ -18965,7 +19035,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The 'Returns' of
 adjacent_find requires only HasEqualTo, or a Predicate.
 Requiring EqualityComparable or EquivalenceRelation seems
@@ -18973,11 +19043,11 @@

 

- <td width="535">
+ <td width="536">
 Change EqualityComparable to HasEqualTo and
 EquivalnceRelation to Predicate

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -18985,7 +19055,7 @@
 UK 
 297

- <td width="117">
+ <td width="118">
 25.2.11

 <td width="85">
@@ -18994,19 +19064,19 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The definition
 of rotate_copy is very complicated. It is equivalent to:
 return copy(first, middle, copy(middle, last, result));

 

- <td width="535">
+ <td width="536">
 Change 'effects' to, returns, requires,
 complexity to: effects: equivalent to: return copy(first,
 middle, copy(middle, last, result));

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19014,7 +19084,7 @@
 UK 
 298

- <td width="117">
+ <td width="118">
 25.2.13

 <td width="85">
@@ -19023,15 +19093,15 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 partition_point requires a partitioned
 array

- <td width="535">
+ <td width="536">
 requires: is_partitioned(first, last, pred)
 != false;

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19039,7 +19109,7 @@
 UK 
 299

- <td width="117">
+ <td width="118">
 25.2.2

 <td width="85">
@@ -19048,19 +19118,19 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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">
 Change way signature is declared:
 template<InputIterator InIter, OutputIterator<auto,
 RvalueOf<InIter::reference>::type> OutIter>
 OutIter move(InIter first, InIter last, OutIter result);

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19068,7 +19138,7 @@
 UK 
 300

- <td width="117">
+ <td width="118">
 25.2.3

 <td width="85">
@@ -19077,7 +19147,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Move primary swap template from
 <algorithm> into <utility>. Move 25.2.3 to
 somewhere under 20.2. Require <algorithm> to #include
 <utility> to access pair and provide legacy support
 for finding swap.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19108,7 +19178,7 @@
 UK 
 301

- <td width="117">
+ <td width="118">
 25.2.5

 <td width="85">
@@ -19117,7 +19187,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 replace and
 replace_if have the requirement: OutputIterator<Iter,
 Iter::reference> Which implies they need to copy some
@@ -19128,11 +19198,11 @@

 

- <td width="535">
+ <td width="536">
 Remove OutputIterator<Iter,
 Iter::reference> from replace and replace_if

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19140,7 +19210,7 @@
 UK 
 302

- <td width="117">
+ <td width="118">
 25.3

 <td width="85">
@@ -19149,18 +19219,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 the concept
 StrictWeakOrder covers the definition of a strict weak
 ordering, described in paragraph 4.

 

- <td width="535">
+ <td width="536">
 Remove 4, and mention StrictWeakOrder in
 paragraph 1.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19168,7 +19238,7 @@
 UK 
 303

- <td width="117">
+ <td width="118">
 25.3

 <td width="85">
@@ -19177,18 +19247,18 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 This paragraph just describes
 is_partitioned

- <td width="535">
+ <td width="536">
 6 A sequence
 [start,finish) is partitioned with respect to an expression
 f(e) if is_partitioned(start, finish, e) != false

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19196,7 +19266,7 @@
 UK 
 304

- <td width="117">
+ <td width="118">
 25.3.6

 <td width="85">
@@ -19205,17 +19275,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 The requires
 clauses of push_heap, pop_heap and make_heap are
 inconsistently formatted, dispite being identical

 

- <td width="535">
+ <td width="536">
 Format them identically.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19223,7 +19293,7 @@
 UK 
 305

- <td width="117">
+ <td width="118">
 25.3.7

 <td width="85">
@@ -19232,23 +19302,23 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Strike the !IsSameType<T, Compare>
 constraint on min/max/minmax algorithms

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 84

- <td width="117">
+ <td width="118">
 26

 <td width="85">
@@ -19257,23 +19327,23 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 
 Parts of the numerics chapter are not concept enabled.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 35

- <td width="117">
+ <td width="118">
 26.3 
 [Complex 
 numbers]
@@ -19284,7 +19354,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Instantiations of the class
 template complex<> have to be allowed for integral
 types, to reflect existing practice and ISO standards
@@ -19292,10 +19362,10 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19303,7 +19373,7 @@
 UK 
 306

- <td width="117">
+ <td width="118">
 26.4

 <td width="85">
@@ -19312,24 +19382,24 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Random number
 library component cannot be used in constrained templates

 

- <td width="535">
+ <td width="536">
 Provide constraints for the random number
 library

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 63

- <td width="117">
+ <td width="118">
 26.4.8.5.1

 <td width="85">
@@ -19338,7 +19408,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 No
 constructor of discrete_distribution that accepts
 initializer_list.
@@ -19369,21 +19439,21 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 the following constructer.

 
 discrete_distribution(initializer_list<result_type>);

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 64

- <td width="117">
+ <td width="118">
 26.5.2

 <td width="85">
@@ -19392,7 +19462,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 “valarray<T>& operator+=
@@ -19401,12 +19471,12 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 valarray<T>& operator+=
 (initializer_list<T>);

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19414,7 +19484,7 @@
 UK 
 307

- <td width="117">
+ <td width="118">
 26.7

 <td width="85">
@@ -19423,7 +19493,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Drop the reference to TR1.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 85

- <td width="117">
+ <td width="118">
 27

 <td width="85">
@@ -19451,16 +19521,16 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 The
 input/output chapter is not concept enabled.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -19468,7 +19538,7 @@
 UK 
 308

- <td width="117">
+ <td width="118">
 27

 <td width="85">
@@ -19477,25 +19547,25 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 
 iostreams library cannot be used from
 constrained templates

 

- <td width="535">
+ <td width="536">
 Provide constraints for the iostreams
 library, clause 27

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 65

- <td width="117">
+ <td width="118">
 27.4.4

 <td width="85">
@@ -19504,7 +19574,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Switch from
 “unspecified-bool-type” to
 

- <td width="535">
+ <td width="536">
 
 Replace "operator unspecified-bool-type() const;"
 with "explicit operator bool() const;"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 66

- <td width="117">
+ <td width="118">
 27.4.4.3

 <td width="85">
@@ -19536,7 +19606,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Switch from
 “unspecified-bool-type” to
 

- <td width="535">
+ <td width="536">
 
 Replace "operator unspecified-bool-type() const;"
 with "explicit operator bool() const;"

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 36

- <td width="117">
+ <td width="118">
 27.6.1.2.2 
 [istream. 
 formatted. 
@@ -19570,7 +19640,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 iostate err = 0;

 
@@ -19582,17 +19652,17 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 37

- <td width="117">
+ <td width="118">
 27.6.1.2.2 
 [istream. 
 formatted. 
@@ -19604,7 +19674,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 else if (lval <
 numeric_limits<int>::min()

@@ -19618,17 +19688,17 @@

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 67

- <td width="117">
+ <td width="118">
 27.7.1

 <td width="85">
@@ -19637,11 +19707,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 basic_stringbuf dose not use concept.

- <td width="535">
+ <td width="536">
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -19767,14 +19837,14 @@
 
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 68

- <td width="117">
+ <td width="118">
 27.7.2

 <td width="85">
@@ -19783,11 +19853,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 basic_istringstream dose not use concept.

- <td width="535">
+ <td width="536">
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -19944,14 +20014,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 69

- <td width="117">
+ <td width="118">
 27.7.3

 <td width="85">
@@ -19960,11 +20030,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 basic_ostringstream dose not use concept.

- <td width="535">
+ <td width="536">
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -20122,14 +20192,14 @@
 
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 71

- <td width="117">
+ <td width="118">
 27.7.3

 <td width="85">
@@ -20138,14 +20208,14 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo.

 "template" is missing in
 "class basic_ostringstream" of the title of the chapter.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -20164,14 +20234,14 @@
 27.7.3 Class template
 basic_ostringstream

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 72

- <td width="117">
+ <td width="118">
 27.7.4

 <td width="85">
@@ -20180,11 +20250,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 basic_stringstream dose not use concept.

- <td width="535">
+ <td width="536">
 
 Replace "class Allocator" to "Allocator Alloc".

@@ -20336,14 +20406,14 @@

 }

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 73

- <td width="117">
+ <td width="118">
 27.8.1.14

 <td width="85">
@@ -20352,7 +20422,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 It is a problem
 from C++98, fstream cannot appoint a filename of wide
@@ -20361,18 +20431,18 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 interface corresponding to wchar_t, char16_t and char32_t.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 86

- <td width="117">
+ <td width="118">
 28

 <td width="85">
@@ -20381,16 +20451,16 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 The
 regular expressions chapter is not concept enabled.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -20398,7 +20468,7 @@
 UK 
 309

- <td width="117">
+ <td width="118">
 28

 <td width="85">
@@ -20407,17 +20477,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Regular
 expressions cannot be used in constrained templates

 

- <td width="535">
+ <td width="536">
 Provide constraints for the regular
 expression library, clause 28

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -20425,7 +20495,7 @@
 UK 
 310

- <td width="117">
+ <td width="118">
 28

 <td width="85">
@@ -20434,16 +20504,16 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Use concepts for iterator template
 arguments throughout.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -20451,7 +20521,7 @@
 UK 
 314

- <td width="117">
+ <td width="118">
 28.4

 <td width="85">
@@ -20460,7 +20530,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

 <tr valign="top">
@@ -20484,7 +20554,7 @@
 UK 
 315

- <td width="117">
+ <td width="118">
 28.4

 <td width="85">
@@ -20493,7 +20563,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 6 Effects:
 string_type str(first, last); return
 use_facet<collate<charT> >(
@@ -20502,11 +20572,11 @@

 

- <td width="535">
+ <td width="536">
 Reword to effect clause to use legal
 iterator dereferences

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -20514,7 +20584,7 @@
 UK 
 316

- <td width="117">
+ <td width="118">
 28.4 ff

 <td width="85">
@@ -20523,17 +20593,17 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The constructors
 for regex classes do not have an r-value overload.

 

- <td width="535">
+ <td width="536">
 Add the missing r-value constructors to
 regex classes.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -20541,7 +20611,7 @@
 UK 
 317

- <td width="117">
+ <td width="118">
 28.8

 <td width="85">
@@ -20550,12 +20620,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 In the
 basic_regex synopsis, after: basic_regex&
 operator=(const charT* ptr); add: basic_regex&
@@ -20566,14 +20636,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 JP 74

- <td width="117">
+ <td width="118">
 28.8

 <td width="85">
@@ -20582,7 +20652,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 “basic_regx & operator=
@@ -20591,11 +20661,11 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 basic_regx & operator= (initializer_list<T>);

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -20603,7 +20673,7 @@
 UK 
 318

- <td width="117">
+ <td width="118">
 28.8.2

 <td width="85">
@@ -20612,17 +20682,17 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Constructor
 definition should appear with the other constructors not
 after assignment ops.

 

- <td width="535">
+ <td width="536">
 Move para 22 to just after para 17.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -20630,7 +20700,7 @@
 UK 
 319

- <td width="117">
+ <td width="118">
 28.12.2

 <td width="85">
@@ -20639,7 +20709,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 To the synopsis
 for regex_token_iterator, after template <std::size_t
 N> regex_token_iterator(BidirectionalIterator a,
@@ -20675,14 +20745,14 @@

 

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 US 87

- <td width="117">
+ <td width="118">
 29

 <td width="85">
@@ -20691,25 +20761,26 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 The
 atomics chapter is not concept enabled. The adopted paper,
 N2427, did have those concepts.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
- 
+ <td width="178">
+ Create an issue for concepts in the atomics chapter. See
+ N2427. Needs to also consider issues 923 and 924. 

 <tr valign="top">
 <td width="29">
 UK 
 311

- <td width="117">
+ <td width="118">
 29

 <td width="85">
@@ -20718,25 +20789,25 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Atomic types
 cannot be used generically in a constrained template

 

- <td width="535">
+ <td width="536">
 Provide constraints for the atomics
 library, clause 29

- <td width="89">
- 
+ <td width="178">
+ Duplicate of US 87. 

 <tr valign="top">
 <td width="29">
 UK 
 312

- <td width="117">
+ <td width="118">
 29

 <td width="85">
@@ -20745,14 +20816,14 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The contents of the <stdatomic.h>
 header are not listed anywhere, and <cstdatomic> 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">
 Remove <cstdatomic> from the C99
 headers in table 14. Add a new header <atomic> 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">
- 
+ <td width="178">
+ Create an issue. Assigned to Lawrence Crowl. May be
+ resolvable with a footnote for clarity stating that the header is
+ defined where it exists. 

 <tr valign="top">
 <td width="29">
 JP 75

- <td width="117">
+ <td width="118">
 29

 <td width="85">
@@ -20777,12 +20850,12 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 A
 definition of enum or struct is the style of C using
 typedef.

- <td width="535">
+ <td width="536">
 
 Change to a style of C++.

@@ -21010,15 +21083,17 @@

 }

- <td width="89">
- 
+ <td width="178">
+ 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. 

 <tr valign="top">
 <td width="29">
 UK 
 313

- <td width="117">
+ <td width="118">
 29.1

 <td width="85">
@@ -21027,12 +21102,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
- 
+ <td width="178">
+ Hans to make proposal. See LWG Issue 926. 

 <tr valign="top">
 <td width="29">
 US 88

- <td width="117">
+ <td width="118">
 29.2

 <td width="85">
@@ -21059,11 +21134,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The "lockfree" facilities do
 not tell the programmer enough.

- <td width="535">
+ <td width="536">
 
 Expand the "lockfree" facilities. See the attached paper
 "Issues with the C++ Standard" under Chapter 29,
@@ -21071,14 +21146,16 @@

 

- <td width="89">
- 
+ <td width="178">
+ 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. 

 <tr valign="top">
 <td width="29">
 US 89

- <td width="117">
+ <td width="118">
 29.3.1

 <td width="85">
@@ -21087,7 +21164,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 types in the table "Atomics for standard typedef types"
 should be typedefs, not classes. These semantics are
@@ -21095,18 +21172,19 @@

 

- <td width="535">
+ <td width="536">
 Change the classes to
 typedefs.

- <td width="89">
- Google
-
- <tr valign="top">
+ <td width="178">
+ 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">
 US 90

- <td width="117">
+ <td width="118">
 29.4

 <td width="85">
@@ -21115,11 +21193,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 Are atomic functions allowed
 to have non-volatile overloads?

- <td width="535">
+ <td width="536">
 
 Allow non-volatile overloads. See the attached paper
 "Issues with the C++ Standard, under Chapter 29, "Are
@@ -21127,14 +21205,15 @@

 

- <td width="89">
- 
+ <td width="178">
+ Create an issue. Assigned to Lawrence Crowl. Should
+ explicitly consider the process shared issue. 

 <tr valign="top">
 <td width="29">
 US 91

- <td width="117">
+ <td width="118">
 29.4

 <td width="85">
@@ -21143,12 +21222,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 
 Make failing compare_exchange operations not be RMW. See
@@ -21157,14 +21236,16 @@

 

- <td width="89">
- 
+ <td width="178">
+ Create an issue, goes to review. Attention: Howard.
+ Group agrees with the resolution as proposed by Anthony Williams in the
+ attached note. 

 <tr valign="top">
 <td width="29">
 US 92

- <td width="117">
+ <td width="118">
 29.4

 <td width="85">
@@ -21173,11 +21254,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The effect of
 memory_order_consume with atomic RMW operations is unclear.

- <td width="535">
+ <td width="536">
 
 Follow the lead of fences [atomics.fences], and promote
 memory_order_consume to memory_order_acquire with RMW
@@ -21185,14 +21266,15 @@

 

- <td width="89">
- 
+ <td width="178">
+ Create an issue. Assigned to Lawrence. Resolution
+ requires proposed wording. 

 <tr valign="top">
 <td width="29">
 JP 76

- <td width="117">
+ <td width="118">
 30

 <td width="85">
@@ -21201,7 +21283,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 A
 description for "Throws: Nothing." are not unified.

@@ -21209,7 +21291,7 @@
 the part without throw, "Throws: Nothing." should be
 described.

- <td width="535">
+ <td width="536">
 Add
 "Throws: Nothing." to the following.

@@ -21238,14 +21320,14 @@
 
 

- <td width="89">
- 
+ <td width="178">
+ Pass on to editor. 

 <tr valign="top">
 <td width="29">
 US 93

- <td width="117">
+ <td width="118">
 30

 <td width="85">
@@ -21254,17 +21336,18 @@
 <td width="62">
 ge

- <td width="604">
+ <td width="514">
 The
 thread chapter is not concept enabled.

 

- <td width="535">
+ <td width="536">
 

- <td width="89">
- 
+ <td width="178">
+ Create an issue. Need to find volunteers to work on
+ this. 

 <tr valign="top">
 <td width="29">
@@ -21274,7 +21357,7 @@

 

- <td width="117">
+ <td width="118">
 30

 <td width="85">
@@ -21283,23 +21366,23 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Threads library cannot be used in
 constrained templates

- <td width="535">
+ <td width="536">
 Provide constraints for the threads
 library, clause 30

- <td width="89">
- 
+ <td width="178">
+ Duplicate of US 93. 

 <tr valign="top">
 <td width="29">
 UK 
 321

- <td width="117">
+ <td width="118">
 30

 <td width="85">
@@ -21308,7 +21391,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 Throughout this
 clause, the term Requires: is used to introduce compile
 time requirements, which we expect to be replaced with
@@ -21322,18 +21405,18 @@

 

- <td width="535">
+ <td width="536">
 Decument Preconditions: paragraphs in
 17.5.2.4, and use consistently through rest of the library.

- <td width="89">
- 
+ <td width="178">
+ Pass on to editor. 

 <tr valign="top">
 <td width="29">
 US 94

- <td width="117">
+ <td width="118">
 30.1.2

 <td width="85">
@@ -21342,12 +21425,12 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Rewrite para 1
 as: “ Some functions described
@@ -21361,14 +21444,14 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Reclassify as editorial. Pass on to editor, wording roughly as proposed.<tr valign="top">
 <td width="29">
 US 95

- <td width="117">
+ <td width="118">
 30.1.3

 <td width="85">
@@ -21377,11 +21460,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 “native_handle_type” is a typedef, not a
 class member.

- <td width="535">
+ <td width="536">
 Several classes
 described in this Clause have a member native_handle (of
@@ -21398,14 +21481,15 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 US 96

- <td width="117">
+ <td width="118">
 30.1.4

 <td width="85">
@@ -21414,10 +21498,10 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 There is no definition here for monotonic clock.

- <td width="535">
+ <td width="536">
 Implementations
 should use a monotonic clock to measure time for
@@ -21427,15 +21511,16 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 322

- <td width="117">
+ <td width="118">
 30.1.4

 <td width="85">
@@ -21444,26 +21529,29 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Not all systms
 can provide a monotonic clock. How are they expected to
 treat a _for function?

 

- <td width="535">
+ <td width="536">
 Add at least a note explaining the intent
 for systems that do not support a monotonic clock.

- <td width="89">
+ <td width="178">
 

- <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 "should" rather than
+ "shall". If this wording is kept, a footnote should be added to make the
+ meaning clear.<tr valign="top">
 <td width="29">
 UK 
 323

- <td width="117">
+ <td width="118">
 30.2.1

 <td width="85">
@@ -21472,7 +21560,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The presence of
 a non-explicit variadic template constructor alongside an
 explicit single-argument constructor can lead to behaviour
@@ -21485,21 +21573,22 @@

 

- <td width="535">
+ <td width="536">
 Mark constructor template <class F,
 class ...Args> thread(F&& f, Args&&...
 args); as explicit and remove the single-argument
 constructor.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue, goes to review. Attention: Howard. Group agrees with the
+ proposed resolution.<tr valign="top">
 <td width="29">
 UK 
 324

- <td width="117">
+ <td width="118">
 30.2.1.1

 <td width="85">
@@ -21508,14 +21597,14 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 thread::id
 objects should be as useable in hashing containers as they
 are in ordered associative containers.

 

- <td width="535">
+ <td width="536">
 Add thread::id
 support for std::hash

@@ -21525,14 +21614,15 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 JP 77

- <td width="117">
+ <td width="118">
 30.2.1.2

 <td width="85">
@@ -21541,7 +21631,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 
 "CopyConstructible" and "MoveConstructible" in
@@ -21552,18 +21642,18 @@
 
 

- <td width="535">
+ <td width="536">
 Add
 a concept for constructor of thread.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
 <td width="29">
 JP 78

- <td width="117">
+ <td width="118">
 30.2.1.2

 <td width="85">
@@ -21576,22 +21666,22 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 In
 "F and each Ti in Args", 'Ti' is not clear.

- <td width="535">
+ <td width="536">
 
 Replace "Ti" with "args"

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Pass on to editor.<tr valign="top">
 <td width="29">
 US 97

- <td width="117">
+ <td width="118">
 30.2.1.3

 <td width="85">
@@ -21600,22 +21690,22 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 detach-on-destruction may result in
 “escaped” threads accessing objects with
 bounded lifetime after the end of their lifetime.

- <td width="535">
+ <td width="536">
 See document WG21 N2802=08-0312 written by Hans Boehm.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. To be discussed in full library group.<tr valign="top">
 <td width="29">
 US 98

- <td width="117">
+ <td width="118">
 30.2.1.3, 
 30.2.1.4

@@ -21625,13 +21715,13 @@
 <td width="62">
 

- <td width="604">
+ <td width="514">
 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">
 
 Change destruction behavior to undefined behavior, with a
 note strongly encouraging termination. See the attached
@@ -21640,15 +21730,15 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Duplicate of US 97.<tr valign="top">
 <td width="29">
 UK 
 325

- <td width="117">
+ <td width="118">
 30.3.3

 <td width="85">
@@ -21657,13 +21747,13 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. The current
+ specification is a "hack", and the proposed specification is a better
+ "hack".<tr valign="top">
 <td width="29">
 UK 
 326

- <td width="117">
+ <td width="118">
 30.3.3.2.1

 <td width="85">
@@ -21690,7 +21782,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 The precondition
 that the mutex is not owned by this thread offers
 introduces the risk of un-necessary undefined behaviour
@@ -21704,18 +21796,19 @@

 

- <td width="535">
+ <td width="536">
 Strike 30.3.3.2.1p7

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.<tr valign="top">
 <td width="29">
 UK 
 327

- <td width="117">
+ <td width="118">
 30.3.3.2.2

 <td width="85">
@@ -21724,7 +21817,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 Not clear what
 the specification for error condition
 resource_deadlock_would_occur means. It is perfectly
@@ -21743,20 +21836,23 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <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">
 UK 
 328

- <td width="117">
+ <td width="118">
 30.3.3.2.2

 <td width="85">
@@ -21765,27 +21861,28 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Add a
 precondition that owns == true. Add an error condition to
 detect a violation, rather than yield undefined behaviour.

 

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 329

- <td width="117">
+ <td width="118">
 30.5

 <td width="85">
@@ -21794,14 +21891,14 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Provide a simple
 function along the lines of: template< typename F,
 typename ... Args > requires Callable< F, Args...
@@ -21824,15 +21921,16 @@

 

- <td width="89">
+ <td width="178">
 

- <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">
 UK 
 330

- <td width="117">
+ <td width="118">
 30.5.1

 <td width="85">
@@ -21841,28 +21939,29 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 30.5.1 (and then 30.5.7) refer to a
 specialisation of
 constructible_with_allocator_prefix<> However this
 trait is not in the CD, so references to it should be
 removed.

- <td width="535">
+ <td width="536">
 Remove the
 reference to constructible_with_allocator_prefix in 30.5.1
 Remove paragraph 30.5.7

 

- <td width="89">
+ <td width="178">
 

- <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">
 JP 79

- <td width="117">
+ <td width="118">
 30.5.1

 <td width="85">
@@ -21871,11 +21970,11 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 The
 concept of UsesAllocator and Allocator should be used.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -21915,15 +22014,15 @@
 
 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
 <td width="29">
 UK 
 331

- <td width="117">
+ <td width="118">
 30.5.3

 <td width="85">
@@ -21932,7 +22031,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <tr valign="top">
+ Create an issue. Assigned to Detlef. Suggested resolution probably makes
+ sense.<tr valign="top">
 <td width="29">
 UK 
 332

- <td width="117">
+ <td width="118">
 30.5.4

 <td width="85">
@@ -21964,7 +22064,7 @@
 <td width="62">
 Ed

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <tr valign="top">
+ Pass on to editor. Detlef has volunteered to provide some wording.<tr valign="top">
 <td width="29">
 UK 
 333

- <td width="117">
+ <td width="118">
 30.5.4

 <td width="85">
@@ -21998,24 +22098,24 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 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">
 Requires fully baked concepts for clause 30

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
 <td width="29">
 UK 
 334

- <td width="117">
+ <td width="118">
 30.5.4

 <td width="85">
@@ -22024,7 +22124,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Effects: If is_ready() would return false,
 block on the asynchronous result associated with *this.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.<tr valign="top">
 <td width="29">
 UK 
 335

- <td width="117">
+ <td width="118">
 30.5.4

 <td width="85">
@@ -22053,7 +22154,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 
 std::unique_future is MoveConstructible, so you can
 transfer the association with an asynchronous result from
@@ -22067,22 +22168,22 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <tr valign="top">
+ Create an issue. Requires input from Howard. Probably NAD.<tr valign="top">
 <td width="29">
 UK 
 336

- <td width="117">
+ <td width="118">
 30.5.4

 <td width="85">
@@ -22091,7 +22192,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 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">
 

- <tr valign="top">
+ Create an issue. Detlef will look into it.<tr valign="top">
 <td width="29">
 JP 80

- <td width="117">
+ <td width="118">
 30.5.4 , 
 30.5.5

@@ -22128,7 +22229,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 Typo, duplicated ">"

@@ -22139,19 +22240,19 @@
 
 

- <td width="535">
+ <td width="536">
 
 Remove one

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Pass on to editor.<tr valign="top">
 <td width="29">
 UK 
 337

- <td width="117">
+ <td width="118">
 30.5.5

 <td width="85">
@@ -22160,7 +22261,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 shared_future
 should support an efficient move constructor that can avoid
 unnecessary manipulation of a reference count, much like
@@ -22168,18 +22269,18 @@

 

- <td width="535">
+ <td width="536">
 Add a move constructor

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Detlef will look into it.<tr valign="top">
 <td width="29">
 UK 
 338

- <td width="117">
+ <td width="118">
 30.5.5

 <td width="85">
@@ -22188,7 +22289,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Remove "=delete"
 from the copy-assignment operator of shared_future. Add a
 move-constructor shared_future(shared_future&&
@@ -22216,15 +22317,15 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Detlef will look into it.<tr valign="top">
 <td width="29">
 UK 
 339

- <td width="117">
+ <td width="118">
 30.5.6

 <td width="85">
@@ -22233,12 +22334,12 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 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 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.<tr valign="top">
 <td width="29">
 UK 
 340

- <td width="117">
+ <td width="118">
 30.5.6

 <td width="85">
@@ -22263,7 +22365,7 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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 @@

 

- <td width="535">
+ <td width="536">
 Postcondition: *this has no associated
 state.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.<tr valign="top">
 <td width="29">
 UK 
 341

- <td width="117">
+ <td width="118">
 30.5.6

 <td width="85">
@@ -22292,25 +22395,25 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Change promise::swap to take an rvalue
 reference.

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Detlef will look into it. Probably ready as it.<tr valign="top">
 <td width="29">
 UK 
 342

- <td width="117">
+ <td width="118">
 30.5.6

 <td width="85">
@@ -22319,26 +22422,27 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 std::promise is
 missing a non-member overload of swap. This is inconsistent
 with other types that provide a swap member function

 

- <td width="535">
+ <td width="536">
 Add a non-member overload void
 swap(promise&& x,promise&& y){ x.swap(y); }

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Move to review, attention: Howard. Detlef will also look
+ into it.<tr valign="top">
 <td width="29">
 UK 
 343

- <td width="117">
+ <td width="118">
 30.5.6

 <td width="85">
@@ -22347,13 +22451,13 @@
 <td width="62">
 Te

- <td width="604">
+ <td width="514">
 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">
 Remove the
 constructor with the signature template <class
 Allocator> promise(allocator_arg_t, const Allocator&
@@ -22361,14 +22465,15 @@

 

- <td width="89">
+ <td width="178">
 

- <tr valign="top">
+ Create an issue. Detlef will look into it. Will solicit feedback from Pablo.
+ Note that "rhs" argument should also be an rvalue reference in any case.<tr valign="top">
 <td width="29">
 JP 81

- <td width="117">
+ <td width="118">
 30.5.8

 <td width="85">
@@ -22377,12 +22482,12 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 
 There are not requirements for F and a concept of Allocator
 dose not use.

- <td width="535">
+ <td width="536">
 
 Correct as follows.

@@ -22492,14 +22597,15 @@
 packaged_task(allocator_arg_t, const Alloc& a,
 F&& f);

- <td width="89">
+ <td width="178">
 

- <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">
 DE-23

- <td width="117">
+ <td width="118">
 Annex B

 <td width="85">
@@ -22508,7 +22614,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 In Annex B, specify a recursion depth of 256 or a larger
 value.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-24

- <td width="117">
+ <td width="118">
 Annex B

 <td width="85">
@@ -22536,23 +22642,23 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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. 

- <td width="535">
+ <td width="536">
 Add a miminum of 10 placeholders to Annex B.

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 DE-25

- <td width="117">
+ <td width="118">
 Annex B

 <td width="85">
@@ -22561,7 +22667,7 @@
 <td width="62">
 te

- <td width="604">
+ <td width="514">
 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">
 Remove the bullet "Recursively nested template
 instantiations [17]".

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
 <td width="29">
 FR 38

- <td width="117">
+ <td width="118">
 C.2 
 [diffs.library]

@@ -22593,7 +22699,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 What is ISO/IEC 1990:9899/DAM
 1? My guess is that's a typo for ISO/IEC

@@ -22603,13 +22709,13 @@
 make reference to things
 which were introduced by Amd.1).

- <td width="535">
+ <td width="536">
 One need probably a reference
 to the document which introduce char16_t and

 char32_t in C (ISO/IEC TR 19769:2004?).

- <td width="89">
+ <td width="178">
 

 <tr valign="top">
@@ -22617,7 +22723,7 @@
 UK 
 344

- <td width="117">
+ <td width="118">
 Appendix D

 <td width="85">
@@ -22626,27 +22732,27 @@
 <td width="62">
 Ge

- <td width="604">
+ <td width="514">
 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">
 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">
 

 <tr valign="top">
 <td width="29">
 FR 39

- <td width="117">
+ <td width="118">
 Index

 <td width="85">
@@ -22655,7 +22761,7 @@
 <td width="62">
 ed

- <td width="604">
+ <td width="514">
 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">
 

- <td width="89">
+ <td width="178">
 

 </table><hr>
\ No newline at end of file

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51567 - sandbox/committee/LWG"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51565 - sandbox/committee/LWG"

Date view	Thread view	Subject view	Author view

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