Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r51571 - sandbox/committee/LWG
From: bdawes_at_[hidden]
Date: 2009-03-03 09:16:34

Next message: fmhess_at_[hidden]: "[Boost-commit] svn:boost r51572 - in trunk: boost/signals2 boost/signals2/detail libs/signals2/test"
Previous message: john_at_[hidden]: "[Boost-commit] svn:boost r51570 - trunk/tools/build/v2/tools"

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

Log:
Remove all width= elements
Text files modified:
sandbox/committee/LWG/LWG_0xCD1_status.html | 4528 ++++++++++++++++++++--------------------
1 files changed, 2264 insertions(+), 2264 deletions(-)

Modified: sandbox/committee/LWG/LWG_0xCD1_status.html
==============================================================================
--- sandbox/committee/LWG/LWG_0xCD1_status.html (original)
+++ sandbox/committee/LWG/LWG_0xCD1_status.html 2009-03-03 09:16:32 EST (Tue, 03 Mar 2009)
@@ -21,32 +21,32 @@
<h1>Library Working Group 
Status of CD1 National Body Comments</h1>
Revised:
-03 Mar 2009 08:36:37 AM -0500
+03 Mar 2009 09:10:21 AM -0500

<table border="1" bordercolor="#000000" cellpadding="7"
- cellspacing="0" style="border-collapse: collapse" width="1628">
+ cellspacing="0" style="border-collapse: collapse">

 <tr valign="top">
- <td width="29">
- MB 
+ <td>
+ MB 

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

- <td width="31">
+ <td>
 Para/ 
- Figure/ Table/ Note<td width="38">
+ Figure/ Table/ Note<td>
 Type 

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

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

- <td width="225">
+ <td>
 
 Disposition
@@ -54,19 +54,19 @@
 

 <tr valign="top">
- <td width="29">
+ <td>
 US 2

- <td width="75">
+ <td>
 17-30

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

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

- <td width="375">
+ <td>
 The
 active issues identified in WG21 N2806, C++ Standard
 Library Active Issues, must be addressed and appropriate
@@ -85,56 +85,56 @@

 

- <td width="466">
+ <td>
 Appropriate action would
 include making changes to the CD, identifying an issue as
 not requiring a change to the CD, or deferring the issue to
 a later point in time.

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

 Acknowledged<tr valign="top">
- <td width="29">
+ <td>
 FR 2

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

- <td width="31">
+ <td>
 Library

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

- <td width="375">
+ <td>
 The adoption of the library `constexpr' proposal was not
 reflected in the draft, despite formal WG21 committee vote.

- <td width="466">
+ <td>
 FR 2

- <td width="225">
+ <td>
 Editorial; sent to Pete Becker<tr valign="top">
- <td width="29">
+ <td>
 US 61

- <td width="75">
+ <td>
 17 onward

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

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

- <td width="375">
+ <td>
 The concepts core language feature is applied to only
 some of the Standard Library clauses, and even then not
 always consistently.

- <td width="466">
+ <td>
 Review all
 clauses of the Standard Library, and consistently apply
@@ -144,77 +144,77 @@

 

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

 Agreed. Duplicates CA2<tr valign="top">
- <td width="29">
+ <td>
 CA-2

- <td width="75">
+ <td>
 17 Library

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

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

- <td width="375">
+ <td>
 
 “Concepts” are a significant new addition to
 the language, but are not exploited uniformly in the
 library as documented in CD 14882.

- <td width="466">
+ <td>
 Fix
 the standard library so that “Concepts” are
 used appropriately in the library.

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

 Agreed; We intend to address this.<tr valign="top">
- <td width="29">
+ <td>
 US 62

- <td width="75">
+ <td>
 17-30

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

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

- <td width="375">
+ <td>
 Provide concepts
 and requirements clauses for all standard library templates

 

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

- <td width="225">
+ <td>
 Agreed. Duplicates CA2 

 <tr valign="top">
- <td width="29">
+ <td>
 US 63

- <td width="75">
+ <td>
 17-30

 

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

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

- <td width="375">
+ <td>
 The behavior of the library in the presence of threads
 is incompletely specified.

@@ -228,28 +228,28 @@
 at() to different characters in the same non-const string
 really introduce a data race?

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

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

 17 SG: should go to threads group; misclassified in document

 Concurrency SG: Create an issue. Hans will look into it.<tr valign="top">
- <td width="29">
+ <td>
 DE-2

- <td width="75">
+ <td>
 17 through 30

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

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

- <td width="375">
+ <td>
 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
@@ -257,20 +257,20 @@
 standard library apparently has not been reviewed for
 marking non-single-parameter constructors as "explicit".

- <td width="466">
+ <td>
 Consider marking zero-parameter and multi-parameter
 constructors "explicit" in classes that have at least one
 constructor marked "explicit" and that do not have an
 initializer-list constructor.

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

 Robert Klarer to address this one<tr valign="top">
- <td width="29">
+ <td>
 JP 21

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

@@ -285,13 +285,13 @@
 27.8.1, 
 28.4

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

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

- <td width="375">
+ <td>
 
 Support of char16_t/char32_t is insufficient. The basic_xxx
 classes of <iostream>, <fstream>,
@@ -302,7 +302,7 @@
 Functions such as stoi, to_string in ‘21.4 Numeric
 Conversion’ does not support char16_t/char32_t types.

- <td width="466">
+ <td>
 Add commented
 lines corresponding to char16_t, char32_t.
@@ -1102,127 +1102,127 @@

 

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

 Previously considered; we decided not to do it. We believe it is not too
 onerous to use wbuffer_convert and wstring_convert which were added as
 intermediaries to avoid proliferation of types.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 144

- <td width="75">
+ <td>
 17.1

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 List of contents of library should be
 extened to cover new clauses

- <td width="466">
+ <td>
 Add "regular expressions, atomic operations
 and threads"

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 145

- <td width="75">
+ <td>
 17.1

- <td width="31">
+ <td>
 6

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

- <td width="375">
+ <td>
 
 Summary of numeric facilities should
 mention random numbers

 

- <td width="466">
+ <td>
 Add random number framework to the list of
 library facilities

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 146

- <td width="75">
+ <td>
 17.1

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

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

- <td width="375">
+ <td>
 Add a summary paragraph for regular
 expressions

- <td width="466">
+ <td>
 Add a summary paragraph for regular
 expressions

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 147

- <td width="75">
+ <td>
 17.1

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

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

- <td width="375">
+ <td>
 Add a summary paragraph for threads

- <td width="466">
+ <td>
 Add a summary paragraph for threads

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 148

- <td width="75">
+ <td>
 17.2

- <td width="31">
+ <td>
 Table 12

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

- <td width="375">
+ <td>
 Table 12 is
 mentioned in and relates to section 17.2, but has been
 pushed down to appear directly after the title of section
@@ -1230,57 +1230,57 @@

 

- <td width="466">
+ <td>
 Make sure tables are rendered in the
 section to which they relate.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 149

- <td width="75">
+ <td>
 17.3

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

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

- <td width="375">
+ <td>
 For consistency
 with narrow-oriented and wide-oriented streams, we should
 add terms for streams of Unicode character sequences

 

- <td width="466">
+ <td>
 Define Utf16-oriented stream classes and
 Uft32-oriented stream classes for streams of
 char16_t/char32_t values.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 150

- <td width="75">
+ <td>
 17.3

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

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

- <td width="375">
+ <td>
 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
@@ -1290,7 +1290,7 @@
 with singular iterators suggest the term 'singular object'
 or 'the object is in a singular state'.

- <td width="466">
+ <td>
 Define 'singular
 state' such that an object with a singular state can only
 be assigned to or safely destroyed. Assiging a new value
@@ -1305,51 +1305,51 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 151

- <td width="75">
+ <td>
 17.3.1

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

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

- <td width="375">
+ <td>
 Missing
 crossreference to 17.3.17 [defns.repositional.stream]

 

- <td width="466">
+ <td>
 Add cross-reference in the existing empty
 brackets

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 152

- <td width="75">
+ <td>
 17.3.12

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

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

- <td width="375">
+ <td>
 Object state is
 using a definition of object (instance of a class) from
 outside the standard, rather than the 'region of storage'
@@ -1357,27 +1357,27 @@

 

- <td width="466">
+ <td>
 Clarify terms and usage

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

 we think we're removing this; Howard to create LWG issue. Howard, see [func.referenceclosure.cons]<tr valign="top">
- <td width="29">
+ <td>
 UK 
 153

- <td width="75">
+ <td>
 17.3.17

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

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

- <td width="375">
+ <td>
 If a
 repositional stream can only seek to a position previously
 encountered, then an arbitrary-positional-stream cannot
@@ -1385,108 +1385,108 @@

 

- <td width="466">
+ <td>
 Strike the word 'only'. A note might be
 added to reinforce the intent

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

 editorial; sent to Pete Becker<tr valign="top">
- <td width="29">
+ <td>
 UK 
 154

 

- <td width="75">
+ <td>
 17.3.20

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

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

- <td width="375">
+ <td>
 Missing definition of a stable partition
 algorithm

- <td width="466">
+ <td>
 Add definition from 25.2.12p7

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 155

- <td width="75">
+ <td>
 17.3.3

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

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

- <td width="375">
+ <td>
 Add clause 28 to list that use this
 definition of character

- <td width="466">
+ <td>
 Add clause 28 to list that use this
 definition of character

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 156

- <td width="75">
+ <td>
 17.3.4

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

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

- <td width="375">
+ <td>
 Add regular
 expressions to set of templates using character container
 type

 

- <td width="466">
+ <td>
 Add regular expressions to set of templates
 using character container type

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 157

- <td width="75">
+ <td>
 17.5.2.2

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

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

- <td width="375">
+ <td>
 Add concepts to
 the ordered list of presentation

@@ -1494,82 +1494,82 @@

 

- <td width="466">
+ <td>
 Add concepts into the sequence

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 158

- <td width="75">
+ <td>
 17.5.2.2

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

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

- <td width="375">
+ <td>
 templates are neither classes nor functions

- <td width="466">
+ <td>
 Replace
 'classes' and 'functions' with 'classes and class
 templates' and 'functions and function templates'

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 159

- <td width="75">
+ <td>
 17.5.2.4

- <td width="31">
+ <td>
 Footnote 152

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

- <td width="375">
+ <td>
 This informative
 footnote was relevant in 1998, not 2008. The term 'existing
 vendors' may imply something different now

 

- <td width="466">
+ <td>
 Strike the footnote, or replace 'existing'
 with 'original' or similar

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 160

- <td width="75">
+ <td>
 17.5.2.4

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

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

- <td width="375">
+ <td>
 requires is now
 a keyword with a specific meaning related to concepts, and
 its use in library specifcation may be confusing. Generally
@@ -1581,27 +1581,27 @@

 

- <td width="466">
+ <td>
 Replace 'Requires' with 'Preconditions'

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 161

- <td width="75">
+ <td>
 17.5.2.4

- <td width="31">
+ <td>
 4

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

- <td width="375">
+ <td>
 This paragraph
 is redundant as the definition of the term 'handler
 function' is already provided in 17.3. Are we in danger of
@@ -1610,27 +1610,27 @@

 

- <td width="466">
+ <td>
 Strike 17.5.2.4p4

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 162

- <td width="75">
+ <td>
 17.5.2.4

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

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

- <td width="375">
+ <td>
 Clause 30 makes
 use of a 'Synchronization' semantic element, that
 frequently appears either between Effects: and
@@ -1638,29 +1638,29 @@

 

- <td width="466">
+ <td>
 Add 'Synchronization' to the list either
 between Effects: and Postconditions:, or between Returns:
 and Throws:.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 163

- <td width="75">
+ <td>
 17.5.2.4

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

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

- <td width="375">
+ <td>
 Many functions
 are defined as "Effects: Equivalent to a...", which seems
 to also define the preconditions, effects, etc. But this is
@@ -1668,34 +1668,34 @@

 

- <td width="466">
+ <td>
 Introduce an explicit "Equivalent to",
 which defines all of the properties of the function.

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

 Tom Plum to open LWG issue; we believe this is related to LWG625<tr valign="top">
- <td width="29">
+ <td>
 UK 
 164

- <td width="75">
+ <td>
 17.5.3.2.1

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 This phrasing predates concepts. While this
 kind of description is still used, the examples provided
 are now all concepts, and should be replaced with
 appropriate examples

- <td width="466">
+ <td>
 Use better names
 for the examples. Ideally totally replace the need by
 constraining all templates in library, so that real
@@ -1704,25 +1704,25 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 165

- <td width="75">
+ <td>
 17.5.3.2.2, 
 17.5.3.2.3

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

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

- <td width="375">
+ <td>
 constraints on
 bitmask and enumation types were supposed to be tightened
 up as part of the motivation for the constexpr feature -
@@ -1730,84 +1730,84 @@

 

- <td width="466">
+ <td>
 Adopt wording in line with the motivation
 described in N2235

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

 Robert Klarer to review<tr valign="top">
- <td width="29">
+ <td>
 UK 
 166

- <td width="75">
+ <td>
 17.5.3.2.4.1, 
 17.5.3.3

 

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

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

- <td width="375">
+ <td>
 List of library clauses should go up to 30,
 not 27

- <td width="466">
+ <td>
 Replace initial refernce to ch27 with ch30

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 167

- <td width="75">
+ <td>
 17.5.3.4 
 Private 
 members

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

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

- <td width="375">
+ <td>
 Comment marker in wrong place.

- <td width="466">
+ <td>
 Change: //
 streambuf* sb; exposition only to streambuf* sb; //
 exposition only To reflect actual usage.

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 168

- <td width="75">
+ <td>
 17.6.2.2

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 We should make
 it clear (either by note or normatively) that namespace std
 may contain inline namespaces, and that entities specified
@@ -1818,31 +1818,31 @@

 

- <td width="466">
+ <td>
 Replace "namespace std or namespaces nested
 within namespace std" with "namespace std or namespaces
 nested within namespace std or inline namespaces nested
 directly or indirectly within namespace std"

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

 Howard will create issue to adopt UK words (some have reservations whether
 it is correct)<tr valign="top">
- <td width="29">
+ <td>
 UK 
 169

- <td width="75">
+ <td>
 17.6.2.2

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

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

- <td width="375">
+ <td>
 This phrasing
 contradicts later freedom to implement the C standard
 library portions in the global namespace as well as std.
@@ -1850,28 +1850,28 @@

 

- <td width="466">
+ <td>
 Resolve conflict in either place

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

 Bill Plaugher to open issue. If the wording is too broad we need to add an
 exception to the standard C library.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 170

- <td width="75">
+ <td>
 17.6.2.3

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

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

- <td width="375">
+ <td>
 One of goals of
 C++0x is to make language easier to teach and for
 'incidental' programmers. The fine-grained headers of the
@@ -1883,34 +1883,34 @@

 

- <td width="466">
+ <td>
 Add a new header <std> that has the
 effect of including everything in tables 13 and 14, except
 <iosfwd> and <cassert>. Add an additional
 header <fwd> that adds all declarations from
 <std> but no definitions.

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

 Alisdair to open issue. We prefer
 <std>only. </std>

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 171

- <td width="75">
+ <td>
 17.6.2.4

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

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

- <td width="375">
+ <td>
 Does
 freestanding implementation require a full implementation
 of all listed headers? The reference to abort, at_exit and
@@ -1921,86 +1921,86 @@

 

- <td width="466">
+ <td>
 Either strike the references to abort,
 at_exit and exit, or clarify which headers only require
 partial support.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 172

- <td width="75">
+ <td>
 17.6.2.4

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

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

- <td width="375">
+ <td>
 No reference to
 new functions quick_exit and at_quick_exit

 

- <td width="466">
+ <td>
 Add reference to quick_exit and
 at_quick_exit

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

 NAD. We do not belive at_exit and at_quick_exit should be required by
 freestanding implementations.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 173

- <td width="75">
+ <td>
 17.6.2.4

- <td width="31">
+ <td>
 table 15

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

- <td width="375">
+ <td>
 
 <initializer_list> is missing from headers required
 in freestanding implementations.

 

- <td width="466">
+ <td>
 Add 18.8, initializer lists,
 <initializer_list>, to the end of the table.

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

 LWG is interested in N2814, but we're concerned whether CWG will accept
 language recommendations.<tr valign="top">
- <td width="29">
+ <td>
 JP 23

- <td width="75">
+ <td>
 17.6.2.4

- <td width="31">
+ <td>
 2nd para, Table 15

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

- <td width="375">
+ <td>
 There is a
 freestanding implementation including <type_traits>,
@@ -2014,32 +2014,32 @@
 
 

- <td width="466">
+ <td>
 Add
 <type_traits>, <array>, <ration> to Table
 15.

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

 LWG is interested in N2814, but we're concerned whether CWG will accept
 language recommendations.

 add <type_traits> only. Alisdair will draft an issue.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 174

- <td width="75">
+ <td>
 17.6.3.2

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

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

- <td width="375">
+ <td>
 The phrasing is
 mildly ambiguous when using the word 'it' to refer back to
 the header - an unfotunate reading might confuse it with
@@ -2048,136 +2048,136 @@

 

- <td width="466">
+ <td>
 Replace 'the first reference to any of the
 entities declared in that header by the translation unit'
 with 'the first reference to any of the entities that
 header declares in the translation unit'

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 175

- <td width="75">
+ <td>
 17.6.4.2.1

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 Local types can
 now be used to instantiate templates, but don't have
 external linkage

 

- <td width="466">
+ <td>
 Remove the reference to external linkage

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

 we accept the proposed solution. Martin will draft an issue.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 176

- <td width="75">
+ <td>
 17.6.4.3.3

- <td width="31">
+ <td>
 Footnote 175

 

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

- <td width="375">
+ <td>
 Reference to namespace ::std should be
 17.6.4.2

- <td width="466">
+ <td>
 Change referfence from 17.6.4.3 to 17.6.4.2

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 177

- <td width="75">
+ <td>
 17.6.4.3.4

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

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

- <td width="375">
+ <td>
 Sentence is
 redundant as double underscores are reserved in all
 contexts by 17.6.4.3.3

 

- <td width="466">
+ <td>
 Strike the sentence

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 178

- <td width="75">
+ <td>
 17.6.4.8

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 The last sentence of the third bullet
 "Operations on such types can report a failure by throwing
 an exception unless otherwise specified" is redundant as
 behaviour is already undefined.

- <td width="466">
+ <td>
 Strike the sentence

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 179

- <td width="75">
+ <td>
 17.6.4.8

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 According to the
 4th bullet there is a problem if "if any replacement
 function or handler function or destructor operation throws
@@ -2186,28 +2186,28 @@

 

- <td width="466">
+ <td>
 Replace the word 'throws' with 'propogates'

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

 Agreed. Alisdair will draft an issue.<tr valign="top">
- <td width="29">
+ <td>
 JP 22

- <td width="75">
+ <td>
 17.6.5.7

- <td width="31">
+ <td>
 4th para, 1st
 line

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

- <td width="375">
+ <td>
 The
 statement below describes relation among two or more
 threads using words “between threads”: 
@@ -2221,7 +2221,7 @@
 such case, “among” is preferred instead of
 “between”.

- <td width="466">
+ <td>
 
 Change "between threads" to "among threads".

@@ -2229,24 +2229,24 @@
 There are same cases in 17.6.1 paragraph 2, 17.6.5.7
 paragraph 6, 30.1 paragraph 1, 30.3.1 paragraph 1 also.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 180

- <td width="75">
+ <td>
 17.6.5.10

- <td width="31">
+ <td>
 1, 4

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

- <td width="375">
+ <td>
 It should not be
 possible to strengthen the exception specification for
 virtual functions as this could break user code. Note this
@@ -2257,28 +2257,28 @@

 

- <td width="466">
+ <td>
 Add restriction that exception
 specification of virtual functions cannot be tightened.

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

 NAD, the standard already has the desired restriction.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 181

- <td width="75">
+ <td>
 17.6.5.10

- <td width="31">
+ <td>
 Footnote 186

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

- <td width="375">
+ <td>
 This footnote is
 wrong. C library functions do not have any exception
 specification, but might be treated as if they had an empty
@@ -2286,30 +2286,30 @@

 

- <td width="466">
+ <td>
 Clarify that this note does not mean the
 functions are genuinely declared with the specification,
 but are treated as-if.

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

 We agree that the footnote is wrong and it will be removed. Pete will handle
 as editorial.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 182

- <td width="75">
+ <td>
 17.6.5.10

- <td width="31">
+ <td>
 Footnote 188

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

- <td width="375">
+ <td>
 It is very
 helpful to assume all exceptions thrown by the standard
 library derive from std::exception. The 'encouragement' of
@@ -2317,28 +2317,28 @@

 

- <td width="466">
+ <td>
 Make this footnote normative

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

 NAD. We cannot mandate all standard-library functions that might use some
 third-party library.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 184

- <td width="75">
+ <td>
 18 -> 30

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

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

- <td width="375">
+ <td>
 The new
 alias-declaration syntax is generally easier to read than a
 typedef declaration. This is especially true for complex
@@ -2346,29 +2346,29 @@

 

- <td width="466">
+ <td>
 Replace all typedef declarations in the
 standard library with alias-declarations, except in the
 standard C library.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 24

- <td width="75">
+ <td>
 18

- <td width="31">
+ <td>
 2nd para, Table 16

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

- <td width="375">
+ <td>
 
 Subclauses are listed in Table 16 as:

@@ -2384,7 +2384,7 @@
 "text-indent: 0.06in; margin-top: 0.04in">"18.7 Exception
 handling …".

- <td width="466">
+ <td>
 
 Sort them in the increasing order 
@@ -2401,55 +2401,55 @@
 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 25

- <td width="75">
+ <td>
 18.1

- <td width="31">
+ <td>
 
 6th para , last line, SEE ALSO

 

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

- <td width="375">
+ <td>
 
 max_align_t is described in 18.1, so add 3.11 Alignment as
 the reference.

- <td width="466">
+ <td>
 Add
 "3.11, Alignment" to
 SEE ALSO.

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

 <tr valign="top">
- <td width="29">
+ <td>
 FR 32

- <td width="75">
+ <td>
 18.2.1 
 [Numeric 
 limits]

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

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

- <td width="375">
+ <td>
 The definition of
 numeric_limits<> as requiring a regular type is both
 conceptually wrong and operationally illogical. As we
@@ -2462,30 +2462,30 @@

 

- <td width="466">
+ <td>
 We suggest that a more pragmatic approach, in the spirit
 of C and C++, be taken so that calls to constrained
 function templates are interpreted as assertions on
 *values*, not necessarily semantics assertions on the
 carrier type.

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

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

- <td width="75">
+ <td>
 18.2.1

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

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

- <td width="375">
+ <td>
 DE-16 The class
 template numeric_limits should not specify the Regular
@@ -2500,31 +2500,31 @@

 

- <td width="466">
+ <td>
 Specify a concept requirement with fewer constraints as
 appropriate, for example SemiRegular.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 26

- <td width="75">
+ <td>
 18.2.1.1

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

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

- <td width="375">
+ <td>
 
 numeric_limits does not use concept.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -2566,23 +2566,23 @@

 

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

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

- <td width="75">
+ <td>
 18.2.6

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

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

- <td width="375">
+ <td>
 DE-17 The class
 type_index should be removed; it provides no additional
@@ -2590,55 +2590,55 @@

 

- <td width="466">
+ <td>
 Specify concept maps for "const type_info *" as required
 by the ordered and unordered containers and remove the
 class type_index.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 185

- <td width="75">
+ <td>
 18.3.1

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 There is no
 header <stdint>, it should either be <stdint.h>
 or <cstdint>

 

- <td width="466">
+ <td>
 Replace <stdint> with <cstdint>

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

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

- <td width="75">
+ <td>
 18.4

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

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

- <td width="375">
+ <td>
 DE-18 The
 proposed C++ standard makes a considerable number of
@@ -2660,31 +2660,31 @@

 

- <td width="466">
+ <td>
 Consider applying the changes proposed in WG21 document
 N2693 "Requirements on programs and backwards
 compatibility", available at
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html
 .

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 186

- <td width="75">
+ <td>
 18.4

- <td width="31">
+ <td>
 Footnote 221

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

- <td width="375">
+ <td>
 What is the
 purpose of this comment? The standard stream objects (cin,
 cerr etc.) have a peculiar lifetime that extends beyond the
@@ -2693,55 +2693,55 @@

 

- <td width="466">
+ <td>
 Remove the footnote

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 187

- <td width="75">
+ <td>
 18.4

- <td width="31">
+ <td>
 9

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

- <td width="375">
+ <td>
 The term "thread
 safe" is not defined nor used in this context anywhere else
 in the standard.

 

- <td width="466">
+ <td>
 Clarify the intended meaing of "thread
 safe"

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 188

- <td width="75">
+ <td>
 18.4

- <td width="31">
+ <td>
 12

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

- <td width="375">
+ <td>
 The function
 _Exit does not appear to be defined in this standard.
 Should it be added to the table of functions
@@ -2749,32 +2749,32 @@

 

- <td width="466">
+ <td>
 Depends on where _Exit comes from

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 189

- <td width="75">
+ <td>
 18.4, 18.7

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

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

- <td width="375">
+ <td>
 The addition of the [[noreturn]] attribute
 to the language will be an important aid for static
 analysis tools.

- <td width="466">
+ <td>
 The following
 functions should be declared in C++ with the [[noreturn]]
 attribute: abort exit quick_exit terminate unexpected
@@ -2782,31 +2782,31 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 27

- <td width="75">
+ <td>
 18.4, 18.9, 
 18.7.2.2, 
 18.7.3.1

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

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

- <td width="375">
+ <td>
 
 There are Standard library functions that never return to
 the caller. They are explained so in the Standard but not
 declared explicitly.

- <td width="466">
+ <td>
 
 Consider to add the attribute [[noreturn]] to such
 functions,
@@ -2831,58 +2831,58 @@
 
 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 190

- <td width="75">
+ <td>
 18.5.1

- <td width="31">
+ <td>
 various

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

- <td width="375">
+ <td>
 It is not entirely clear how the current
 specification acts in the presence of a garbage collected
 implementation.

- <td width="466">
+ <td>
 All deallocation
 functions taking a pointer parameter should have a
 Precondition : ptr is a safely-derived pointer value.

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 191

- <td width="75">
+ <td>
 18.5.1.1

- <td width="31">
+ <td>
 4

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

- <td width="375">
+ <td>
 According to the second bullet, behaviour
 becomes undefined (for lack of a specification) if the user
 has not yet called set_new_handler.

- <td width="466">
+ <td>
 Rephrase the
 second bullet in terms of a new handler being installed,
 and update any definition of handler function necessary to
@@ -2890,24 +2890,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 192

- <td width="75">
+ <td>
 18.5.1.2

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

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

- <td width="375">
+ <td>
 The declared
 signature is not compatible with the current requirement to
 throw std::length_error. It is too late to weaken the
@@ -2917,56 +2917,56 @@

 

- <td width="466">
+ <td>
 Fix 5.3.4p7 by required std::bad_alloc
 rather than std::length_error

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 193

- <td width="75">
+ <td>
 18.5.2.2

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 quick_exit has
 been added as a new valid way to terminate a program in a
 well defined way

 

- <td width="466">
+ <td>
 Change 3rd bullet: call either abort(),
 exit() or quick_exit();

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 194

- <td width="75">
+ <td>
 18.6

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

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

- <td width="375">
+ <td>
 The inclusion of
 type_index and hash<type_index> in <typeinfo>
 brings dependencies into <typeinfo> which are
@@ -2975,30 +2975,30 @@

 

- <td width="466">
+ <td>
 Move type_index and hash<type_index>
 out of <typeinfo> and into a new header,
 <typeindex>.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 28

- <td width="75">
+ <td>
 18.6, 
 18.7, 
 19.1

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

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

- <td width="375">
+ <td>
 
 Errors reported by Exception classes are of types char or
 std::string only. For example, std::exception is declared
@@ -3008,31 +3008,31 @@

 

- <td width="466">
+ <td>
 
 Consider other types.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 29

- <td width="75">
+ <td>
 18.7.6

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

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

- <td width="375">
+ <td>
 
 throw_with_nested does not use concept.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -3055,55 +3055,55 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 30

- <td width="75">
+ <td>
 18.7.6

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

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

- <td width="375">
+ <td>
 To
 handle nested exceptions strictly, error information of
 tree structure will be required though, the
 nested_exception does not support tree structure. It is
 insufficient as error handling.

- <td width="466">
+ <td>
 
 Consider nested_exception to support tree structure.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 31

- <td width="75">
+ <td>
 18.7.6

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

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

- <td width="375">
+ <td>
 It
 is difficult to understand in which case nested_exception
 is applied.

- <td width="466">
+ <td>
 Consider to add
 a sample program which rethrows exception.
@@ -3111,24 +3111,24 @@
 
 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 195

- <td width="75">
+ <td>
 18.8

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

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

- <td width="375">
+ <td>
 The class
 definition of std::initializer_list contains concept-maps
 to Range which should be out of the class, and in
@@ -3138,33 +3138,33 @@

 

- <td width="466">
+ <td>
 Delete the two concept maps from
 std::initializer_list.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 196

- <td width="75">
+ <td>
 18.8.3

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

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

- <td width="375">
+ <td>
 Concept maps for initializer_list to Range
 should not be in language support headers, but instead in
 iterator concepts.

- <td width="466">
+ <td>
 Remove section
 18.8.3 and put it in 24.1.8.1 instead, so that the
 concept_maps from initializer_list to Range are specified
@@ -3174,30 +3174,30 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 197

- <td width="75">
+ <td>
 19

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

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

- <td width="375">
+ <td>
 All the exception classes in this clause
 take a std::string argument by const reference. They should
 all be overloaded to accept std::string by rvalue rerefence
 for an efficient move as well.

- <td width="466">
+ <td>
 Provide a
 constructor for every exception class in clause 19
 accepting a std::string by rvalue reference, with the
@@ -3205,23 +3205,23 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 32

- <td width="75">
+ <td>
 19.1

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

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

- <td width="375">
+ <td>
 
 Messages returned by the member function what() of standard
 exception classes seem difficult to judge.
@@ -3262,34 +3262,34 @@
 
 

- <td width="466">
+ <td>
 
 Consider to add footnote that recommends what() returns
 message easy to recognize what exception was thrown.

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 64

- <td width="75">
+ <td>
 19.3

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 “ See also: ISO C
 7.1.4, 7.2, Amendment 1 4.3.”
 It is unclear why this cross reference is here. Amendment 1
 was to C89, not C99.

- <td width="466">
+ <td>
 Delete this
 cross reference. If necessary, expand the main text to
@@ -3297,26 +3297,26 @@

 

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

 The statement made in the comment was already aired prior to the last vote.
 Without further input, the committee cannot remove a feature that was voted
 into the draft. We will look at this comment in the light of N2829, which
 attempts to make scoped allocators less intrusive.<tr valign="top">
- <td width="29">
+ <td>
 US 65

- <td width="75">
+ <td>
 20

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

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

- <td width="375">
+ <td>
 Scoped allocators and
 allocator propagation traits add a small amount of utility
 at the cost of a great deal of machinery. The machinery is
@@ -3324,7 +3324,7 @@
 don't have any obvious connection to allocators, including
 basic concepts and simple components like pair and tuple.

- <td width="466">
+ <td>
 
 Sketch of proposed resolution: Eliminate scoped allocators,
 replace allocator propagation traits with a simple uniform
@@ -3350,29 +3350,29 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 198

- <td width="75">
+ <td>
 20

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

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

- <td width="375">
+ <td>
 The organization of clause 20 could be
 improved to better group related items, making the standard
 easier to navigate.

- <td width="466">
+ <td>
 20.6.7, 20.6.8,
 20.6.9 and 20.6.10 should be grouped under a section called
 "operator wrappers" or similar. The goal of all 4
@@ -3405,25 +3405,25 @@

 

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

 Agree that this is editorial -- forward to project editor. (effective
 duplicate of US 69)<tr valign="top">
- <td width="29">
+ <td>
 UK 
 199

- <td width="75">
+ <td>
 20.1.1, 20.1.2

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 The requirement
 that programs do not supply concept_maps should probably be
 users do not supply their own concept_map specializations.
@@ -3435,32 +3435,32 @@

 

- <td width="466">
+ <td>
 Replace the term 'program' with 'user'.

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

 Agree change 'program' to 'user' in clauses 20.1.1 and 20.1.2<tr valign="top">
- <td width="29">
+ <td>
 UK 
 200

- <td width="75">
+ <td>
 20.1.4

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

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

- <td width="375">
+ <td>
 All standard library use expects Predicates
 to be CopyConstructible, and this should be recognised
 easily without reatedly stating on every use-case.

- <td width="466">
+ <td>
 Either require
 CopyConstructible<F> as part of Predicate, or create
 a refined concept, StdPredicate, used throughout the
@@ -3469,7 +3469,7 @@

 

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

 We agree that adding constraints to predicate is a good idea. Predicate
@@ -3478,24 +3478,24 @@
 Predicate should refine MoveConstructible. However, upon review of existing
 library components, CopyConstructible or even SemiRegular might be more
 appropriate for Predicate.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 201

- <td width="75">
+ <td>
 20.1.5

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

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

- <td width="375">
+ <td>
 The Consistency axiom for
 LessThanComparable will not compile.

- <td width="466">
+ <td>
 Add a requires
 clause to the Consistency axiomL requires
 HasLessEquals<T> &&
@@ -3505,29 +3505,29 @@

 

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

 After consultation with the submitter, we agreed that the suggestion was in
 error and there is nothing else to be done.<tr valign="top">
- <td width="29">
+ <td>
 JP 33

- <td width="75">
+ <td>
 20.1.5

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

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

- <td width="375">
+ <td>
 
 LessThanComparable and EqualityComparable don't correspond
 to NaN.

- <td width="466">
+ <td>
 Apply
 concept_map to these concepts at FloatingPointType
@@ -3535,67 +3535,67 @@
 
 

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

 We believe that no change is necessary, but it should be reviewed by a group
 devoted to numeric issues. Not every possible state for a type must
 participate in the axioms. For example, pointers are dereferenceable even if
 some pointers (e.g. the null pointer) should not be dereferenced.<tr valign="top">
- <td width="29">
+ <td>
 US 66

- <td width="75">
+ <td>
 20.1.10

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

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

- <td width="375">
+ <td>
 Application of the "Regular" concept to floating-point
 types appears to be controversial (see long discussion on
 std-lib reflector).

- <td width="466">
+ <td>
 State that the “Regular” concept does not
 apply to floating-point types.

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

 Recommend that we handle the same as JP 33.<tr valign="top">
- <td width="29">
+ <td>
 JP 34

- <td width="75">
+ <td>
 20.2

- <td width="31">
+ <td>
 
 1st para, 4th line

 

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

- <td width="375">
+ <td>
 
 Though N2672 pointed at adding
 "#include<initializer_list>", it isn't reflected.

- <td width="466">
+ <td>
 add
 followings

 
 #include <initializer_list> // for concept_map

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

 Agree that the omission of <code>#include
@@ -3606,73 +3606,73 @@
 header includes another anywhere else in the standard. However, the paper
 that was voted in explicitly did make that guarantee. Removing that
 guarantee is beyond the scope of this review.<tr valign="top">
- <td width="29">
+ <td>
 US 67

- <td width="75">
+ <td>
 20.2.1

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

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

- <td width="375">
+ <td>
 Some connective words are missing.

- <td width="466">
+ <td>
 Insert “corresponding to” before “an
 lvalue reference type.”

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

 Yes. Forward to project editor.<tr valign="top">
- <td width="29">
+ <td>
 JP 35

- <td width="75">
+ <td>
 20.2.3

- <td width="31">
+ <td>
 
 6th para, 1st line

 

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

- <td width="375">
+ <td>
 
 Typo,

 "stdforward" should be
 "std::forward"

- <td width="466">
+ <td>
 Correct typo.

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

 Yes. Forward to project editor.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 202

- <td width="75">
+ <td>
 20.2.4

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

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

- <td width="375">
+ <td>
 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
@@ -3680,54 +3680,54 @@

 

- <td width="466">
+ <td>
 Remove the std:: qualification from these
 references to pair.

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

 Yes. Forward to project editor.<tr valign="top">
- <td width="29">
+ <td>
 US 68

- <td width="75">
+ <td>
 20.2.12

- <td width="31">
+ <td>
 IntegralLike

- <td width="38">
+ <td>
 te/ed

- <td width="375">
+ <td>
 The code defining the context is syntactically
 incorrect.

- <td width="466">
+ <td>
 Insert a comma in two places: at the end of the third
 line of refinements, and at the end of the fourth line of
 refinements.

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

 Editorial. The correct section is 20.1.12, not 20.2.12. Forward to project
 editor.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 203

- <td width="75">
+ <td>
 20.3.2

- <td width="31">
+ <td>
 1-4

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

- <td width="375">
+ <td>
 The ratio_xyz
 types have a misplaced '}'. For example: template <class
 R1, class R2> struct ratio_add { typedef see below}
@@ -3735,60 +3735,60 @@

 

- <td width="466">
+ <td>
 Move the '}' to after the typedef: template
 <class R1, class R2> struct ratio_add { typedef see
 below type; };

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

 Yes. Forward to project editor.<tr valign="top">
- <td width="29">
+ <td>
 JP 36

- <td width="75">
+ <td>
 20.4.2.1

- <td width="31">
+ <td>
 
 19th para, 6th line

 

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

- <td width="375">
+ <td>
 
 Typo.

 "it
 it" should be "it is"

- <td width="466">
+ <td>
 
 Correct typo.

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

 Yes. Forward to project editor.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 204

- <td width="75">
+ <td>
 20.5

- <td width="31">
+ <td>
 Table 41

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

- <td width="375">
+ <td>
 It is not
 possible to create a variant union based on a parameter
 pack expansion, e.g. to implement a classic discriminated
@@ -3796,53 +3796,53 @@

 

- <td width="466">
+ <td>
 Restore aligned_union template that was
 removed by LWG issue 856.

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

 Agree that aligned_union is not completely redundant. We are investigating
 whether the need for aligned_union is compelling enough to reinstate.<tr valign="top">
- <td width="29">
+ <td>
 US 69

- <td width="75">
+ <td>
 20.5

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

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

- <td width="375">
+ <td>
 This section, dealing with tuple<>, should be in
 the same section as the similar utility pair<>.

- <td width="466">
+ <td>
 Restructure Clause 20 so as to bring these similar
 components together.

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

 Editorial (effective duplicate of UK 198). Forward to project editor.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 205

- <td width="75">
+ <td>
 20.5.3

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

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

- <td width="375">
+ <td>
 
 integral_constant objects should be usable in
 integral-constant-expressions. The addition to the language
@@ -3851,30 +3851,30 @@

 

- <td width="466">
+ <td>
 Add a constexpr conversion operator to
 class tempalate integral_constant: constexpr operator
 value_type() { return value; }

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

 Agree: Add a constexpr conversion operator to class template
 integral_constant: <code>constexpr operator value_type() { return value; }</code><tr valign="top">
- <td width="29">
+ <td>
 UK 
 206

- <td width="75">
+ <td>
 20.5.5

- <td width="31">
+ <td>
 para 4

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

- <td width="375">
+ <td>
 Currently the
 std says: "In order to instantiate the template
 is_convertible<From, To>, the following code shall be
@@ -3884,7 +3884,7 @@

 

- <td width="466">
+ <td>
 Change: "In order to instantiate the
 template is_convertible<From, To>, the following code
 shall be well formed:" To: "The template
@@ -3892,31 +3892,31 @@
 indirectly from true_type if the following code is well
 formed:"

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

 Agree with the proposed resolution: Section 20.5.5, Change: "In order to
 instantiate the template is_convertible<From, To>, the following code shall
 be well formed:" To: "The template is_convertible<From, To> inherits either
 directly or indirectly from true_type if the following code is well formed:"<tr valign="top">
- <td width="29">
+ <td>
 UK 
 207

- <td width="75">
+ <td>
 20.5.6.1

- <td width="31">
+ <td>
 Table 36

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

- <td width="375">
+ <td>
 suffix "::type" is missing from the some of
 the examples.

- <td width="466">
+ <td>
 Change:
 Example:remove_const<const volatile int>::type
 evaluates to volatile int, whereas remove_const<const
@@ -3940,24 +3940,24 @@

 

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

 We tend to agree. Forward to project editor. Also recommend that the word
 "is" be replaced with "evaluates to" in the same text.<tr valign="top">
- <td width="29">
+ <td>
 JP 37

- <td width="75">
+ <td>
 20.5.7

- <td width="31">
+ <td>
 Table 41

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

- <td width="375">
+ <td>
 
 Typo.

@@ -3987,31 +3987,31 @@

 

- <td width="466">
+ <td>
 Add
 ”.”

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

 Agree. Forward to project editor.<tr valign="top">
- <td width="29">
+ <td>
 US 70

- <td width="75">
+ <td>
 20.6

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

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

- <td width="375">
+ <td>
 Specifications now expressed via narrative text are more
 accurately and clearly expressed via executable code.

- <td width="466">
+ <td>
 Wherever
 concepts are available that directly match this
@@ -4023,50 +4023,50 @@

 

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

 (The correct reference is section 20.5, not 20.6) We think that this is a
 good idea, but it requires a lot of work. If someone submits a paper
 proposing specific changes, we would be happy to review it at the next
 meeting.<tr valign="top">
- <td width="29">
+ <td>
 US 71

- <td width="75">
+ <td>
 20.6.7

- <td width="31">
+ <td>
 Table 51, last row, column 3

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

- <td width="375">
+ <td>
 The grammar is incorrect.

- <td width="466">
+ <td>
 Change “conversion are” to “conversion
 is”.

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

 (The correct reference is section 20.5.7, table 41, last row). Agree:
 Forward to project editor. There are several ways to fix the grammar.<tr valign="top">
- <td width="29">
+ <td>
 JP 38

- <td width="75">
+ <td>
 20.6.12.1.3

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

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

- <td width="375">
+ <td>
 
 add the move requirement for bind's return type. 
@@ -4100,7 +4100,7 @@
 
 

- <td width="466">
+ <td>
 Add
 the following requirements. 
 "it has a public move constructor
@@ -4109,7 +4109,7 @@
 Add
 the MoveConstructible.

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

 We were not clear about what the submitter really intended. Requiring that
@@ -4120,23 +4120,23 @@
 that makes it clear that move-only types can be Returnable.] </t>

 <tr valign="top">
- <td width="29">
+ <td>
 JP 39

- <td width="75">
+ <td>
 20.6.16.2

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

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

- <td width="375">
+ <td>
 
 There are no requires corresponding to F of std::function.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -4187,32 +4187,32 @@

 

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

 Agree with one correction: CopyConstructible?
 should be ConstructibleWithAllocator?
 . Pablo to supply wording. Also check with Howard that omission was not
 deliberate.<tr valign="top">
- <td width="29">
+ <td>
 JP 40

- <td width="75">
+ <td>
 20.6.16.2

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

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

- <td width="375">
+ <td>
 
 Thougn it's "Allocator Aloc" at other places, it's
 "Allocator A" only std::function constructor template
 parameter.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -4246,28 +4246,28 @@
 
 

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

 Agree, though minor. Forward to project editor (who may disregard).<tr valign="top">
- <td width="29">
+ <td>
 JP 41

- <td width="75">
+ <td>
 20.6.16.2

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

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

- <td width="375">
+ <td>
 
 There are no requires corresponding to R and Args of
 UsesAllocator.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -4305,24 +4305,24 @@

 }

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

 This change would be redundant because function<> is already sufficiently
 constrained. No actions necessary.<tr valign="top">
- <td width="29">
+ <td>
 JP 42

- <td width="75">
+ <td>
 20.6.16.2

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

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

- <td width="375">
+ <td>
 The requires
 are wrong.
@@ -4332,7 +4332,7 @@
 by a definition of function, then it's a mistake to
 designate followings by MoveConstructible.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -4432,58 +4432,58 @@
 
 

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

 As with JP 41, these constraints are redundant given that function<> is
 already constrained. So we recommend changing each occurence of "MoveConstructible"
 to "class". Note: this issue is also present in func.wrap.func.nullptr.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 208

- <td width="75">
+ <td>
 20.6.17

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 std::hash should
 be implemented for much more of the standard library. In
 particular for pair, tuple and all the standard containers.

 

- <td width="466">
+ <td>
 .

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

 Consensus is that this is an expansion of the scope of C++0X and so we
 recommend no action.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 209

- <td width="75">
+ <td>
 20.7

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

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

- <td width="375">
+ <td>
 Smart pointers cannot be used in
 constrained templates

- <td width="466">
+ <td>
 Provide
 constraints for smart pointers

@@ -4491,25 +4491,25 @@

 

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

 We look forward to a paper on this topic. We recommend no action until a
 paper is available. We understand that a paper is forthcoming.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 213

- <td width="75">
+ <td>
 20.7.6

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

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

- <td width="375">
+ <td>
 std::allocator
 should be constrained to simplify its use on constrained
 contexts. This library component models allocation from
@@ -4521,63 +4521,63 @@

 

- <td width="466">
+ <td>
 The primary allocator template should be
 constrained to require ObjectType<T> and
 FreeStoreAllocatable<T>. Further operations to be
 constrained as required.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 214

- <td width="75">
+ <td>
 20.7.8

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

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

- <td width="375">
+ <td>
 
 raw_storage_iterator needs constraining as an iterator
 adaptor to be safely used in constrained templates

 

- <td width="466">
+ <td>
 Constrain the raw_storage_iterator template

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

 We look forward to a paper on this topic. We recommend no action until a
 paper is available.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 210

- <td width="75">
+ <td>
 20.7.11

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

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

- <td width="375">
+ <td>
 Specialized algorithms for memory
 managenment need requirements to be easily usable in
 constrained templates

- <td width="466">
+ <td>
 Provide
 constraints for all algorithms in 20.7.11

@@ -4585,104 +4585,104 @@

 

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

 We look forward to a paper on this topic. We recommend no action until a
 paper is available.<tr valign="top">
- <td width="29">
+ <td>
 DE-20

- <td width="75">
+ <td>
 20.7.12

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

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

- <td width="375">
+ <td>
 DE-20 The section heading and the first sentence use the
 term "template function", which is undefined.

- <td width="466">
+ <td>
 Replace
 "template function" by "function template".

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 72

- <td width="75">
+ <td>
 20.7.12

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

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

- <td width="375">
+ <td>
 
 bind should support move-only functors and bound arguments.

 

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

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

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

- <td width="75">
+ <td>
 20.7.12.1.3

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

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

- <td width="375">
+ <td>
 DE-21 The specification for bind claims twice that "the
 values and types for the bound arguments v1, v2, ..., vN
 are determined as specified below". No such specification
 appears to exist.

- <td width="466">
+ <td>
 Add the missing specification in the same section, or
 add a cross-reference indicating the section where the
 specification appears.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 211

- <td width="75">
+ <td>
 20.7.12.2.3

- <td width="31">
+ <td>
 11

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

- <td width="375">
+ <td>
 The nullptr_t
 type was introduced to resolve the null pointer literal
 problem. It should be used for the assignemnt operator, as
@@ -4690,29 +4690,29 @@

 

- <td width="466">
+ <td>
 Change signature here and in the synopsis
 to: unique_ptr& operator=(nullptr_t); Strike the
 sentance an note before the Effects clause.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 212

- <td width="75">
+ <td>
 20.7.13.7

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

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

- <td width="375">
+ <td>
 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
@@ -4722,55 +4722,55 @@

 

- <td width="466">
+ <td>
 Move this specification to 18.5. Move the
 declarations into the header <new>.

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

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

- <td width="75">
+ <td>
 20.7.16.2

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

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

- <td width="375">
+ <td>
 DE-22 The conditions for deriving from
 std::unary_function and std::binary_function are unclear:
 The condition would also be satisfied if ArgTypes were
 std::vector<T1>, because it (arguably) "contains" T1.

- <td width="466">
+ <td>
 Consider stating the conditions in normative prose
 instead of in comments in the class definition. Use
 "consists of" instead of "contains". Consider using "if and
 only if" instead of "iff".

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 73

- <td width="75">
+ <td>
 20.7.18

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

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

- <td width="375">
+ <td>
 The
 std::reference_closure template is redundant with
 std::function and should be removed.
@@ -4803,7 +4803,7 @@

 

- <td width="466">
+ <td>
 Remove 20.7.18
 [func.referenceclosure].

@@ -4811,23 +4811,23 @@

 Remove 5.1.1 paragraph 12.

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 74

- <td width="75">
+ <td>
 20.8

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

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

- <td width="375">
+ <td>
 Scoped
 allocators represent a poor trade-off for standardization,
 since (1) scoped-allocator--aware containers can be
@@ -4855,7 +4855,7 @@

 

- <td width="466">
+ <td>
 Remove support
 for scoped allocators from the working paper. This includes
 at least the following changes:
@@ -4885,79 +4885,79 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 74

- <td width="75">
+ <td>
 20.8.2.2

- <td width="31">
+ <td>
 (a) synopsis (b) after ¶ 14

- <td width="38">
+ <td>
 te/ed

- <td width="375">
+ <td>
 A concept name is twice misspelled.

- <td width="466">
+ <td>
 Change “Hasconstructor” to
 “HasConstructor” (twice).

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 75

- <td width="75">
+ <td>
 20.8.2.2

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

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

- <td width="375">
+ <td>
 Allocator concepts are incomplete

- <td width="466">
+ <td>
 See paper:
 http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 43

- <td width="75">
+ <td>
 20.8.3

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

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

- <td width="375">
+ <td>
 
 Typo.

 
 "alloc" should be "Alloc"

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -4997,50 +4997,50 @@
 
 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 215

- <td width="75">
+ <td>
 20.8.3.3

- <td width="31">
+ <td>
 6,8

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

- <td width="375">
+ <td>
 Extra pair of
 {}, presumably some formatting code gone awry :
 duration& operator-{-}();

 

- <td width="466">
+ <td>
 Remove the {} or fix formatting

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 77

- <td width="75">
+ <td>
 20.8.4

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

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

- <td width="375">
+ <td>
 
 Allocator-specific move and copy behavior for containers
 (N2525) complicates a little-used and already-complicated
@@ -5064,7 +5064,7 @@

 

- <td width="466">
+ <td>
 Remove 20.8.4.

 
@@ -5076,30 +5076,30 @@
 Remove all references to the facilities in
 20.8.4 and 20.8.5 from clause 23.

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 78

- <td width="75">
+ <td>
 20.8.12, 
 20.8.13.2

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

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

- <td width="375">
+ <td>
 There is presently no way to
 convert directly from a <code>shared_ptr</code> to a
 <code>unique_ptr</code>.

- <td width="466">
+ <td>
 Add
 an interface that performs the conversion. See the
 attached, Issues with the C++ Standard" paper under Chapter
@@ -5109,23 +5109,23 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 79

- <td width="75">
+ <td>
 20.8.12.2.1

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

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

- <td width="375">
+ <td>
 
 [unique.ptr.single.ctor]/5 no longer requires for D not to
 be a pointer type.  This restriction needs to be put
@@ -5148,26 +5148,26 @@

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 44

- <td width="75">
+ <td>
 20.8.13.6

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

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

- <td width="375">
+ <td>
 The
 1st parameter p and 2nd parameter v is now
 shared_ptr<T> *.
@@ -5177,28 +5177,28 @@
 shared_ptr<T>* then add the "p shall not be a null
 pointer" at the requires.

- <td width="466">
+ <td>
 
 Change shared_ptr<T>& or add the "p shall not be
 a null pionter" at the requires.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 45

- <td width="75">
+ <td>
 20.9

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

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

- <td width="375">
+ <td>
 
 Rep, Period, Clock and Duration don't correspond to
 concept.
@@ -5215,32 +5215,32 @@
 
 

- <td width="466">
+ <td>
 
 Make concept for Rep, Period, Clock and Duration, and fix
 20.9 and wait_until and wait_for's template parameter at
 30.

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 80

- <td width="75">
+ <td>
 20.9.2.1

- <td width="31">
+ <td>
 Heading

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

- <td width="375">
+ <td>
 The section heading does not describe the contents.

- <td width="466">
+ <td>
 Change the
 heading “

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 81

- <td width="75">
+ <td>
 20.9.3

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

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

- <td width="375">
+ <td>
 
 chrono::duration is missing the modulous operator for both
 member and non-member arithmetic. This operator is useful
@@ -5308,7 +5308,7 @@

 

- <td width="466">
+ <td>
 Add:

 
@@ -5368,77 +5368,77 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 82

- <td width="75">
+ <td>
 20.9.5.3

- <td width="31">
+ <td>
 after ¶ 1

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

- <td width="375">
+ <td>
 The code synopsis has a minor alignment error.

- <td width="466">
+ <td>
 Align “rep” with the other symbols defined
 in this synopsis.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 216

- <td width="75">
+ <td>
 21

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

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

- <td width="375">
+ <td>
 All the containers use concepts for their
 iterator usage, exect for basic_string. This needs fixing.

- <td width="466">
+ <td>
 Use concepts for iterator template
 parameters throughout the chapter.

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

 NB comments to be handled by Dave Abrahams and Howard Hinnant with advice
 from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies extensive
 proposed wording; start there.<tr valign="top">
- <td width="29">
+ <td>
 JP 46

- <td width="75">
+ <td>
 21.2, 21.3

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

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

- <td width="375">
+ <td>
 The
 basic_string does not use concept.

- <td width="466">
+ <td>
 The
 "class Alloc" is changed to "Allocator Alloc".

@@ -6432,23 +6432,23 @@
 
 

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

 See UK 216<tr valign="top">
- <td width="29">
+ <td>
 JP 47

- <td width="75">
+ <td>
 21.3

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

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

- <td width="375">
+ <td>
 
 Typo. Missing ”>”

@@ -6469,27 +6469,27 @@

 

- <td width="466">
+ <td>
 
 Correct typo.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 48

- <td width="75">
+ <td>
 21.3

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

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

- <td width="375">
+ <td>
 
 char_traits does not use concept.

@@ -6513,33 +6513,33 @@
 
 

- <td width="466">
+ <td>
 Add
 a concept for char_traits.

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

 See UK 216<tr valign="top">
- <td width="29">
+ <td>
 UK 
 217

- <td width="75">
+ <td>
 21.3

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

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

- <td width="375">
+ <td>
 basic_string refers to
 constructible_with_allocator_suffix, which I thought was
 removed?

- <td width="466">
+ <td>
 Remove the
 lines: template <class charT, class traits, class Alloc
 struct constructible_with_allocator_suffix<
@@ -6548,24 +6548,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 218

- <td width="75">
+ <td>
 21.3.1

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

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

- <td width="375">
+ <td>
 The identity
 "&*(s.begin() + n) == &*s.begin() + n" relies on
 operator& doing the "right thing", which (AFAICS) there
@@ -6576,57 +6576,57 @@

 

- <td width="466">
+ <td>
 See my recommendations for "23.2.1,
 23.2.6".

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

 NAD, we think. basic_string elements have to be POD and PODs may not have
 overloaded operator&. Need to check whether this is true in light of relaxed
 POD constraints.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 219

- <td width="75">
+ <td>
 21.3.6.6 
 [string. 
 replace]

- <td width="31">
+ <td>
 11

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

- <td width="375">
+ <td>
 Effects refers to "whose first begin() - i1
 elements" However i1 is greater than begin()...

- <td width="466">
+ <td>
 Effects refers to "whose first i1 - begin()
 elements"

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 220

- <td width="75">
+ <td>
 21.3.8.9

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

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

- <td width="375">
+ <td>
 The
 operator<< for basic_string takes the output stream
 by r-value reference. This is different from the same
@@ -6636,32 +6636,32 @@

 

- <td width="466">
+ <td>
 Use the same reference type for the all the
 library types. This should be the r-value reference. There
 are other places in the standard where TR1, and new
 classes, did not receive an 'R-value' update.

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

 We did it differently for basic_string because otherwise rvalue strreaming
 was producing confusing results with strings, but this difference will be
 fixed by N2831 if it's accepted.<tr valign="top">
- <td width="29">
+ <td>
 FR 33

- <td width="75">
+ <td>
 22.1.1 
 [locale]

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

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

- <td width="375">
+ <td>
 ios_base::iostate err = 0;

 
@@ -6671,26 +6671,26 @@

 goodbit is the solution.

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 49

- <td width="75">
+ <td>
 22.1.3.2.2

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

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

- <td width="375">
+ <td>
 
 codecvt does not use concept. For example, create
 CodeConvert concept and change as follows.
@@ -6699,32 +6699,32 @@
 template<CodeConvert Codecvt, class Elem =
 wchar_t> class wstring_convert {

- <td width="466">
+ <td>
 Add
 a concept for codecvt.

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

 to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
- <td width="29">
+ <td>
 JP 50

- <td width="75">
+ <td>
 22.1.3.2.2

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

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

- <td width="375">
+ <td>
 Add
 custom allocator parameter to wstring_convert, since we
 cannot allocate memory for strings from a custom allocator.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -6778,49 +6778,49 @@
 
 

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

 to be handled by PJ Plaugher<tr valign="top">
- <td width="29">
+ <td>
 FI 4

- <td width="75">
+ <td>
 22.2.1.4.1

 22.2.1.4.2

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

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

- <td width="375">
+ <td>
 <tt>to_end and to_limit are both used. Only one is
 needed.</tt>

- <td width="466">
+ <td>
 Change to_limit to to_end.

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

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

- <td width="75">
+ <td>
 <tt>22.2.1.4.2</tt>

- <td width="31">
+ <td>
 #3

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

- <td width="375">
+ <td>
 <tt>[ Note: As
 a result of operations on state, it can return ok or
@@ -6847,21 +6847,21 @@
 from_next is unaltered, to_next is advanced, state is
 altered and return value is partial.</tt>

- <td width="466">
+ <td>
 <tt>[ Note: As a result of operations on state, do_in
 and do_out can return</tt> 
 <tt>ok or partial and set from_next == from and/or to_next
 != to. —end</tt> 
 <tt>note ]</tt>

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

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

- <td width="75">
+ <td>
 22.2.1.5

@@ -6869,13 +6869,13 @@
 22.2.1.4 
 (1,2,3)

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

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

- <td width="375">
+ <td>
 
 <tt>codecvt_byname is only specified to work with locale
@@ -6893,29 +6893,29 @@

 

- <td width="466">
+ <td>
 <tt>There should be a built-in means to find a codecvt
 with a pair of character set names.</tt>

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

 Martin Sebor interested in solving this problem (also POSIX group), but
 addressing it controversial because it's probably too late in the process
 for what looks like a new feature.<tr valign="top">
- <td width="29">
+ <td>
 FI 7

- <td width="75">
+ <td>
 22.2.1.4

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

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

- <td width="375">
+ <td>
 The word
 "codeset" is used, whereas the word "character set" is used
@@ -6925,28 +6925,28 @@

 

- <td width="466">
+ <td>
 Change "codeset" to "character set."

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 51

- <td width="75">
+ <td>
 22.2.5.1.1

- <td width="31">
+ <td>
 7th para, 1st
 line

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

- <td width="375">
+ <td>
 A
 parameter `end’ should be `fmtend’. 
 get() function had two `end’ parameters at N2321.
@@ -6964,7 +6964,7 @@
 
 

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -6984,29 +6984,29 @@
 
 Requires: [fmt,fmtend) shall be a valid range.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 52

- <td width="75">
+ <td>
 22.2.5.1, 
 22.2.5.2, 
 22.2.6.1

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

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

- <td width="375">
+ <td>
 
 InputIterator does not use concept.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -7175,28 +7175,28 @@

 

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

 to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
- <td width="29">
+ <td>
 JP 53

- <td width="75">
+ <td>
 22.2.5.3 , 
 22.2.5.4

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

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

- <td width="375">
+ <td>
 
 OutputIterator does not use concept.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -7309,57 +7309,57 @@
 typedef OutputIter
 iter_type;

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

 to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
- <td width="29">
+ <td>
 JP 54

- <td width="75">
+ <td>
 23

- <td width="31">
+ <td>
 
 2nd para, Table 79

 

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

- <td width="375">
+ <td>
 
 There is not <forward_list> in Table 79.

- <td width="466">
+ <td>
 Add
 <forward_list> between <deque> and
 <list>.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 221

- <td width="75">
+ <td>
 23

- <td width="31">
+ <td>
 Table 79

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

- <td width="375">
+ <td>
 The table is missing the new
 <forward_list> header.

- <td width="466">
+ <td>
 Add
 <forward_list> to the table for sequence containers.
 Alternative (technical) solution might be to merge
@@ -7367,24 +7367,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 222

- <td width="75">
+ <td>
 23

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

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

- <td width="375">
+ <td>
 It is not clear
 what purpose the Requirement tables serve in the Containers
 clause. Are they the definition of a library Container? Or
@@ -7401,7 +7401,7 @@

 

- <td width="466">
+ <td>
 Clarify all the tables in 23.1 are there as
 a convenience for documentation, rather than a strict set
 of requirements. Containers should be allowed to relax
@@ -7412,55 +7412,55 @@
 not provide the required size operation as it cannot be
 implemented efficiently.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 55

- <td width="75">
+ <td>
 23.1.1

- <td width="31">
+ <td>
 
 3rd para, 4th line

 

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

- <td width="375">
+ <td>
 It
 seems that “the MinimalAllocator concep” is the
 typo of “the MinimalAllocator concept”.

- <td width="466">
+ <td>
 
 Change to … models the MinimalAllocator
 concept.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 223

- <td width="75">
+ <td>
 23.1.1

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

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

- <td width="375">
+ <td>
 The library does
 not define the MinimalAllocator or ScopedAllocator
 concepts, these were part of an earlier Allocators proposal
@@ -7468,34 +7468,34 @@

 

- <td width="466">
+ <td>
 Remove the references to MinimalAllocator
 and ScopedAllocator, or add definitions for these concepts
 to clause 20.7.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 224

- <td width="75">
+ <td>
 23.1.1

- <td width="31">
+ <td>
 8

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

- <td width="375">
+ <td>
 This paragraph implicitly requires all
 containers in clause 23 to support allocators, which
 std::array does not.

- <td width="466">
+ <td>
 Add an 'unless
 otherwise specified' rider somewhere in p8, or move the
 whole array container from clause 23 [containers] to clause
@@ -7503,24 +7503,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 225

- <td width="75">
+ <td>
 23.1.1

- <td width="31">
+ <td>
 Table 81

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

- <td width="375">
+ <td>
 Inconsistent
 words used to say the same thing. Table 80 describes
 iterator/const_iterator typedef as returning an "iterator
@@ -7531,29 +7531,29 @@

 

- <td width="466">
+ <td>
 Change return types for
 X::(const)_reverse_iterator to say "iterator type whose
 value type is (const) T".

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 226

- <td width="75">
+ <td>
 23.1.1

- <td width="31">
+ <td>
 10

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

- <td width="375">
+ <td>
 <array>
 must be added to this list. In particular it doesn't
 satisfy: - no swap() function invalidates any references,
@@ -7563,90 +7563,90 @@

 

- <td width="466">
+ <td>
 If <array> remains a container, this
 will have to also reference array, which will then have to
 say which of these points it satisfies.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 227

- <td width="75">
+ <td>
 23.1.1

- <td width="31">
+ <td>
 Table 80

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

- <td width="375">
+ <td>
 The post-condition for a = rv uses the word
 “construction” when it means
 “assignment”

- <td width="466">
+ <td>
 Replace the word
 “construction” with the word
 “assignment”

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 228

- <td width="75">
+ <td>
 23.1.1

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

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

- <td width="375">
+ <td>
 Line 4 contains
 a spelling mistake in the fragment "MinimalAllocator
 concep."

 

- <td width="466">
+ <td>
 Replace "concep" with "concept"

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 229

- <td width="75">
+ <td>
 23.1.1

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

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

- <td width="375">
+ <td>
 The fragment "A container may directly call
 constructors" is not technically correct as constructors
 are not callable.

- <td width="466">
+ <td>
 Replace "A
 container may directly call constructors and destructors
 for its stored objects" with something similar to "A
@@ -7655,24 +7655,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 230

- <td width="75">
+ <td>
 23.1.2

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 
 “implementations shall consider the following
 functions to be const” - what does this mean? I don't
@@ -7682,33 +7682,33 @@

 

- <td width="466">
+ <td>
 Clarify what is meant and what requirements
 an implementation must satisfy.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 56

- <td width="75">
+ <td>
 23.1.3

- <td width="31">
+ <td>
 12th para, Table 84

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

- <td width="375">
+ <td>
 
 `array’ is unstated in Table 84 - Optional sequence
 container operations.

- <td width="466">
+ <td>
 Add
 `array’ to Container field for the following
 Expression.
@@ -7725,84 +7725,84 @@
 a.at(n)

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 231

- <td width="75">
+ <td>
 23.1.3

- <td width="31">
+ <td>
 9-11

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

- <td width="375">
+ <td>
 These paragraphs
 are redundant now that Concepts define what it means to be
 an Iterator and guide overload resolution accordingly.

 

- <td width="466">
+ <td>
 Strike 23.1.3p9-11. Make sure
 std::basic_string has constraints similar to std::vector to
 meet this old guarantee.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 232

- <td width="75">
+ <td>
 23.1.3

- <td width="31">
+ <td>
 Table 84

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

- <td width="375">
+ <td>
 match_results
 may follow the requirements but is not listed a general
 purpose library container.

 

- <td width="466">
+ <td>
 Remove reference to match_results against
 a[n] operation

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 233

- <td width="75">
+ <td>
 23.1.3

- <td width="31">
+ <td>
 Table 84

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

- <td width="375">
+ <td>
 Add references to the new containers.

- <td width="466">
+ <td>
 Add reference to
 array to the rows for: a.front(), a. back(), a[n] a.at(n).
 Add reference to forward_list to the rows for: a.front(),
@@ -7812,24 +7812,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 234

- <td width="75">
+ <td>
 23.1.3

- <td width="31">
+ <td>
 Table 84

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

- <td width="375">
+ <td>
 Ther reference
 to iterator in semantics for back should also allow for
 const_iterator when called on a const-qualified container.
@@ -7838,34 +7838,34 @@

 

- <td width="466">
+ <td>
 Replace iterator with auto in semantics for
 back: { auto tmp = a.end(); --tmp; return *tmp; }

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 235

- <td width="75">
+ <td>
 23.1.3

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 “The library provides three basic
 kinds of sequence containers: vector, list, and
 deque” - text appears to be out of date re addition
 of array and forward_list

- <td width="466">
+ <td>
 Change the text
 to read: “The library provides five basic kinds of
 sequence containers: array, deque, forward_list, list and
@@ -7873,24 +7873,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 236

- <td width="75">
+ <td>
 23.1.3

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 [ 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
@@ -7907,32 +7907,32 @@

 

- <td width="466">
+ <td>
 Remove this paragraph

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 237

- <td width="75">
+ <td>
 23.1.3

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 vector, list, and deque offer the
 programmer different complexity trade-offs and should be
 used accordingly - this ignores array and forward_list

- <td width="466">
+ <td>
 Modify the text
 to read: "array, deque, forward_list, list and vector offer
 the programmer different complexity trade-offs and should
@@ -7940,24 +7940,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 238

- <td width="75">
+ <td>
 23.1.4

- <td width="31">
+ <td>
 6

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

- <td width="375">
+ <td>
 Leaving it
 unspecified whether or not iterator and const_iterator are
 the same type is dangerous, as user code may or may not
@@ -7970,7 +7970,7 @@

 

- <td width="466">
+ <td>
 Change 'unspecified' to 'implementation
 defined'. Add "[Note: As itererator and const_iterator have
 identical semantics in this case, and iterator is
@@ -7978,29 +7978,29 @@
 the One Definition Rule by always using const_iterator in
 their function parameter lists -- end note]

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 239

- <td width="75">
+ <td>
 23.1.4

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

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

- <td width="375">
+ <td>
 It is not possible to take a move-only key
 out of an unordered container, such as (multi)set or
 (multi)map, or the new hashed containers.

- <td width="466">
+ <td>
 Add below
 a.erase(q), a.extract(q), with the following notation:
 a.extract(q), Return type pair<key, iterator>
@@ -8012,24 +8012,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 240

- <td width="75">
+ <td>
 23.1.6.1

- <td width="31">
+ <td>
 12

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

- <td width="375">
+ <td>
 The axiom
 EmplacePushEquivalence should be asserting the stronger
 contract that emplace and insert return the same iterator
@@ -8044,7 +8044,7 @@

 

- <td width="466">
+ <td>
 Remove the * to deference the returned
 iterator either side of the == in the
 EmplacePushEquivalence axiom, rename the axiom
@@ -8055,110 +8055,110 @@
 position, Args... args) { emplace(c, position, args...) ==
 insert(c, position, value_type(args...)); }

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 57

- <td width="75">
+ <td>
 23.1.6.3

- <td width="31">
+ <td>
 
 1st para, 4th line

 

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

- <td width="375">
+ <td>
 
 Typo, duplicated "to"

 
 "to to model insertion container concepts."

- <td width="466">
+ <td>
 
 Remove one.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 241

- <td width="75">
+ <td>
 23.2.1

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

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

- <td width="375">
+ <td>
 std::array does
 not have an allocator, so need to document an exception to
 the requirements of 23.1.1p3

 

- <td width="466">
+ <td>
 add exception to 23.1.1p3

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 242

- <td width="75">
+ <td>
 23.2.1

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

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

- <td width="375">
+ <td>
 std:: qualification no longer needed for
 reverse_iterator.

- <td width="466">
+ <td>
 remove std::
 qualification from std::reverse_iterator<iterator>
 and std::reverse_iterator<const_iterator>

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 243

- <td width="75">
+ <td>
 23.2.1

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

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

- <td width="375">
+ <td>
 Most containers,
 and types in general have 3 swaps: swap(T&, T&)
 swap(T&&, T&) swap(T&, T&&) But
@@ -8166,28 +8166,28 @@

 

- <td width="466">
+ <td>
 add the other two swaps.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 244

- <td width="75">
+ <td>
 23.2.1, 
 23.2.6

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 The validity of
 the expression &a[n] == &a[0] + n is contingent on
 operator& doing the “right thing” (as
@@ -8200,7 +8200,7 @@

 

- <td width="466">
+ <td>
 Define a ContiguousStrorage and apply it to
 vector,array and string. The Concept (supplied by Alisdair
 M) looks like this: Concept< typename C >
@@ -8209,24 +8209,24 @@
 Contiguous { C c; true = equal_ranges( data( c), data(c) +
 size(c), begin(c)); } };

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 245

- <td width="75">
+ <td>
 23.2.3

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 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
@@ -8235,7 +8235,7 @@
 library specification in general. See earlier comment for
 details, that would render this one redundant.

- <td width="466">
+ <td>
 Add
 CopyConstructible requirement to the following signatures:
 template <Predicate<auto, T> Pred> requires
@@ -8255,59 +8255,59 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 58

- <td width="75">
+ <td>
 23.2.3.2

- <td width="31">
+ <td>
 
 1st line
 before 1st para

 

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

- <td width="375">
+ <td>
 
 Unnecessary "{" exists before a word iterator like
 "{iterator before_begin()".

- <td width="466">
+ <td>
 
 Remove "{"

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 59

- <td width="75">
+ <td>
 23.2.4.4

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

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

- <td width="375">
+ <td>
 
 Types of the third and forth parameter of splice() are
 iterator at 23.2.4.4, though types of them are
 const_iterator at 23.2.4. (They are both const_iterator on
 N2350)

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -8346,23 +8346,23 @@
 
 

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 83

- <td width="75">
+ <td>
 23.2.6.2

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

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

- <td width="375">
+ <td>
 
 "shrink_to_fint" should be "shrink_to_fit".

@@ -8371,27 +8371,27 @@

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 246

- <td width="75">
+ <td>
 23.3.2.2

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

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

- <td width="375">
+ <td>
 The content of
 this sub-clause is purely trying to describe in words the
 effect of the requires clauses on these operations, now
@@ -8402,29 +8402,29 @@

 

- <td width="466">
+ <td>
 Strike 23.3.2.2 entirely. (but do NOT
 strike these signatures from the class template
 definition!)

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 247

- <td width="75">
+ <td>
 24.1

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

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

- <td width="375">
+ <td>
 Iterator
 concepts are not extensive enough to merit a whole new
 header, and should be merged into <concpts>. This is
@@ -8436,30 +8436,30 @@

 

- <td width="466">
+ <td>
 Move the concepts of
 <iterator_concepts> into the <concepts> header.
 We take no position on moving the text from Clause 24 to
 Clause 20 though.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 248

- <td width="75">
+ <td>
 24.1

- <td width="31">
+ <td>
 6

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

- <td width="375">
+ <td>
 The text "so for
 any iterator type there is an iterator value that points
 past the last element of a corresponding container" is
@@ -8469,55 +8469,55 @@

 

- <td width="466">
+ <td>
 Replace the reference to container with a
 more appropriate concept

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 250

- <td width="75">
+ <td>
 24.1.1

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

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

- <td width="375">
+ <td>
 A default implementation should be supplied
 for the post-increment operator to simplify implementation
 of iterators by users.

- <td width="466">
+ <td>
 Copy the Effects clause into the concept
 description as the default implementation. Assumes a
 default value for postincrement_result

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 251

- <td width="75">
+ <td>
 24.1.1

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

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

- <td width="375">
+ <td>
 The
 post-increment operator is dangerous for a general
 InputIterator. The multi-pass guarantees that make it
@@ -8531,57 +8531,57 @@

 

- <td width="466">
+ <td>
 Move declaration of postincrement operator
 and postincrement_result type from Interator concept to the
 ForwardIterator concept

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 252

 

- <td width="75">
+ <td>
 24.1.2

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

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

- <td width="375">
+ <td>
 istream_iterator is not a class, but a
 class template

- <td width="466">
+ <td>
 Change 'class' to 'class template' in the
 note.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 253

- <td width="75">
+ <td>
 24.1.3

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 First sentance
 does not make gramatical sense, Seems to be missing the
 words 'if it' by comparison with similar sentance in other
@@ -8589,113 +8589,113 @@

 

- <td width="466">
+ <td>
 Add the words 'if it' : "X satisfies the
 requirements of an output iterator IF IT meets the
 syntactic and semantic requirements"

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 254

- <td width="75">
+ <td>
 24.1.3

- <td width="31">
+ <td>
 5

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

- <td width="375">
+ <td>
 This
 postcondition for pre-increment operator should be written
 as an axiom

 

- <td width="466">
+ <td>
 Move the postcondition into the concept
 definition as an axiom

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 255

- <td width="75">
+ <td>
 24.1.4

- <td width="31">
+ <td>
 4

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

- <td width="375">
+ <td>
 This
 postcondition for pre-increment operator should be written
 as an axiom

 

- <td width="466">
+ <td>
 Move the postcondition into the concept
 definition as an axiom

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 256

- <td width="75">
+ <td>
 24.1.5

- <td width="31">
+ <td>
 3, 4, 5

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

- <td width="375">
+ <td>
 The relationship between pre- and post-
 decrement should be expressed as an axiom.

- <td width="466">
+ <td>
 Move the text
 specification of pre/post-conditions and behaviour into an
 axiom within the BidirectionalIterator concept

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 257

- <td width="75">
+ <td>
 24.1.5

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

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

- <td width="375">
+ <td>
 There is a
 reasonable default for postdecrement_result type, which is
 X. X is required to be regular, therefore CopyConstructible
@@ -8704,57 +8704,57 @@

 

- <td width="466">
+ <td>
 Add the default : typename
 postincrement_result = X;

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 258

- <td width="75">
+ <td>
 24.1.5

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

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

- <td width="375">
+ <td>
 A default
 implementation should be supplied for the post-decrement
 operator to simplify implementation of iterators by users.

 

- <td width="466">
+ <td>
 Copy the Effects clause into the concept
 description as the default implementation. Assumes a
 default value for postincrement_result

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 259

- <td width="75">
+ <td>
 24.1.5

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

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

- <td width="375">
+ <td>
 
 postdecrement_result is effectively returning a copy of the
 original iterator value, so should have similar
@@ -8764,34 +8764,34 @@

 

- <td width="466">
+ <td>
 Add the requirement: requires Iterator<
 postdecrement_result >;

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 260

- <td width="75">
+ <td>
 24.1.5

- <td width="31">
+ <td>
 6

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

- <td width="375">
+ <td>
 The effects clause for post-decrement
 iterator should be available as an axiom and a default
 implementation, where the compiler can make better use of
 it.

- <td width="466">
+ <td>
 Move the Effects
 clause into the BidirectionalIterator concept definition as
 an axiom, and as the default implementation for the
@@ -8799,25 +8799,25 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 249

- <td width="75">
+ <td>
 24.1.6

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 The semantic for
 operator+= should also be provided as a default
 implementation to simplify implementation of user-defined
@@ -8825,61 +8825,61 @@

 

- <td width="466">
+ <td>
 Copy the text from the effects clause into
 the RandomAccessIterator concept as the default
 implementaiton.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 261

- <td width="75">
+ <td>
 24.1.6

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

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

- <td width="375">
+ <td>
 To simplify user
 defined random access iterator types, the
 subscript_reference type should default to reference

 

- <td width="466">
+ <td>
 typename subscript_reference = reference;

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 262

- <td width="75">
+ <td>
 24.1.6

- <td width="31">
+ <td>
 3, 4

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

- <td width="375">
+ <td>
 Effects and post-conditions for operator+
 are more useful if expressed as axioms, and supplied as
 default implementations.

- <td width="466">
+ <td>
 Move the effects
 and Postcondition definitions into the RandomAccessIterator
 concept and copy the code in the specification as the
@@ -8887,29 +8887,29 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 263

- <td width="75">
+ <td>
 24.1.6

- <td width="31">
+ <td>
 5

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

- <td width="375">
+ <td>
 This requirement on operator-= would be
 better expressed as a default implementation in the
 concept, with a matching axiom

- <td width="466">
+ <td>
 Move the
 specification for operator-= from the returns clause into
 an axiom and default implementation within the
@@ -8917,52 +8917,52 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 264

- <td width="75">
+ <td>
 24.1.6

- <td width="31">
+ <td>
 6

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

- <td width="375">
+ <td>
 Effects clauses are better expressed as
 axioms where possible.

- <td width="466">
+ <td>
 Move code in
 operator- effects clause into RandomAccessIterator concept
 as both a default implementation and an axiom

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 265

- <td width="75">
+ <td>
 24.1.6

- <td width="31">
+ <td>
 8

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

- <td width="375">
+ <td>
 This effects
 clause is nonesense. It looks more like an axiom stating
 equivalence, and certainly an effects clause cannot change
@@ -8970,31 +8970,31 @@

 

- <td width="466">
+ <td>
 Strike the Effects clause

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 266

- <td width="75">
+ <td>
 24.1.6

- <td width="31">
+ <td>
 9

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

- <td width="375">
+ <td>
 This sentance should be provided as a
 default definition, along with a matching axiom

- <td width="466">
+ <td>
 Move the Returns
 clause into the spefication for RandomAccessIterator
 operator- as a default implementation. Move the Effects
@@ -9002,52 +9002,52 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 267

- <td width="75">
+ <td>
 24.1.6

- <td width="31">
+ <td>
 24.1.6

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

- <td width="375">
+ <td>
 The code in the
 Requires clause for RandomAccessIterator operator[] would
 be better expressed as an axiom.

 

- <td width="466">
+ <td>
 Rewrite the Requires clause as an axiom in
 the RandomAccessIterator concept

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 268

- <td width="75">
+ <td>
 24.1.6

- <td width="31">
+ <td>
 12

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

- <td width="375">
+ <td>
 This note is
 potentialy confusing as __far enters the syntax as a clear
 language extension, but the note treats it as a regular
@@ -9056,29 +9056,29 @@

 

- <td width="466">
+ <td>
 Clean up the note to either avoid using
 language extension, or spell out this is a constraint to
 support extensions.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 60

- <td width="75">
+ <td>
 24.1.8

- <td width="31">
+ <td>
 1st para

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

- <td width="375">
+ <td>
 
 Capability of an iterator is too much restricted by
 concept.
@@ -9250,85 +9250,85 @@
 
 

- <td width="466">
+ <td>
 Add
 InputRange, OutputRange, ForwardRange, BidirectionalRange
 and RandomAccessRange.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 269

- <td width="75">
+ <td>
 24.3

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

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

- <td width="375">
+ <td>
 'decrements for
 negative n' seems to imply a negative number of decrement
 operations, which is odd.

 

- <td width="466">
+ <td>
 Need simple, clearer wording

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 270

- <td width="75">
+ <td>
 24.3

- <td width="31">
+ <td>
 4

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

- <td width="375">
+ <td>
 The reachability
 constraint in p5 means that a negavite result, implying
 decrements operations in p4, is not possible

 

- <td width="466">
+ <td>
 Split the two overloads into separate
 descriptions, where reachability is permitted to be in
 either direction for RandomAccessIterator

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 271

- <td width="75">
+ <td>
 24.3

- <td width="31">
+ <td>
 6,7

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

- <td width="375">
+ <td>
 next/prev return
 an incremented iterator without changing the value of the
 original iterator. However, even this may invalidate an
@@ -9337,28 +9337,28 @@

 

- <td width="466">
+ <td>
 Replace InputIterator constraint with
 FOrwardIterator in next and prev function templates.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 272

- <td width="75">
+ <td>
 24.4

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

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

- <td width="375">
+ <td>
 reverse_iterator
 and move_iterator use different formulations for their
 comparison operations. move_iterator merely requires the
@@ -9377,29 +9377,29 @@

 

- <td width="466">
+ <td>
 Rephrase the reverse_iterator comparison
 operations using only operators < and ==, as per the
 move_iterator specification.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 274

- <td width="75">
+ <td>
 24.4, 24.5

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

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

- <td width="375">
+ <td>
 The subclauses
 for standard iterator adaptors could be better organised.
 There are essentially 3 kinds of iterator wrappers
@@ -9412,30 +9412,30 @@

 

- <td width="466">
+ <td>
 Promote 24.4.2 [insert.iterators] up one
 level to 24.6. Emphasize that insert iterators adapt
 containers Retarget 24.4 [predef.iterators] as iterator
 adapters for iterator templates that wrap other iterators.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 275

- <td width="75">
+ <td>
 24.4.1.1

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

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

- <td width="375">
+ <td>
 The constructor
 template taking a single Iterator argument will be selected
 for Copy Initialization instead of the non-template
@@ -9444,28 +9444,28 @@

 

- <td width="466">
+ <td>
 The reverse_iterator template constructor
 taking a single Iterator argument should be explicit.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 276

- <td width="75">
+ <td>
 24.4.1.1

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

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

- <td width="375">
+ <td>
 It is odd to
 have a mix of declaration stlyes for operator+ overloads.
 Prefer if either all are member functions, or all are
@@ -9473,28 +9473,28 @@

 

- <td width="466">
+ <td>
 Make the member operators taking a
 difference_type argument non-member operators

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 277

- <td width="75">
+ <td>
 24.4.1.2.1

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 The default
 constructor default-initializes current, rather than
 value-initializes. This means that when Iterator
@@ -9507,7 +9507,7 @@

 

- <td width="466">
+ <td>
 i/ Specify value initialization rather than
 default intialization or ii/ specify = default; rather than
 spell out the semantic. This will at least allow users to
@@ -9515,24 +9515,24 @@
 iii/ Add a note to the description emphasizing the singular
 nature of a value-initialized reserve iterator.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 278

- <td width="75">
+ <td>
 24.4.1.2.1

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

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

- <td width="375">
+ <td>
 There is an
 inconsistency between the constructor taking an iterator
 and the constructor template taking a reverse_iterator
@@ -9542,29 +9542,29 @@

 

- <td width="466">
+ <td>
 Change the const reverse_iterator
 & parameter to pass-by-value

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 279

- <td width="75">
+ <td>
 24.4.1.2.12, 
 24.4.3.2.12

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

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

- <td width="375">
+ <td>
 The reason the
 return type became unspecified is LWG issue 386. This
 reasoning no longer applies as there are at least two ways
@@ -9573,28 +9573,28 @@

 

- <td width="466">
+ <td>
 Specify the return type using either
 decltype or the Iter concept map

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 280

- <td width="75">
+ <td>
 24.4.1.2.4

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

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

- <td width="375">
+ <td>
 The presence of
 the second iterator value is surprising for many readers
 who underestimate the size of a reverse_iterator object.
@@ -9603,28 +9603,28 @@

 

- <td width="466">
+ <td>
 Add reverse_iterator expsoition only member
 tmp as a comment to class declaration, as a private member

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 281

- <td width="75">
+ <td>
 24.4.1.2.5

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

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

- <td width="375">
+ <td>
 The current
 specification for return value will always be a true
 pointer type, but reverse_iterator supports proxy iterators
@@ -9632,20 +9632,20 @@

 

- <td width="466">
+ <td>
 Replace the existing returns specification
 with a copy of the operator* specification that returns
 this->tmp.operator->

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 282

- <td width="75">
+ <td>
 24.4.2.1, 
 24.4.2.2.2, 
 24.4.2.3, 
@@ -9653,41 +9653,41 @@
 24.4.2.5, 
 24.4.2.6.2

- <td width="31">
+ <td>
 n/a

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

- <td width="375">
+ <td>
 Insert iterators of move-only types will
 move from lvalues

- <td width="466">
+ <td>
 Add an additional constrained overload for
 operator= that requires
 !CopyConstructible<Cont::value_type> and mark it
 =delete.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 283

- <td width="75">
+ <td>
 24.4.2.5, 
 24.4.2.6.4

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

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

- <td width="375">
+ <td>
 postincrement operator overloads
 traditionally return by value - insert_iterator is declared
 as return by reference. The change is harmless in this
@@ -9695,113 +9695,113 @@
 matching change for consistency, or this function should
 return-by-value

- <td width="466">
+ <td>
 change operator++(int) overload to return
 by value, not reference. Affects both class summary and
 operator definition in p

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 61

- <td width="75">
+ <td>
 24.4.3.2.1

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

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

- <td width="375">
+ <td>
 
 Typo.

 
 "intializing" should be "initializing"

- <td width="466">
+ <td>
 Add
 "i"

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 284

- <td width="75">
+ <td>
 24.5

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

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

- <td width="375">
+ <td>
 The stream
 iterators need constraining with concepts/requrires
 clauses.

 

- <td width="466">
+ <td>
 Provide constraints

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 285

- <td width="75">
+ <td>
 24.5.1

- <td width="31">
+ <td>
 1,2

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

- <td width="375">
+ <td>
 Much of the
 content of p1 and the whole of p2 is a redundant
 redefinition of InputIterator. It should be simplified

 

- <td width="466">
+ <td>
 Strike p2. Simplify p1 and add a
 cross-reference to the definition of InputIterator concept.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 286

- <td width="75">
+ <td>
 24.5.1

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

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

- <td width="375">
+ <td>
 To the casual
 reader it is not clear if it is intended to be able to
 assign to istream_iterator objects. Specifying the copy
@@ -9810,29 +9810,29 @@

 

- <td width="466">
+ <td>
 Either provide a similar definition to the
 copy-assign operator as for the copy constructor, or strike
 the copy constructor

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 287

- <td width="75">
+ <td>
 24.5.1.1

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 It is not clear
 what the intial state of an istream_iterator should be. Is
 _value_ initialized by reading the stream, or default/value
@@ -9844,57 +9844,57 @@

 

- <td width="466">
+ <td>
 Specify _value_ is initialized by reading
 the stream, or the iterator takes on the end-of-stream
 value if the stream is empty

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 288

- <td width="75">
+ <td>
 24.5.1.1

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

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

- <td width="375">
+ <td>
 The provided specification is vacuous,
 offering no useful information.

- <td width="466">
+ <td>
 Either strike
 the specification of the copy constructor, or simply
 replace it with an = default definition.

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 289

- <td width="75">
+ <td>
 24.5.1.2

- <td width="31">
+ <td>
 6

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

- <td width="375">
+ <td>
 It is very hard
 to pick up the correct specification for
 istream_iterator::operator== as the complete specification
@@ -9906,29 +9906,29 @@

 

- <td width="466">
+ <td>
 Merge 24.5.1p3, equality comparison of
 end-of-stream-iterators, into 24.5.1.2p6, the specification
 of the equality operator for istream_iterator.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 290

- <td width="75">
+ <td>
 24.5.2

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 The character
 type of a string delimiter for an ostream_iterator should
 be const charT *, the type of the elements, not char *, a
@@ -9936,27 +9936,27 @@

 

- <td width="466">
+ <td>
 Replace char * with const charT *

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 291

- <td width="75">
+ <td>
 24.5.2.2

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 ostream_iterator
 postincrement operator returns by reference rather than by
 value. This may be a small efficiency gain, but it is
@@ -9964,88 +9964,88 @@

 

- <td width="466">
+ <td>
 ostream_iterator operator++(int);

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

 <tr valign="top">
- <td width="29">
+ <td>
 FR 34

- <td width="75">
+ <td>
 24.5.3 
 [istreambuf. 
 iterator]

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

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

- <td width="375">
+ <td>
 There are two public
 sections, and the content of the second one is indented
 with respect to the first. I don't it should be.

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 292

- <td width="75">
+ <td>
 24.5.3

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 Prefer the use
 of the new nullptr constant to the zero literal when using
 a null pointer in text.

 

- <td width="466">
+ <td>
 Change istreambuf_iterator(0) to
 istreambuf_iterator(nullptr)

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 293

- <td width="75">
+ <td>
 24.5.3

- <td width="31">
+ <td>
 2,3,4

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

- <td width="375">
+ <td>
 The listed paragraphs redundantly redefine
 an input iterator, and redundancy can be a dangerous thing
 in a specification. Suggest a simpler phrasing below.

- <td width="466">
+ <td>
 2. The result of
 operator*() on an end of stream is undefined. For any other
 iterator value a char_type value is returned. 3. Two end of
@@ -10058,29 +10058,29 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 294

- <td width="75">
+ <td>
 24.5.3.2

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 Implicit converting constructors can be
 invoked at surprising times, so there should always be a
 good reason for declaring one.

- <td width="466">
+ <td>
 Mark the two
 single-argument constructors take a stream or stream buffer
 as explicit. The proxy constructor should remain implicit.
@@ -10092,24 +10092,24 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 295

- <td width="75">
+ <td>
 25

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

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

- <td width="375">
+ <td>
 THere is a level
 of redundancy in the library specification for many
 algorithms that can be eliminated with the combination of
@@ -10119,27 +10119,27 @@

 

- <td width="466">
+ <td>
 Adopt n2743, or an update of that paper.

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 62

- <td width="75">
+ <td>
 25, 25.3.1.5, 
 26.3.6.5

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

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

- <td width="375">
+ <td>
 
 The return types of is_sorted_until function and
@@ -10155,31 +10155,31 @@
 

- <td width="466">
+ <td>
 
 Change "is_sorted_until" to "sorted_bound"

 
 Change "is_heap" to "heap_bound"

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 296

- <td width="75">
+ <td>
 25.1.8

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 The 'Returns' of
 adjacent_find requires only HasEqualTo, or a Predicate.
 Requiring EqualityComparable or EquivalenceRelation seems
@@ -10187,111 +10187,111 @@

 

- <td width="466">
+ <td>
 Change EqualityComparable to HasEqualTo and
 EquivalnceRelation to Predicate

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 297

- <td width="75">
+ <td>
 25.2.11

- <td width="31">
+ <td>
 6

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

- <td width="375">
+ <td>
 The definition
 of rotate_copy is very complicated. It is equivalent to:
 return copy(first, middle, copy(middle, last, result));

 

- <td width="466">
+ <td>
 Change 'effects' to, returns, requires,
 complexity to: effects: equivalent to: return copy(first,
 middle, copy(middle, last, result));

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 298

- <td width="75">
+ <td>
 25.2.13

- <td width="31">
+ <td>
 13

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

- <td width="375">
+ <td>
 partition_point requires a partitioned
 array

- <td width="466">
+ <td>
 requires: is_partitioned(first, last, pred)
 != false;

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 299

- <td width="75">
+ <td>
 25.2.2

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

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

- <td width="375">
+ <td>
 Should be consistent in style use of
 concepts in template parameter lists. The
 auto-OutputIterator sytle used in std::copy is probably
 preferred.

- <td width="466">
+ <td>
 Change way signature is declared:
 template<InputIterator InIter, OutputIterator<auto,
 RvalueOf<InIter::reference>::type> OutIter>
 OutIter move(InIter first, InIter last, OutIter result);

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 300

- <td width="75">
+ <td>
 25.2.3

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

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

- <td width="375">
+ <td>
 Since publishing
 the original standard, we have learned that swap is a
 fundamental operation, and several common idioms rely on it
@@ -10307,31 +10307,31 @@

 

- <td width="466">
+ <td>
 Move primary swap template from
 <algorithm> into <utility>. Move 25.2.3 to
 somewhere under 20.2. Require <algorithm> to #include
 <utility> to access pair and provide legacy support
 for finding swap.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 301

- <td width="75">
+ <td>
 25.2.5

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

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

- <td width="375">
+ <td>
 replace and
 replace_if have the requirement: OutputIterator<Iter,
 Iter::reference> Which implies they need to copy some
@@ -10342,163 +10342,163 @@

 

- <td width="466">
+ <td>
 Remove OutputIterator<Iter,
 Iter::reference> from replace and replace_if

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 302

- <td width="75">
+ <td>
 25.3

- <td width="31">
+ <td>
 4

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

- <td width="375">
+ <td>
 the concept
 StrictWeakOrder covers the definition of a strict weak
 ordering, described in paragraph 4.

 

- <td width="466">
+ <td>
 Remove 4, and mention StrictWeakOrder in
 paragraph 1.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 303

- <td width="75">
+ <td>
 25.3

- <td width="31">
+ <td>
 6

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

- <td width="375">
+ <td>
 This paragraph just describes
 is_partitioned

- <td width="466">
+ <td>
 6 A sequence
 [start,finish) is partitioned with respect to an expression
 f(e) if is_partitioned(start, finish, e) != false

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 304

- <td width="75">
+ <td>
 25.3.6

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

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

- <td width="375">
+ <td>
 The requires
 clauses of push_heap, pop_heap and make_heap are
 inconsistently formatted, dispite being identical

 

- <td width="466">
+ <td>
 Format them identically.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 305

- <td width="75">
+ <td>
 25.3.7

- <td width="31">
+ <td>
 1, 9, 17

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

- <td width="375">
+ <td>
 The negative requirement on IsSameType is a
 hold-over from an earlier draught with a variadic template
 form of min/max algorith. It is no longer necessary.

- <td width="466">
+ <td>
 Strike the !IsSameType<T, Compare>
 constraint on min/max/minmax algorithms

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 84

- <td width="75">
+ <td>
 26

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

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

- <td width="375">
+ <td>
 
 Parts of the numerics chapter are not concept enabled.

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 FR 35

- <td width="75">
+ <td>
 26.3 
 [Complex 
 numbers]

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

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

- <td width="375">
+ <td>
 Instantiations of the class
 template complex<> have to be allowed for integral
 types, to reflect existing practice and ISO standards
@@ -10506,53 +10506,53 @@

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 306

- <td width="75">
+ <td>
 26.4

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

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

- <td width="375">
+ <td>
 Random number
 library component cannot be used in constrained templates

 

- <td width="466">
+ <td>
 Provide constraints for the random number
 library

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 63

- <td width="75">
+ <td>
 26.4.8.5.1

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

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

- <td width="375">
+ <td>
 No
 constructor of discrete_distribution that accepts
 initializer_list.
@@ -10583,30 +10583,30 @@
 
 

- <td width="466">
+ <td>
 Add
 the following constructer.

 
 discrete_distribution(initializer_list<result_type>);

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 64

- <td width="75">
+ <td>
 26.5.2

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

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

- <td width="375">
+ <td>
 
 “valarray<T>& operator+=
@@ -10615,29 +10615,29 @@
 
 

- <td width="466">
+ <td>
 Add
 valarray<T>& operator+=
 (initializer_list<T>);

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 307

- <td width="75">
+ <td>
 26.7

- <td width="31">
+ <td>
 Footnote 288

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

- <td width="375">
+ <td>
 The footnote
 refers to TR1, which is not a defined term in this
 standard. Drop the reference to TR1, those templates are a
@@ -10646,79 +10646,79 @@

 

- <td width="466">
+ <td>
 Drop the reference to TR1.

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 85

- <td width="75">
+ <td>
 27

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

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

- <td width="375">
+ <td>
 The
 input/output chapter is not concept enabled.

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 308

- <td width="75">
+ <td>
 27

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

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

- <td width="375">
+ <td>
 
 iostreams library cannot be used from
 constrained templates

 

- <td width="466">
+ <td>
 Provide constraints for the iostreams
 library, clause 27

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 65

- <td width="75">
+ <td>
 27.4.4

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

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

- <td width="375">
+ <td>
 Switch from
 “unspecified-bool-type” to
 

- <td width="466">
+ <td>
 
 Replace "operator unspecified-bool-type() const;"
 with "explicit operator bool() const;"

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 66

- <td width="75">
+ <td>
 27.4.4.3

- <td width="31">
+ <td>
 1st para

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

- <td width="375">
+ <td>
 Switch from
 “unspecified-bool-type” to
 

- <td width="466">
+ <td>
 
 Replace "operator unspecified-bool-type() const;"
 with "explicit operator bool() const;"

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

 <tr valign="top">
- <td width="29">
+ <td>
 FR 36

- <td width="75">
+ <td>
 27.6.1.2.2 
 [istream. 
 formatted. 
 arithmetic]

- <td width="31">
+ <td>
 1, 2, and 3

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

- <td width="375">
+ <td>
 iostate err = 0;

 
@@ -10796,29 +10796,29 @@

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 FR 37

- <td width="75">
+ <td>
 27.6.1.2.2 
 [istream. 
 formatted. 
 arithmetic]

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

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

- <td width="375">
+ <td>
 else if (lval <
 numeric_limits<int>::min()

@@ -10832,30 +10832,30 @@

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 67

- <td width="75">
+ <td>
 27.7.1

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

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

- <td width="375">
+ <td>
 
 basic_stringbuf dose not use concept.

- <td width="466">
+ <td>
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -10981,27 +10981,27 @@
 
 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 68

- <td width="75">
+ <td>
 27.7.2

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

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

- <td width="375">
+ <td>
 
 basic_istringstream dose not use concept.

- <td width="466">
+ <td>
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -11158,27 +11158,27 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 69

- <td width="75">
+ <td>
 27.7.3

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

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

- <td width="375">
+ <td>
 
 basic_ostringstream dose not use concept.

- <td width="466">
+ <td>
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -11336,30 +11336,30 @@
 
 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 71

- <td width="75">
+ <td>
 27.7.3

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

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

- <td width="375">
+ <td>
 
 Typo.

 "template" is missing in
 "class basic_ostringstream" of the title of the chapter.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -11378,27 +11378,27 @@
 27.7.3 Class template
 basic_ostringstream

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 72

- <td width="75">
+ <td>
 27.7.4

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

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

- <td width="375">
+ <td>
 
 basic_stringstream dose not use concept.

- <td width="466">
+ <td>
 
 Replace "class Allocator" to "Allocator Alloc".

@@ -11550,23 +11550,23 @@

 }

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 73

- <td width="75">
+ <td>
 27.8.1.14

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

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

- <td width="375">
+ <td>
 It is a problem
 from C++98, fstream cannot appoint a filename of wide
@@ -11575,106 +11575,106 @@
 
 

- <td width="466">
+ <td>
 Add
 interface corresponding to wchar_t, char16_t and char32_t.

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 86

- <td width="75">
+ <td>
 28

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

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

- <td width="375">
+ <td>
 The
 regular expressions chapter is not concept enabled.

 

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

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 309

- <td width="75">
+ <td>
 28

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

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

- <td width="375">
+ <td>
 Regular
 expressions cannot be used in constrained templates

 

- <td width="466">
+ <td>
 Provide constraints for the regular
 expression library, clause 28

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 310

- <td width="75">
+ <td>
 28

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

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

- <td width="375">
+ <td>
 The regex chapter uses iterators in the old
 pre-concept style, it should be changed to use concepts
 instead.

- <td width="466">
+ <td>
 Use concepts for iterator template
 arguments throughout.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 314

- <td width="75">
+ <td>
 28.4

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

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

- <td width="375">
+ <td>
 The swap
 overloads for regex classes are only supplied for l-value
 references. Other sections of the library (eg 21 strings or
@@ -11684,30 +11684,30 @@

 

- <td width="466">
+ <td>
 Add the missing overloads to 28.4 and the
 corresponding later sections in 28 for each swap function.
 We want to accept AMs paper which proposes a single
 overload with two r-value references

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 315

- <td width="75">
+ <td>
 28.4

- <td width="31">
+ <td>
 p6

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

- <td width="375">
+ <td>
 6 Effects:
 string_type str(first, last); return
 use_facet<collate<charT> >(
@@ -11716,60 +11716,60 @@

 

- <td width="466">
+ <td>
 Reword to effect clause to use legal
 iterator dereferences

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 316

- <td width="75">
+ <td>
 28.4 ff

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

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

- <td width="375">
+ <td>
 The constructors
 for regex classes do not have an r-value overload.

 

- <td width="466">
+ <td>
 Add the missing r-value constructors to
 regex classes.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 317

- <td width="75">
+ <td>
 28.8

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

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

- <td width="375">
+ <td>
 basic_string has both a constructor and an
 assignment operator that accepts an initializer list,
 basic_regex should have the same.

- <td width="466">
+ <td>
 In the
 basic_regex synopsis, after: basic_regex&
 operator=(const charT* ptr); add: basic_regex&
@@ -11780,23 +11780,23 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 JP 74

- <td width="75">
+ <td>
 28.8

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

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

- <td width="375">
+ <td>
 
 “basic_regx & operator=
@@ -11805,55 +11805,55 @@
 
 

- <td width="466">
+ <td>
 Add
 basic_regx & operator= (initializer_list<T>);

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 318

- <td width="75">
+ <td>
 28.8.2

- <td width="31">
+ <td>
 para 22

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

- <td width="375">
+ <td>
 Constructor
 definition should appear with the other constructors not
 after assignment ops.

 

- <td width="466">
+ <td>
 Move para 22 to just after para 17.

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

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 319

- <td width="75">
+ <td>
 28.12.2

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

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

- <td width="375">
+ <td>
 It was always expected that
 regex_token_iterator would be constructible from an array
 literal: indeed ideally this is the prefered method of
@@ -11866,7 +11866,7 @@
 initializer_lists we should use them to remove this
 particular wart.

- <td width="466">
+ <td>
 To the synopsis
 for regex_token_iterator, after template <std::size_t
 N> regex_token_iterator(BidirectionalIterator a,
@@ -11889,85 +11889,85 @@

 

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

 <tr valign="top">
- <td width="29">
+ <td>
 US 87

- <td width="75">
+ <td>
 29

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

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

- <td width="375">
+ <td>
 The
 atomics chapter is not concept enabled. The adopted paper,
 N2427, did have those concepts.

 

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

- <td width="225">
+ <td>
 Create an issue for concepts in the atomics chapter. See
 N2427. Needs to also consider issues 923 and 924. 

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 311

- <td width="75">
+ <td>
 29

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

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

- <td width="375">
+ <td>
 Atomic types
 cannot be used generically in a constrained template

 

- <td width="466">
+ <td>
 Provide constraints for the atomics
 library, clause 29

- <td width="225">
+ <td>
 Duplicate of US 87. 

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 312

- <td width="75">
+ <td>
 29

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

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

- <td width="375">
+ <td>
 The contents of the <stdatomic.h>
 header are not listed anywhere, and <cstdatomic> is
 listed as a C99 header in chapter 17. If we intend to use
 these for compatibility with a future C standard, we should
 not use them now.

- <td width="466">
+ <td>
 Remove <cstdatomic> from the C99
 headers in table 14. Add a new header <atomic> to the
 headers in table 13. Update chapter 29 to remove reference
@@ -11976,30 +11976,30 @@
 adds atomic operations to C we can add corresponding
 headers to table 14 with a TR.

- <td width="225">
+ <td>
 Create an issue. Assigned to Lawrence Crowl. May be
 resolvable with a footnote for clarity stating that the header is
 defined where it exists. 

 <tr valign="top">
- <td width="29">
+ <td>
 JP 75

- <td width="75">
+ <td>
 29

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

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

- <td width="375">
+ <td>
 A
 definition of enum or struct is the style of C using
 typedef.

- <td width="466">
+ <td>
 
 Change to a style of C++.

@@ -12227,31 +12227,31 @@

 }

- <td width="225">
+ <td>
 Recommend to reject the comment: We believe the current
 syntax is most appropriate for an interface that is intended to be
 highly compatible with C. 

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 313

- <td width="75">
+ <td>
 29.1

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

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

- <td width="375">
+ <td>
 seq_cst fences don't necessarily guarantee
 ordering
 http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926

- <td width="466">
+ <td>
 Add a new
 paragraph after 29.1 [atomics.order]p5 that says For atomic
 operations A and B on an atomic object M, where A and B
@@ -12262,27 +12262,27 @@

 

- <td width="225">
+ <td>
 Hans to make proposal. See LWG Issue 926. 

 <tr valign="top">
- <td width="29">
+ <td>
 US 88

- <td width="75">
+ <td>
 29.2

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

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

- <td width="375">
+ <td>
 The "lockfree" facilities do
 not tell the programmer enough.

- <td width="466">
+ <td>
 
 Expand the "lockfree" facilities. See the attached paper
 "Issues with the C++ Standard" under Chapter 29,
@@ -12290,25 +12290,25 @@

 

- <td width="225">
+ <td>
 Create an issue, will require more discussion. Assigned
 to Lawrence. Description of issue should be based on what is in the
 additional notes for US 88. 

 <tr valign="top">
- <td width="29">
+ <td>
 US 89

- <td width="75">
+ <td>
 29.3.1

- <td width="31">
+ <td>
 Table 122

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

- <td width="375">
+ <td>
 The
 types in the table "Atomics for standard typedef types"
 should be typedefs, not classes. These semantics are
@@ -12316,32 +12316,32 @@

 

- <td width="466">
+ <td>
 Change the classes to
 typedefs.

- <td width="225">
+ <td>
 LWG Issue 937. Direct the editor to turn the types into
 typedefs as proposed in the comment. Paper approved by committee used
 typedefs, this appears to have been introduced as an editorial change.
 Rationale: for compatibility with C.<tr valign="top">
- <td width="29">
+ <td>
 US 90

- <td width="75">
+ <td>
 29.4

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

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

- <td width="375">
+ <td>
 Are atomic functions allowed
 to have non-volatile overloads?

- <td width="466">
+ <td>
 
 Allow non-volatile overloads. See the attached paper
 "Issues with the C++ Standard, under Chapter 29, "Are
@@ -12349,29 +12349,29 @@

 

- <td width="225">
+ <td>
 Create an issue. Assigned to Lawrence Crowl. Should
 explicitly consider the process shared issue. 

 <tr valign="top">
- <td width="29">
+ <td>
 US 91

- <td width="75">
+ <td>
 29.4

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

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

- <td width="375">
+ <td>
 Whether or not a failed
 compare_exchange is a RMW operation (as used in 1.10
 [intro.multithread]) is unclear.

- <td width="466">
+ <td>
 
 Make failing compare_exchange operations not be RMW. See
@@ -12380,29 +12380,29 @@

 

- <td width="225">
+ <td>
 Create an issue, goes to review. Attention: Howard.
 Group agrees with the resolution as proposed by Anthony Williams in the
 attached note. 

 <tr valign="top">
- <td width="29">
+ <td>
 US 92

- <td width="75">
+ <td>
 29.4

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

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

- <td width="375">
+ <td>
 The effect of
 memory_order_consume with atomic RMW operations is unclear.

- <td width="466">
+ <td>
 
 Follow the lead of fences [atomics.fences], and promote
 memory_order_consume to memory_order_acquire with RMW
@@ -12410,24 +12410,24 @@

 

- <td width="225">
+ <td>
 Create an issue. Assigned to Lawrence. Resolution
 requires proposed wording. 

 <tr valign="top">
- <td width="29">
+ <td>
 JP 76

- <td width="75">
+ <td>
 30

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

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

- <td width="375">
+ <td>
 A
 description for "Throws: Nothing." are not unified.

@@ -12435,7 +12435,7 @@
 the part without throw, "Throws: Nothing." should be
 described.

- <td width="466">
+ <td>
 Add
 "Throws: Nothing." to the following.

@@ -12464,78 +12464,78 @@
 
 

- <td width="225">
+ <td>
 Pass on to editor. 

 <tr valign="top">
- <td width="29">
+ <td>
 US 93

- <td width="75">
+ <td>
 30

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

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

- <td width="375">
+ <td>
 The
 thread chapter is not concept enabled.

 

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

- <td width="225">
+ <td>
 Create an issue. Need to find volunteers to work on
 this. 

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 320

 

- <td width="75">
+ <td>
 30

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

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

- <td width="375">
+ <td>
 Threads library cannot be used in
 constrained templates

- <td width="466">
+ <td>
 Provide constraints for the threads
 library, clause 30

- <td width="225">
+ <td>
 Duplicate of US 93. 

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 321

- <td width="75">
+ <td>
 30

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

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

- <td width="375">
+ <td>
 Throughout this
 clause, the term Requires: is used to introduce compile
 time requirements, which we expect to be replaced with
@@ -12549,32 +12549,32 @@

 

- <td width="466">
+ <td>
 Decument Preconditions: paragraphs in
 17.5.2.4, and use consistently through rest of the library.

- <td width="225">
+ <td>
 Pass on to editor. 

 <tr valign="top">
- <td width="29">
+ <td>
 US 94

- <td width="75">
+ <td>
 30.1.2

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 The first sentence of para 1 suggests that no other
 library function is permitted to call operating system or
 low level APIs.

- <td width="466">
+ <td>
 Rewrite para 1
 as: “ Some functions described
@@ -12588,27 +12588,27 @@

 

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

 Reclassify as editorial. Pass on to editor, wording roughly as proposed.<tr valign="top">
- <td width="29">
+ <td>
 US 95

- <td width="75">
+ <td>
 30.1.3

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 “native_handle_type” is a typedef, not a
 class member.

- <td width="466">
+ <td>
 Several classes
 described in this Clause have a member native_handle (of
@@ -12625,27 +12625,27 @@

 

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

 Not a defect. native_handle_type is a typedef, but it is also a member of
 the classes in question.<tr valign="top">
- <td width="29">
+ <td>
 US 96

- <td width="75">
+ <td>
 30.1.4

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 There is no definition here for monotonic clock.

- <td width="466">
+ <td>
 Implementations
 should use a monotonic clock to measure time for
@@ -12655,56 +12655,56 @@

 

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

 Create an issue, together with UK 322. Detlef will write the issue, but not
 proposed wording. Refer also to sections [time.clock.req] and [time.clock.monotonic].<tr valign="top">
- <td width="29">
+ <td>
 UK 
 322

- <td width="75">
+ <td>
 30.1.4

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 Not all systms
 can provide a monotonic clock. How are they expected to
 treat a _for function?

 

- <td width="466">
+ <td>
 Add at least a note explaining the intent
 for systems that do not support a monotonic clock.

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

 Create an issue, together with UK 96. Note that the specification as is
 already allows a non-monotonic clock due to the word "should" rather than
 "shall". If this wording is kept, a footnote should be added to make the
 meaning clear.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 323

- <td width="75">
+ <td>
 30.2.1

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 The presence of
 a non-explicit variadic template constructor alongside an
 explicit single-argument constructor can lead to behaviour
@@ -12717,38 +12717,38 @@

 

- <td width="466">
+ <td>
 Mark constructor template <class F,
 class ...Args> thread(F&& f, Args&&...
 args); as explicit and remove the single-argument
 constructor.

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

 Create an issue, goes to review. Attention: Howard. Group agrees with the
 proposed resolution.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 324

- <td width="75">
+ <td>
 30.2.1.1

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

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

- <td width="375">
+ <td>
 thread::id
 objects should be as useable in hashing containers as they
 are in ordered associative containers.

 

- <td width="466">
+ <td>
 Add thread::id
 support for std::hash

@@ -12758,24 +12758,24 @@

 

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

 Not a defect. See [unord.hash], where std::thread:id is already listed as a
 required specialization for std::hash().<tr valign="top">
- <td width="29">
+ <td>
 JP 77

- <td width="75">
+ <td>
 30.2.1.2

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

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

- <td width="375">
+ <td>
 
 "CopyConstructible" and "MoveConstructible" in
@@ -12786,86 +12786,86 @@
 
 

- <td width="466">
+ <td>
 Add
 a concept for constructor of thread.

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

 Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td width="29">
+ <td>
 JP 78

- <td width="75">
+ <td>
 30.2.1.2

- <td width="31">
+ <td>
 
 4th para, 1st line

 

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

- <td width="375">
+ <td>
 In
 "F and each Ti in Args", 'Ti' is not clear.

- <td width="466">
+ <td>
 
 Replace "Ti" with "args"

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

 Pass on to editor.<tr valign="top">
- <td width="29">
+ <td>
 US 97

- <td width="75">
+ <td>
 30.2.1.3

- <td width="31">
+ <td>
 1

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

- <td width="375">
+ <td>
 detach-on-destruction may result in
 “escaped” threads accessing objects with
 bounded lifetime after the end of their lifetime.

- <td width="466">
+ <td>
 See document WG21 N2802=08-0312 written by Hans Boehm.

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

 Create an issue. To be discussed in full library group.<tr valign="top">
- <td width="29">
+ <td>
 US 98

- <td width="75">
+ <td>
 30.2.1.3, 
 30.2.1.4

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

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

- <td width="375">
+ <td>
 The current defined behavior
 for the std::thread destructor is to detach the thread.
 Unfortunately, this behavior exposes programmers to tricky,
 hard-to-diagnose, undefined behavior.

- <td width="466">
+ <td>
 
 Change destruction behavior to undefined behavior, with a
 note strongly encouraging termination. See the attached
@@ -12874,30 +12874,30 @@

 

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

 Duplicate of US 97.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 325

- <td width="75">
+ <td>
 30.3.3

- <td width="31">
+ <td>
 2

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

- <td width="375">
+ <td>
 We believe constexpr literal values should
 be a more natural expression of empty tag types than extern
 objects as it should improve the compilers ability to
 optimize the empty object away completely.

- <td width="466">
+ <td>
 Replace the
 extern declarations: extern const defer_lock_t defer_lock;
 extern const try_to_lock_t try_to_lock; extern const
@@ -12907,26 +12907,26 @@

 

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

 Create an issue. Move to review, attention: Howard. The current
 specification is a "hack", and the proposed specification is a better
 "hack".<tr valign="top">
- <td width="29">
+ <td>
 UK 
 326

- <td width="75">
+ <td>
 30.3.3.2.1

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

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

- <td width="375">
+ <td>
 The precondition
 that the mutex is not owned by this thread offers
 introduces the risk of un-necessary undefined behaviour
@@ -12940,28 +12940,28 @@

 

- <td width="466">
+ <td>
 Strike 30.3.3.2.1p7

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

 Create an issue. Move to review, attention: Howard. Proposed resolution is
 fine.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 327

- <td width="75">
+ <td>
 30.3.3.2.2

- <td width="31">
+ <td>
 4, 9, 14, 19

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

- <td width="375">
+ <td>
 Not clear what
 the specification for error condition
 resource_deadlock_would_occur means. It is perfectly
@@ -12980,69 +12980,69 @@

 

- <td width="466">
+ <td>
 Add a precondition !owns. Change the 'i.e.'
 in the error condition to be 'e.g.' to allow for this
 condition to propogate deadlock detection by the host OS.

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

 Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock
 means for recursive locks when you are the owner. POSIX has language on
 this, which should ideally be followed. Proposed fix is not quite right, for
 example, try_lock should have different wording from lock.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 328

- <td width="75">
+ <td>
 30.3.3.2.2

- <td width="31">
+ <td>
 20

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

- <td width="375">
+ <td>
 There is a missing precondition that owns
 is true, or an if(owns) test is missing from the effect
 clause

- <td width="466">
+ <td>
 Add a
 precondition that owns == true. Add an error condition to
 detect a violation, rather than yield undefined behaviour.

 

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

 Handle in same issue as UK 327. Also uncertain that the proposed resolution
 is the correct one.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 329

- <td width="75">
+ <td>
 30.5

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

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

- <td width="375">
+ <td>
 future, promise and packaged_task provide a
 framework for creating future values, but a simple function
 to tie all three components together is missing. Note that
 we only need a *simple* facility for C++0x. Advanced thread
 pools are to be left for TR2.

- <td width="466">
+ <td>
 Provide a simple
 function along the lines of: template< typename F,
 typename ... Args > requires Callable< F, Args...
@@ -13065,60 +13065,60 @@

 

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

 Not a defect. This class of feature has been rejected by the committee as a
 whole multiple times.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 330

- <td width="75">
+ <td>
 30.5.1

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

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

- <td width="375">
+ <td>
 30.5.1 (and then 30.5.7) refer to a
 specialisation of
 constructible_with_allocator_prefix<> However this
 trait is not in the CD, so references to it should be
 removed.

- <td width="466">
+ <td>
 Remove the
 reference to constructible_with_allocator_prefix in 30.5.1
 Remove paragraph 30.5.7

 

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

 Related to JP 79 and therefore subset of US 93. Should be addressed under
 the issue corresponding to US 93.<tr valign="top">
- <td width="29">
+ <td>
 JP 79

- <td width="75">
+ <td>
 30.5.1

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

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

- <td width="375">
+ <td>
 The
 concept of UsesAllocator and Allocator should be used.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -13158,24 +13158,24 @@
 
 

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

 Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 331

- <td width="75">
+ <td>
 30.5.3

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

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

- <td width="375">
+ <td>
 Not clear what
 it means for a public constructor to be 'exposition only'.
 If the intent is purely to support the library calling this
@@ -13185,30 +13185,30 @@

 

- <td width="466">
+ <td>
 Declare the constructor as private with a
 note about intended friendship, or remove the
 exposition-only comment and document the semantics.

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

 Create an issue. Assigned to Detlef. Suggested resolution probably makes
 sense.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 332

- <td width="75">
+ <td>
 30.5.4

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

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

- <td width="375">
+ <td>
 It is not clear
 without reference to the original proposal how to use a
 future. In particular, the only way for the user to
@@ -13219,56 +13219,56 @@

 

- <td width="466">
+ <td>
 Provide a small introductory paragraph,
 docuenting intended purpose of the future class template
 and the way futures can only be created via the promise
 API.

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

 Pass on to editor. Detlef has volunteered to provide some wording.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 333

- <td width="75">
+ <td>
 30.5.4

- <td width="31">
+ <td>
 5

- <td width="38">
+ <td>
 Ge

- <td width="375">
+ <td>
 We expect the complicated 3-signature
 specifcation for future::get() to be simplified to a single
 signature with a requires clause by the application of
 concepts.

- <td width="466">
+ <td>
 Requires fully baked concepts for clause 30

- <td width="225">
+ <td>
 

 Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 334

- <td width="75">
+ <td>
 30.5.4

- <td width="31">
+ <td>
 5

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 Behaviour of
 get() is undefined if calling get() while not is_ready().
 The intent is that get() is a blocking call, and will wait
@@ -13276,29 +13276,29 @@

 

- <td width="466">
+ <td>
 Effects: If is_ready() would return false,
 block on the asynchronous result associated with *this.

- <td width="225">
+ <td>
 

 Create an issue. Move to review, attention: Howard. Proposed resolution is
 fine.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 335

- <td width="75">
+ <td>
 30.5.4

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 
 std::unique_future is MoveConstructible, so you can
 transfer the association with an asynchronous result from
@@ -13312,31 +13312,31 @@

 

- <td width="466">
+ <td>
 Add a "waitable()" function to
 unique_future (and shared_future) akin to
 std::thread::joinable(), which returns true if there is an
 associated result to wait for (whether or not it is ready).
 Then we can say: if(uf.waitable()) uf.wait();

- <td width="225">
+ <td>
 

 Create an issue. Requires input from Howard. Probably NAD.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 336

- <td width="75">
+ <td>
 30.5.4

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 It is possible
 to transfer ownership of the asynchronous result from one
 unique_future instance to another via the move-constructor.
@@ -13350,30 +13350,30 @@

 

- <td width="466">
+ <td>
 Add a default constructor with the
 semantics that it creates a unique_future with no
 associated asynchronous result. Add a move-assignment
 operator which transfers ownership.

- <td width="225">
+ <td>
 

 Create an issue. Detlef will look into it.<tr valign="top">
- <td width="29">
+ <td>
 JP 80

- <td width="75">
+ <td>
 30.5.4 , 
 30.5.5

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 ed

- <td width="375">
+ <td>
 
 Typo, duplicated ">"

@@ -13384,28 +13384,28 @@
 
 

- <td width="466">
+ <td>
 
 Remove one

- <td width="225">
+ <td>
 

 Pass on to editor.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 337

- <td width="75">
+ <td>
 30.5.5

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 shared_future
 should support an efficient move constructor that can avoid
 unnecessary manipulation of a reference count, much like
@@ -13413,27 +13413,27 @@

 

- <td width="466">
+ <td>
 Add a move constructor

- <td width="225">
+ <td>
 

 Create an issue. Detlef will look into it.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 338

- <td width="75">
+ <td>
 30.5.5

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 shared_future is currently
 CopyConstructible, but not CopyAssignable. This is
 inconsistent with shared_ptr, and will surprise users.
@@ -13446,7 +13446,7 @@
 retained by declaring such an instance as "const
 shared_future".

- <td width="466">
+ <td>
 Remove "=delete"
 from the copy-assignment operator of shared_future. Add a
 move-constructor shared_future(shared_future&&
@@ -13461,29 +13461,29 @@

 

- <td width="225">
+ <td>
 

 Create an issue. Detlef will look into it.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 339

- <td width="75">
+ <td>
 30.5.6

- <td width="31">
+ <td>
 6, 7

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 Move assignment is goiing in the wrong
 direction, assigning from *this to the passed rvalue, and
 then returning a reference to an unusable *this

- <td width="466">
+ <td>
 Strike 6. 7
 Postcondition: associated state of *this is the same as the
 associated state of rhs before the call. rhs has no
@@ -13491,25 +13491,25 @@

 

- <td width="225">
+ <td>
 

 Create an issue. Move to review, attention: Howard. Proposed resolution is
 fine.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 340

- <td width="75">
+ <td>
 30.5.6

- <td width="31">
+ <td>
 11, 12, 13

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 There is an
 implied postcondition that the state of the promise is
 transferred into the future leaving the promise with no
@@ -13517,91 +13517,91 @@

 

- <td width="466">
+ <td>
 Postcondition: *this has no associated
 state.

- <td width="225">
+ <td>
 

 Create an issue. Move to review, attention: Howard. Proposed resolution is
 fine.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 341

- <td width="75">
+ <td>
 30.5.6

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 promise::swap accepts its parameter by
 lvalue reference. This is inconsistent with other types
 that provide a swap member function, where those swap
 functions accept an rvalue reference

- <td width="466">
+ <td>
 Change promise::swap to take an rvalue
 reference.

- <td width="225">
+ <td>
 

 Create an issue. Detlef will look into it. Probably ready as it.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 342

- <td width="75">
+ <td>
 30.5.6

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 std::promise is
 missing a non-member overload of swap. This is inconsistent
 with other types that provide a swap member function

 

- <td width="466">
+ <td>
 Add a non-member overload void
 swap(promise&& x,promise&& y){ x.swap(y); }

- <td width="225">
+ <td>
 

 Create an issue. Move to review, attention: Howard. Detlef will also look
 into it.<tr valign="top">
- <td width="29">
+ <td>
 UK 
 343

- <td width="75">
+ <td>
 30.5.6

- <td width="31">
+ <td>
 3

- <td width="38">
+ <td>
 Te

- <td width="375">
+ <td>
 The move constructor of a std::promise
 object does not need to allocate any memory, so the
 move-construct-with-allocator overload of the constructor
 is superfluous.

- <td width="466">
+ <td>
 Remove the
 constructor with the signature template <class
 Allocator> promise(allocator_arg_t, const Allocator&
@@ -13609,29 +13609,29 @@

 

- <td width="225">
+ <td>
 

 Create an issue. Detlef will look into it. Will solicit feedback from Pablo.
 Note that "rhs" argument should also be an rvalue reference in any case.<tr valign="top">
- <td width="29">
+ <td>
 JP 81

- <td width="75">
+ <td>
 30.5.8

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 ed

- <td width="375">
+ <td>
 
 There are not requirements for F and a concept of Allocator
 dose not use.

- <td width="466">
+ <td>
 
 Correct as follows.

@@ -13741,24 +13741,24 @@
 packaged_task(allocator_arg_t, const Alloc& a,
 F&& f);

- <td width="225">
+ <td>
 

 Subset of US 93. Should be addressed under the issue corresponding to US 93.
 We do not consider this to be an editorial change.<tr valign="top">
- <td width="29">
+ <td>
 DE-23

- <td width="75">
+ <td>
 Annex B

- <td width="31">
+ <td>
 p2

- <td width="38">
+ <td>
 te

- <td width="375">
+ <td>
 DE-23 Recursive
 use of constexpr functions appears to be permitted. Since
@@ -13766,52 +13766,52 @@
 compile-time, Annex B "implementation quantities" should
 specify a maximum depth of recursion.

- <td width="466">
+ <td>
 In Annex B, specify a recursion depth of 256 or a larger
 value.

- <td width="225">
+ <td>
 

 <tr valign="top">
- <td width="29">
+ <td>
 DE-24

- <td width="75">
+ <td>
 Annex B

- <td width="31">
+ <td>
 p2

- <td width="38">
+ <td>
 te

- <td width="375">
+ <td>
 DE-24 The
 number of placeholders for "bind" is implementation-defined
 in 20.7.12.1.4, but no minimum is suggested in Annex B. 

- <td width="466">
+ <td>
 Add a miminum of 10 placeholders to Annex B.

- <td width="225">
+ <td>
 

 <tr valign="top">
- <td width="29">
+ <td>
 DE-25

- <td width="75">
+ <td>
 Annex B

- <td width="31">
+ <td>
 p2

- <td width="38">
+ <td>
 te

- <td width="375">
+ <td>
 DE-25
 Specifying a minimum of 17 recursively nested template
@@ -13822,28 +13822,28 @@
 . The conclusion is that the metric "number of recursively
 nested template instantiations" is inapposite.

- <td width="466">
+ <td>
 Remove the bullet "Recursively nested template
 instantiations [17]".

- <td width="225">
+ <td>
 

 <tr valign="top">
- <td width="29">
+ <td>
 FR 38

- <td width="75">
+ <td>
 C.2 
 [diffs.library]

- <td width="31">
+ <td>
 1

- <td width="38">
+ <td>
 ed

- <td width="375">
+ <td>
 What is ISO/IEC 1990:9899/DAM
 1? My guess is that's a typo for ISO/IEC

@@ -13853,59 +13853,59 @@
 make reference to things
 which were introduced by Amd.1).

- <td width="466">
+ <td>
 One need probably a reference
 to the document which introduce char16_t and

 char32_t in C (ISO/IEC TR 19769:2004?).

- <td width="225">
+ <td>
 

 <tr valign="top">
- <td width="29">
+ <td>
 UK 
 344

- <td width="75">
+ <td>
 Appendix D

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 Ge

- <td width="375">
+ <td>
 It is desirable to allow some mechanism to
 support phasing out of deprecated features in the future.
 Allowing compilers to implement a mode where deprecated
 features are not available is a good first step.

- <td width="466">
+ <td>
 Add to the definition of deprecated
 features permission for compilers to maintain a
 conditionally supported mode where deprecated features can
 be disabled, so long as they also default to a mode where
 all deprecated features are supported.

- <td width="225">
+ <td>
 

 <tr valign="top">
- <td width="29">
+ <td>
 FR 39

- <td width="75">
+ <td>
 Index

- <td width="31">
+ <td>
 

- <td width="38">
+ <td>
 ed

- <td width="375">
+ <td>
 Some definitions seem not
 indexed (such as /trivially copyable/ or

@@ -13915,10 +13915,10 @@
 increase the usefulness; having a separate index of all
 definitions is something which could also be considered).

- <td width="466">
+ <td>
 

- <td width="225">
+ <td>
 

 </table><hr>
\ No newline at end of file

Next message: fmhess_at_[hidden]: "[Boost-commit] svn:boost r51572 - in trunk: boost/signals2 boost/signals2/detail libs/signals2/test"
Previous message: john_at_[hidden]: "[Boost-commit] svn:boost r51570 - trunk/tools/build/v2/tools"

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