Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r51565 - sandbox/committee/LWG
From: bdawes_at_[hidden]
Date: 2009-03-03 08:31:43

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

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

Log:
cleanup
Text files modified:
sandbox/committee/LWG/0xCD1_Comments.html | 4883 ++++++++++++++++++++-------------------
1 files changed, 2466 insertions(+), 2417 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:31:41 EST (Tue, 03 Mar 2009)
@@ -25,17 +25,17 @@
 <td width="29">
 MB 

- <td>
+ <td width="117">
 Clause No./ 
 Subclause No./ 
 Annex (e.g. 3.1)

- <td width="107">
+ <td width="85">
 Para/ 
- Figure/ Table/ Note<td width="38">
+ Figure/ Table/ Note<td width="62">
 Type 

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

 <td width="535">
@@ -52,16 +52,17 @@
 <td width="29">
 FR 1

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 Interactions between several
 new features appear obscure, and very few examples are
 offered to guide understanding of the formal text on
@@ -80,16 +81,16 @@
 <td width="29">
 US 1

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge/te

- <td width="510">
+ <td width="604">
 The
 active issues identified in WG21 N2803, C++ Standard Core
 Language Active Issues, must be addressed and appropriate
@@ -118,16 +119,16 @@
 <td width="29">
 CA-1

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ge

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

@@ -142,16 +143,16 @@
 <td width="29">
 DE-1

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge/te

- <td width="510">
+ <td width="604">
 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
@@ -169,16 +170,16 @@
 <td width="29">
 CH 2

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

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

@@ -192,16 +193,16 @@
 <td width="29">
 US 3

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

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

 <td width="535">
@@ -218,16 +219,16 @@
 <td width="29">
 FR 3

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 ed

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

 <td width="535">
@@ -236,16 +237,16 @@
 <td width="29">
 US 4

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 ed

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

@@ -255,16 +256,16 @@
 <td width="29">
 UK 1

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 List of additional facilities over C has
 been extended with this standard, so should be mentioned in
 the introductory material.
@@ -281,16 +282,16 @@
 <td width="29">
 FR 4

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 ed

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

@@ -304,16 +305,16 @@
 <td width="29">
 UK 2

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 
 We recommend taking the latest update to
 each listed standard, yet the C standard is quite
@@ -330,16 +331,16 @@
 <td width="29">
 UK 3

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The definition of an argument does not seem
 to cover many assumed use cases, and we believe that is not
 intentional.
@@ -366,16 +367,16 @@
 <td width="29">
 UK 4

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This definition is essentially worthless,
 as it says nothing about what distinguished a diagnostic
 message from other output messages provided by the
@@ -394,17 +395,18 @@
 <td width="29">
 FR 5

- <td>
+ <td width="117">
 1.3.4 
- [defns.dynamic.type]
+ [defns. 
+ dynamic.type]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

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

@@ -418,16 +420,16 @@
 <td width="29">
 US 5

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The wording is unclear as to whether it is the input or
 the implementation "that is not a well-formed program".

@@ -442,17 +444,18 @@
 <td width="29">
 FR 6

- <td>
+ <td width="117">
 1.3.6 
- [defns.impl.defined]
+ [defns. 
+ impl.defined]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

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

@@ -466,17 +469,18 @@
 <td width="29">
 FR 7

- <td>
+ <td width="117">
 1.3.13 
- [defns.undefined]
+ [defns. 
+ undefined]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

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

@@ -491,16 +495,16 @@
 <td width="29">
 US 6

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 
 Unspecified behavior does not clearly state whether or not
 undefined behavior is permitted. (The standard says that
@@ -519,17 +523,18 @@
 <td width="29">
 FR 8

- <td>
+ <td width="117">
 1.4 
- [intro.compliance]
+ [intro. 
+ compliance]

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 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
@@ -545,16 +550,16 @@
 <td width="29">
 UK 5

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ge

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

@@ -569,16 +574,16 @@
 <td width="29">
 UK 6

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 Missing annex describing potential
 incompatibility to previous edition of the standard (see
 ISO/IEC TR 10176, 4.1.1p9)
@@ -594,16 +599,16 @@
 <td width="29">
 US 7

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 ed

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

 <td width="535">
@@ -617,16 +622,16 @@
 <td width="29">
 US 8

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The paragraph
 omits to mention concepts and concept maps among its list
@@ -643,16 +648,16 @@
 <td width="29">
 US 9

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 ed

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

@@ -666,16 +671,16 @@
 <td width="29">
 US 10

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 ed

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

@@ -690,16 +695,16 @@
 <td width="29">
 US 11

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

- <td width="107">
+ <td width="85">
 ¶ 3 last sent.

- <td width="38">
+ <td width="62">
 ed

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

@@ -713,16 +718,16 @@
 <td width="29">
 US 12

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

- <td width="107">
+ <td width="85">
 ¶ 3 first sent.

- <td width="38">
+ <td width="62">
 te

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

@@ -737,16 +742,16 @@
 <td width="29">
 US 13

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

- <td width="107">
+ <td width="85">
 ¶ 3 last sent.

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 It is unclear what is meant by memory locations that are
 "separate": are they distinct? non-overlapping? how much
 "separation" is needed?
@@ -763,16 +768,16 @@
 <td width="29">
 US 14

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

- <td width="107">
+ <td width="85">
 ¶ 4

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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".
@@ -788,16 +793,16 @@
 <td width="29">
 US 15

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

- <td width="107">
+ <td width="85">
 ¶ 5

- <td width="38">
+ <td width="62">
 te

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

@@ -812,16 +817,16 @@
 <td width="29">
 US 16

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 

- <td width="510">
+ <td width="604">
 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
@@ -837,16 +842,16 @@
 <td width="29">
 UK 8

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -867,16 +872,16 @@
 <td width="29">
 UK 7

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Does the term 'sequence' imply all
 reads/writes through volatile memory much be serialized,
 and cannot occur in parallel on truly parallel hardware?
@@ -895,16 +900,17 @@
 <td width="29">
 FR 9

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

- <td width="107">
+ <td width="85">
 16

- <td width="38">
+ <td width="62">
 ed

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

@@ -918,16 +924,16 @@
 <td width="29">
 US 17

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 This definition of
 “thread” is poor, and assumes the user already
 knows what multi-threaded means (probably true!). In
@@ -958,16 +964,16 @@
 <td width="29">
 UK 9

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

- <td width="107">
+ <td width="85">
 2, 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -992,16 +998,16 @@
 <td width="29">
 UK 10

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Implementation
 defined seems unnecessarily burdensome for negligible gain.
 I am yet to see code that depended on whether non-empty
@@ -1020,18 +1026,18 @@
 <td width="29">
 FR 10

- <td>
+ <td width="117">
 2.1 [lex.phases]/5 
 and 
 2.2 [lex.charset]/3

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 [defns.multibyte] "the
 extended character set."

@@ -1071,16 +1077,16 @@

 11

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Trigraphs are a complicated solution to an
 old problem, that cause more problems than they solve in
 the modern environment. Unexpected trigraphs in string
@@ -1101,16 +1107,16 @@

 12

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This undefined
 behaviour in token concatenation is worrying and we believe
 hard to justify. An implementation should either support
@@ -1131,16 +1137,16 @@
 <td width="29">
 US 18

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

- <td width="107">
+ <td width="85">
 ¶ 2

- <td width="38">
+ <td width="62">
 ed

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

 <td width="535">
@@ -1153,16 +1159,17 @@
 <td width="29">
 FR 11

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 ed

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

 <td width="535">
@@ -1175,17 +1182,18 @@
 <td width="29">
 FR 12

- <td>
+ <td width="117">
 2.5 [lex.digraph] 
- and 2.11 [lex.key]/2
+ and 2.11 
+ [lex.key]/2

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

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

@@ -1199,16 +1207,16 @@
 <td width="29">
 FI 2

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

- <td width="107">
+ <td width="85">
 Table 2

- <td width="38">
+ <td width="62">
 te

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

@@ -1225,16 +1233,16 @@

 13

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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.
@@ -1254,16 +1262,16 @@

 14

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

- <td width="107">
+ <td width="85">
 table 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The table is
 nearly sorted, but not quite. It was sorted in previous
 versions of the standard.
@@ -1278,16 +1286,16 @@
 <td width="29">
 JP 1

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

- <td width="107">
+ <td width="85">
 Table 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 Keywords in the table are listed disorderly. Also, a
 part of a frame of the table is not drawn.

@@ -1302,17 +1310,19 @@
 <td width="29">
 US 19

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

- <td width="107">
- Table 5, rows “l or L” and “ll or
+ <td width="85">
+ Table 5, 
+ rows “l or 
+ L” and “ll or
 LL”

- <td width="38">
+ <td width="62">
 te

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

@@ -1327,16 +1337,17 @@
 <td width="29">
 US 20

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Long strings of digits in
 literals are a continuing problem in the production and
 maintenance of programs.
@@ -1359,16 +1370,16 @@

 15

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Inconsistency between definition of a
 multicharacter literal and a wide character literal
 containing multiple c-chars.
@@ -1389,16 +1400,16 @@

 16

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

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

@@ -1412,18 +1423,18 @@
 <td width="29">
 JP 2

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

- <td width="107">
+ <td width="85">
 
 1st para, 2nd line

- <td width="38">
+ <td width="62">
 ed

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

@@ -1437,15 +1448,15 @@
 <td width="29">
 JP 3

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

- <td width="107">
+ <td width="85">
 2nd para<td width="38">
+ style="font-size: 11pt">para<td width="62">
 te

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

@@ -1515,18 +1526,19 @@
 <td width="29">
 JP 4

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

- <td width="107">
+ <td width="85">
 3rd para, 1st line of
+ style="font-size: 11pt">para, 
+ 1st line of
 example

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Typo. Lack of a necessary backslash in the first line of
 the example as follows:
@@ -1568,16 +1580,16 @@
 <td width="29">
 US 21

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

- <td width="107">
+ <td width="85">
 ¶ 3

- <td width="38">
+ <td width="62">
 ed

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

@@ -1592,16 +1604,16 @@
 <td width="29">
 US 22

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

- <td width="107">
+ <td width="85">
 ¶ 3

- <td width="38">
+ <td width="62">
 te

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

@@ -1615,18 +1627,18 @@
 <td width="29">
 JP 5

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

- <td width="107">
+ <td width="85">
 
 11th para, Table 7

- <td width="38">
+ <td width="62">
 te

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

@@ -1640,16 +1652,17 @@
 <td width="29">
 FR 13

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 ed

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

 assert(std::strcmp(p, "a\nb\nc") == 0);
@@ -1667,16 +1680,16 @@

 17

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

- <td width="107">
+ <td width="85">
 10

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It would be
 preferred for attempts to modify string literals to be
 diagnosable errors. This is not possible due to the
@@ -1705,16 +1718,16 @@

 18

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The addition of
 static_assert (7p4) to the language raises the need to
 concatenate string representations of integral constant
@@ -1745,16 +1758,16 @@

 19

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The grammar for string literal is becoming
 unwieldy and could easily be refactored into the type
 optional specifier and the string contents.
@@ -1775,16 +1788,16 @@
 <td width="29">
 FR 14

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

- <td width="107">
+ <td width="85">
 7

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 "In general it is necessary to determine whether a name
 denotes one of these entities before parsing the program
 that contains it."
@@ -1811,16 +1824,16 @@
 <td width="29">
 FR 15

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

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 /operator-function-id/,
 /conversion-function-id/, /template-id/ are followed by a
 space and then a "s" while usually such production names
@@ -1838,16 +1851,16 @@

 20

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 Chapter 3
 ("Basic concepts") provides common definitions used in the
 rest of the document. Now that we have concepts as a
@@ -1868,16 +1881,16 @@

 21

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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.
@@ -1896,16 +1909,16 @@

 22

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 References are
 frequently considered variables, but this definition only
 applies to objects.
@@ -1924,16 +1937,16 @@

 23

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 
 alias-declarations are not definitions and should be added
 to the list
@@ -1952,16 +1965,16 @@

 24

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The current
 words suggest the declaration of a static integral constant
 data member of a class cannot be a definition. Trying to
@@ -1985,16 +1998,16 @@

 25

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Example is
 misleading as implicitly defined default constructor uses
 default initialization, not value initialization, for
@@ -2018,16 +2031,16 @@

 26

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 THe one
 definition rule should cover references, and unless the
 term 'variable' is extended to cover references the list in
@@ -2046,16 +2059,16 @@

 27

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 A class type
 must be complete when catching exceptions, even by
 reference or pointer. See 15.3.
@@ -2071,17 +2084,18 @@
 <td width="29">
 FR 16

- <td>
- 3.3 [Declarative 
+ <td width="117">
+ 3.3 
+ [Declarative 
 regions and scopes.]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The scope of function
 parameters is defined, but what is the scope of template
 parameters?
@@ -2099,16 +2113,16 @@

 28

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

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

@@ -2125,16 +2139,16 @@

 29

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -2154,17 +2168,17 @@
 <td width="29">
 FR 17

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 This section does not specify
 whether concept names have linkage.

@@ -2184,16 +2198,16 @@
 UK 
 30

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -2211,16 +2225,16 @@
 UK 
 31

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -2239,16 +2253,16 @@
 <td width="29">
 US 23

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 ed

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

@@ -2262,16 +2276,17 @@
 <td width="29">
 FR 18

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 ed

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

 <td width="535">
@@ -2284,17 +2299,18 @@
 <td width="29">
 FR 19

- <td>
+ <td width="117">
 3.6 [Start 
- and termination]
+ and 
+ termination]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 This section completely
 ignores the real world and practical case of dynamically
 linked or loaded libraries. In current computing
@@ -2319,16 +2335,16 @@
 UK 
 32

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

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

@@ -2343,16 +2359,16 @@
 <td width="29">
 US 24

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 te

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

@@ -2372,16 +2388,16 @@
 <td width="29">
 US 25

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

- <td width="107">
+ <td width="85">
 ¶ 2 last sent.

- <td width="38">
+ <td width="62">
 ed

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

@@ -2395,18 +2411,19 @@
 <td width="29">
 JP 6

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

- <td width="107">
+ <td width="85">
 4th para, 4th
+ style="font-size: 11pt">para, 
+ 4th
 line

- <td width="38">
+ <td width="62">
 ed

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

@@ -2456,16 +2473,16 @@
 <td width="29">
 DE-3

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-3 It is
 unclear whether the following code has well-defined
@@ -2489,16 +2506,16 @@
 <td width="29">
 US 26

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

- <td width="107">
+ <td width="85">
 1 and 5

- <td width="38">
+ <td width="62">
 te

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

@@ -2517,16 +2534,16 @@
 <td width="29">
 US 27

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

- <td width="107">
+ <td width="85">
 ¶ 9 first sent.

- <td width="38">
+ <td width="62">
 ed

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

 <td width="535">
@@ -2540,16 +2557,16 @@
 <td width="29">
 FR 20

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The phrase 'effective type'
 is defined and used in a way that is incompatible with C99.
 Such a deliberate incompatible choice of terminology is
@@ -2568,18 +2585,19 @@
 <td width="29">
 JP 7

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

- <td width="107">
+ <td width="85">
 3rd para, 13th
+ style="font-size: 11pt">para, 
+ 13th
 line

- <td width="38">
+ <td width="62">
 ed

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

@@ -2607,16 +2625,16 @@
 <td width="29">
 US 28

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

- <td width="107">
+ <td width="85">
 ¶ 5 first sent.

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The closing
 braces of the first two sets are preceded by extraneous
@@ -2632,16 +2650,16 @@
 <td width="29">
 DE 4

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

- <td width="107">
+ <td width="85">
 p2

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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
@@ -2666,16 +2684,16 @@
 <td width="29">
 CH 1

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 With respect to the target type, pointer to members
 should behave like normal pointers (least surprise
 principle).
@@ -2696,16 +2714,18 @@
 <td width="29">
 DE-5

- <td>
- 4.11, 5.3.1, 5.5
+ <td width="117">
+ 4.11, 
+ 5.3.1, 
+ 5.5

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

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

@@ -2724,16 +2744,16 @@
 UK 
 33

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -2754,16 +2774,16 @@
 UK 
 34

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 6th bullet, "the
 rank of char" - first letter should be capitalised for
 consistency with the other bullets
@@ -2779,16 +2799,16 @@
 UK 
 36

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Primary
 expressions are literals, names, names qualified by the
 scope resolution operator ::, and lambda expressions. The
@@ -2804,16 +2824,16 @@
 UK 
 37

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

- <td width="107">
+ <td width="85">
 11

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Member function
 templates are not member functions, so should also be
 listed in the 3rd bullet
@@ -2830,16 +2850,16 @@
 UK 
 38

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -2857,17 +2877,17 @@
 <td width="29">
 JP 8

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

- <td width="107">
+ <td width="85">
 7th para, Syntax rules

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 In
 the current syntax definition, a scope operator(::) cannot
 be applied to decltype, but it should be. It would be
@@ -2920,16 +2940,16 @@
 <td width="29">
 JP 9

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 It
 would be preferable that “&&” could be
 specified in a lambda expression to declare move capture.
@@ -3116,16 +3136,16 @@
 <td width="29">
 JP 10

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 In
 the current syntax definition, a returned type of a
 function object cannot be obtained by using result_of from
@@ -3175,16 +3195,16 @@
 <td width="29">
 US 29

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 standard does not state whether or not direct recursion of
 lambdas is possible.
@@ -3199,16 +3219,16 @@
 <td width="29">
 US 30

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

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

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 The current wording does not specify
 how context capturing and name resolution
@@ -3255,16 +3275,16 @@
 UK 
 45

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

- <td width="107">
+ <td width="85">
 para 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Lambda is a language feature with an
 apparent dependency on <functional>. This increases
 dependency of language on library, and is inconsistent with
@@ -3292,16 +3312,16 @@

 

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The
 final italic "this" in the paragraph should be a teletype
 "this".
@@ -3317,16 +3337,16 @@
 UK 
 39

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

- <td width="107">
+ <td width="85">
 11

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This paragraph lists all the special member
 functions for the class representing a lambda. But it omits
 the destructor, which is awkward.
@@ -3343,16 +3363,16 @@
 UK 
 40

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

- <td width="107">
+ <td width="85">
 12

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -3378,16 +3398,16 @@
 UK 
 41

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

- <td width="107">
+ <td width="85">
 12

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -3410,16 +3430,16 @@
 UK 
 42

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -3445,16 +3465,16 @@
 UK 
 43

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

- <td width="107">
+ <td width="85">
 12

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The note spells
 out the intent that objects from lambda-expressions with an
 effective capture list of references should be implemented
@@ -3477,16 +3497,16 @@
 UK 
 44

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

- <td width="107">
+ <td width="85">
 12

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 There is a
 strong similarity between a [&]{} lambda capturing a
 stack frame, and a [this]{} lambda binding a member
@@ -3512,16 +3532,16 @@
 UK 
 46

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

- <td width="107">
+ <td width="85">
 para 12

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The requirement that a lambda meeting
 appropriate conditions be an object derived from
 reference_closure makes lambda the language feature
@@ -3546,16 +3566,16 @@
 <td width="29">
 DE-6

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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
@@ -3575,16 +3595,16 @@
 <td width="29">
 DE-7

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

- <td width="107">
+ <td width="85">
 p10

- <td width="38">
+ <td width="62">
 ed

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

@@ -3598,16 +3618,16 @@
 <td width="29">
 DE-8

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

- <td width="107">
+ <td width="85">
 p10

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-8 The construction of the function call operator
 signature is missing specifications for the ref-qualifier
 and the attribute-specifier.
@@ -3623,16 +3643,16 @@
 <td width="29">
 US 33

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

- <td width="107">
+ <td width="85">
 11

- <td width="38">
+ <td width="62">
 Ge

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

@@ -3651,16 +3671,16 @@
 <td width="29">
 DE-9

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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
@@ -3679,16 +3699,16 @@
 UK 
 52

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

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

@@ -3703,16 +3723,16 @@
 UK 
 53

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The definition in p1 makes no allowance for
 overloaded operator[] that treats the expression as a
 simple function call, and does not support the
@@ -3734,16 +3754,16 @@
 UK 
 59

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

- <td width="107">
+ <td width="85">
 7

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -3763,16 +3783,16 @@
 UK 
 60

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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.
@@ -3788,16 +3808,16 @@
 UK 
 61

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

- <td width="107">
+ <td width="85">
 p1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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
@@ -3816,16 +3836,16 @@
 UK 
 62

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -3842,16 +3862,16 @@
 <td width="29">
 DE-10

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-10 If E1.E2 is referring to a non-static member
 function, the potential ref-qualification on E2 should be
 taken into account.
@@ -3868,16 +3888,16 @@
 UK 
 63

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

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

 <td width="535">
@@ -3891,16 +3911,16 @@
 UK 
 64

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 A new name R is introduced for use in
 paragraphs 3 and 4. But R is the same as T.

@@ -3920,16 +3940,16 @@
 UK 
 65

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

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -3950,16 +3970,16 @@
 UK 
 66

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 typeid may
 return "an implementation-defined class derived from std ::
 type_info". The derivation must be public.
@@ -3978,16 +3998,16 @@
 UK 
 67

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

- <td width="107">
+ <td width="85">
 1, 2, 3

- <td width="38">
+ <td width="62">
 Te

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

@@ -4009,16 +4029,16 @@
 UK 
 54

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

- <td width="107">
+ <td width="85">
 3, 6

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Para 3: "The mapping performed by
 reinterpret_cast is implementation-defined.". Para 6: "...
 the result of such a pointer conversion is unspecified."
@@ -4040,16 +4060,16 @@
 UK 
 55

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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,
@@ -4072,16 +4092,16 @@
 UK 
 56

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The notion of
 safely derived pointers means this conversion may not be as
 safe in the revised standard as the original. It would be
@@ -4103,16 +4123,16 @@
 UK 
 57

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

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Conditionally supported behaviour gives a
 wide range or permission, so clarify relationship between
 safely-derived object pointers and function pointers in a
@@ -4132,16 +4152,16 @@
 UK 
 58

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

- <td width="107">
+ <td width="85">
 9

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -4165,16 +4185,16 @@

 

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 ed

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

@@ -4189,16 +4209,16 @@
 UK 
 68

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

- <td width="107">
+ <td width="85">
 2-9

- <td width="38">
+ <td width="62">
 Te

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

@@ -4217,16 +4237,16 @@
 UK 
 69

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 If we cannot
 bind references/take address of functions in concept_maps,
 does that mean we cannot use generic bind in constrained
@@ -4251,16 +4271,16 @@
 UK 
 70

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The sizeof
 operator shall not be applied to ... an enumeration type
 before all its enumerators have been declared We should
@@ -4280,16 +4300,16 @@
 UK 
 71

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -4309,16 +4329,16 @@
 UK 
 72

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

- <td width="107">
+ <td width="85">
 7

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The library
 headers have been carefully structured to limit the
 dependencies between core language and specific headers.
@@ -4343,16 +4363,16 @@
 UK 
 73

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 A class type
 with conversion operator can only be used if the conversion
 type is constexpr and the class is a literal type. Adding
@@ -4372,16 +4392,16 @@
 UK 
 74

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

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 operators, like
 constructors and destructors, do not have names. However,
 in certain circumstances they can be treated as if they had
@@ -4403,16 +4423,16 @@
 UK 
 35

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

- <td width="107">
+ <td width="85">
 9

- <td width="38">
+ <td width="62">
 Ed

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

@@ -4430,16 +4450,16 @@
 UK 
 75

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

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 A paragraph
 strarting with [Note... is easily skipped when reading,
 missing the normative text at the end.
@@ -4456,16 +4476,17 @@
 <td width="29">
 FR 21

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

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

@@ -4479,16 +4500,16 @@
 <td width="29">
 US 35

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

- <td width="107">
+ <td width="85">
 2 and 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 There is curious spacing in the expressions "E1 <<E2"
 and "E1 >>E2". This is a formatting change since
@@ -4507,16 +4528,16 @@
 UK 
 47

- <td>
+ <td width="117">
 5.14 / 5.15

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Why are the
 descriptions of order of evaluation of expressions and side
 effects different between && and || operators. The
@@ -4538,16 +4559,16 @@
 UK 
 48

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The defining
 feature of the comma operator is the guaranteed sequencing
 of two expressions. This guarantee is lost when presented
@@ -4569,16 +4590,16 @@
 UK 
 49

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -4605,16 +4626,16 @@
 UK 
 50

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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).
@@ -4635,16 +4656,16 @@
 UK 
 51

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 typeid
 expressions can never be constant, whether or not the
 operand is a polymorphic class type. The result of the
@@ -4667,16 +4688,16 @@
 UK 
 76

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Do we really need two different terms that
 say the same thing?

@@ -4694,18 +4715,18 @@
 <td width="29">
 FR 22

- <td>
+ <td width="117">
 6.4.2 
 [The switch 
 statement]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The constant-expression in

 
@@ -4734,16 +4755,16 @@
 UK 
 77

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The terms i/o
 operation, synchronize operation and atomic operation have
 very specific meanings within the standard. The paragraph
@@ -4763,18 +4784,19 @@
 <td width="29">
 JP 11

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

- <td width="107">
+ <td width="85">
 1st para, 5th
+ style="font-size: 11pt">para, 
+ 5th
 line

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 There is no _RangeT type in the equivalent code to
 “range-base for” statement. It existed in
 N2049.
@@ -4837,16 +4859,16 @@
 UK 
 78

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Including the header
 <iterator_concepts> is far too unwieldy to enable an
 important and (expected to be) frequently used syntax.
@@ -4868,16 +4890,16 @@
 UK 
 79

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The definition
 of for (for-range-declaration : expression) statement is
 expanded in terms which require a Range concept, and the
@@ -4905,16 +4927,16 @@
 <td width="29">
 DE-11

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

- <td width="107">
+ <td width="85">
 p1

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-11 A
 sentence in paragraph 1 reads: "Outside of a constrained
@@ -4937,16 +4959,16 @@
 UK 
 80

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Many of the
 sections and major subsections open with a sentence
 summarising the content. I'm not sure this is necessary;
@@ -4971,16 +4993,16 @@
 UK 
 81

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 String literal
 concatenation happens in phase 6, before parsing, so it is
 legal and useful to use it for the string literal in a
@@ -5002,16 +5024,16 @@
 UK 
 82

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Paragraph 2
 talks about declarations that can have nested declarations
 within them. It doesn't mention scoped enumerations - but
@@ -5032,16 +5054,16 @@
 UK 
 83

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The longest
 sequence of decl-specifiers that could possibly be a type
 name is taken as the decl-specifier-seq of a declaration.
@@ -5062,16 +5084,16 @@
 UK 
 84

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The grammar
 includes alignment-specifier as a production for
 decl-specifier, but there is no production for
@@ -5091,16 +5113,18 @@
 <td width="29">
 FI 3

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

- <td width="107">
- [dcl.spec.auto]
+ <td width="85">
+ [dcl. 
+ spec. 
+ auto]

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 While
 it’s considered too late for this standard revision,
@@ -5121,16 +5145,16 @@
 UK 
 85

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 ... the
 init-declarator-list of the declaration shall not be empty
 (except for global anonymous unions, which shall be
@@ -5152,16 +5176,16 @@
 UK 
 86

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

- <td width="107">
+ <td width="85">
 2,3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The register
 keyword serves very little function, offering no more than
 a hint that a note says is typically ignored. It should be
@@ -5184,16 +5208,16 @@
 UK 
 87

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

- <td width="107">
+ <td width="85">
 1, 4, 5

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Why require two
 keywords, where one on its own becomes ill-formed?
 thread_local should imply 'static' in this case, and the
@@ -5215,16 +5239,16 @@
 <td width="29">
 US 36

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 permission to use thread_local static data members is
 missing.
@@ -5242,16 +5266,17 @@
 <td width="29">
 FR 23

- <td>
- 7.1.5 [constexpr]
+ <td width="117">
+ 7.1.5 
+ [constexpr]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 'constexpr' functions should
 be allowed to take const reference parameters, as long as
 their uses are in a context where a constant expression may
@@ -5283,16 +5308,16 @@
 <td width="29">
 JP 12

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 It should be
 allowed to define constexpr recursively.
@@ -5436,16 +5461,16 @@
 <td width="29">
 US 37

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 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
@@ -5466,16 +5491,16 @@
 UK 
 89

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The two
 normative sentences in this paragraph appear to duplicate
 text elsewhere - but they aren't exact duplicates, which
@@ -5515,16 +5540,16 @@
 UK 
 90

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

- <td width="107">
+ <td width="85">
 para 1 and table 9

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The grammar in
 paragraph one makes "nested-name-specifier template
 simple-template-id" a simple-type-specifier, but unlike all
@@ -5545,16 +5570,16 @@
 UK 
 91

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 5.1/5 says "[A]
 parenthesized expression can be used in exactly the same
 contexts as those where the enclosed expression can be
@@ -5586,16 +5611,16 @@
 UK 
 92

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The note
 correctly indicates that, if T is a template type
 parameter, then "friend class T;" is ill-formed. It might
@@ -5616,16 +5641,16 @@
 UK 
 93

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

- <td width="107">
+ <td width="85">
 Grammar before para 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 In the third
 production, "enum ::opt nested-name-specifieropt
 identifier", enum should not be in italics; its referring
@@ -5644,16 +5669,16 @@
 UK 
 94

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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
@@ -5677,16 +5702,16 @@
 UK 
 95

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 (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
@@ -5711,17 +5736,18 @@
 <td width="29">
 FR 24

- <td>
+ <td width="117">
 7.1.6.4 
- [auto specifier]
+ [auto 
+ specifier]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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
@@ -5780,16 +5806,16 @@
 <td width="29">
 US 38

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The
 discussion of attribute specifiers should be a separate
 paragraph.
@@ -5806,16 +5832,16 @@
 <td width="29">
 US 39

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 paragraph says in part "An opaque-enum-declaration
 declaring an unscoped enumeration shall not omit the
@@ -5838,16 +5864,16 @@
 <td width="29">
 JP 13

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

- <td width="107">
+ <td width="85">
 para 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 In
 the description for an unscoped enumeration, enum-base in
 redeclaration must be the same underlying type as in the
@@ -5869,16 +5895,16 @@
 UK 
 96

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

- <td width="107">
+ <td width="85">
 7

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 enum E { }; What
 are the values of E? It has neither a smallest nor largest
 enumerator, so paragraph 7 doesn't help. (Paragraph 6
@@ -5901,16 +5927,16 @@
 UK 
 97

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

- <td width="107">
+ <td width="85">
 9

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Missing
 punctuation after "blue" in: "The possible values of an
 object of type color are red, yellow, green, blue these
@@ -5931,16 +5957,16 @@
 UK 
 98

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It would be
 useful to be able to determine the underlying type of an
 arbitrary enumeration type. This would allow safe casting
@@ -5963,16 +5989,16 @@
 UK 
 99

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It is unclear
 whether an enumeration type is complete after an
 opaque-enum-declaration. This paragraph only says so in a
@@ -5994,16 +6020,16 @@
 <td width="29">
 JP 14

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 The description of the behavior when a member that was
@@ -6091,16 +6117,16 @@
 UK 
 100

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

- <td width="107">
+ <td width="85">
 10 and 13

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Para 10 says "A
 using-declaration is a declaration and can therefore be
 used repeatedly where (and only where) multiple
@@ -6124,16 +6150,16 @@
 UK 
 101

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

- <td width="107">
+ <td width="85">
 20

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 If a
 using-declaration uses the keyword typename and specifies a
 dependent name (14.6.2), the name introduced by the
@@ -6156,16 +6182,16 @@
 <td width="29">
 DE-12

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

- <td width="107">
+ <td width="85">
 p15

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-12
 Overriding and hiding of member functions named in
@@ -6184,18 +6210,18 @@
 <td width="29">
 FR 25

- <td>
+ <td width="117">
 7.3.3 
 [The using 
 declaration]

- <td width="107">
+ <td width="85">
 Para 21

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The syntax for concept map alias is unnecessarily both
 confused and verbose.

@@ -6219,16 +6245,16 @@
 UK 
 102

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This paragraph
 says "If name lookup finds a declaration for a name in two
 different namespaces, and the declarations do not declare
@@ -6249,16 +6275,16 @@
 <td width="29">
 US 40

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 list of attributes is missing an attribute to indicate that
 a function with a 
 US 41

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 A
 common problem is unintentionally declaring a new virtual
 member function instead of overriding a base virtual member
@@ -6308,16 +6334,16 @@
 <td width="29">
 FR 26

- <td>
- 7.6 [Attributes]
+ <td width="117">
+ 7.6 [Attributes]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 Are they part of object types
 or not? The section does not appear to indicate that
 clearly.
@@ -6334,16 +6360,16 @@
 <td width="29">
 FI 1

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Add override-attribute for functions in order to avoid
 mistakes when overriding functions.

@@ -6357,16 +6383,16 @@
 <td width="29">
 FR 27

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 This section specifies that
 no name lookup is performed on any identifier contained in
 an attribute-token. This in particular implies that, for
@@ -6395,16 +6421,16 @@
 UK 
 103

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Attributes should support pack expansion.
 For example, this would be extremely useful with the align
 attribute, directly supporting the (removed) functionality
@@ -6427,16 +6453,16 @@
 UK 
 104

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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
@@ -6456,16 +6482,16 @@
 UK 
 105

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Allowing only one level of namespaces in
 attributes seems unnecessarily limiting.

@@ -6482,16 +6508,16 @@
 UK 
 106

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Extensive use of
 alignment and related terms without cross reference.

@@ -6507,16 +6533,16 @@
 <td width="29">
 JP 15

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 An abbreviation
 of 7.6.2 should be “[decl.attr.align]” instead
@@ -6542,16 +6568,16 @@
 UK 
 107

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 While undefined
 behaviour might be the best we can guarantee, it would be
 helpful to encourage implementations to diagnose function
@@ -6573,16 +6599,16 @@
 UK 
 108

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It is unclear
 why no diagnostic is required for an easily detectable
 violation. It is even more surprising that the associated
@@ -6601,16 +6627,16 @@
 <td width="29">
 US 42

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 meaning of the <code>[[final]]</code> attribute applied
@@ -6638,16 +6664,16 @@
 UK 
 109

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The example code
 refers in comments to "Compilation unit" A and B. The term
 should be "Translation unit" (2/1)
@@ -6665,16 +6691,16 @@
 <td width="29">
 

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 

- <td width="510">
+ <td width="604">
 

 <td width="535">
@@ -6688,16 +6714,16 @@
 UK 
 110

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The code in the
 example (compilation unit A) has:
 "foo_head[i].load(memory_order_consume)". foo_head[i] is of
@@ -6716,16 +6742,16 @@
 <td width="29">
 US 43

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 With the introduction of late-specified return types for
 functions and lambda expressions, we now have three
@@ -6748,16 +6774,16 @@
 UK 
 111

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

- <td width="107">
+ <td width="85">
 13

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Example missing
 closing bracket in template<typename... T> void f(T
 (* ...t)(int, int);
@@ -6775,16 +6801,16 @@
 <td width="29">
 US 44

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

- <td width="107">
+ <td width="85">
 13

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 In
 the Example, "template void f(T (* ...t)(int, int);" is
 missing a close parenthesis.
@@ -6802,16 +6828,16 @@
 <td width="29">
 US 45

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

- <td width="107">
+ <td width="85">
 13

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 At present,
 function parameter packs can only occur at the end of a
 parameter-declaration-list. This restriction unnecessarily
@@ -6918,16 +6944,16 @@
 <td width="29">
 DE-13

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

- <td width="107">
+ <td width="85">
 p2

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-13 The second paragraph, quoting the grammar for the
 declarator of a function declaration, is not considering
 late-specified return types and attributes.
@@ -6942,20 +6968,20 @@
 <td width="29">
 JP 16

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

- <td width="107">
+ <td width="85">
 
 15th para, 1st line

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Typo, duplicated "in"

@@ -6972,16 +6998,16 @@
 <td width="29">
 US 46

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The ability for
 an rvalue reference to bind to an lvalue opens a
 type-safety hole that becomes very dangerous with concepts.
@@ -7053,16 +7079,16 @@
 <td width="29">
 US 49

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 In the Example, the comments
 could be improved.

@@ -7081,16 +7107,16 @@
 UK 
 112

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

- <td width="107">
+ <td width="85">
 4-9

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 We now have
 concepts that should (or should not?) map to the terms
 described in Clause 9 - these should be at least
@@ -7110,16 +7136,16 @@
 UK 
 113

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Mis-applied edit from the paper n2756

 <td width="535">
@@ -7135,16 +7161,18 @@
 <td width="29">
 US 50

- <td>
- 12.1, 12.4, 12.8
+ <td width="117">
+ 12.1, 
+ 12.4, 
+ 12.8

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 Implicitly-declared default constructors, destructors, copy
 constructors, and copy assignment operators are deleted
@@ -7214,20 +7242,20 @@
 <td width="29">
 FR 28

- <td>
+ <td width="117">
 12.6.1 
 [Explicit 
 initialization]

 

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 This section, in particular the example with `g' appears
 contradictory with the syntax for uniform initialization.

@@ -7241,16 +7269,16 @@
 <td width="29">
 US 51

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The
 discussion of delegating constructors should be in its own
 paragraph.
@@ -7268,16 +7296,16 @@
 UK 
 114

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Despite all the attempts to unify
 initialization syntax, it is still not possible to
 copy-initialize base classes or non-static data members,
@@ -7309,16 +7337,16 @@
 <td width="29">
 US 52

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

- <td width="107">
+ <td width="85">
 ¶ 5

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 A word is misspelled.

 <td width="535">
@@ -7332,16 +7360,16 @@
 UK 
 115

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

- <td width="107">
+ <td width="85">
 6-11

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 Exported
 templates were a great idea that is generally understood to
 have failed. In the decade since the standard was adopted,
@@ -7370,16 +7398,16 @@
 UK 
 116

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

- <td width="107">
+ <td width="85">
 6-11

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Is it possible
 to export a concept map template? The current wording
 suggests it is possible, but it is not entirely clear what
@@ -7400,16 +7428,16 @@
 UK 
 117

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 It would be nice
 to allow template alias within a function scope, and
 possibly a scoped concept map. As these affect name lookup
@@ -7431,16 +7459,16 @@
 UK 
 118

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

- <td width="107">
+ <td width="85">
 6-11

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Exported
 templates are a complicated feature with surprisingly
 little text. To make this important text more visible,
@@ -7460,16 +7488,16 @@
 UK 
 119

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Does a concept
 map have linkage? Reading this paragraph and 3.5 suggests a
 concept map template has external linkage, but not a
@@ -7492,16 +7520,16 @@
 UK 
 120

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

- <td width="107">
+ <td width="85">
 9

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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
@@ -7521,16 +7549,16 @@
 UK 
 121

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

- <td width="107">
+ <td width="85">
 18

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The example
 (that follows the normative text) has no begin example
 marker
@@ -7547,20 +7575,20 @@
 <td width="29">
 FR 29

- <td>
+ <td width="117">
 14.3 
 [Template 
 arguments]

 

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Constant expressions of any literal type should be
 allowed as template arguments.

@@ -7574,16 +7602,16 @@
 <td width="29">
 US 53

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 If the
 requirements of a constrained member that is a copy
 constructor, copy assignment operator, or destructor are
@@ -7634,16 +7662,16 @@
 UK 
 122

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Variadic
 templates should be supported in axioms. There are axioms
 in the library that rely on this feature, such as the
@@ -7665,17 +7693,18 @@
 <td width="29">
 FR 30

- <td>
+ <td width="117">
 14.5.7 
- [Template aliases]
+ [Template 
+ aliases]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 When are two template alias
 names equivalent?

@@ -7724,18 +7753,18 @@
 <td width="29">
 JP 17

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

- <td width="107">
+ <td width="85">
 2nd para, 15th
 line

- <td width="38">
+ <td width="62">
 ed

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

@@ -7770,16 +7799,16 @@
 <td width="29">
 DE-14

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

- <td width="107">
+ <td width="85">
 p1

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-14 The bulleted list neither addresses "member
 function template of a class" nor "member class template of
 a class".
@@ -7794,18 +7823,18 @@
 <td width="29">
 JP 18

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

- <td width="107">
+ <td width="85">
 2nd para, 2nd
 line

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Typo,

@@ -7838,18 +7867,18 @@
 <td width="29">
 JP 19

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

- <td width="107">
+ <td width="85">
 6th para, 1st
 line

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Typo, duplicated "is"

@@ -7872,20 +7901,22 @@
 <td width="29">
 US 54

- <td>
+ <td width="117">
 14.9 [concept],
+ "margin-top: 0.04in; margin-bottom: 0.04in">14.9 
+ [concept],

 14.10 
- [temp.constrained]
+ [temp. 
+ constrained]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 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
@@ -7902,16 +7933,16 @@
 <td width="29">
 US 55

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

- <td width="107">
+ <td width="85">
 ¶ 6

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The paragraph number is in the wrong place, causing a
 grammar rule to be indented more than its fellows.

@@ -7927,16 +7958,16 @@
 <td width="29">
 US 56

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

- <td width="107">
+ <td width="85">
 ¶ 6

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The sentence contains two references to 14.9.1.3
 [concept.req].

@@ -7951,16 +7982,16 @@
 <td width="29">
 US 57

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

- <td width="107">
+ <td width="85">
 ¶ 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 A word is misplaced, changing the intended meaning.

 <td width="535">
@@ -7974,16 +8005,16 @@
 <td width="29">
 US 58

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

- <td width="107">
+ <td width="85">
 ¶ 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The listed phrases are not grammatically parallel.

 <td width="535">
@@ -7998,16 +8029,16 @@
 <td width="29">
 US 59

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Axioms are under-specified and provide
 little benefit to programmers, so they should be removed
 from the working paper. The optimizations permitted by
@@ -8085,16 +8116,17 @@
 <td width="29">
 FR 31

- <td>
- 14.9.1.4 [Axioms]
+ <td width="117">
+ 14.9.1.4 
+ [Axioms]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 This section states that an
 axiom-definition defines a new semantics axiom but is
 unusually vague as to what those semantics might be.
@@ -8129,16 +8161,16 @@
 <td width="29">
 DE-15

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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
@@ -8161,16 +8193,16 @@
 UK 
 123

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 auto concepts
 and axioms are incompatible. An axiom defines the semantics
 of an operaton or set of operations that describes the run
@@ -8197,16 +8229,16 @@

 

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Spelling mistake, double-e in were.

 <td width="535">
@@ -8220,16 +8252,16 @@
 UK 
 125

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The implicit
 equality comparison operator available to axioms has no
 semantic. It is not clear what expressing the condition if(
@@ -8254,16 +8286,16 @@
 UK 
 126

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

- <td width="107">
+ <td width="85">
 41

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This paragraph
 contains the only definition of the underlying_type member
 - but it's a note, so not normative.
@@ -8282,16 +8314,16 @@
 UK 
 127

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Provide a
 diagram clearly showing refinement relationship between the
 different support concepts. Several were created during
@@ -8310,16 +8342,16 @@
 UK 
 128

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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
@@ -8340,17 +8372,17 @@
 <td width="29">
 JP 20

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

- <td width="107">
+ <td width="85">
 2nd para

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 Trivially copyable type was added in “3.9
@@ -8375,16 +8407,17 @@
 UK 
 129

- <td>
- 14.10.1, 20.1.2
+ <td width="117">
+ 14.10.1, 
+ 20.1.2

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It should be
 possible to support boolean constant expressions as
 requirements without resorting to defining the True concept
@@ -8410,16 +8443,16 @@
 <td width="29">
 US 60

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The use of && as the separator for
 a list of requirements has shown itself to be a serious
 teachability problem. The mental model behind
@@ -8478,16 +8511,16 @@
 UK 
 130

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 With the new
 crrent_exception API it is possible to capture a reference
 to an exception that will outlive its last active handler.
@@ -8511,16 +8544,16 @@
 UK 
 131

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 A handler
 catching its parameter by rvalue-reference is syntactically
 valid, but will never be activated.
@@ -8539,16 +8572,16 @@
 UK 
 132

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

- <td width="107">
+ <td width="85">
 16

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 There are
 obscure cases whrere a copy constructor is not usually the
 best match to copy-initialize an object, e.g. A converting
@@ -8572,16 +8605,16 @@
 UK 
 133

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Template aliases
 have the same semantics as a typedef so should also be
 disallowed
@@ -8600,16 +8633,16 @@
 UK 
 134

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The sentance "An
 exception-specification can also include the class
 std::bad_exception (18.7.2.1)." is redundant.
@@ -8629,16 +8662,16 @@
 UK 
 135

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

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Unclear if std::unexpected is called before
 or after the function arguments have been destroyed

@@ -8656,16 +8689,16 @@
 UK 
 136

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 Exception specifications have proven close
 to worthless in practice, while adding a measurable
 overhead to programs. The feature should be deprecated. The
@@ -8691,16 +8724,16 @@
 UK 
 137

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 There is no
 mention of the current_exception API which can extend the
 lifetime of an exception object. There should at least be a
@@ -8721,16 +8754,16 @@
 UK 
 138

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The third bullet
 is redundant with the first, as it is a subset of the same
 conditions.
@@ -8749,16 +8782,16 @@
 UK 
 139

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 According to the
 first bullet it is perfectly alright for a library function
 to exit by throwing an exception during stack unwinding,
@@ -8778,16 +8811,16 @@
 UK 
 140

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The detailed
 specification can fool people into thinking an exception
 will automatically be translated into bad_exception, where
@@ -8809,16 +8842,16 @@
 UK 
 141

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This whole
 subclause is redundant due to 15.1p5 and 15.3p17

@@ -8835,16 +8868,16 @@
 UK 
 142

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This paragraph
 opens with "[ Note" but has no corresponding "end note ]"

@@ -8861,16 +8894,16 @@
 UK 
 143

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

- <td width="107">
+ <td width="85">
 7

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Example uses #define t(x,y.z) x ## y ## z

 <td width="535">
@@ -8883,16 +8916,16 @@
 <td width="29">
 US 2

- <td>
+ <td width="117">
 17-30

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge/te

- <td width="510">
+ <td width="604">
 The
 active issues identified in WG21 N2806, C++ Standard
 Library Active Issues, must be addressed and appropriate
@@ -8921,16 +8954,17 @@
 <td width="29">
 FR 2

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

- <td width="107">
+ <td width="85">
 Library

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 The adoption of the library `constexpr' proposal was not
 reflected in the draft, despite formal WG21 committee vote.

@@ -8944,16 +8978,16 @@
 <td width="29">
 US 61

- <td>
+ <td width="117">
 17 onward

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The concepts core language feature is applied to only
 some of the Standard Library clauses, and even then not
 always consistently.
@@ -8975,16 +9009,16 @@
 <td width="29">
 CA-2

- <td>
+ <td width="117">
 17 Library

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 
 “Concepts” are a significant new addition to
 the language, but are not exploited uniformly in the
@@ -9002,16 +9036,16 @@
 <td width="29">
 US 62

- <td>
+ <td width="117">
 17-30

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 Provide concepts
 and requirements clauses for all standard library templates

@@ -9027,18 +9061,18 @@
 <td width="29">
 US 63

- <td>
+ <td width="117">
 17-30

 

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The behavior of the library in the presence of threads
 is incompletely specified.

@@ -9062,16 +9096,16 @@
 <td width="29">
 DE-2

- <td>
+ <td width="117">
 17 through 30

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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
@@ -9092,7 +9126,7 @@
 <td width="29">
 JP 21

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

@@ -9103,15 +9137,17 @@
 21.2, 21.4,

 27.2, 27.6, 
- 27.7, 27.8.1, 28.4
+ 27.7, 
+ 27.8.1, 
+ 28.4

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 Support of char16_t/char32_t is insufficient. The basic_xxx
 classes of <iostream>, <fstream>,
@@ -9930,16 +9966,16 @@
 UK 
 144

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 List of contents of library should be
 extened to cover new clauses

@@ -9955,16 +9991,16 @@
 UK 
 145

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 
 Summary of numeric facilities should
 mention random numbers
@@ -9983,16 +10019,16 @@
 UK 
 146

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Add a summary paragraph for regular
 expressions

@@ -10008,16 +10044,16 @@
 UK 
 147

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Add a summary paragraph for threads

 <td width="535">
@@ -10031,16 +10067,16 @@
 UK 
 148

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

- <td width="107">
+ <td width="85">
 Table 12

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Table 12 is
 mentioned in and relates to section 17.2, but has been
 pushed down to appear directly after the title of section
@@ -10060,16 +10096,16 @@
 UK 
 149

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 For consistency
 with narrow-oriented and wide-oriented streams, we should
 add terms for streams of Unicode character sequences
@@ -10089,16 +10125,16 @@
 UK 
 150

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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
@@ -10131,16 +10167,16 @@
 UK 
 151

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Missing
 crossreference to 17.3.17 [defns.repositional.stream]

@@ -10158,16 +10194,16 @@
 UK 
 152

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Object state is
 using a definition of object (instance of a class) from
 outside the standard, rather than the 'region of storage'
@@ -10186,16 +10222,16 @@
 UK 
 153

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 If a
 repositional stream can only seek to a position previously
 encountered, then an arbitrary-positional-stream cannot
@@ -10218,16 +10254,16 @@

 

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Missing definition of a stable partition
 algorithm

@@ -10242,16 +10278,16 @@
 UK 
 155

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Add clause 28 to list that use this
 definition of character

@@ -10267,16 +10303,16 @@
 UK 
 156

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Add regular
 expressions to set of templates using character container
 type
@@ -10295,16 +10331,16 @@
 UK 
 157

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Add concepts to
 the ordered list of presentation

@@ -10323,16 +10359,16 @@
 UK 
 158

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 templates are neither classes nor functions

 <td width="535">
@@ -10350,16 +10386,16 @@
 UK 
 159

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

- <td width="107">
+ <td width="85">
 Footnote 152

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This informative
 footnote was relevant in 1998, not 2008. The term 'existing
 vendors' may imply something different now
@@ -10378,16 +10414,16 @@
 UK 
 160

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 requires is now
 a keyword with a specific meaning related to concepts, and
 its use in library specifcation may be confusing. Generally
@@ -10410,16 +10446,16 @@
 UK 
 161

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This paragraph
 is redundant as the definition of the term 'handler
 function' is already provided in 17.3. Are we in danger of
@@ -10439,16 +10475,16 @@
 UK 
 162

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Clause 30 makes
 use of a 'Synchronization' semantic element, that
 frequently appears either between Effects: and
@@ -10469,16 +10505,16 @@
 UK 
 163

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Many functions
 are defined as "Effects: Equivalent to a...", which seems
 to also define the preconditions, effects, etc. But this is
@@ -10498,16 +10534,16 @@
 UK 
 164

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This phrasing predates concepts. While this
 kind of description is still used, the examples provided
 are now all concepts, and should be replaced with
@@ -10530,17 +10566,17 @@
 UK 
 165

- <td>
+ <td width="117">
 17.5.3.2.2, 
 17.5.3.2.3

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 constraints on
 bitmask and enumation types were supposed to be tightened
 up as part of the motivation for the constexpr feature -
@@ -10560,19 +10596,19 @@
 UK 
 166

- <td>
+ <td width="117">
 17.5.3.2.4.1, 
 17.5.3.3

 

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 List of library clauses should go up to 30,
 not 27

@@ -10587,17 +10623,18 @@
 UK 
 167

- <td>
+ <td width="117">
 17.5.3.4 
- Private members
+ Private 
+ members

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Comment marker in wrong place.

 <td width="535">
@@ -10615,16 +10652,16 @@
 UK 
 168

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 We should make
 it clear (either by note or normatively) that namespace std
 may contain inline namespaces, and that entities specified
@@ -10649,16 +10686,16 @@
 UK 
 169

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This phrasing
 contradicts later freedom to implement the C standard
 library portions in the global namespace as well as std.
@@ -10677,16 +10714,16 @@
 UK 
 170

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 One of goals of
 C++0x is to make language easier to teach and for
 'incidental' programmers. The fine-grained headers of the
@@ -10713,16 +10750,16 @@
 UK 
 171

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Does
 freestanding implementation require a full implementation
 of all listed headers? The reference to abort, at_exit and
@@ -10746,16 +10783,16 @@
 UK 
 172

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 No reference to
 new functions quick_exit and at_quick_exit

@@ -10773,16 +10810,16 @@
 UK 
 173

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

- <td width="107">
+ <td width="85">
 table 15

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 
 <initializer_list> is missing from headers required
 in freestanding implementations.
@@ -10800,17 +10837,17 @@
 <td width="29">
 JP 23

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

- <td width="107">
+ <td width="85">
 2nd para, Table 15

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 There is a
 freestanding implementation including <type_traits>,
@@ -10837,16 +10874,16 @@
 UK 
 174

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The phrasing is
 mildly ambiguous when using the word 'it' to refer back to
 the header - an unfotunate reading might confuse it with
@@ -10869,16 +10906,16 @@
 UK 
 175

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Local types can
 now be used to instantiate templates, but don't have
 external linkage
@@ -10896,18 +10933,18 @@
 UK 
 176

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

- <td width="107">
+ <td width="85">
 Footnote 175

 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Reference to namespace ::std should be
 17.6.4.2

@@ -10922,16 +10959,16 @@
 UK 
 177

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Sentence is
 redundant as double underscores are reserved in all
 contexts by 17.6.4.3.3
@@ -10949,16 +10986,16 @@
 UK 
 178

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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
@@ -10975,16 +11012,16 @@
 UK 
 179

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 According to the
 4th bullet there is a problem if "if any replacement
 function or handler function or destructor operation throws
@@ -11003,18 +11040,18 @@
 <td width="29">
 JP 22

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

- <td width="107">
+ <td width="85">
 4th para, 1st
 line

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The
 statement below describes relation among two or more
 threads using words “between threads”: 
@@ -11044,16 +11081,16 @@
 UK 
 180

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

- <td width="107">
+ <td width="85">
 1, 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It should not be
 possible to strengthen the exception specification for
 virtual functions as this could break user code. Note this
@@ -11076,16 +11113,16 @@
 UK 
 181

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

- <td width="107">
+ <td width="85">
 Footnote 186

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This footnote is
 wrong. C library functions do not have any exception
 specification, but might be treated as if they had an empty
@@ -11106,16 +11143,16 @@
 UK 
 182

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

- <td width="107">
+ <td width="85">
 Footnote 188

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It is very
 helpful to assume all exceptions thrown by the standard
 library derive from std::exception. The 'encouragement' of
@@ -11134,16 +11171,16 @@
 UK 
 184

- <td>
+ <td width="117">
 18 -> 30

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The new
 alias-declaration syntax is generally easier to read than a
 typedef declaration. This is especially true for complex
@@ -11163,17 +11200,17 @@
 <td width="29">
 JP 24

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

- <td width="107">
+ <td width="85">
 2nd para, Table 16

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Subclauses are listed in Table 16 as:

@@ -11213,20 +11250,20 @@
 <td width="29">
 JP 25

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

- <td width="107">
+ <td width="85">
 
 6th para , last line, SEE ALSO

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 max_align_t is described in 18.1, so add 3.11 Alignment as
 the reference.
@@ -11243,17 +11280,18 @@
 <td width="29">
 FR 32

- <td>
+ <td width="117">
 18.2.1 
- [Numeric limits]
+ [Numeric 
+ limits]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The definition of
 numeric_limits<> as requiring a regular type is both
 conceptually wrong and operationally illogical. As we
@@ -11280,16 +11318,16 @@
 <td width="29">
 DE-16

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-16 The class
 template numeric_limits should not specify the Regular
@@ -11315,16 +11353,16 @@
 <td width="29">
 JP 26

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 numeric_limits does not use concept.

@@ -11377,16 +11415,16 @@
 <td width="29">
 DE-17

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-17 The class
 type_index should be removed; it provides no additional
@@ -11407,16 +11445,16 @@
 UK 
 185

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 There is no
 header <stdint>, it should either be <stdint.h>
 or <cstdint>
@@ -11433,16 +11471,16 @@
 <td width="29">
 DE-18

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-18 The
 proposed C++ standard makes a considerable number of
@@ -11479,16 +11517,16 @@
 UK 
 186

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

- <td width="107">
+ <td width="85">
 Footnote 221

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 What is the
 purpose of this comment? The standard stream objects (cin,
 cerr etc.) have a peculiar lifetime that extends beyond the
@@ -11508,16 +11546,16 @@
 UK 
 187

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

- <td width="107">
+ <td width="85">
 9

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The term "thread
 safe" is not defined nor used in this context anywhere else
 in the standard.
@@ -11536,16 +11574,16 @@
 UK 
 188

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

- <td width="107">
+ <td width="85">
 12

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The function
 _Exit does not appear to be defined in this standard.
 Should it be added to the table of functions
@@ -11564,16 +11602,16 @@
 UK 
 189

- <td>
+ <td width="117">
 18.4, 18.7

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The addition of the [[noreturn]] attribute
 to the language will be an important aid for static
 analysis tools.
@@ -11593,18 +11631,18 @@
 <td width="29">
 JP 27

- <td>
+ <td width="117">
 18.4, 18.9, 
 18.7.2.2, 
 18.7.3.1

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 There are Standard library functions that never return to
 the caller. They are explained so in the Standard but not
@@ -11643,16 +11681,16 @@
 UK 
 190

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

- <td width="107">
+ <td width="85">
 various

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It is not entirely clear how the current
 specification acts in the presence of a garbage collected
 implementation.
@@ -11672,16 +11710,16 @@
 UK 
 191

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 According to the second bullet, behaviour
 becomes undefined (for lack of a specification) if the user
 has not yet called set_new_handler.
@@ -11702,16 +11740,16 @@
 UK 
 192

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The declared
 signature is not compatible with the current requirement to
 throw std::length_error. It is too late to weaken the
@@ -11733,16 +11771,16 @@
 UK 
 193

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 quick_exit has
 been added as a new valid way to terminate a program in a
 well defined way
@@ -11761,16 +11799,16 @@
 UK 
 194

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The inclusion of
 type_index and hash<type_index> in <typeinfo>
 brings dependencies into <typeinfo> which are
@@ -11791,18 +11829,18 @@
 <td width="29">
 JP 28

- <td>
+ <td width="117">
 18.6, 
 18.7, 
 19.1

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 Errors reported by Exception classes are of types char or
 std::string only. For example, std::exception is declared
@@ -11823,16 +11861,16 @@
 <td width="29">
 JP 29

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 throw_with_nested does not use concept.

@@ -11866,16 +11904,16 @@
 <td width="29">
 JP 30

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 To
 handle nested exceptions strictly, error information of
 tree structure will be required though, the
@@ -11893,16 +11931,16 @@
 <td width="29">
 JP 31

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 It
 is difficult to understand in which case nested_exception
 is applied.
@@ -11923,16 +11961,16 @@
 UK 
 195

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The class
 definition of std::initializer_list contains concept-maps
 to Range which should be out of the class, and in
@@ -11954,16 +11992,16 @@
 UK 
 196

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Concept maps for initializer_list to Range
 should not be in language support headers, but instead in
 iterator concepts.
@@ -11986,16 +12024,16 @@
 UK 
 197

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -12016,16 +12054,16 @@
 <td width="29">
 JP 32

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 Messages returned by the member function what() of standard
 exception classes seem difficult to judge.
@@ -12078,16 +12116,16 @@
 <td width="29">
 US 64

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 “ See also: ISO C
 7.1.4, 7.2, Amendment 1 4.3.”
 It is unclear why this cross reference is here. Amendment 1
@@ -12108,16 +12146,16 @@
 <td width="29">
 US 65

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Scoped allocators and
 allocator propagation traits add a small amount of utility
 at the cost of a great deal of machinery. The machinery is
@@ -12159,16 +12197,16 @@
 UK 
 198

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The organization of clause 20 could be
 improved to better group related items, making the standard
 easier to navigate.
@@ -12214,16 +12252,16 @@
 UK 
 199

- <td>
+ <td width="117">
 20.1.1, 20.1.2

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The requirement
 that programs do not supply concept_maps should probably be
 users do not supply their own concept_map specializations.
@@ -12246,16 +12284,16 @@
 UK 
 200

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 All standard library use expects Predicates
 to be CopyConstructible, and this should be recognised
 easily without reatedly stating on every use-case.
@@ -12277,16 +12315,16 @@
 UK 
 201

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The Consistency axiom for
 LessThanComparable will not compile.

@@ -12307,16 +12345,16 @@
 <td width="29">
 JP 33

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 LessThanComparable and EqualityComparable don't correspond
 to NaN.
@@ -12336,16 +12374,16 @@
 <td width="29">
 US 66

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Application of the "Regular" concept to floating-point
 types appears to be controversial (see long discussion on
 std-lib reflector).
@@ -12361,20 +12399,20 @@
 <td width="29">
 JP 34

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

- <td width="107">
+ <td width="85">
 
 1st para, 4th line

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Though N2672 pointed at adding
 "#include<initializer_list>", it isn't reflected.
@@ -12393,16 +12431,16 @@
 <td width="29">
 US 67

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

- <td width="107">
+ <td width="85">
 ¶ 5 first sent.

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 Some connective words are missing.

 <td width="535">
@@ -12416,20 +12454,20 @@
 <td width="29">
 JP 35

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

- <td width="107">
+ <td width="85">
 
 6th para, 1st line

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Typo,

@@ -12447,16 +12485,16 @@
 UK 
 202

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 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
@@ -12475,16 +12513,16 @@
 <td width="29">
 US 68

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

- <td width="107">
+ <td width="85">
 IntegralLike

- <td width="38">
+ <td width="62">
 te/ed

- <td width="510">
+ <td width="604">
 The code defining the context is syntactically
 incorrect.

@@ -12501,16 +12539,16 @@
 UK 
 203

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

- <td width="107">
+ <td width="85">
 1-4

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The ratio_xyz
 types have a misplaced '}'. For example: template <class
 R1, class R2> struct ratio_add { typedef see below}
@@ -12530,20 +12568,20 @@
 <td width="29">
 JP 36

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

- <td width="107">
+ <td width="85">
 
 19th para, 6th line

 

- <td width="38">
+ <td width="62">
 ed

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

@@ -12562,16 +12600,16 @@
 UK 
 204

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

- <td width="107">
+ <td width="85">
 Table 41

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It is not
 possible to create a variant union based on a parameter
 pack expansion, e.g. to implement a classic discriminated
@@ -12590,16 +12628,16 @@
 <td width="29">
 US 69

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 This section, dealing with tuple<>, should be in
 the same section as the similar utility pair<>.

@@ -12615,16 +12653,16 @@
 UK 
 205

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 
 integral_constant objects should be usable in
 integral-constant-expressions. The addition to the language
@@ -12646,16 +12684,16 @@
 UK 
 206

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

- <td width="107">
+ <td width="85">
 para 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Currently the
 std says: "In order to instantiate the template
 is_convertible<From, To>, the following code shall be
@@ -12681,16 +12719,16 @@
 UK 
 207

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

- <td width="107">
+ <td width="85">
 Table 36

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 suffix "::type" is missing from the some of
 the examples.

@@ -12725,16 +12763,16 @@
 <td width="29">
 JP 37

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

- <td width="107">
+ <td width="85">
 Table 41

- <td width="38">
+ <td width="62">
 ed

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

@@ -12775,16 +12813,16 @@
 <td width="29">
 US 70

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Specifications now expressed via narrative text are more
 accurately and clearly expressed via executable code.

@@ -12807,16 +12845,16 @@
 <td width="29">
 US 71

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

- <td width="107">
+ <td width="85">
 Table 51, last row, column 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The grammar is incorrect.

 <td width="535">
@@ -12830,16 +12868,16 @@
 <td width="29">
 JP 38

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 add the move requirement for bind's return type. 
@@ -12889,16 +12927,16 @@
 <td width="29">
 JP 39

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 There are no requires corresponding to F of std::function.

@@ -12960,16 +12998,16 @@
 <td width="29">
 JP 40

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Thougn it's "Allocator Aloc" at other places, it's
 "Allocator A" only std::function constructor template
@@ -13016,16 +13054,16 @@
 <td width="29">
 JP 41

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 There are no requires corresponding to R and Args of
 UsesAllocator.
@@ -13075,16 +13113,16 @@
 <td width="29">
 JP 42

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The requires
 are wrong.
@@ -13202,16 +13240,16 @@
 UK 
 208

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 std::hash should
 be implemented for much more of the standard library. In
 particular for pair, tuple and all the standard containers.
@@ -13229,16 +13267,16 @@
 UK 
 209

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Smart pointers cannot be used in
 constrained templates

@@ -13258,16 +13296,16 @@
 UK 
 213

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 std::allocator
 should be constrained to simplify its use on constrained
 contexts. This library component models allocation from
@@ -13293,16 +13331,16 @@
 UK 
 214

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 
 raw_storage_iterator needs constraining as an iterator
 adaptor to be safely used in constrained templates
@@ -13320,16 +13358,16 @@
 UK 
 210

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Specialized algorithms for memory
 managenment need requirements to be easily usable in
 constrained templates
@@ -13349,16 +13387,16 @@
 <td width="29">
 DE-20

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 DE-20 The section heading and the first sentence use the
 term "template function", which is undefined.

@@ -13376,16 +13414,16 @@
 <td width="29">
 US 72

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 bind should support move-only functors and bound arguments.

@@ -13401,16 +13439,16 @@
 <td width="29">
 DE-21

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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
@@ -13429,16 +13467,16 @@
 UK 
 211

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

- <td width="107">
+ <td width="85">
 11

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The nullptr_t
 type was introduced to resolve the null pointer literal
 problem. It should be used for the assignemnt operator, as
@@ -13459,16 +13497,16 @@
 UK 
 212

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -13489,16 +13527,16 @@
 <td width="29">
 DE-22

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 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
@@ -13517,16 +13555,16 @@
 <td width="29">
 US 73

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 std::reference_closure template is redundant with
 std::function and should be removed.
@@ -13574,16 +13612,16 @@
 <td width="29">
 US 74

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Scoped
 allocators represent a poor trade-off for standardization,
 since (1) scoped-allocator--aware containers can be
@@ -13648,16 +13686,16 @@
 <td width="29">
 US 74

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

- <td width="107">
+ <td width="85">
 (a) synopsis (b) after ¶ 14

- <td width="38">
+ <td width="62">
 te/ed

- <td width="510">
+ <td width="604">
 A concept name is twice misspelled.

 <td width="535">
@@ -13671,16 +13709,16 @@
 <td width="29">
 US 75

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Allocator concepts are incomplete

 <td width="535">
@@ -13697,16 +13735,16 @@
 <td width="29">
 JP 43

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

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

@@ -13761,16 +13799,16 @@
 UK 
 215

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

- <td width="107">
+ <td width="85">
 6,8

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Extra pair of
 {}, presumably some formatting code gone awry :
 duration& operator-{-}();
@@ -13787,16 +13825,16 @@
 <td width="29">
 US 77

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 Allocator-specific move and copy behavior for containers
 (N2525) complicates a little-used and already-complicated
@@ -13839,17 +13877,17 @@
 <td width="29">
 US 78

- <td>
+ <td width="117">
 20.8.12, 
 20.8.13.2

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 There is presently no way to
 convert directly from a <code>shared_ptr</code> to a
@@ -13872,16 +13910,16 @@
 <td width="29">
 US 79

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 [unique.ptr.single.ctor]/5 no longer requires for D not to
 be a pointer type.  This restriction needs to be put
@@ -13914,16 +13952,16 @@
 <td width="29">
 JP 44

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 1st parameter p and 2nd parameter v is now
 shared_ptr<T> *.
@@ -13945,16 +13983,16 @@
 <td width="29">
 JP 45

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 Rep, Period, Clock and Duration don't correspond to
 concept.
@@ -13984,16 +14022,16 @@
 <td width="29">
 US 80

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

- <td width="107">
+ <td width="85">
 Heading

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The section heading does not describe the contents.

 <td width="535">
@@ -14014,16 +14052,16 @@
 <td width="29">
 US 81

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 chrono::duration is missing the modulous operator for both
 member and non-member arithmetic. This operator is useful
@@ -14131,16 +14169,16 @@
 <td width="29">
 US 82

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

- <td width="107">
+ <td width="85">
 after ¶ 1

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The code synopsis has a minor alignment error.

 <td width="535">
@@ -14155,16 +14193,16 @@
 UK 
 216

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 All the containers use concepts for their
 iterator usage, exect for basic_string. This needs fixing.

@@ -14179,16 +14217,16 @@
 <td width="29">
 JP 46

- <td>
+ <td width="117">
 21.2, 21.3

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 basic_string does not use concept.

@@ -15193,16 +15231,16 @@
 <td width="29">
 JP 47

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Typo. Missing ”>”

@@ -15234,16 +15272,16 @@
 <td width="29">
 JP 48

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 char_traits does not use concept.

@@ -15279,16 +15317,16 @@
 UK 
 217

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 basic_string refers to
 constructible_with_allocator_suffix, which I thought was
 removed?
@@ -15310,16 +15348,16 @@
 UK 
 218

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The identity
 "&*(s.begin() + n) == &*s.begin() + n" relies on
 operator& doing the "right thing", which (AFAICS) there
@@ -15342,17 +15380,18 @@
 UK 
 219

- <td>
+ <td width="117">
 21.3.6.6 
- [string.replace]
+ [string. 
+ replace]

- <td width="107">
+ <td width="85">
 11

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Effects refers to "whose first begin() - i1
 elements" However i1 is greater than begin()...

@@ -15368,16 +15407,16 @@
 UK 
 220

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The
 operator<< for basic_string takes the output stream
 by r-value reference. This is different from the same
@@ -15400,16 +15439,17 @@
 <td width="29">
 FR 33

- <td>
- 22.1.1 [locale]
+ <td width="117">
+ 22.1.1 
+ [locale]

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 ios_base::iostate err = 0;

 
@@ -15429,16 +15469,16 @@
 <td width="29">
 JP 49

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 codecvt does not use concept. For example, create
 CodeConvert concept and change as follows.
@@ -15458,16 +15498,16 @@
 <td width="29">
 JP 50

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Add
 custom allocator parameter to wstring_convert, since we
 cannot allocate memory for strings from a custom allocator.
@@ -15533,19 +15573,19 @@
 <td width="29">
 FI 4

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

 22.2.1.4.2

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 <tt>to_end and to_limit are both used. Only one is
 needed.</tt>

@@ -15559,16 +15599,16 @@
 <td width="29">
 FI 5

- <td>
+ <td width="117">
 <tt>22.2.1.4.2</tt>

- <td width="107">
+ <td width="85">
 #3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 <tt>[ Note: As
 a result of operations on state, it can return ok or
@@ -15609,20 +15649,21 @@
 <td width="29">
 FI 6

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

 See also 
- 22.2.1.4 (1,2,3)
+ 22.2.1.4 
+ (1,2,3)

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 <tt>codecvt_byname is only specified to work with locale
@@ -15651,16 +15692,16 @@
 <td width="29">
 FI 7

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

- <td width="107">
+ <td width="85">
 1,2,3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 The word
 "codeset" is used, whereas the word "character set" is used
@@ -15680,18 +15721,18 @@
 <td width="29">
 JP 51

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

- <td width="107">
+ <td width="85">
 7th para, 1st
 line

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 A
 parameter `end’ should be `fmtend’. 
 get() function had two `end’ parameters at N2321.
@@ -15736,18 +15777,18 @@
 <td width="29">
 JP 52

- <td>
+ <td width="117">
 22.2.5.1, 
 22.2.5.2, 
 22.2.6.1

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 InputIterator does not use concept.

@@ -15927,17 +15968,17 @@
 <td width="29">
 JP 53

- <td>
+ <td width="117">
 22.2.5.3 , 
 22.2.5.4

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 OutputIterator does not use concept.

@@ -16061,20 +16102,20 @@
 <td width="29">
 JP 54

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

- <td width="107">
+ <td width="85">
 
 2nd para, Table 79

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 There is not <forward_list> in Table 79.

@@ -16091,16 +16132,16 @@
 UK 
 221

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

- <td width="107">
+ <td width="85">
 Table 79

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The table is missing the new
 <forward_list> header.

@@ -16120,16 +16161,16 @@
 UK 
 222

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It is not clear
 what purpose the Requirement tables serve in the Containers
 clause. Are they the definition of a library Container? Or
@@ -16164,20 +16205,20 @@
 <td width="29">
 JP 55

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

- <td width="107">
+ <td width="85">
 
 3rd para, 4th line

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 It
 seems that “the MinimalAllocator concep” is the
 typo of “the MinimalAllocator concept”.
@@ -16196,16 +16237,16 @@
 UK 
 223

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The library does
 not define the MinimalAllocator or ScopedAllocator
 concepts, these were part of an earlier Allocators proposal
@@ -16226,16 +16267,16 @@
 UK 
 224

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

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This paragraph implicitly requires all
 containers in clause 23 to support allocators, which
 std::array does not.
@@ -16256,16 +16297,16 @@
 UK 
 225

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

- <td width="107">
+ <td width="85">
 Table 81

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Inconsistent
 words used to say the same thing. Table 80 describes
 iterator/const_iterator typedef as returning an "iterator
@@ -16289,16 +16330,16 @@
 UK 
 226

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

- <td width="107">
+ <td width="85">
 10

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 <array>
 must be added to this list. In particular it doesn't
 satisfy: - no swap() function invalidates any references,
@@ -16321,16 +16362,16 @@
 UK 
 227

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

- <td width="107">
+ <td width="85">
 Table 80

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The post-condition for a = rv uses the word
 “construction” when it means
 “assignment”
@@ -16350,16 +16391,16 @@
 UK 
 228

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Line 4 contains
 a spelling mistake in the fragment "MinimalAllocator
 concep."
@@ -16377,16 +16418,16 @@
 UK 
 229

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The fragment "A container may directly call
 constructors" is not technically correct as constructors
 are not callable.
@@ -16408,16 +16449,16 @@
 UK 
 230

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 
 “implementations shall consider the following
 functions to be const” - what does this mean? I don't
@@ -16438,17 +16479,17 @@
 <td width="29">
 JP 56

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

- <td width="107">
+ <td width="85">
 12th para, Table 84

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 `array’ is unstated in Table 84 - Optional sequence
 container operations.
@@ -16478,16 +16519,16 @@
 UK 
 231

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

- <td width="107">
+ <td width="85">
 9-11

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 These paragraphs
 are redundant now that Concepts define what it means to be
 an Iterator and guide overload resolution accordingly.
@@ -16507,16 +16548,16 @@
 UK 
 232

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

- <td width="107">
+ <td width="85">
 Table 84

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 match_results
 may follow the requirements but is not listed a general
 purpose library container.
@@ -16535,16 +16576,16 @@
 UK 
 233

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

- <td width="107">
+ <td width="85">
 Table 84

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Add references to the new containers.

 <td width="535">
@@ -16565,16 +16606,16 @@
 UK 
 234

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

- <td width="107">
+ <td width="85">
 Table 84

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Ther reference
 to iterator in semantics for back should also allow for
 const_iterator when called on a const-qualified container.
@@ -16595,16 +16636,16 @@
 UK 
 235

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 “The library provides three basic
 kinds of sequence containers: vector, list, and
 deque” - text appears to be out of date re addition
@@ -16626,16 +16667,16 @@
 UK 
 236

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 [ 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
@@ -16663,16 +16704,16 @@
 UK 
 237

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 vector, list, and deque offer the
 programmer different complexity trade-offs and should be
 used accordingly - this ignores array and forward_list
@@ -16693,16 +16734,16 @@
 UK 
 238

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Leaving it
 unspecified whether or not iterator and const_iterator are
 the same type is dangerous, as user code may or may not
@@ -16731,16 +16772,16 @@
 UK 
 239

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

- <td width="107">
+ <td width="85">
 85

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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.
@@ -16765,16 +16806,16 @@
 UK 
 240

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

- <td width="107">
+ <td width="85">
 12

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The axiom
 EmplacePushEquivalence should be asserting the stronger
 contract that emplace and insert return the same iterator
@@ -16807,20 +16848,20 @@
 <td width="29">
 JP 57

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

- <td width="107">
+ <td width="85">
 
 1st para, 4th line

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Typo, duplicated "to"

@@ -16839,16 +16880,16 @@
 UK 
 241

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 std::array does
 not have an allocator, so need to document an exception to
 the requirements of 23.1.1p3
@@ -16866,16 +16907,16 @@
 UK 
 242

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 std:: qualification no longer needed for
 reverse_iterator.

@@ -16894,16 +16935,16 @@
 UK 
 243

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Most containers,
 and types in general have 3 swaps: swap(T&, T&)
 swap(T&&, T&) swap(T&, T&&) But
@@ -16922,16 +16963,17 @@
 UK 
 244

- <td>
- 23.2.1, 23.2.6
+ <td width="117">
+ 23.2.1, 
+ 23.2.6

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The validity of
 the expression &a[n] == &a[0] + n is contingent on
 operator& doing the “right thing” (as
@@ -16961,16 +17003,16 @@
 UK 
 245

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -17006,20 +17048,20 @@
 <td width="29">
 JP 58

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

- <td width="107">
+ <td width="85">
 
 1st line
 before 1st para

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Unnecessary "{" exists before a word iterator like
 "{iterator before_begin()".
@@ -17035,16 +17077,16 @@
 <td width="29">
 JP 59

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Types of the third and forth parameter of splice() are
 iterator at 23.2.4.4, though types of them are
@@ -17097,16 +17139,16 @@
 <td width="29">
 US 83

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

- <td width="107">
+ <td width="85">
 7

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 "shrink_to_fint" should be "shrink_to_fit".

@@ -17126,16 +17168,16 @@
 UK 
 246

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The content of
 this sub-clause is purely trying to describe in words the
 effect of the requires clauses on these operations, now
@@ -17159,16 +17201,16 @@
 UK 
 247

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 Iterator
 concepts are not extensive enough to merit a whole new
 header, and should be merged into <concpts>. This is
@@ -17194,16 +17236,16 @@
 UK 
 248

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The text "so for
 any iterator type there is an iterator value that points
 past the last element of a corresponding container" is
@@ -17225,16 +17267,16 @@
 UK 
 250

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 A default implementation should be supplied
 for the post-increment operator to simplify implementation
 of iterators by users.
@@ -17252,16 +17294,16 @@
 UK 
 251

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The
 post-increment operator is dangerous for a general
 InputIterator. The multi-pass guarantees that make it
@@ -17291,16 +17333,16 @@

 

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 istream_iterator is not a class, but a
 class template

@@ -17316,16 +17358,16 @@
 UK 
 253

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 First sentance
 does not make gramatical sense, Seems to be missing the
 words 'if it' by comparison with similar sentance in other
@@ -17346,16 +17388,16 @@
 UK 
 254

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This
 postcondition for pre-increment operator should be written
 as an axiom
@@ -17374,16 +17416,16 @@
 UK 
 255

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This
 postcondition for pre-increment operator should be written
 as an axiom
@@ -17402,16 +17444,16 @@
 UK 
 256

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

- <td width="107">
+ <td width="85">
 3, 4, 5

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The relationship between pre- and post-
 decrement should be expressed as an axiom.

@@ -17430,16 +17472,16 @@
 UK 
 257

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 There is a
 reasonable default for postdecrement_result type, which is
 X. X is required to be regular, therefore CopyConstructible
@@ -17460,16 +17502,16 @@
 UK 
 258

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 A default
 implementation should be supplied for the post-decrement
 operator to simplify implementation of iterators by users.
@@ -17489,16 +17531,16 @@
 UK 
 259

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 
 postdecrement_result is effectively returning a copy of the
 original iterator value, so should have similar
@@ -17520,16 +17562,16 @@
 UK 
 260

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -17551,17 +17593,17 @@
 UK 
 249

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The semantic for
 operator+= should also be provided as a default
 implementation to simplify implementation of user-defined
@@ -17582,16 +17624,16 @@
 UK 
 261

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 To simplify user
 defined random access iterator types, the
 subscript_reference type should default to reference
@@ -17609,16 +17651,16 @@
 UK 
 262

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

- <td width="107">
+ <td width="85">
 3, 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Effects and post-conditions for operator+
 are more useful if expressed as axioms, and supplied as
 default implementations.
@@ -17639,16 +17681,16 @@
 UK 
 263

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This requirement on operator-= would be
 better expressed as a default implementation in the
 concept, with a matching axiom
@@ -17669,16 +17711,16 @@
 UK 
 264

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Effects clauses are better expressed as
 axioms where possible.

@@ -17697,16 +17739,16 @@
 UK 
 265

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

- <td width="107">
+ <td width="85">
 8

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This effects
 clause is nonesense. It looks more like an axiom stating
 equivalence, and certainly an effects clause cannot change
@@ -17725,16 +17767,16 @@
 UK 
 266

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

- <td width="107">
+ <td width="85">
 9

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 This sentance should be provided as a
 default definition, along with a matching axiom

@@ -17754,16 +17796,16 @@
 UK 
 267

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

- <td width="107">
+ <td width="85">
 24.1.6

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The code in the
 Requires clause for RandomAccessIterator operator[] would
 be better expressed as an axiom.
@@ -17782,16 +17824,16 @@
 UK 
 268

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

- <td width="107">
+ <td width="85">
 12

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This note is
 potentialy confusing as __far enters the syntax as a clear
 language extension, but the note treats it as a regular
@@ -17812,17 +17854,17 @@
 <td width="29">
 JP 60

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

- <td width="107">
+ <td width="85">
 1st para

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 Capability of an iterator is too much restricted by
 concept.
@@ -18007,16 +18049,16 @@
 UK 
 269

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 'decrements for
 negative n' seems to imply a negative number of decrement
 operations, which is odd.
@@ -18034,16 +18076,16 @@
 UK 
 270

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The reachability
 constraint in p5 means that a negavite result, implying
 decrements operations in p4, is not possible
@@ -18063,16 +18105,16 @@
 UK 
 271

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

- <td width="107">
+ <td width="85">
 6,7

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 next/prev return
 an incremented iterator without changing the value of the
 original iterator. However, even this may invalidate an
@@ -18093,16 +18135,16 @@
 UK 
 272

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 reverse_iterator
 and move_iterator use different formulations for their
 comparison operations. move_iterator merely requires the
@@ -18134,16 +18176,16 @@
 UK 
 274

- <td>
+ <td width="117">
 24.4, 24.5

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The subclauses
 for standard iterator adaptors could be better organised.
 There are essentially 3 kinds of iterator wrappers
@@ -18170,16 +18212,16 @@
 UK 
 275

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The constructor
 template taking a single Iterator argument will be selected
 for Copy Initialization instead of the non-template
@@ -18200,16 +18242,16 @@
 UK 
 276

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 It is odd to
 have a mix of declaration stlyes for operator+ overloads.
 Prefer if either all are member functions, or all are
@@ -18229,16 +18271,16 @@
 UK 
 277

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The default
 constructor default-initializes current, rather than
 value-initializes. This means that when Iterator
@@ -18267,16 +18309,16 @@
 UK 
 278

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 There is an
 inconsistency between the constructor taking an iterator
 and the constructor template taking a reverse_iterator
@@ -18298,17 +18340,17 @@
 UK 
 279

- <td>
+ <td width="117">
 24.4.1.2.12, 
 24.4.3.2.12

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The reason the
 return type became unspecified is LWG issue 386. This
 reasoning no longer applies as there are at least two ways
@@ -18329,16 +18371,16 @@
 UK 
 280

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The presence of
 the second iterator value is surprising for many readers
 who underestimate the size of a reverse_iterator object.
@@ -18359,16 +18401,16 @@
 UK 
 281

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The current
 specification for return value will always be a true
 pointer type, but reverse_iterator supports proxy iterators
@@ -18389,7 +18431,7 @@
 UK 
 282

- <td>
+ <td width="117">
 24.4.2.1, 
 24.4.2.2.2, 
 24.4.2.3, 
@@ -18397,13 +18439,13 @@
 24.4.2.5, 
 24.4.2.6.2

- <td width="107">
+ <td width="85">
 n/a

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Insert iterators of move-only types will
 move from lvalues

@@ -18421,17 +18463,17 @@
 UK 
 283

- <td>
+ <td width="117">
 24.4.2.5, 
 24.4.2.6.4

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 postincrement operator overloads
 traditionally return by value - insert_iterator is declared
 as return by reference. The change is harmless in this
@@ -18451,18 +18493,18 @@
 <td width="29">
 JP 61

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

- <td width="107">
+ <td width="85">
 2nd para, 1st
 line

- <td width="38">
+ <td width="62">
 ed

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

@@ -18481,16 +18523,16 @@
 UK 
 284

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The stream
 iterators need constraining with concepts/requrires
 clauses.
@@ -18508,16 +18550,16 @@
 UK 
 285

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

- <td width="107">
+ <td width="85">
 1,2

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Much of the
 content of p1 and the whole of p2 is a redundant
 redefinition of InputIterator. It should be simplified
@@ -18536,16 +18578,16 @@
 UK 
 286

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 To the casual
 reader it is not clear if it is intended to be able to
 assign to istream_iterator objects. Specifying the copy
@@ -18567,16 +18609,16 @@
 UK 
 287

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It is not clear
 what the intial state of an istream_iterator should be. Is
 _value_ initialized by reading the stream, or default/value
@@ -18601,16 +18643,16 @@
 UK 
 288

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The provided specification is vacuous,
 offering no useful information.

@@ -18629,16 +18671,16 @@
 UK 
 289

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 It is very hard
 to pick up the correct specification for
 istream_iterator::operator== as the complete specification
@@ -18663,16 +18705,16 @@
 UK 
 290

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The character
 type of a string delimiter for an ostream_iterator should
 be const charT *, the type of the elements, not char *, a
@@ -18691,16 +18733,16 @@
 UK 
 291

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 ostream_iterator
 postincrement operator returns by reference rather than by
 value. This may be a small efficiency gain, but it is
@@ -18718,17 +18760,18 @@
 <td width="29">
 FR 34

- <td>
+ <td width="117">
 24.5.3 
- [istreambuf.iterator]
+ [istreambuf. 
+ iterator]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 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.
@@ -18746,16 +18789,16 @@
 UK 
 292

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Prefer the use
 of the new nullptr constant to the zero literal when using
 a null pointer in text.
@@ -18774,16 +18817,16 @@
 UK 
 293

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

- <td width="107">
+ <td width="85">
 2,3,4

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The listed paragraphs redundantly redefine
 an input iterator, and redundancy can be a dangerous thing
 in a specification. Suggest a simpler phrasing below.
@@ -18809,16 +18852,16 @@
 UK 
 294

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Implicit converting constructors can be
 invoked at surprising times, so there should always be a
 good reason for declaring one.
@@ -18843,16 +18886,16 @@
 UK 
 295

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 THere is a level
 of redundancy in the library specification for many
 algorithms that can be eliminated with the combination of
@@ -18872,17 +18915,17 @@
 <td width="29">
 JP 62

- <td>
+ <td width="117">
 25, 25.3.1.5, 
 26.3.6.5

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 The return types of is_sorted_until function and
@@ -18913,16 +18956,16 @@
 UK 
 296

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The 'Returns' of
 adjacent_find requires only HasEqualTo, or a Predicate.
 Requiring EqualityComparable or EquivalenceRelation seems
@@ -18942,16 +18985,16 @@
 UK 
 297

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The definition
 of rotate_copy is very complicated. It is equivalent to:
 return copy(first, middle, copy(middle, last, result));
@@ -18971,16 +19014,16 @@
 UK 
 298

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

- <td width="107">
+ <td width="85">
 13

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 partition_point requires a partitioned
 array

@@ -18996,16 +19039,16 @@
 UK 
 299

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Should be consistent in style use of
 concepts in template parameter lists. The
 auto-OutputIterator sytle used in std::copy is probably
@@ -19025,16 +19068,16 @@
 UK 
 300

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Since publishing
 the original standard, we have learned that swap is a
 fundamental operation, and several common idioms rely on it
@@ -19065,16 +19108,16 @@
 UK 
 301

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 replace and
 replace_if have the requirement: OutputIterator<Iter,
 Iter::reference> Which implies they need to copy some
@@ -19097,16 +19140,16 @@
 UK 
 302

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

- <td width="107">
+ <td width="85">
 4

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 the concept
 StrictWeakOrder covers the definition of a strict weak
 ordering, described in paragraph 4.
@@ -19125,16 +19168,16 @@
 UK 
 303

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

- <td width="107">
+ <td width="85">
 6

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 This paragraph just describes
 is_partitioned

@@ -19153,16 +19196,16 @@
 UK 
 304

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The requires
 clauses of push_heap, pop_heap and make_heap are
 inconsistently formatted, dispite being identical
@@ -19180,16 +19223,16 @@
 UK 
 305

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

- <td width="107">
+ <td width="85">
 1, 9, 17

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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.
@@ -19205,16 +19248,16 @@
 <td width="29">
 US 84

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 
 Parts of the numerics chapter are not concept enabled.

@@ -19230,17 +19273,18 @@
 <td width="29">
 FR 35

- <td>
+ <td width="117">
 26.3 
- [Complex numbers]
+ [Complex 
+ numbers]

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Instantiations of the class
 template complex<> have to be allowed for integral
 types, to reflect existing practice and ISO standards
@@ -19259,16 +19303,16 @@
 UK 
 306

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Random number
 library component cannot be used in constrained templates

@@ -19285,16 +19329,16 @@
 <td width="29">
 JP 63

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 No
 constructor of discrete_distribution that accepts
 initializer_list.
@@ -19339,16 +19383,16 @@
 <td width="29">
 JP 64

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 “valarray<T>& operator+=
@@ -19370,16 +19414,16 @@
 UK 
 307

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

- <td width="107">
+ <td width="85">
 Footnote 288

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 The footnote
 refers to TR1, which is not a defined term in this
 standard. Drop the reference to TR1, those templates are a
@@ -19398,16 +19442,16 @@
 <td width="29">
 US 85

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 The
 input/output chapter is not concept enabled.

@@ -19424,16 +19468,16 @@
 UK 
 308

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 
 iostreams library cannot be used from
 constrained templates
@@ -19451,16 +19495,16 @@
 <td width="29">
 JP 65

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Switch from
 “unspecified-bool-type” to
 JP 66

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

- <td width="107">
+ <td width="85">
 1st para

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Switch from
 “unspecified-bool-type” to
 FR 36

- <td>
- 27.6.1.2.2 [istream. 
- formatted.arithmetic]
+ <td width="117">
+ 27.6.1.2.2 
+ [istream. 
+ formatted. 
+ arithmetic]

- <td width="107">
+ <td width="85">
 1, 2, and 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 iostate err = 0;

 
@@ -19546,17 +19592,19 @@
 <td width="29">
 FR 37

- <td>
- 27.6.1.2.2 [istream. 
- formatted.arithmetic]
+ <td width="117">
+ 27.6.1.2.2 
+ [istream. 
+ formatted. 
+ arithmetic]

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 else if (lval <
 numeric_limits<int>::min()

@@ -19580,16 +19628,16 @@
 <td width="29">
 JP 67

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 basic_stringbuf dose not use concept.

@@ -19726,16 +19774,16 @@
 <td width="29">
 JP 68

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 basic_istringstream dose not use concept.

@@ -19903,16 +19951,16 @@
 <td width="29">
 JP 69

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 basic_ostringstream dose not use concept.

@@ -20081,16 +20129,16 @@
 <td width="29">
 JP 71

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

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

@@ -20123,16 +20171,16 @@
 <td width="29">
 JP 72

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 basic_stringstream dose not use concept.

@@ -20295,16 +20343,16 @@
 <td width="29">
 JP 73

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 It is a problem
 from C++98, fstream cannot appoint a filename of wide
@@ -20324,16 +20372,16 @@
 <td width="29">
 US 86

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 The
 regular expressions chapter is not concept enabled.

@@ -20350,16 +20398,16 @@
 UK 
 309

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Regular
 expressions cannot be used in constrained templates

@@ -20377,16 +20425,16 @@
 UK 
 310

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The regex chapter uses iterators in the old
 pre-concept style, it should be changed to use concepts
 instead.
@@ -20403,16 +20451,16 @@
 UK 
 314

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The swap
 overloads for regex classes are only supplied for l-value
 references. Other sections of the library (eg 21 strings or
@@ -20436,16 +20484,16 @@
 UK 
 315

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

- <td width="107">
+ <td width="85">
 p6

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 6 Effects:
 string_type str(first, last); return
 use_facet<collate<charT> >(
@@ -20466,16 +20514,16 @@
 UK 
 316

- <td>
+ <td width="117">
 28.4 ff

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The constructors
 for regex classes do not have an r-value overload.

@@ -20493,16 +20541,16 @@
 UK 
 317

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 basic_string has both a constructor and an
 assignment operator that accepts an initializer list,
 basic_regex should have the same.
@@ -20525,16 +20573,16 @@
 <td width="29">
 JP 74

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 “basic_regx & operator=
@@ -20555,16 +20603,16 @@
 UK 
 318

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

- <td width="107">
+ <td width="85">
 para 22

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Constructor
 definition should appear with the other constructors not
 after assignment ops.
@@ -20582,16 +20630,16 @@
 UK 
 319

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It was always expected that
 regex_token_iterator would be constructible from an array
 literal: indeed ideally this is the prefered method of
@@ -20634,16 +20682,16 @@
 <td width="29">
 US 87

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 The
 atomics chapter is not concept enabled. The adopted paper,
 N2427, did have those concepts.
@@ -20661,16 +20709,16 @@
 UK 
 311

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Atomic types
 cannot be used generically in a constrained template

@@ -20688,16 +20736,16 @@
 UK 
 312

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -20720,16 +20768,16 @@
 <td width="29">
 JP 75

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 A
 definition of enum or struct is the style of C using
 typedef.
@@ -20970,16 +21018,16 @@
 UK 
 313

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 seq_cst fences don't necessarily guarantee
 ordering
 http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926
@@ -21002,16 +21050,16 @@
 <td width="29">
 US 88

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The "lockfree" facilities do
 not tell the programmer enough.

@@ -21030,16 +21078,16 @@
 <td width="29">
 US 89

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

- <td width="107">
+ <td width="85">
 Table 122

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 types in the table "Atomics for standard typedef types"
 should be typedefs, not classes. These semantics are
@@ -21058,16 +21106,16 @@
 <td width="29">
 US 90

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Are atomic functions allowed
 to have non-volatile overloads?

@@ -21086,16 +21134,16 @@
 <td width="29">
 US 91

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 Whether or not a failed
 compare_exchange is a RMW operation (as used in 1.10
 [intro.multithread]) is unclear.
@@ -21116,16 +21164,16 @@
 <td width="29">
 US 92

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The effect of
 memory_order_consume with atomic RMW operations is unclear.

@@ -21144,16 +21192,16 @@
 <td width="29">
 JP 76

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 A
 description for "Throws: Nothing." are not unified.

@@ -21197,16 +21245,16 @@
 <td width="29">
 US 93

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ge

- <td width="510">
+ <td width="604">
 The
 thread chapter is not concept enabled.

@@ -21226,16 +21274,16 @@

 

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Threads library cannot be used in
 constrained templates

@@ -21251,16 +21299,16 @@
 UK 
 321

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 Throughout this
 clause, the term Requires: is used to introduce compile
 time requirements, which we expect to be replaced with
@@ -21285,16 +21333,16 @@
 <td width="29">
 US 94

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The first sentence of para 1 suggests that no other
 library function is permitted to call operating system or
 low level APIs.
@@ -21320,16 +21368,16 @@
 <td width="29">
 US 95

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 “native_handle_type” is a typedef, not a
 class member.

@@ -21357,16 +21405,16 @@
 <td width="29">
 US 96

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 There is no definition here for monotonic clock.

 <td width="535">
@@ -21387,16 +21435,16 @@
 UK 
 322

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Not all systms
 can provide a monotonic clock. How are they expected to
 treat a _for function?
@@ -21415,16 +21463,16 @@
 UK 
 323

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The presence of
 a non-explicit variadic template constructor alongside an
 explicit single-argument constructor can lead to behaviour
@@ -21451,16 +21499,16 @@
 UK 
 324

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 thread::id
 objects should be as useable in hashing containers as they
 are in ordered associative containers.
@@ -21484,16 +21532,16 @@
 <td width="29">
 JP 77

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 
 "CopyConstructible" and "MoveConstructible" in
@@ -21515,20 +21563,20 @@
 <td width="29">
 JP 78

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

- <td width="107">
+ <td width="85">
 
 4th para, 1st line

 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 In
 "F and each Ti in Args", 'Ti' is not clear.

@@ -21543,16 +21591,16 @@
 <td width="29">
 US 97

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

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 detach-on-destruction may result in
 “escaped” threads accessing objects with
 bounded lifetime after the end of their lifetime.
@@ -21567,17 +21615,17 @@
 <td width="29">
 US 98

- <td>
+ <td width="117">
 30.2.1.3, 
 30.2.1.4

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 

- <td width="510">
+ <td width="604">
 The current defined behavior
 for the std::thread destructor is to detach the thread.
 Unfortunately, this behavior exposes programmers to tricky,
@@ -21600,16 +21648,16 @@
 UK 
 325

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

- <td width="107">
+ <td width="85">
 2

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -21633,16 +21681,16 @@
 UK 
 326

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

- <td width="107">
+ <td width="85">
 7

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 The precondition
 that the mutex is not owned by this thread offers
 introduces the risk of un-necessary undefined behaviour
@@ -21667,16 +21715,16 @@
 UK 
 327

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

- <td width="107">
+ <td width="85">
 4, 9, 14, 19

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Not clear what
 the specification for error condition
 resource_deadlock_would_occur means. It is perfectly
@@ -21708,16 +21756,16 @@
 UK 
 328

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

- <td width="107">
+ <td width="85">
 20

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 There is a missing precondition that owns
 is true, or an if(owns) test is missing from the effect
 clause
@@ -21737,16 +21785,16 @@
 UK 
 329

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -21784,16 +21832,16 @@
 UK 
 330

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 30.5.1 (and then 30.5.7) refer to a
 specialisation of
 constructible_with_allocator_prefix<> However this
@@ -21814,16 +21862,16 @@
 <td width="29">
 JP 79

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 The
 concept of UsesAllocator and Allocator should be used.

@@ -21875,16 +21923,16 @@
 UK 
 331

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Not clear what
 it means for a public constructor to be 'exposition only'.
 If the intent is purely to support the library calling this
@@ -21907,16 +21955,16 @@
 UK 
 332

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ed

- <td width="510">
+ <td width="604">
 It is not clear
 without reference to the original proposal how to use a
 future. In particular, the only way for the user to
@@ -21941,16 +21989,16 @@
 UK 
 333

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 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
@@ -21967,16 +22015,16 @@
 UK 
 334

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

- <td width="107">
+ <td width="85">
 5

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Behaviour of
 get() is undefined if calling get() while not is_ready().
 The intent is that get() is a blocking call, and will wait
@@ -21996,16 +22044,16 @@
 UK 
 335

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 
 std::unique_future is MoveConstructible, so you can
 transfer the association with an asynchronous result from
@@ -22034,16 +22082,16 @@
 UK 
 336

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 It is possible
 to transfer ownership of the asynchronous result from one
 unique_future instance to another via the move-constructor.
@@ -22070,16 +22118,17 @@
 <td width="29">
 JP 80

- <td>
- 30.5.4 , 30.5.5
+ <td width="117">
+ 30.5.4 , 
+ 30.5.5

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 Typo, duplicated ">"

@@ -22102,16 +22151,16 @@
 UK 
 337

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 shared_future
 should support an efficient move constructor that can avoid
 unnecessary manipulation of a reference count, much like
@@ -22130,16 +22179,16 @@
 UK 
 338

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 shared_future is currently
 CopyConstructible, but not CopyAssignable. This is
 inconsistent with shared_ptr, and will surprise users.
@@ -22175,16 +22224,16 @@
 UK 
 339

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

- <td width="107">
+ <td width="85">
 6, 7

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 Move assignment is goiing in the wrong
 direction, assigning from *this to the passed rvalue, and
 then returning a reference to an unusable *this
@@ -22205,16 +22254,16 @@
 UK 
 340

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

- <td width="107">
+ <td width="85">
 11, 12, 13

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 There is an
 implied postcondition that the state of the promise is
 transferred into the future leaving the promise with no
@@ -22234,16 +22283,16 @@
 UK 
 341

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 promise::swap accepts its parameter by
 lvalue reference. This is inconsistent with other types
 that provide a swap member function, where those swap
@@ -22261,16 +22310,16 @@
 UK 
 342

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 std::promise is
 missing a non-member overload of swap. This is inconsistent
 with other types that provide a swap member function
@@ -22289,16 +22338,16 @@
 UK 
 343

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

- <td width="107">
+ <td width="85">
 3

- <td width="38">
+ <td width="62">
 Te

- <td width="510">
+ <td width="604">
 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
@@ -22319,16 +22368,16 @@
 <td width="29">
 JP 81

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 
 There are not requirements for F and a concept of Allocator
 dose not use.
@@ -22450,16 +22499,16 @@
 <td width="29">
 DE-23

- <td>
+ <td width="117">
 Annex B

- <td width="107">
+ <td width="85">
 p2

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-23 Recursive
 use of constexpr functions appears to be permitted. Since
@@ -22478,16 +22527,16 @@
 <td width="29">
 DE-24

- <td>
+ <td width="117">
 Annex B

- <td width="107">
+ <td width="85">
 p2

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-24 The
 number of placeholders for "bind" is implementation-defined
@@ -22503,16 +22552,16 @@
 <td width="29">
 DE-25

- <td>
+ <td width="117">
 Annex B

- <td width="107">
+ <td width="85">
 p2

- <td width="38">
+ <td width="62">
 te

- <td width="510">
+ <td width="604">
 DE-25
 Specifying a minimum of 17 recursively nested template
@@ -22534,17 +22583,17 @@
 <td width="29">
 FR 38

- <td>
+ <td width="117">
 C.2 
 [diffs.library]

- <td width="107">
+ <td width="85">
 1

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 What is ISO/IEC 1990:9899/DAM
 1? My guess is that's a typo for ISO/IEC

@@ -22568,16 +22617,16 @@
 UK 
 344

- <td>
+ <td width="117">
 Appendix D

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 Ge

- <td width="510">
+ <td width="604">
 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
@@ -22597,16 +22646,16 @@
 <td width="29">
 FR 39

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

- <td width="107">
+ <td width="85">
 

- <td width="38">
+ <td width="62">
 ed

- <td width="510">
+ <td width="604">
 Some definitions seem not
 indexed (such as /trivially copyable/ or

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51566 - sandbox/committee/LWG"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51564 - 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