Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r51683 - sandbox/committee/LWG
From: bdawes_at_[hidden]
Date: 2009-03-10 08:24:07

Next message: aschoedl_at_[hidden]: "[Boost-commit] svn:boost r51684 - sandbox/partition_point/boost/partition_point"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51682 - sandbox/committee/LWG"

Author: bemandawes
Date: 2009-03-10 08:24:04 EDT (Tue, 10 Mar 2009)
New Revision: 51683
URL: http://svn.boost.org/trac/boost/changeset/51683

Log:
Apply a long series of changes to the HTML to make it easier to convert to XML. No content was changed.
Text files modified:
sandbox/committee/LWG/LWG_0xCD1_status.html | 18460 +++++++++++++++++----------------------
1 files changed, 7870 insertions(+), 10590 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-10 08:24:04 EDT (Tue, 10 Mar 2009)
@@ -21,7 +21,7 @@
<h1>Library Working Group 
Status of CD1 National Body Comments</h1>
Revised:
-09 Mar 2009 08:41:27 PM -0500
+10 Mar 2009 07:03:02 AM -0500

Disposition [Being reviewed by Editor] has been applied all Type Ed comments
which do not have a specific response from a sub-group.
@@ -29,5027 +29,3962 @@
<table border="1" bordercolor="#000000" cellpadding="7"
 cellspacing="0" style="border-collapse: collapse">

- <tr valign="top">
- <td>
- MB 
+
+
+<tr valign="top">
+<td>MB 
+
+<td>Clause No./ 
+Subclause No./ 
+Annex (e.g. 3.1)

- <td>
- Clause No./ 
- Subclause No./ 
- Annex (e.g. 3.1)
+<td>Para/ 
+Figure/ Table/ Note<td>Type 

- <td>
- Para/ 
- Figure/ Table/ Note<td>
- Type 
+<td>Comment (justification for change) by the MB

- <td>
- Comment (justification for change) by the MB
+<td>Proposed change by the MB

- <td>
- Proposed change by the MB
+<td>
+Library Work Group Notes

- <td>
- 
- Library Work Group Notes
+

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

- <td>
- 17-30
+<td>17-30

- <td>
- 
+<td>

- <td>
- ge/te
+<td>ge/te

- <td>
- The
- active issues identified in WG21 N2806, C++ Standard
- Library Active Issues, must be addressed and appropriate
- action taken.
+<td>The
+active issues identified in WG21 N2806, C++ Standard
+Library Active Issues, must be addressed and appropriate
+action taken.

- 
- 
+
+ 

- 
- <a href=
- "http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
- http://www.open-std.org/> 
-  
- <a href=
- "http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
- jtc1/sc22/wg21/docs/lwg-active.html</a>
+
+<a href=
+"http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
+http://www.open-std.org/> 
+ 
+<a href=
+"http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
+jtc1/sc22/wg21/docs/lwg-active.html</a>

- 
+<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>
- 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>Acknowledged

- <td>
- 
+<tr valign="top">
+<td>FR2

- Acknowledged<tr valign="top">
- <td>
- FR 2
+<td>General 
+Comment

- <td>
- General 
- Comment
+<td>Library

- <td>
- Library
+<td>ge

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

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

- <td>
- FR 2
+<td>Editorial; sent to Pete Becker

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

- <td>
- 17 onward
+<td>17 onward

- <td>
- 
+<td>

- <td>
- te
+<td>te

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

- <td>
- Review all
- clauses of the Standard Library, and consistently apply
- concept technology wherever possible and appropriate. The
- proposed wording in WG21 N2781 exemplifies the necessary
- level of detail.
+<td>Review all
+clauses of the Standard Library, and consistently apply
+concept technology wherever possible and appropriate. The
+proposed wording in WG21 N2781 exemplifies the necessary
+level of detail.

- 
+

- <td>
- 
+<td>Agreed. Duplicates CA2

- Agreed. Duplicates CA2<tr valign="top">
- <td>
- <a name="CA2">CA-2 </a>
+<tr valign="top">
+<td><a name="CA2">CA2 </a>

- <td>
- 17 Library
+<td>17 Library

- <td>
- 
+<td>

- <td>
- Ge
+<td>Ge

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

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

- <td>
- 
+<td>Agreed; We intend to address this.

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

- <td>
- 17-30
+<td>17-30

- <td>
- 
+<td>

- <td>
- ge
+<td>ge

- <td>
- Provide concepts
- and requirements clauses for all standard library templates
+<td>Provide concepts
+and requirements clauses for all standard library templates

- 
+<td>

- <td>
- 
+<td>Agreed. Duplicates CA2 

- <td>
- Agreed. Duplicates CA2 
+

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

- <td>
- 17-30
+<td>17-30

- 
+

- <td>
- 
+<td>

- <td>
- te
+<td>te

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

- For example, if thread 1 assigns to X, then writes data
- to file f, which is read by thread 2, and then accesses
- variable X, is thread 2 guaranteed to be able to see the
- value assigned to X by thread 1? In other words, does the
- write of the data "happen before" the read?
+For example, if thread 1 assigns to X, then writes data
+to file f, which is read by thread 2, and then accesses
+variable X, is thread 2 guaranteed to be able to see the
+value assigned to X by thread 1? In other words, does the
+write of the data "happen before" the read?

- Another example: does simultaneous access using operator
- at() to different characters in the same non-const string
- really introduce a data race?
+Another example: does simultaneous access using operator
+at() to different characters in the same non-const string
+really introduce a data race?

- <td>
- 
+<td>

- <td>
- 
+<td>17 SG: should go to threads group; misclassified in document

- 17 SG: should go to threads group; misclassified in document
+ Concurrency SG: Create an issue. Hans will look into it.

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

- <td>
- 17 through 30
+<td>17 through 30

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <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
- in a copy-initialization context, see 13.3.1.7. The
- standard library apparently has not been reviewed for
- marking non-single-parameter constructors as "explicit".
+<td>DE2 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
+in a copy-initialization context, see 13.3.1.7. The
+standard library apparently has not been reviewed for
+marking non-single-parameter constructors as "explicit".

- <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>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>
- 
+<td>Robert Klarer to address this one

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

- <td>
- 
- 
+<td>
+ 

- 17
- Library
+17
+Library

- 
- 21.2, 21.4,
+
+21.2, 21.4,

- 27.2, 27.6, 
+27.2, 27.6, 
 27.7, 
 27.8.1, 
 28.4

- <td>
- 
-
- <td>
- te
+<td>

- <td>
- 
- Support of char16_t/char32_t is insufficient. The basic_xxx
- classes of <iostream>, <fstream>,
- <regex>, etc. does not have typedefs for
- char16_t/char32_t.
+<td>te

- 
- Functions such as stoi, to_string in ‘21.4 Numeric
- Conversion’ does not support char16_t/char32_t types.
+<td>
+Support of char16_t/char32_t is insufficient. The basic_xxx
+classes of <iostream>, <fstream>,
+<regex>, etc. does not have typedefs for
+char16_t/char32_t.

- <td>
- Add commented
- lines corresponding to char16_t, char32_t.
+
+Functions such as stoi, to_string in ‘21.4 Numeric
+Conversion’ does not support char16_t/char32_t types.

- 
- 
+<td>Add commented
+lines corresponding to char16_t, char32_t.

- 
- 21.2 paragraph1
+
+ 

- 
-  
+
+21.2 paragraph1

- 
- namespace std {
+
+ 

- 
-  ...
+
+namespace std {

- 
-  
+
+ ...

- 
-  // 21.4: numeric conversions
+
+ 

- 
-  ...
+
+ // 21.4: numeric conversions

- 
-  
+
+ ...

- 
-  int stoi(const u16string& str, size_t *idx = 0,
- int base = 10);
+
+ 

- 
-  long stol(const u16string& str, size_t *idx = 0,
- int base = 10);
+
+ int stoi(const u16string& str, size_t *idx = 0,
+int base = 10);

- 
-  unsigned long stoul(const u16string& str, size_t
- *idx = 0, int base = 10);
+
+ long stol(const u16string& str, size_t *idx = 0,
+int base = 10);

- 
-  long long stoll(const u16string& str, size_t *idx
- = 0, int base = 10);
+
+ unsigned long stoul(const u16string& str, size_t
+*idx = 0, int base = 10);

- 
-  unsigned long long stoull(const u16string& str,
- size_t *idx = 0, int base = 10);
+
+ long long stoll(const u16string& str, size_t *idx
+= 0, int base = 10);

- 
-  float stof(const u16string& str, size_t *idx =
- 0);
+
+ unsigned long long stoull(const u16string& str,
+size_t *idx = 0, int base = 10);

- 
-  double stod(const u16string& str, size_t *idx =
- 0);
+
+ float stof(const u16string& str, size_t *idx =
+0);

- 
-  long double stold(const u16string& str, size_t
- *idx = 0);
+
+ double stod(const u16string& str, size_t *idx =
+0);

- 
-  u16string to_u16string(long long val);
+
+ long double stold(const u16string& str, size_t
+*idx = 0);

- 
-  u16string to_u16string(unsigned long long val);
+
+ u16string to_u16string(long long val);

- 
-  u16string to_u16string(long double val);
+
+ u16string to_u16string(unsigned long long val);

- 
-  
+
+ u16string to_u16string(long double val);

- 
-   int stoi(const u32string& str, size_t *idx = 0,
- int base = 10);
+
+ 

- 
-  long stol(const u32string& str, size_t *idx = 0,
- int base = 10);
+
+  int stoi(const u32string& str, size_t *idx = 0,
+int base = 10);

- 
-  unsigned long stoul(const u32string& str, size_t
- *idx = 0, int base = 10);
+
+ long stol(const u32string& str, size_t *idx = 0,
+int base = 10);

- 
-  long long stoll(const u32string& str, size_t *idx
- = 0, int base = 10);
+
+ unsigned long stoul(const u32string& str, size_t
+*idx = 0, int base = 10);

- 
-  unsigned long long stoull(const u32string& str,
- size_t *idx = 0, int base = 10);
+
+ long long stoll(const u32string& str, size_t *idx
+= 0, int base = 10);

- 
-  float stof(const u32string& str, size_t *idx =
- 0);
+
+ unsigned long long stoull(const u32string& str,
+size_t *idx = 0, int base = 10);

- 
-  double stod(const u32string& str, size_t *idx =
- 0);
+
+ float stof(const u32string& str, size_t *idx =
+0);

- 
-  long double stold(const u32string& str, size_t
- *idx = 0);
+
+ double stod(const u32string& str, size_t *idx =
+0);

- 
-  u32string to_u32string(long long val);
+
+ long double stold(const u32string& str, size_t
+*idx = 0);

- 
-  u32string to_u32string(unsigned long long val);
+
+ u32string to_u32string(long long val);

- 
-  u32string to_u32string(long double val);
+
+ u32string to_u32string(unsigned long long val);

- }
+
+ u32string to_u32string(long double val);

- 
- 
+}

- 
- 27.2
+
+ 

- 
-  
+
+27.2

- 
- namespace std {
+
+ 

- 
-  ...
+
+namespace std {

- 
-  typedef basic_ios<char> ios;
+
+ ...

- 
-  typedef basic_ios<wchar_t> wios;
+
+ typedef basic_ios<char> ios;

- 
-  typedef basic_ios<char16_t> u16ios;
+
+ typedef basic_ios<wchar_t> wios;

- 
-  typedef basic_ios<char32_t> u32ios;
+
+ typedef basic_ios<char16_t> u16ios;

- 
-  
+
+ typedef basic_ios<char32_t> u32ios;

- 
-  ...
+
+ 

- 
-  typedef basic_ifstream<wchar_t> wifstream;
+
+ ...

- 
-  typedef basic_ofstream<wchar_t> wofstream;
+
+ typedef basic_ifstream<wchar_t> wifstream;

- 
-  typedef basic_fstream<wchar_t> wfstream;
+
+ typedef basic_ofstream<wchar_t> wofstream;

- 
-  
+
+ typedef basic_fstream<wchar_t> wfstream;

- 
-  typedef basic_streambuf<char16_t> u16streambuf;
+
+ 

- 
-  typedef basic_istream<char16_t> u16istream;
+
+ typedef basic_streambuf<char16_t> u16streambuf;

- 
-  typedef basic_ostream<char16_t> u16ostream;
+
+ typedef basic_istream<char16_t> u16istream;

- 
-  typedef basic_iostream<char16_t> u16iostream;
+
+ typedef basic_ostream<char16_t> u16ostream;

- 
-  
+
+ typedef basic_iostream<char16_t> u16iostream;

- 
-  typedef basic_stringbuf<char16_t> u16stringbuf;
+
+ 

- 
-  typedef basic_istringstream<char16_t>
- u16istringstream;
+
+ typedef basic_stringbuf<char16_t> u16stringbuf;

- 
-  typedef basic_ostringstream<char16_t>
- u16ostringstream;
+
+ typedef basic_istringstream<char16_t>
+u16istringstream;

- 
-  typedef basic_stringstream<char16_t>
- u16stringstream;
+
+ typedef basic_ostringstream<char16_t>
+u16ostringstream;

- 
-  typedef basic_filebuf<char16_t> u16filebuf;
+
+ typedef basic_stringstream<char16_t>
+u16stringstream;

- 
-  
+
+ typedef basic_filebuf<char16_t> u16filebuf;

- 
-  typedef basic_ifstream<char16_t> u16ifstream;
+
+ 

- 
-  typedef basic_ofstream<char16_t> u16ofstream;
+
+ typedef basic_ifstream<char16_t> u16ifstream;

- 
-  typedef basic_fstream<char16_t> u16fstream;
+
+ typedef basic_ofstream<char16_t> u16ofstream;

- 
-  
+
+ typedef basic_fstream<char16_t> u16fstream;

- 
-  typedef basic_streambuf<char32_t> u32streambuf;
+
+ 

- 
-  typedef basic_istream<char32_t> u32istream;
+
+ typedef basic_streambuf<char32_t> u32streambuf;

- 
-  typedef basic_ostream<char32_t> u32ostream;
+
+ typedef basic_istream<char32_t> u32istream;

- 
-  typedef basic_iostream<char32_t> u32iostream;
+
+ typedef basic_ostream<char32_t> u32ostream;

- 
-  
+
+ typedef basic_iostream<char32_t> u32iostream;

- 
-  typedef basic_stringbuf<char32_t> u32stringbuf;
+
+ 

- 
-  typedef basic_istringstream<char32_t>
- u32istringstream;
+
+ typedef basic_stringbuf<char32_t> u32stringbuf;

- 
-  typedef basic_ostringstream<char32_t>
- u32ostringstream;
+
+ typedef basic_istringstream<char32_t>
+u32istringstream;

- 
-  typedef basic_stringstream<char32_t>
- u32stringstream;
+
+ typedef basic_ostringstream<char32_t>
+u32ostringstream;

- 
-  typedef basic_filebuf<char32_t> u32filebuf;
+
+ typedef basic_stringstream<char32_t>
+u32stringstream;

- 
-  
+
+ typedef basic_filebuf<char32_t> u32filebuf;

- 
-  typedef basic_ifstream<char32_t> u32ifstream;
+
+ 

- 
-  typedef basic_ofstream<char32_t> u32ofstream;
+
+ typedef basic_ifstream<char32_t> u32ifstream;

- 
-  typedef basic_fstream<char32_t>
- u32fstream;
+
+ typedef basic_ofstream<char32_t> u32ofstream;

- 
-  
+
+ typedef basic_fstream<char32_t>
+u32fstream;

- 
-  ...
+
+ 

- 
-  template <class state> class fpos;
+
+ ...

- 
-  typedef
- fpos<char_traits<char>::state_type> streampos;
+
+ template <class state> class fpos;

- 
-  typedef
- fpos<char_traits<wchar_t>::state_type>
- wstreampos;
+
+ typedef
+fpos<char_traits<char>::state_type> streampos;

- 
-  typedef
- fpos<char_traits<char16_t>::state_type>
- u16streampos;
+
+ typedef
+fpos<char_traits<wchar_t>::state_type>
+wstreampos;

- 
-  typedef
- fpos<char_traits<char32_t>::state_type>
- u32streampos;
+
+ typedef
+fpos<char_traits<char16_t>::state_type>
+u16streampos;

- }
+
+ typedef
+fpos<char_traits<char32_t>::state_type>
+u32streampos;

- 
- 
+}

- 
- 27.6
+
+ 

- 
-  
+
+27.6

- 
- namespace std {
+
+ 

- 
-  template <class charT, class traits =
- char_traits<charT> >
+
+namespace std {

- 
-  class basic_istream;
+
+ template <class charT, class traits =
+char_traits<charT> >

- 
-  typedef basic_istream<char> istream;
+
+ class basic_istream;

- 
-  typedef basic_istream<wchar_t> wistream;
+
+ typedef basic_istream<char> istream;

- 
-  typedef basic_istream<char16_t>
- u16istream;
+
+ typedef basic_istream<wchar_t> wistream;

- 
-  typedef basic_istream<char32_t> u32istream;
+
+ typedef basic_istream<char16_t>
+u16istream;

- 
-  
+
+ typedef basic_istream<char32_t> u32istream;

- 
-  template <class charT, class traits =
- char_traits<charT> >
+
+ 

- 
-  class basic_iostream;
+
+ template <class charT, class traits =
+char_traits<charT> >

- 
-  typedef basic_iostream<char> iostream;
+
+ class basic_iostream;

- 
-  typedef basic_iostream<wchar_t> wiostream;
+
+ typedef basic_iostream<char> iostream;

- 
-  typedef basic_iostream<char16_t>
- u16iostream;
+
+ typedef basic_iostream<wchar_t> wiostream;

- 
-  typedef basic_iostream<char32_t> u32iostream;
+
+ typedef basic_iostream<char16_t>
+u16iostream;

- }
+
+ typedef basic_iostream<char32_t> u32iostream;

- 
-  
+}

- 
- namespace std {
+
+ 

- 
-  template <class charT, class traits =
- char_traits<charT> >
+
+namespace std {

- 
-  class basic_ostream;
+
+ template <class charT, class traits =
+char_traits<charT> >

- 
-  typedef basic_ostream<char> ostream;
+
+ class basic_ostream;

- 
-  typedef basic_ostream<wchar_t> wostream;
+
+ typedef basic_ostream<char> ostream;

- 
-  typedef basic_ostream<char16_t>
- u16ostream;
+
+ typedef basic_ostream<wchar_t> wostream;

- 
-  typedef basic_ostream<char32_t> u32ostream;
+
+ typedef basic_ostream<char16_t>
+u16ostream;

- }
+
+ typedef basic_ostream<char32_t> u32ostream;

- 
- 
+}

- 
- 27.7 paragraph 1
+
+ 

- 
-  
+
+27.7 paragraph 1

- 
- namespace std {
+
+ 

- 
-  template <class charT, class traits =
- char_traits<charT>,
+
+namespace std {

- 
-      class Allocator =
- allocator<charT> >
+
+ template <class charT, class traits =
+char_traits<charT>,

- 
-  class basic_stringbuf;
+
+     class Allocator =
+allocator<charT> >

- 
-  
+
+ class basic_stringbuf;

- 
-  typedef basic_stringbuf<char> stringbuf;
+
+ 

- 
-  typedef basic_stringbuf<wchar_t> wstringbuf;
+
+ typedef basic_stringbuf<char> stringbuf;

- 
-  typedef basic_stringbuf<char16_t>
- u16stringbuf;
+
+ typedef basic_stringbuf<wchar_t> wstringbuf;

- 
-  typedef basic_stringbuf<char32_t> u32stringbuf;
+
+ typedef basic_stringbuf<char16_t>
+u16stringbuf;

- 
-  
+
+ typedef basic_stringbuf<char32_t> u32stringbuf;

- 
-  template <class charT, class traits =
- char_traits<charT>,
+
+ 

- 
-      class Allocator =
- allocator<charT> >
+
+ template <class charT, class traits =
+char_traits<charT>,

- 
-  class basic_istringstream;
+
+     class Allocator =
+allocator<charT> >

- 
-  
+
+ class basic_istringstream;

- 
-  typedef basic_istringstream<char>
- istringstream;
+
+ 

- 
-  typedef basic_istringstream<wchar_t>
- wistringstream;
+
+ typedef basic_istringstream<char>
+istringstream;

- 
-  typedef basic_istringstream<char16_t>
- u16istringstream;
+
+ typedef basic_istringstream<wchar_t>
+wistringstream;

- 
-  typedef basic_istringstream<char32_t>
- u32istringstream;
+
+ typedef basic_istringstream<char16_t>
+u16istringstream;

- 
-  
+
+ typedef basic_istringstream<char32_t>
+u32istringstream;

- 
-  template <class charT, class traits =
- char_traits<charT>,
+
+ 

- 
-      class Allocator =
- allocator<charT> >
+
+ template <class charT, class traits =
+char_traits<charT>,

- 
-  class basic_ostringstream;
+
+     class Allocator =
+allocator<charT> >

- 
-  
+
+ class basic_ostringstream;

- 
-  typedef basic_ostringstream<char>
- ostringstream;
+
+ 

- 
-  typedef basic_ostringstream<wchar_t>
- wostringstream;
+
+ typedef basic_ostringstream<char>
+ostringstream;

- 
-  typedef basic_ostringstream<char16_t>
- u16ostringstream;
+
+ typedef basic_ostringstream<wchar_t>
+wostringstream;

- 
-  typedef basic_ostringstream<char32_t>
- u32ostringstream;
+
+ typedef basic_ostringstream<char16_t>
+u16ostringstream;

- 
-  
+
+ typedef basic_ostringstream<char32_t>
+u32ostringstream;

- 
-  template <class charT, class traits =
- char_traits<charT>,
+
+ 

- 
-      class Allocator =
- allocator<charT> >
+
+ template <class charT, class traits =
+char_traits<charT>,

- 
-  class basic_stringstream;
+
+     class Allocator =
+allocator<charT> >

- 
-  
+
+ class basic_stringstream;

- 
-  typedef basic_stringstream<char> stringstream;
+
+ 

- 
-  typedef basic_stringstream<wchar_t>
- wstringstream;
+
+ typedef basic_stringstream<char> stringstream;

- 
-  typedef basic_stringstream<char16_t>
- u16stringstream;
+
+ typedef basic_stringstream<wchar_t>
+wstringstream;

- 
-  typedef basic_stringstream<char32_t>
- u32stringstream;
+
+ typedef basic_stringstream<char16_t>
+u16stringstream;

- }
+
+ typedef basic_stringstream<char32_t>
+u32stringstream;

- 
- 
+}

- 
- 27.8.1 paragraph 1
+
+ 

- 
-  
+
+27.8.1 paragraph 1

- 
- namespace std {
+
+ 

- 
-  template <class charT, class traits =
- char_traits<charT> >
+
+namespace std {

- 
-  class basic_filebuf;
+
+ template <class charT, class traits =
+char_traits<charT> >

- 
-  typedef basic_filebuf<char> filebuf;
+
+ class basic_filebuf;

- 
-  typedef basic_filebuf<wchar_t> wfilebuf;
+
+ typedef basic_filebuf<char> filebuf;

- 
-  typedef basic_filebuf<char16_t>
- u16filebuf;
+
+ typedef basic_filebuf<wchar_t> wfilebuf;

- 
-  typedef basic_filebuf<char32_t> u32filebuf;
+
+ typedef basic_filebuf<char16_t>
+u16filebuf;

- 
-  
+
+ typedef basic_filebuf<char32_t> u32filebuf;

- 
-  template <class charT, class traits =
- char_traits<charT> >
+
+ 

- 
-  class basic_ifstream;
+
+ template <class charT, class traits =
+char_traits<charT> >

- 
-  typedef basic_ifstream<char> ifstream;
+
+ class basic_ifstream;

- 
-  typedef basic_ifstream<wchar_t> wifstream;
+
+ typedef basic_ifstream<char> ifstream;

- 
-  typedef basic_ifstream<char16_t>
- u16ifstream;
+
+ typedef basic_ifstream<wchar_t> wifstream;

- 
-  typedef basic_ifstream<char32_t> u32ifstream;
+
+ typedef basic_ifstream<char16_t>
+u16ifstream;

- 
-  
+
+ typedef basic_ifstream<char32_t> u32ifstream;

- 
-  template <class charT, class traits =
- char_traits<charT> >
+
+ 

- 
-  class basic_ofstream;
+
+ template <class charT, class traits =
+char_traits<charT> >

- 
-  typedef basic_ofstream<char> ofstream;
+
+ class basic_ofstream;

- 
-  typedef basic_ofstream<wchar_t> wofstream;
+
+ typedef basic_ofstream<char> ofstream;

- 
-  typedef basic_ofstream<char16_t>
- u16ofstream;
+
+ typedef basic_ofstream<wchar_t> wofstream;

- 
-  typedef basic_ofstream<char32_t> u32ofstream;
+
+ typedef basic_ofstream<char16_t>
+u16ofstream;

- 
-  
+
+ typedef basic_ofstream<char32_t> u32ofstream;

- 
-  template <class charT, class traits =
- char_traits<charT> >
+
+ 

- 
-  class basic_fstream;
+
+ template <class charT, class traits =
+char_traits<charT> >

- 
-  typedef basic_fstream<char> fstream;
+
+ class basic_fstream;

- 
-  typedef basic_fstream<wchar_t> wfstream;
+
+ typedef basic_fstream<char> fstream;

- 
-  typedef basic_fstream<char16_t>
- u16fstream;
+
+ typedef basic_fstream<wchar_t> wfstream;

- 
-  typedef basic_fstream<char32_t> u32fstream;
+
+ typedef basic_fstream<char16_t>
+u16fstream;

- }
+
+ typedef basic_fstream<char32_t> u32fstream;

- 
- 
+}

- 
- 28.4
+
+ 

- 
-  
+
+28.4

- 
- namespace std {
+
+ 

- 
-  ...
+
+namespace std {

- 
-  typedef basic_regex<char> regex;
+
+ ...

- 
-  typedef basic_regex<wchar_t> wregex;
+
+ typedef basic_regex<char> regex;

- 
-  typedef basic_regex<char16_t> u16regex;
+
+ typedef basic_regex<wchar_t> wregex;

- 
-  typedef basic_regex<char32_t> u32regex;
+
+ typedef basic_regex<char16_t> u16regex;

- 
-  
+
+ typedef basic_regex<char32_t> u32regex;

- 
-  ...
+
+ 

- 
-  typedef sub_match<const char*> csub_match;
+
+ ...

- 
-  typedef sub_match<const wchar_t*> wcsub_match;
+
+ typedef sub_match<const char*> csub_match;

- 
-  typedef sub_match<const char16_t*>
- u16csub_match;
+
+ typedef sub_match<const wchar_t*> wcsub_match;

- 
-  typedef sub_match<const char32_t*>
- u16csub_match;
+
+ typedef sub_match<const char16_t*>
+u16csub_match;

- 
-  typedef sub_match<string::const_iterator>
- ssub_match;
+
+ typedef sub_match<const char32_t*>
+u16csub_match;

- 
-  typedef sub_match<wstring::const_iterator>
- wssub_match;
+
+ typedef sub_match<string::const_iterator>
+ssub_match;

- 
-  typedef sub_match<u16string::const_iterator>
- u16ssub_match;
+
+ typedef sub_match<wstring::const_iterator>
+wssub_match;

- 
-  typedef sub_match<u32string::const_iterator>
- u32ssub_match;
+
+ typedef sub_match<u16string::const_iterator>
+u16ssub_match;

- 
-  
+
+ typedef sub_match<u32string::const_iterator>
+u32ssub_match;

- 
-  ...
+
+ 

- 
-  typedef match_results<const char*> cmatch;
+
+ ...

- 
-  typedef match_results<const wchar_t*> wcmatch;
+
+ typedef match_results<const char*> cmatch;

- 
-  typedef match_results<const char16_t*>
- u16cmatch;
+
+ typedef match_results<const wchar_t*> wcmatch;

- 
-  typedef match_results<const char32_t*>
- u32cmatch;
+
+ typedef match_results<const char16_t*>
+u16cmatch;

- 
-  typedef match_results<string::const_iterator>
- smatch;
+
+ typedef match_results<const char32_t*>
+u32cmatch;

- 
-  typedef match_results<wstring::const_iterator>
- wsmatch;
+
+ typedef match_results<string::const_iterator>
+smatch;

- 
-  typedef
- match_results<u16string::const_iterator> u16smatch;
+
+ typedef match_results<wstring::const_iterator>
+wsmatch;

- 
-  typedef
- match_results<u32string::const_iterator> u32smatch;
+
+ typedef
+match_results<u16string::const_iterator> u16smatch;

- 
-  
+
+ typedef
+match_results<u32string::const_iterator> u32smatch;

- 
-  ...
+
+ 

- 
-  typedef regex_iterator<const char*>
- cregex_iterator;
+
+ ...

- 
-  typedef regex_iterator<const wchar_t*>
- wcregex_iterator;
+
+ typedef regex_iterator<const char*>
+cregex_iterator;

- 
-  typedef regex_iterator<const cha16r_t*>
- u16cregex_iterator;
+
+ typedef regex_iterator<const wchar_t*>
+wcregex_iterator;

- 
-  typedef regex_iterator<const char32_t*>
- u32cregex_iterator;
+
+ typedef regex_iterator<const cha16r_t*>
+u16cregex_iterator;

- 
-  typedef regex_iterator<string::const_iterator>
- sregex_iterator;
+
+ typedef regex_iterator<const char32_t*>
+u32cregex_iterator;

- 
-  typedef regex_iterator<wstring::const_iterator>
- wsregex_iterator;
+
+ typedef regex_iterator<string::const_iterator>
+sregex_iterator;

- 
-  typedef
- regex_iterator<u16string::const_iterator>
- u16sregex_iterator;
+
+ typedef regex_iterator<wstring::const_iterator>
+wsregex_iterator;

- 
-  typedef
- regex_iterator<u32string::const_iterator>
- u32sregex_iterator;
+
+ typedef
+regex_iterator<u16string::const_iterator>
+u16sregex_iterator;

- 
-  
+
+ typedef
+regex_iterator<u32string::const_iterator>
+u32sregex_iterator;

- 
-  ...
+
+ 

- 
-  typedef regex_token_iterator<const char*>
- cregex_token_iterator;
+
+ ...

- 
-  typedef regex_token_iterator<const wchar_t*>
- wcregex_token_iterator;
+
+ typedef regex_token_iterator<const char*>
+cregex_token_iterator;

- 
-  typedef regex_token_iterator<const char16_t*>
- u16cregex_token_iterator;
+
+ typedef regex_token_iterator<const wchar_t*>
+wcregex_token_iterator;

- 
-  typedef regex_token_iterator<const char32_t*>
- u32cregex_token_iterator;
+
+ typedef regex_token_iterator<const char16_t*>
+u16cregex_token_iterator;

- 
-  typedef
- regex_token_iterator<string::const_iterator>
- sregex_token_iterator;
+
+ typedef regex_token_iterator<const char32_t*>
+u32cregex_token_iterator;

- 
-  typedef
- regex_token_iterator<wstring::const_iterator>
- 　　　wsregex_token_iterator;
+
+ typedef
+regex_token_iterator<string::const_iterator>
+sregex_token_iterator;

- 
-  typedef
- regex_token_iterator<u16string::const_iterator>
- u16sregex_token_iterator;
+
+ typedef
+regex_token_iterator<wstring::const_iterator>
+　　　wsregex_token_iterator;

- 
-  typedef
- regex_token_iterator<u32string::const_iterator>
- 　u32sregex_token_iterator;
+
+ typedef
+regex_token_iterator<u16string::const_iterator>
+u16sregex_token_iterator;

- }
+
+ typedef
+regex_token_iterator<u32string::const_iterator>
+　u32sregex_token_iterator;

- 
+}

- <td>
- 
-
- Previously considered; we decided not to do it. We believe it is not too
+<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>
- UK 
- 144
-
- <td>
- 17.1
-
- <td>
- 2
-
- <td>
- Ed
-
- <td>
- List of contents of library should be
- extened to cover new clauses
-
- <td>
- Add "regular expressions, atomic operations
- and threads"
+ intermediaries to avoid proliferation of types.

- <td>
- 
+<tr valign="top">
+<td>UK144

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 145
+<td>17.1

- <td>
- 17.1
+<td>2

- <td>
- 6
+<td>Ed

- <td>
- Ed
+<td>List of contents of library should be
+extened to cover new clauses

- <td>
- 
- Summary of numeric facilities should
- mention random numbers
+<td>Add "regular expressions, atomic operations
+and threads"

- 
+<td>[Being reviewed by Editor]

- <td>
- Add random number framework to the list of
- library facilities
+<tr valign="top">
+<td>UK145

- <td>
- 
+<td>17.1

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 146
+<td>6

- <td>
- 17.1
+<td>Ed

- <td>
- 
+<td>
+Summary of numeric facilities should
+mention random numbers

- <td>
- Ed
+<td>Add random number framework to the list of
+library facilities

- <td>
- Add a summary paragraph for regular
- expressions
+<td>[Being reviewed by Editor]

- <td>
- Add a summary paragraph for regular
- expressions
+<tr valign="top">
+<td>UK146

- <td>
- 
+<td>17.1

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 147
+<td>

- <td>
- 17.1
+<td>Ed

- <td>
- 
+<td>Add a summary paragraph for regular
+expressions

- <td>
- Ed
+<td>Add a summary paragraph for regular
+expressions

- <td>
- Add a summary paragraph for threads
+<td>[Being reviewed by Editor]

- <td>
- Add a summary paragraph for threads
+<tr valign="top">
+<td>UK147

- <td>
- 
+<td>17.1

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 148
+<td>

- <td>
- 17.2
+<td>Ed

- <td>
- Table 12
+<td>Add a summary paragraph for threads

- <td>
- Ed
+<td>Add a summary paragraph for threads

- <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
- 17.3 which is rather unfortunate/confusing for the reader.
+<td>[Being reviewed by Editor]

- 
+<tr valign="top">
+<td>UK148

- <td>
- Make sure tables are rendered in the
- section to which they relate.
+<td>17.2

- <td>
- 
+<td>Table 12

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 149
+<td>Ed

- <td>
- 17.3
+<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
+17.3 which is rather unfortunate/confusing for the reader.

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

- <td>
- Ed
+<td>[Being reviewed by Editor]

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

- 
+<td>17.3

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

- <td>
- 
+<td>Ed

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 150
+<td>For consistency
+with narrow-oriented and wide-oriented streams, we should
+add terms for streams of Unicode character sequences

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

- <td>
- 
+<td>[Being reviewed by Editor]

- <td>
- Ed
+<tr valign="top">
+<td>UK150

- <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
- safely be performed unless it is assigned a new value.
- Library presentation would be simplified and made more
- precise if we introduce a term for this state. By analogy
- with singular iterators suggest the term 'singular object'
- or 'the object is in a singular state'.
+<td>17.3

- <td>
- Define 'singular
- state' such that an object with a singular state can only
- be assigned to or safely destroyed. Assiging a new value
- typically removes the singular state. Note that objects
- with a singular state may not be safely copied, so you
- cannot put an object into a singular state by copying
- another object in a singular state. Use this new term in
- the postcondition of all library APIs that move from an
- rvalue reference. It might also be used to simplify the
- definition of singular iterator to an iterator value with a
- singular state.
+<td>

- 
+<td>Ed

- <td>
- 
+<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
+safely be performed unless it is assigned a new value.
+Library presentation would be simplified and made more
+precise if we introduce a term for this state. By analogy
+with singular iterators suggest the term 'singular object'
+or 'the object is in a singular state'.

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 151
+<td>Define 'singular
+state' such that an object with a singular state can only
+be assigned to or safely destroyed. Assiging a new value
+typically removes the singular state. Note that objects
+with a singular state may not be safely copied, so you
+cannot put an object into a singular state by copying
+another object in a singular state. Use this new term in
+the postcondition of all library APIs that move from an
+rvalue reference. It might also be used to simplify the
+definition of singular iterator to an iterator value with a
+singular state.

- <td>
- 17.3.1
+<td>[Being reviewed by Editor]

- <td>
- 
+<tr valign="top">
+<td>UK151

- <td>
- Ed
+<td>17.3.1

- <td>
- Missing
- crossreference to 17.3.17 [defns.repositional.stream]
+<td>

- 
+<td>Ed

- <td>
- Add cross-reference in the existing empty
- brackets
+<td>Missing
+crossreference to 17.3.17 [defns.repositional.stream]

- <td>
- 
+<td>Add cross-reference in the existing empty
+brackets

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 152
+<td>[Being reviewed by Editor]

- <td>
- 17.3.12
+<tr valign="top">
+<td>UK152

- <td>
- 
+<td>17.3.12

- <td>
- Te
+<td>

- <td>
- Object state is
- using a definition of object (instance of a class) from
- outside the standard, rather than the 'region of storage'
- definiton in 1.8p1
+<td>Te

- 
+<td>Object state is
+using a definition of object (instance of a class) from
+outside the standard, rather than the 'region of storage'
+definiton in 1.8p1

- <td>
- Clarify terms and usage
+<td>Clarify terms and usage

- <td>
- 
+<td>we think we're removing this; Howard to create LWG issue. Howard, see [func.referenceclosure.cons]

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

- <td>
- 17.3.17
+<td>17.3.17

- <td>
- 
+<td>

- <td>
- Te
+<td>Te

- <td>
- If a
- repositional stream can only seek to a position previously
- encountered, then an arbitrary-positional-stream cannot
- satisfy this definition, as cross-referenced in 17.3.17
+<td>If a
+repositional stream can only seek to a position previously
+encountered, then an arbitrary-positional-stream cannot
+satisfy this definition, as cross-referenced in 17.3.17

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

- <td>
- Strike the word 'only'. A note might be
- added to reinforce the intent
+<td>editorial; sent to Pete Becker

- <td>
- 
+<tr valign="top">
+<td>UK154

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

- 
+<td>17.3.20

- <td>
- 17.3.20
+<td>

- <td>
- 
+<td>Ed

- <td>
- Ed
+<td>Missing definition of a stable partition
+algorithm

- <td>
- Missing definition of a stable partition
- algorithm
+<td>Add definition from 25.2.12p7

- <td>
- Add definition from 25.2.12p7
+<td>[Being reviewed by Editor]

- <td>
- 
+<tr valign="top">
+<td>UK155

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 155
+<td>17.3.3

- <td>
- 17.3.3
+<td>

- <td>
- 
+<td>Ed

- <td>
- Ed
+<td>Add clause 28 to list that use this
+definition of character

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

- <td>
- Add clause 28 to list that use this
- definition of character
+<td>[Being reviewed by Editor]

- <td>
- 
+<tr valign="top">
+<td>UK156

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 156
+<td>17.3.4

- <td>
- 17.3.4
+<td>

- <td>
- 
+<td>Ed

- <td>
- Ed
+<td>Add regular
+expressions to set of templates using character container
+type

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

- 
+<td>[Being reviewed by Editor]

- <td>
- Add regular expressions to set of templates
- using character container type
+<tr valign="top">
+<td>UK157

- <td>
- 
+<td>17.5.2.2

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 157
+<td>3

- <td>
- 17.5.2.2
+<td>Ed

- <td>
- 3
+<td>Add concepts to
+the ordered list of presentation

- <td>
- Ed
+ 

- <td>
- Add concepts to
- the ordered list of presentation
+<td>Add concepts into the sequence

- 
+<td>[Being reviewed by Editor]

- 
+<tr valign="top">
+<td>UK158

- <td>
- Add concepts into the sequence
+<td>17.5.2.2

- <td>
- 
+<td>3

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 158
+<td>Ed

- <td>
- 17.5.2.2
+<td>templates are neither classes nor functions

- <td>
- 3
+<td>Replace
+'classes' and 'functions' with 'classes and class
+templates' and 'functions and function templates'

- <td>
- Ed
+<td>[Being reviewed by Editor]

- <td>
- templates are neither classes nor functions
+<tr valign="top">
+<td>UK159

- <td>
- Replace
- 'classes' and 'functions' with 'classes and class
- templates' and 'functions and function templates'
+<td>17.5.2.4

- 
+<td>Footnote 152

- <td>
- 
+<td>Ed

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 159
+<td>This informative
+footnote was relevant in 1998, not 2008. The term 'existing
+vendors' may imply something different now

- <td>
- 17.5.2.4
+<td>Strike the footnote, or replace 'existing'
+with 'original' or similar

- <td>
- Footnote 152
+<td>[Being reviewed by Editor]

- <td>
- Ed
+<tr valign="top">
+<td>UK160

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

- 
+<td>3

- <td>
- Strike the footnote, or replace 'existing'
- with 'original' or similar
+<td>Ed

- <td>
- 
+<td>requires is now
+a keyword with a specific meaning related to concepts, and
+its use in library specifcation may be confusing. Generally
+the Requires clause is used to make requirements on the
+caller, not the library, so typically providing runtime
+pre-conditions. Suggest a new name to refflect that. Note
+that Clause 30 already seems to be written to this
+convention.

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 160
+<td>Replace 'Requires' with 'Preconditions'

- <td>
- 17.5.2.4
+<td>[Being reviewed by Editor]

- <td>
- 3
+<tr valign="top">
+<td>UK161

- <td>
- Ed
+<td>17.5.2.4

- <td>
- requires is now
- a keyword with a specific meaning related to concepts, and
- its use in library specifcation may be confusing. Generally
- the Requires clause is used to make requirements on the
- caller, not the library, so typically providing runtime
- pre-conditions. Suggest a new name to refflect that. Note
- that Clause 30 already seems to be written to this
- convention.
+<td>4

- 
+<td>Ed

- <td>
- Replace 'Requires' with 'Preconditions'
+<td>This paragraph
+is redundant as the definition of the term 'handler
+function' is already provided in 17.3. Are we in danger of
+proving two definitions of the same terms? Which is the
+'controlling' definition?

- <td>
- 
+<td>Strike 17.5.2.4p4

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 161
+<td>[Being reviewed by Editor]

- <td>
- 17.5.2.4
+<tr valign="top">
+<td>UK162

- <td>
- 4
+<td>17.5.2.4

- <td>
- Ed
+<td>3

- <td>
- This paragraph
- is redundant as the definition of the term 'handler
- function' is already provided in 17.3. Are we in danger of
- proving two definitions of the same terms? Which is the
- 'controlling' definition?
+<td>Ed

- 
+<td>Clause 30 makes
+use of a 'Synchronization' semantic element, that
+frequently appears either between Effects: and
+Postconditions:, or between Returns: and Throws:

- <td>
- Strike 17.5.2.4p4
+<td>Add 'Synchronization' to the list either
+between Effects: and Postconditions:, or between Returns:
+and Throws:.

- <td>
- 
+<td>[Being reviewed by Editor]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 162
+<tr valign="top">
+<td>UK163

- <td>
- 17.5.2.4
+<td>17.5.2.4

- <td>
- 3
+<td>3

- <td>
- Ed
+<td>Te

- <td>
- Clause 30 makes
- use of a 'Synchronization' semantic element, that
- frequently appears either between Effects: and
- Postconditions:, or between Returns: and Throws:
+<td>Many functions
+are defined as "Effects: Equivalent to a...", which seems
+to also define the preconditions, effects, etc. But this is
+not made clear.

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

- <td>
- Add 'Synchronization' to the list either
- between Effects: and Postconditions:, or between Returns:
- and Throws:.
+<td>Tom Plum to open LWG issue; we believe this is related to
+ LWG625

- <td>
- 
+<tr valign="top">
+<td>UK164

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 163
+<td>17.5.3.2.1

- <td>
- 17.5.2.4
+<td>1

- <td>
- 3
+<td>Ed

- <td>
- Te
+<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>
- Many functions
- are defined as "Effects: Equivalent to a...", which seems
- to also define the preconditions, effects, etc. But this is
- not made clear.
+<td>Use better names
+for the examples. Ideally totally replace the need by
+constraining all templates in library, so that real
+concepts are all that is needed. Note if retained that
+CopyConstructible is mis-spelled.

- 
+<td>[Being reviewed by Editor]

- <td>
- Introduce an explicit "Equivalent to",
- which defines all of the properties of the function.
+<tr valign="top">
+<td>UK165

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

- <td>
- 17.5.3.2.1
+<td>

- <td>
- 1
+<td>Te

- <td>
- Ed
+<td>constraints on
+bitmask and enumation types were supposed to be tightened
+up as part of the motivation for the constexpr feature -
+see paper n2235 for deails

- <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>Adopt wording in line with the motivation
+described in N2235

- <td>
- Use better names
- for the examples. Ideally totally replace the need by
- constraining all templates in library, so that real
- concepts are all that is needed. Note if retained that
- CopyConstructible is mis-spelled.
+<td>Robert Klarer to review

- 
+<tr valign="top">
+<td>UK166

- <td>
- 
+<td>17.5.3. 
+2.4.1, 
+17.5.3.3

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 165
+<td>

- <td>
- 17.5.3.2.2, 
- 17.5.3.2.3
+<td>Ed

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

- <td>
- Te
+<td>Replace initial refernce to ch27 with ch30

- <td>
- constraints on
- bitmask and enumation types were supposed to be tightened
- up as part of the motivation for the constexpr feature -
- see paper n2235 for deails
+<td>[Being reviewed by Editor]

- 
+<tr valign="top">
+<td>UK167

- <td>
- Adopt wording in line with the motivation
- described in N2235
+<td>17.5.3.4 
+ Private 
+ members

- <td>
- 
+<td>

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

- <td>
- 17.5.3. 
- 2.4.1, 
- 17.5.3.3
+<td>Comment marker in wrong place.

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

- <td>
- 
+<td>[Being reviewed by Editor]

- <td>
- Ed
+<tr valign="top">
+<td>UK168

- <td>
- List of library clauses should go up to 30,
- not 27
+<td>17.6.2.2

- <td>
- Replace initial refernce to ch27 with ch30
+<td>2

- <td>
- 
+<td>Te

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 167
+<td>We should make
+it clear (either by note or normatively) that namespace std
+may contain inline namespaces, and that entities specified
+to be defined in std may in fact be defined in one of these
+inline namespaces. (If we're going to use them for
+versioning, eg when TR2 comes along, we're going to need
+that.)

- <td>
- 17.5.3.4 
- Private 
- members
+<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>
- 
+<td>Howard will create issue to adopt UK words (some have reservations whether
+ it is correct)

- <td>
- Ed
+<tr valign="top">
+<td>UK169

- <td>
- Comment marker in wrong place.
+<td>17.6.2.2

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

- 
+<td>Te

- <td>
- 
+<td>This phrasing
+contradicts later freedom to implement the C standard
+library portions in the global namespace as well as std.
+(17.6.2.3p4)

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 168
+<td>Resolve conflict in either place

- <td>
- 17.6.2.2
+<td>Bill Plauger to open issue. If the wording is too broad we need to add an
+ exception to the standard C library.

- <td>
- 2
+<tr valign="top">
+<td>UK170

- <td>
- Te
+<td>17.6.2.3

- <td>
- We should make
- it clear (either by note or normatively) that namespace std
- may contain inline namespaces, and that entities specified
- to be defined in std may in fact be defined in one of these
- inline namespaces. (If we're going to use them for
- versioning, eg when TR2 comes along, we're going to need
- that.)
+<td>

- 
+<td>Te

- <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>One of goals of
+C++0x is to make language easier to teach and for
+'incidental' programmers. The fine-grained headers of the
+C++ library are valuable in large scale systems for
+managing dependencies and optimising build times, but
+overcomplicated for simple development and tutorials. Add
+additional headers to support the whole library through a
+single include statement.

- <td>
- 
+<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.

- Howard will create issue to adopt UK words (some have reservations whether
- it is correct)<tr valign="top">
- <td>
- UK 
- 169
+<td>Alisdair to open issue. We prefer <std> only.

- <td>
- 17.6.2.2
+<tr valign="top">
+<td>UK171

- <td>
- 
+<td>17.6.2.4

- <td>
- Te
+<td>3

- <td>
- This phrasing
- contradicts later freedom to implement the C standard
- library portions in the global namespace as well as std.
- (17.6.2.3p4)
+<td>Ed

- 
+<td>Does
+freestanding implementation require a full implementation
+of all listed headers? The reference to abort, at_exit and
+exit is confusing. Is a conforming implementation allow to
+deliver partial forms of these headers? If so which ones?
+Are empty versions of everything but <cstdlib>
+conforming?

- <td>
- Resolve conflict in either place
+<td>Either strike the references to abort,
+at_exit and exit, or clarify which headers only require
+partial support.

- <td>
- 
+<td>[Being reviewed by Editor]

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

- <td>
- 17.6.2.3
+<td>17.6.2.4

- <td>
- 
+<td>3

- <td>
- Te
+<td>Te

- <td>
- One of goals of
- C++0x is to make language easier to teach and for
- 'incidental' programmers. The fine-grained headers of the
- C++ library are valuable in large scale systems for
- managing dependencies and optimising build times, but
- overcomplicated for simple development and tutorials. Add
- additional headers to support the whole library through a
- single include statement.
+<td>No reference to
+new functions quick_exit and at_quick_exit

- 
+<td>Add reference to quick_exit and
+at_quick_exit

- <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>NAD. We do not belive at_exit and at_quick_exit should be required by
+ freestanding implementations.

- <td>
- 
+<tr valign="top">
+<td>UK173

- Alisdair to open issue. We prefer <std> only.<tr valign="top">
- <td>
- UK 
- 171
+<td>17.6.2.4

- <td>
- 17.6.2.4
+<td>table 15

- <td>
- 3
+<td>Te

- <td>
- Ed
+<td>
+<initializer_list> is missing from headers required
+in freestanding implementations.

- <td>
- Does
- freestanding implementation require a full implementation
- of all listed headers? The reference to abort, at_exit and
- exit is confusing. Is a conforming implementation allow to
- deliver partial forms of these headers? If so which ones?
- Are empty versions of everything but <cstdlib>
- conforming?
+<td>Add 18.8, initializer lists,
+<initializer_list>, to the end of the table.

- 
+<td>LWG is interested in
+ N2814, but we're concerned whether CWG will accept
+ language recommendations.

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

- <td>
- 
+<td>17.6.2.4

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 172
+<td>2nd para, Table 15

- <td>
- 17.6.2.4
+<td>te

- <td>
- 3
+<td>There is a
+freestanding implementation including <type_traits>,
+<array>, <ratio>, lately added to Table 13, C++
+library headers. 
+Programmers think them useful and hope that these headers
+are also added to Table 15, C++ headers for freestanding
+implementations, that shows the set of headers which a
+freestanding implementation shall include at least.

- <td>
- Te
+
+ 

- <td>
- No reference to
- new functions quick_exit and at_quick_exit
+<td>Add
+<type_traits>, <array>, <ration> to Table
+15.

- 
+<td>LWG is interested in
+ N2814, but we're concerned whether CWG will accept
+ language recommendations.

- <td>
- Add reference to quick_exit and
- at_quick_exit
+ add <type_traits> only. Alisdair will draft an issue.

- <td>
- 
+<tr valign="top">
+<td>UK174

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

- <td>
- 17.6.2.4
+<td>3

- <td>
- table 15
+<td>Ed

- <td>
- Te
+<td>The phrasing is
+mildly ambiguous when using the word 'it' to refer back to
+the header - an unfotunate reading might confuse it with
+the translate unit, which is the subject of the surrounding
+clause.

- <td>
- 
- <initializer_list> is missing from headers required
- in freestanding implementations.
+<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>[Being reviewed by Editor]

- <td>
- Add 18.8, initializer lists,
- <initializer_list>, to the end of the table.
+<tr valign="top">
+<td>UK175

- <td>
- 
+<td>17.6.4.2.1

- LWG is interested in
- N2814, but we're concerned whether CWG will accept
- language recommendations.<tr valign="top">
- <td>
- JP 23
-
- <td>
- 17.6.2.4
-
- <td>
- 2nd para, Table 15
-
- <td>
- te
-
- <td>
- There is a
- freestanding implementation including <type_traits>,
- <array>, <ratio>, lately added to Table 13, C++
- library headers. 
- Programmers think them useful and hope that these headers
- are also added to Table 15, C++ headers for freestanding
- implementations, that shows the set of headers which a
- freestanding implementation shall include at least.
-
- 
- 
-
- <td>
- Add
- <type_traits>, <array>, <ration> to Table
- 15.
+<td>2

- <td>
- 
+<td>Te

- LWG is interested in
- N2814, but we're concerned whether CWG will accept
- language recommendations.
+<td>Local types can
+now be used to instantiate templates, but don't have
+external linkage

- add <type_traits> only. Alisdair will draft an issue.<tr valign="top">
- <td>
- UK 
- 174
+<td>Remove the reference to external linkage

- <td>
- 17.6.3.2
+<td>we accept the proposed solution. Martin will draft an issue.

- <td>
- 3
+<tr valign="top">
+<td>UK176

- <td>
- Ed
+<td>17.6.4.3.3

- <td>
- The phrasing is
- mildly ambiguous when using the word 'it' to refer back to
- the header - an unfotunate reading might confuse it with
- the translate unit, which is the subject of the surrounding
- clause.
+<td>Footnote 175

- 
+<td>Ed

- <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>Reference to namespace ::std should be
+17.6.4.2

- <td>
- 
+<td>Change referfence from 17.6.4.3 to 17.6.4.2

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 175
+<td>[Being reviewed by Editor]

- <td>
- 17.6.4.2.1
+<tr valign="top">
+<td>UK177

- <td>
- 2
+<td>17.6.4.3.4

- <td>
- Te
+<td>3

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

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

- <td>
- Remove the reference to external linkage
+<td>Strike the sentence

- <td>
- 
+<td>[Being reviewed by Editor]

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

- <td>
- 17.6.4.3.3
+<td>17.6.4.8

- <td>
- Footnote 175
+<td>2

- 
+<td>Ed

- <td>
- Ed
+<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>
- Reference to namespace ::std should be
- 17.6.4.2
+<td>Strike the sentence

- <td>
- Change referfence from 17.6.4.3 to 17.6.4.2
+<td>[Being reviewed by Editor]

- <td>
- 
+<tr valign="top">
+<td>UK179

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 177
+<td>17.6.4.8

- <td>
- 17.6.4.3.4
+<td>2

- <td>
- 3
+<td>Te

- <td>
- Ed
+<td>According to the
+4th bullet there is a problem if "if any replacement
+function or handler function or destructor operation throws
+an exception". There should be no problem throwing
+exceptions so long as they are caught within the function.

- <td>
- Sentence is
- redundant as double underscores are reserved in all
- contexts by 17.6.4.3.3
+<td>Replace the word 'throws' with 'propogates'

- 
+<td>Agreed. Alisdair will draft an issue.

- <td>
- Strike the sentence
+<tr valign="top">
+<td>JP22

- <td>
- 
+<td>17.6.5.7

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 178
+<td>4th para, 1st
+line

- <td>
- 17.6.4.8
+<td>ed

- <td>
- 2
+<td>The
+statement below describes relation among two or more
+threads using words “between threads”: 
+[Note: This means, for example, that implementations
+can’t use a static object for internal purposes
+without synchronization because it could cause a data race
+even in programs that do not explicitly share objects
+between threads. —end note ]

- <td>
- Ed
+In
+such case, “among” is preferred instead of
+“between”.

- <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>
+Change "between threads" to "among threads".

- <td>
- Strike the sentence
+
+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>
- 
+<td>[Being reviewed by Editor]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 179
+<tr valign="top">
+<td><a name="UK180">UK180</a>

- <td>
- 17.6.4.8
+<td>17.6.5.10

- <td>
- 2
+<td>1, 4

- <td>
- Te
+<td>Te

- <td>
- According to the
- 4th bullet there is a problem if "if any replacement
- function or handler function or destructor operation throws
- an exception". There should be no problem throwing
- exceptions so long as they are caught within the function.
+<td>It should not be
+possible to strengthen the exception specification for
+virtual functions as this could break user code. Note this
+is not a problem in practice as there are no virtual
+functions with exception specifications in the current
+library, other than empty throw specifications which it is
+not possible to strengthen.

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

- <td>
- Replace the word 'throws' with 'propogates'
+<td>NAD, the standard already has the desired restriction.

- <td>
- 
+<tr valign="top">
+<td>UK181

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

- <td>
- 17.6.5.7
+<td>Footnote 186

- <td>
- 4th para, 1st
- line
+<td>Te

- <td>
- ed
+<td>This footnote is
+wrong. C library functions do not have any exception
+specification, but might be treated as if they had an empty
+throw specification

- <td>
- The
- statement below describes relation among two or more
- threads using words “between threads”: 
- [Note: This means, for example, that implementations
- can’t use a static object for internal purposes
- without synchronization because it could cause a data race
- even in programs that do not explicitly share objects
- between threads. —end note ]
+<td>Clarify that this note does not mean the
+functions are genuinely declared with the specification,
+but are treated as-if.

- In
- such case, “among” is preferred instead of
- “between”.
+<td>We agree that the footnote is wrong and it will be removed. Pete will handle
+ as editorial.

- <td>
- 
- Change "between threads" to "among threads".
+<tr valign="top">
+<td>UK182

- 
- 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>17.6.5.10

- <td>
- 
+<td>Footnote 188

- [Being reviewed by Editor]<tr valign="top">
- <td>
- <a name="UK180">UK 
- 180</a>
+<td>Te

- <td>
- 17.6.5.10
+<td>It is very
+helpful to assume all exceptions thrown by the standard
+library derive from std::exception. The 'encouragement' of
+this note should be made normative.

- <td>
- 1, 4
+<td>Make this footnote normative

- <td>
- Te
+<td>NAD. We cannot mandate all standard-library functions that might use some
+ third-party library.

- <td>
- It should not be
- possible to strengthen the exception specification for
- virtual functions as this could break user code. Note this
- is not a problem in practice as there are no virtual
- functions with exception specifications in the current
- library, other than empty throw specifications which it is
- not possible to strengthen.
+<tr valign="top">
+<td>UK184

- 
+<td>18 -> 30

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

- <td>
- 
+<td>Ed

- NAD, the standard already has the desired restriction.<tr valign="top">
- <td>
- UK 
- 181
+<td>The new
+alias-declaration syntax is generally easier to read than a
+typedef declaration. This is especially true for complex
+types like function pointers.

- <td>
- 17.6.5.10
+<td>Replace all typedef declarations in the
+standard library with alias-declarations, except in the
+standard C library.

- <td>
- Footnote 186
+<td>[Being reviewed by Editor]

- <td>
- Te
+<tr valign="top">
+<td>JP24

- <td>
- This footnote is
- wrong. C library functions do not have any exception
- specification, but might be treated as if they had an empty
- throw specification
+<td>18

- 
+<td>2nd para, Table 16

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

- <td>
- 
+<td>
+Subclauses are listed in Table 16 as:

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

- <td>
- 17.6.5.10
+"18.8 Initializer
+lists …"

- <td>
- Footnote 188
+"18.7 Exception
+handling …".

- <td>
- Te
+<td>
+Sort them in the increasing order 
+"18.6 Type identification …"

- <td>
- It is very
- helpful to assume all exceptions thrown by the standard
- library derive from std::exception. The 'encouragement' of
- this note should be made normative.
+"18.7 Exception
+handling …".

- 
+
+"18.8 Initializer lists …"

- <td>
- Make this footnote normative
+ 

- <td>
- 
+<td>[Being reviewed by Editor]

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

- <td>
- 18 -> 30
+<td>18.1

- <td>
- 
+<td>
+6th para , last line, SEE ALSO

- <td>
- Ed
+<td>ed

- <td>
- The new
- alias-declaration syntax is generally easier to read than a
- typedef declaration. This is especially true for complex
- types like function pointers.
+<td>
+max_align_t is described in 18.1, so add 3.11 Alignment as
+the reference.

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

- <td>
- Replace all typedef declarations in the
- standard library with alias-declarations, except in the
- standard C library.
+<td>[Being reviewed by Editor]

- <td>
- 
+<tr valign="top">
+<td>FR32

- [Being reviewed by Editor]<tr valign="top">
- <td>
- JP 24
+<td>18.2.1 
+ [Numeric 
+ limits]

- <td>
- 18
+<td>

- <td>
- 2nd para, Table 16
+<td>te

- <td>
- ed
+<td>The definition of
+numeric_limits<> as requiring a regular type is both
+conceptually wrong and operationally illogical. As we
+pointed before, this mistake needs to be corrected. For
+example, the template can be left unconstrained. In fact
+this reflects a much more general problem with
+concept_maps/axioms and their interpretations. It appears
+that the current text heavily leans toward experimental
+academic type theory.

- <td>
- 
- Subclauses are listed in Table 16 as:
+

- "18.6 Type
- identification …"
+<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.

- "18.8 Initializer
- lists …"
+<td>Alisdair and Gaby will work on a resolution.

- "18.7 Exception
- handling …".
+<tr valign="top">
+<td>DE16

- <td>
- 
- Sort them in the increasing order 
- "18.6 Type identification …"
+<td>18.2.1

- "18.7 Exception
- handling …".
+<td>

- 
- "18.8 Initializer lists …"
+<td>te

- 
+<td>DE16 The class
+template numeric_limits should not specify the Regular
+concept requirement for its template parameter, because it
+contains functions returning NaN values for floating-point
+types; these values violate the semantics of
+EqualityComparable. See also library issue 902 in WG21
+document N2794 "C++ Standard Library Active Issues List
+(Revision R60)", available at
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html
+.

- <td>
- 
+

- [Being reviewed by Editor]<tr valign="top">
- <td>
- JP 25
+<td>Specify a concept requirement with fewer constraints as
+appropriate, for example SemiRegular.

- <td>
- 18.1
+<td>Alisdair and Gaby will work on a resolution.

- <td>
- 
- 6th para , last line, SEE ALSO
+<tr valign="top">
+<td>JP26

- 
+<td>18.2.1.1

- <td>
- ed
+<td>

- <td>
- 
- max_align_t is described in 18.1, so add 3.11 Alignment as
- the reference.
+<td>te

- <td>
- Add
- "3.11, Alignment" to
- SEE ALSO.
+<td>
+numeric_limits does not use concept.

- <td>
- 
+<td>
+Correct as follows.

- [Being reviewed by Editor]<tr valign="top">
- <td>
- FR 32
+
+ 

- <td>
- 18.2.1 
- [Numeric 
- limits]
+
+template<class T> class numeric_limits<const
+T>;

- <td>
- 
+
+template<class T> class numeric_limits<volatile
+T>;

- <td>
- te
+
+template<class T> class numeric_limits<const
+volatile T>;

- <td>
- The definition of
- numeric_limits<> as requiring a regular type is both
- conceptually wrong and operationally illogical. As we
- pointed before, this mistake needs to be corrected. For
- example, the template can be left unconstrained. In fact
- this reflects a much more general problem with
- concept_maps/axioms and their interpretations. It appears
- that the current text heavily leans toward experimental
- academic type theory.
+
+ 

- 
+
+should be

- <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>
- 
+
+template<Regular T> class
+numeric_limits<const T>;

- Alisdair and Gaby will work on a resolution.<tr valign="top">
- <td>
- DE-16
+
+template<Regular T> class
+numeric_limits<volatile T>;

- <td>
- 18.2.1
+
+template<Regular T> class
+numeric_limits<const volatile T>;

- <td>
- 
+<td>Alisdair will work on a resolution.

- <td>
- te
+<tr valign="top">
+<td>DE17

- <td>
- DE-16 The class
- template numeric_limits should not specify the Regular
- concept requirement for its template parameter, because it
- contains functions returning NaN values for floating-point
- types; these values violate the semantics of
- EqualityComparable. See also library issue 902 in WG21
- document N2794 "C++ Standard Library Active Issues List
- (Revision R60)", available at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html
- .
+<td>18.2.6

- 
+<td>

- <td>
- Specify a concept requirement with fewer constraints as
- appropriate, for example SemiRegular.
+<td>te

- <td>
- 
+<td>DE17 The class
+type_index should be removed; it provides no additional
+functionality beyond providing appropriate concept maps.

- Alisdair and Gaby will work on a resolution.<tr valign="top">
- <td>
- JP 26
+

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

- <td>
- 
+<td>Doug will open an issue.

- <td>
- te
+<tr valign="top">
+<td>UK185

- <td>
- 
- numeric_limits does not use concept.
+<td>18.3.1

- <td>
- 
- Correct as follows.
+<td>2

- 
- 
+<td>Ed

- 
- template<class T> class numeric_limits<const
- T>;
+<td>There is no
+header <stdint>, it should either be <stdint.h>
+or <cstdint>

- 
- template<class T> class numeric_limits<volatile
- T>;
+<td>Replace <stdint> with <cstdint>

- 
- template<class T> class numeric_limits<const
- volatile T>;
+<td>[Being reviewed by Editor]

- 
- 
+<tr valign="top">
+<td>DE18

- 
- should be
+<td>18.4

- 
- 
+<td>

- 
- template<Regular T> class
- numeric_limits<const T>;
+<td>te

- 
- template<Regular T> class
- numeric_limits<volatile T>;
+<td>DE18 The
+proposed C++ standard makes a considerable number of
+existing programs that have well-defined behavior according
+to ISO/IEC 14882:2003 have undefined behavior without a
+diagnostic hint to the programmer at all. This applies to
+the presence of threads and to pointer safety (the latter
+was introduced to support garbage collection). In order to
+avoid requiring a full code review for user code,
+facilities should be present that allow the compile-time
+detection of the advanced features of the proposed C++
+standard. It is expected that C++ implementations will
+provide a means (for example, a command-line switch) to
+turn off either or both of threads and garbage collection
+support, turning potentially undefined programs into
+well-defined ones. 
+Note: This issue is contributing significantly to
+Germany's overall “no” vote.

- 
- template<Regular T> class
- numeric_limits<const volatile T>;
+

- 
+<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>
- 
+<td>Straw polls: pointer safety: 9-1-10; threading: 14-2-9. Jens will open
+ multiple issues.

- Alisdair will work on a resolution.<tr valign="top">
- <td>
- DE-17
+<tr valign="top">
+<td>UK186

- <td>
- 18.2.6
+<td>18.4

- <td>
- 
+<td>Footnote 221

- <td>
- te
+<td>Ed

- <td>
- DE-17 The class
- type_index should be removed; it provides no additional
- functionality beyond providing appropriate concept maps.
+<td>What is the
+purpose of this comment? The standard stream objects (cin,
+cerr etc.) have a peculiar lifetime that extends beyond the
+program. They may never be destroyed so will not be
+responsible for flushing buffers at the stated time.

- 
+<td>Remove the footnote

- <td>
- Specify concept maps for "const type_info *" as required
- by the ordered and unordered containers and remove the
- class type_index.
+<td>[Being reviewed by Editor]

- <td>
- 
+<tr valign="top">
+<td>UK187

- Doug will open an issue.<tr valign="top">
- <td>
- UK 
- 185
+<td>18.4

- <td>
- 18.3.1
+<td>9

- <td>
- 2
+<td>Te

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

- <td>
- There is no
- header <stdint>, it should either be <stdint.h>
- or <cstdint>
+<td>Clarify the intended meaing of "thread
+safe"

- 
+<td>Lawrence Crowl will open an issue.

- <td>
- Replace <stdint> with <cstdint>
+<tr valign="top">
+<td>UK188

- <td>
- 
+<td>18.4

- [Being reviewed by Editor]<tr valign="top">
- <td>
- DE-18
+<td>12

- <td>
- 18.4
+<td>Te

- <td>
- 
+<td>The function
+_Exit does not appear to be defined in this standard.
+Should it be added to the table of functions
+included-by-reference to the C standard?

- <td>
- te
+<td>Depends on where _Exit comes from

- <td>
- DE-18 The
- proposed C++ standard makes a considerable number of
- existing programs that have well-defined behavior according
- to ISO/IEC 14882:2003 have undefined behavior without a
- diagnostic hint to the programmer at all. This applies to
- the presence of threads and to pointer safety (the latter
- was introduced to support garbage collection). In order to
- avoid requiring a full code review for user code,
- facilities should be present that allow the compile-time
- detection of the advanced features of the proposed C++
- standard. It is expected that C++ implementations will
- provide a means (for example, a command-line switch) to
- turn off either or both of threads and garbage collection
- support, turning potentially undefined programs into
- well-defined ones. 
- Note: This issue is contributing significantly to
- Germany's overall “no” vote.
+<td>Agreed. Bill Plauger will open an issue.

- 
+<tr valign="top">
+<td>UK189

- <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>18.4, 18.7

- <td>
- 
+<td>

- Straw polls: pointer safety: 9-1-10; threading: 14-2-9. Jens will open
- multiple issues.<tr valign="top">
- <td>
- UK 
- 186
+<td>Te

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

- <td>
- Footnote 221
+<td>The following
+functions should be declared in C++ with the [[noreturn]]
+attribute: abort exit quick_exit terminate unexpected
+rethrow_exception throw_with_nested

- <td>
- Ed
+<td>Agreed. Howard will open an issue.

- <td>
- What is the
- purpose of this comment? The standard stream objects (cin,
- cerr etc.) have a peculiar lifetime that extends beyond the
- program. They may never be destroyed so will not be
- responsible for flushing buffers at the stated time.
+<tr valign="top">
+<td>JP27

- 
+<td>18.4, 18.9, 
+ 18.7.2.2, 
+ 18.7.3.1

- <td>
- Remove the footnote
+<td>

- <td>
- 
+<td>te

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 187
+<td>
+There are Standard library functions that never return to
+the caller. They are explained so in the Standard but not
+declared explicitly.

- <td>
- 18.4
+<td>
+Consider to add the attribute [[noreturn]] to such
+functions,

- <td>
- 9
+
+ 

- <td>
- Te
+
+15.5.2 unexpected 
+18.4: abort(), exit(), quick_exit, 
+18.7.2.2: unexpected_handler, 
+18.7.3.1: terminate_handler,

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

- 
+18.7.6
+throw_with_nested 
+18.9: longjmp.

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

- <td>
- 
+<td>See UK 180

- Lawrence Crowl will open an issue.<tr valign="top">
- <td>
- UK 
- 188
+<tr valign="top">
+<td>UK190

- <td>
- 18.4
+<td>18.5.1

- <td>
- 12
+<td>various

- <td>
- Te
+<td>Te

- <td>
- The function
- _Exit does not appear to be defined in this standard.
- Should it be added to the table of functions
- included-by-reference to the C standard?
+<td>It is not entirely clear how the current
+specification acts in the presence of a garbage collected
+implementation.

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

- <td>
- Depends on where _Exit comes from
+<td>agreed. Alisdair will open an issue.

- <td>
- 
+<tr valign="top">
+<td>UK191

- Agreed. Bill Plauger will open an issue.<tr valign="top">
- <td>
- UK 
- 189
+<td>18.5.1.1

- <td>
- 18.4, 18.7
+<td>4

- <td>
- 
+<td>Ed

- <td>
- Te
+<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>
- The addition of the [[noreturn]] attribute
- to the language will be an important aid for static
- analysis tools.
+<td>Rephrase the
+second bullet in terms of a new handler being installed,
+and update any definition of handler function necessary to
+be sure the term 'installed' is defined.

- <td>
- The following
- functions should be declared in C++ with the [[noreturn]]
- attribute: abort exit quick_exit terminate unexpected
- rethrow_exception throw_with_nested
+<td>[Being reviewed by Editor]

- 
+<tr valign="top">
+<td>UK192

- <td>
- 
+<td>18.5.1.2

- Agreed. Howard will open an issue.<tr valign="top">
- <td>
- JP 27
+<td>

- <td>
- 18.4, 18.9, 
- 18.7.2.2, 
- 18.7.3.1
+<td>Te

- <td>
- 
+<td>The declared
+signature is not compatible with the current requirement to
+throw std::length_error. It is too late to weaken the
+exception specification, so the only other change is to
+preserve new (improved) behaviour is to throw
+std::bad_alloc, or something derived from std::bad_alloc.

- <td>
- te
+<td>Fix 5.3.4p7 by required std::bad_alloc
+rather than std::length_error

- <td>
- 
- There are Standard library functions that never return to
- the caller. They are explained so in the Standard but not
- declared explicitly.
+<td>Howard will open a CWG issue referring to N2814.

- <td>
- 
- Consider to add the attribute [[noreturn]] to such
- functions,
+<tr valign="top">
+<td>UK193

- 
- 
+<td>18.5.2.2

- 
- 15.5.2 unexpected 
- 18.4: abort(), exit(), quick_exit, 
- 18.7.2.2: unexpected_handler, 
- 18.7.3.1: terminate_handler,
+<td>2

- 
- 18.7.6 rethrow_nested
+<td>Te

- 18.7.6
- throw_with_nested 
- 18.9: longjmp.
+<td>quick_exit has
+been added as a new valid way to terminate a program in a
+well defined way

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

- <td>
- 
+<td>change "call either abort() or exit()" to terminate the program. Bill
+ Plauger will open an issue.

- See UK 180<tr valign="top">
- <td>
- UK 
- 190
+<tr valign="top">
+<td>UK194

- <td>
- 18.5.1
+<td>18.6

- <td>
- various
+<td>

- <td>
- Te
+<td>Te

- <td>
- It is not entirely clear how the current
- specification acts in the presence of a garbage collected
- implementation.
+<td>The inclusion of
+type_index and hash<type_index> in <typeinfo>
+brings dependencies into <typeinfo> which are
+inconsistent with the definition of freestanding C++ in
+17.6.2.4.

- <td>
- All deallocation
- functions taking a pointer parameter should have a
- Precondition : ptr is a safely-derived pointer value.
+<td>Move type_index and hash<type_index>
+out of <typeinfo> and into a new header,
+<typeindex>.

- 
+<td>already handled by the free-standing paper.

- <td>
- 
+<tr valign="top">
+<td>JP28

- agreed. Alisdair will open an issue.<tr valign="top">
- <td>
- UK 
- 191
+<td>18.6, 
+ 18.7, 
+ 19.1

- <td>
- 18.5.1.1
+<td>

- <td>
- 4
+<td>te

- <td>
- Ed
+<td>
+Errors reported by Exception classes are of types char or
+std::string only. For example, std::exception is declared
+with char, std::string types, therefore types
+wchar_t/wstring, char16_t/u16string, or char32_t/u32string
+can not be used.

- <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>
+Consider other types.

- <td>
- Rephrase the
- second bullet in terms of a new handler being installed,
- and update any definition of handler function necessary to
- be sure the term 'installed' is defined.
+<td>NAD. There is already guidance in the CD. It is the caller's responsibility
+ to internationalize MB character string.

- 
+<tr valign="top">
+<td>JP29

- <td>
- 
+<td>18.7.6

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 192
+<td>

- <td>
- 18.5.1.2
+<td>te

- <td>
- 
+<td>
+throw_with_nested does not use concept.

- <td>
- Te
+<td>
+Correct as follows.

- <td>
- The declared
- signature is not compatible with the current requirement to
- throw std::length_error. It is too late to weaken the
- exception specification, so the only other change is to
- preserve new (improved) behaviour is to throw
- std::bad_alloc, or something derived from std::bad_alloc.
+
+template<class T> void throw_with_nested(T&&
+t); // [[noreturn]]

- 
+
+ 

- <td>
- Fix 5.3.4p7 by required std::bad_alloc
- rather than std::length_error
+should be

- <td>
- 
+
+ 

- Howard will open a CWG issue referring to N2814.<tr valign="top">
- <td>
- UK 
- 193
+
+template<CopyConstructible T> void
+throw_with_nested(T&& t); // [[noreturn]]

- <td>
- 18.5.2.2
+<td>Alisdair will open an issue.

- <td>
- 2
+<tr valign="top">
+<td>JP30

- <td>
- Te
+<td>18.7.6

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

- 
+<td>te

- <td>
- Change 3rd bullet: call either abort(),
- exit() or quick_exit();
+<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>
- 
+<td>
+Consider nested_exception to support tree structure.

- change "call either abort() or exit()" to terminate the program. Bill
- Plauger will open an issue.<tr valign="top">
- <td>
- UK 
- 194
+<td>Howard will ping Bill Plauger to request more information.

- <td>
- 18.6
+<tr valign="top">
+<td>JP31

- <td>
- 
+<td>18.7.6

- <td>
- Te
+<td>

- <td>
- The inclusion of
- type_index and hash<type_index> in <typeinfo>
- brings dependencies into <typeinfo> which are
- inconsistent with the definition of freestanding C++ in
- 17.6.2.4.
+<td>te

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

- <td>
- Move type_index and hash<type_index>
- out of <typeinfo> and into a new header,
- <typeindex>.
+<td>Consider to add
+a sample program which rethrows exception.

- <td>
- 
+
+ 

- already handled by the free-standing paper.<tr valign="top">
- <td>
- JP 28
+<td>Alisdair will incorporate this in the JP29 paper.

- <td>
- 18.6, 
- 18.7, 
- 19.1
+<tr valign="top">
+<td>UK195

- <td>
- 
+<td>18.8

- <td>
- te
+<td>

- <td>
- 
- Errors reported by Exception classes are of types char or
- std::string only. For example, std::exception is declared
- with char, std::string types, therefore types
- wchar_t/wstring, char16_t/u16string, or char32_t/u32string
- can not be used.
+<td>Te

- 
+<td>The class
+definition of std::initializer_list contains concept-maps
+to Range which should be out of the class, and in
+<iterator_concepts> instead. Otherwise, it's not
+possible to use initializer_lists in a freestanding C++
+implementation.

- <td>
- 
- Consider other types.
+<td>Delete the two concept maps from
+std::initializer_list.

- <td>
- 
+<td>will be handled in connection with the free-standing paper.

- NAD. There is already guidance in the CD. It is the caller's responsibility
- to internationalize MB character string.<tr valign="top">
- <td>
- JP 29
+<tr valign="top">
+<td>UK196

- <td>
- 18.7.6
+<td>18.8.3

- <td>
- 
+<td>

- <td>
- te
+<td>Te

- <td>
- 
- throw_with_nested does not use concept.
+<td>Concept maps for initializer_list to Range
+should not be in language support headers, but instead in
+iterator concepts.

- <td>
- 
- Correct as follows.
+<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
+under Range instead of under initializer lists; also, so
+that they're implemented in <iterator_concepts>
+instead of <initializer_list>.

- 
- template<class T> void throw_with_nested(T&&
- t); // [[noreturn]]
+<td>will be handled in connection with the free-standing paper.

- 
- 
+<tr valign="top">
+<td>UK197

- should be
+<td>19

- 
- 
+<td>

- 
- template<CopyConstructible T> void
- throw_with_nested(T&& t); // [[noreturn]]
+<td>Te

- 
+<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>
- 
+<td>Provide a
+constructor for every exception class in clause 19
+accepting a std::string by rvalue reference, with the
+semantics that the passed string may be moved.

- Alisdair will open an issue.<tr valign="top">
- <td>
- JP 30
+<td>NAD. Implementations are permitted to add the requested signature under the
+ as-if rule.

- <td>
- 18.7.6
+<tr valign="top">
+<td>JP32

- <td>
- 
+<td>19.1

- <td>
- te
+<td>

- <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>te

- <td>
- 
- Consider nested_exception to support tree structure.
+<td>
+Messages returned by the member function what() of standard
+exception classes seem difficult to judge.

- <td>
- 
+For
+example, following messages are returned by what() of
+std::bad_alloc of existing implementations:

- Howard will ping Bill Plauger to request more information.<tr valign="top">
- <td>
- JP 31
+
+ 

- <td>
- 18.7.6
+
+Compiler: Message returned by what()

- <td>
- 
+
+---------------------------------------------

- <td>
- te
+
+Borland C++ 5.6.4: no named exception thrown

- <td>
- It
- is difficult to understand in which case nested_exception
- is applied.
+
+Visual C++ 8.0: bad allocation

- <td>
- Consider to add
- a sample program which rethrows exception.
+
+Code Warrior 8.0: exception

- 
- 
+g++
+3.4.4: St9exception

- <td>
- 
+
+ 

- Alisdair will incorporate this in the JP29 paper.<tr valign="top">
- <td>
- UK 
- 195
+It is difficult
+to recognize what exception was thrown when using those
+compilers except Visual C++.

- <td>
- 18.8
+
+ 

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

- <td>
- Te
+<td>NAD. Q of I.

- <td>
- The class
- definition of std::initializer_list contains concept-maps
- to Range which should be out of the class, and in
- <iterator_concepts> instead. Otherwise, it's not
- possible to use initializer_lists in a freestanding C++
- implementation.
+<tr valign="top">
+<td>US64

- 
+<td>19.3

- <td>
- Delete the two concept maps from
- std::initializer_list.
+<td>1

- <td>
- 
+<td>Ge

- will be handled in connection with the free-standing paper.<tr valign="top">
- <td>
- UK 
- 196
+<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>
- 18.8.3
+<td>Delete this
+cross reference. If necessary, expand the main text to
+include the relevant referenced text

- <td>
- 
+

- <td>
- Te
+<td>We believe that this is editorial.

- <td>
- Concept maps for initializer_list to Range
- should not be in language support headers, but instead in
- iterator concepts.
+<tr valign="top">
+<td><a name="US65">US 65</a>

- <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
- under Range instead of under initializer lists; also, so
- that they're implemented in <iterator_concepts>
- instead of <initializer_list>.
+<td>20

- 
+<td>

- <td>
- 
+<td>te

- will be handled in connection with the free-standing paper.<tr valign="top">
- <td>
- UK 
- 197
+<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
+user visible, and it extends to library components that
+don't have any obvious connection to allocators, including
+basic concepts and simple components like pair and tuple.

- <td>
- 19
+<td>
+Sketch of proposed resolution: Eliminate scoped allocators,
+replace allocator propagation traits with a simple uniform
+rule (e.g. always propagate on copy and move), remove all
+mention of allocators from components that don't explicitly
+allocate memory (e.g. pair), and adjust container
+interfaces to reflect this simplification.

- <td>
- 
+
+Components that I propose eliminating include HasAllocatorType
+<a href=
+"http://wiki.corp.google.com/twiki/bin/edit/Main/HasAllocatorType?topicparent=Main.CppStandardIssues">
+?</a>, is_scoped_allocator,
+allocator_propagation_map, scoped_allocator_adaptor, and
+ConstructibleAsElement
+<a href=
+"http://wiki.corp.google.com/twiki/bin/edit/Main/ConstructibleAsElement?topicparent=Main.CppStandardIssues">
+?</a>.

- <td>
- Te
+<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.Later: US
+65, remove scoped allocators: straw poll, 4 pro - 9 con - 3 abstain, no
+consensus for removing scoped allocators.D2840: straw
+poll, this is the direction we want to go: 11 pro - 0 con - 5 abstain,
+we have consensus. Straw poll, put on format motions page for this
+meeting (pro) or review and consider at next meeting (con): 7 pro - 1
+con - many abstain, consensus for moving as formal motion at this
+meeting.D2840 was renamed
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
+N2840</a> and was accepted into the WP in Summit. 

- <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>
- Provide a
- constructor for every exception class in clause 19
- accepting a std::string by rvalue reference, with the
- semantics that the passed string may be moved.
+<tr valign="top">
+<td><a name="UK198">UK198 </a>

- 
+<td>20

- <td>
- 
+<td>

- NAD. Implementations are permitted to add the requested signature under the
- as-if rule.<tr valign="top">
- <td>
- JP 32
+<td>Ed

- <td>
- 19.1
+<td>The organization of clause 20 could be
+improved to better group related items, making the standard
+easier to navigate.
+
+<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
+subsections combined is to provide a functor for every
+operator in the language. 20.6.17 class template hash
+should numerically appear immediately after the operator
+wrappers, as they are functors that are used in similar
+ways 20.6.11, 20.6.12, 20.6.13, 20.6.14, 20.6.15 are
+strongly related to 20.6.3, and to an extent 20.6.2. These
+should all come under a subheading of "function adapters"
+20.7.1, 20.7.3, 20.7.4, 20.7.5, 20.7.6, 20.7.7 and 20.7.10
+should all be grouped as subclauses under [20.7.2
+Allocators] [20.7.12 unique_ptr] should be a sub-section of
+[20.7.13 smart pointers] [20.7.13 smart pointers] is
+important enough to have a high level bullet after [20.7
+memory], suggest renumbering as [20.8 smart pointers]
+[20.7.13.7 Pointer safety] is nothing to do with smart
+pointers and should become its own subclause [20.7.14
+Pointer safety] [20.9 date and time functions] should be
+moved under [20.8 time utilities] and retitled [20.8.6 C
+Library] (as per memory management/C Library) [20.6.18
+reference_closure] is fundamentally a language support
+feature and should move to clause 18, see separate comment
+[20.6.5 reference_wrapper] should be simplified and moved
+into [2.2 utility components], see separate comment [20.6.4 result_of] should be reorganised as a type trait - see
+separate comment Tuples and pairs are closely related so
+merge tuple and pair into the same subclause - see more
+general comment on this
+
+<td>Agree that this is editorial -- forward to project editor. (effective
+ duplicate of US 69)
+
+<tr valign="top">
+<td>UK199
+
+<td>20.1.1, 20.1.2
+
+<td>2
+
+<td>Te
+
+<td>The requirement
+that programs do not supply concept_maps should probably be
+users do not supply their own concept_map specializations.
+THe program will almost certainly supply concept_maps - the
+standard itself supplies a specialization for RvalueOf?
+references. Note that the term _program_ is defined in
+3.5p1 and makes no account of the standard library being
+treated differently to user written code.
+
+<td>Replace the term 'program' with 'user'.
+
+<td>Agree change 'program' to 'user' in clauses 20.1.1 and 20.1.2
+
+<tr valign="top">
+<td><a name="UK200">UK200</a>
+
+<td>20.1.4
+
+<td>
+
+<td>Te
+
+<td>All standard library use expects Predicates
+to be CopyConstructible, and this should be recognised
+easily without reatedly stating on every use-case.
+
+<td>Either require
+CopyConstructible<F> as part of Predicate, or create
+a refined concept, StdPredicate, used throughout the
+library that requires CopyConstructible as well as
+Callable. Consider making (Std)Predicate SemiRegular.

- <td>
- 
+<td>After further
+ discussion of UK200, we do not think adding constraints to predicates is a
+ good idea. Straw poll on UK200: status quo, 5 pro - 2 con; remove
+ copy-constructible, 3 pro - 4 con; pred must be copy-constructible, 4 pro -
+ 3 con; no consensus for moving away from the status quo. 

- <td>
- te
+ Also see UK245.

- <td>
- 
- Messages returned by the member function what() of standard
- exception classes seem difficult to judge.
+<tr valign="top">
+<td>UK201

- For
- example, following messages are returned by what() of
- std::bad_alloc of existing implementations:
+<td>20.1.5

- 
- 
+<td>

- 
- Compiler: Message returned by what()
+<td>Te

- 
- ---------------------------------------------
+<td>The Consistency axiom for
+LessThanComparable will not compile.

- 
- Borland C++ 5.6.4: no named exception thrown
+<td>Add a requires
+clause to the Consistency axiomL requires
+HasLessEquals<T> &&
+HasGreaterEquals<T>, or split the Consistency axiom
+into two so that 'basic' consistency can be asserted
+regardless of the <=/>= requirement.

- 
- Visual C++ 8.0: bad allocation
+<td>After consultation with the submitter, we agreed that the suggestion was in
+ error and there is nothing else to be done.

- 
- Code Warrior 8.0: exception
+<tr valign="top">
+<td>JP33

- g++
- 3.4.4: St9exception
+<td>20.1.5

- 
- 
+<td>

- It is difficult
- to recognize what exception was thrown when using those
- compilers except Visual C++.
+<td>te

- 
- 
+<td>
+LessThanComparable and EqualityComparable don't correspond
+to NaN.

- <td>
- 
- Consider to add footnote that recommends what() returns
- message easy to recognize what exception was thrown.
+<td>Apply
+concept_map to these concepts at FloatingPointType

- <td>
- 
+
+ 

- NAD. Q of I.<tr valign="top">
- <td>
- US 64
+<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.

- <td>
- 19.3
+<tr valign="top">
+<td>US66

- <td>
- 1
+<td>20.1.10

- <td>
- Ge
+<td>

- <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>te

- <td>
- Delete this
- cross reference. If necessary, expand the main text to
- include the relevant referenced text
+<td>Application of the "Regular" concept to floating-point
+types appears to be controversial (see long discussion on
+std-lib reflector).

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

- <td>
- 
+<td>Recommend that we handle the same as JP 33.

- We believe that this is editorial.<tr valign="top">
- <td>
- <a name="US65">US 65</a>
+<tr valign="top">
+<td>JP34

- <td>
- 20
+<td>20.2

- <td>
- 
+<td>
+1st para, 4th line

- <td>
- te
+<td>ed

- <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
- user visible, and it extends to library components that
- don't have any obvious connection to allocators, including
- basic concepts and simple components like pair and tuple.
+<td>
+Though N2672 pointed at adding
+"#include<initializer_list>", it isn't reflected.

- <td>
- 
- Sketch of proposed resolution: Eliminate scoped allocators,
- replace allocator propagation traits with a simple uniform
- rule (e.g. always propagate on copy and move), remove all
- mention of allocators from components that don't explicitly
- allocate memory (e.g. pair), and adjust container
- interfaces to reflect this simplification.
+<td>add
+followings

- 
- Components that I propose eliminating include HasAllocatorType
- <a href=
- "http://wiki.corp.google.com/twiki/bin/edit/Main/HasAllocatorType?topicparent=Main.CppStandardIssues">
- ?</a>, is_scoped_allocator,
- allocator_propagation_map, scoped_allocator_adaptor, and
- ConstructibleAsElement
- <a href=
- "http://wiki.corp.google.com/twiki/bin/edit/Main/ConstructibleAsElement?topicparent=Main.CppStandardIssues">
- ?</a>.
+
+#include <initializer_list> // for concept_map

- 
+<td>Agree that the omission of <code>#include
+ <initializer_list></initializer_list>
+ </code>was not agreed to in a vote and that the editor should reinstate it.
+ There is some disagreement as to whether it actually should be
+ there. Some believed it did not belong because we do not guarantee that one
+ header includes another anywhere else in the standard. However, the paper
+ that was voted in explicitly did make that guarantee. Removing that
+ guarantee is beyond the scope of this review.

- <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.Later: US
- 65, remove scoped allocators: straw poll, 4 pro - 9 con - 3 abstain, no
- consensus for removing scoped allocators.D2840: straw
- poll, this is the direction we want to go: 11 pro - 0 con - 5 abstain,
- we have consensus. Straw poll, put on format motions page for this
- meeting (pro) or review and consider at next meeting (con): 7 pro - 1
- con - many abstain, consensus for moving as formal motion at this
- meeting.D2840 was renamed
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
- N2840</a> and was accepted into the WP in Summit. 
-
- <tr valign="top">
- <td>
- <a name="UK198">UK 
- 198 </a>
-
- <td>
- 20
-
- <td>
- 
-
- <td>
- Ed
-
- <td>
- The organization of clause 20 could be
- improved to better group related items, making the standard
- easier to navigate.
-
- <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
- subsections combined is to provide a functor for every
- operator in the language. 20.6.17 class template hash
- should numerically appear immediately after the operator
- wrappers, as they are functors that are used in similar
- ways 20.6.11, 20.6.12, 20.6.13, 20.6.14, 20.6.15 are
- strongly related to 20.6.3, and to an extent 20.6.2. These
- should all come under a subheading of "function adapters"
- 20.7.1, 20.7.3, 20.7.4, 20.7.5, 20.7.6, 20.7.7 and 20.7.10
- should all be grouped as subclauses under [20.7.2
- Allocators] [20.7.12 unique_ptr] should be a sub-section of
- [20.7.13 smart pointers] [20.7.13 smart pointers] is
- important enough to have a high level bullet after [20.7
- memory], suggest renumbering as [20.8 smart pointers]
- [20.7.13.7 Pointer safety] is nothing to do with smart
- pointers and should become its own subclause [20.7.14
- Pointer safety] [20.9 date and time functions] should be
- moved under [20.8 time utilities] and retitled [20.8.6 C
- Library] (as per memory management/C Library) [20.6.18
- reference_closure] is fundamentally a language support
- feature and should move to clause 18, see separate comment
- [20.6.5 reference_wrapper] should be simplified and moved
- into [2.2 utility components], see separate comment [20.6.4 result_of] should be reorganised as a type trait - see
- separate comment Tuples and pairs are closely related so
- merge tuple and pair into the same subclause - see more
- general comment on this
-
- 
-
- <td>
- 
-
- Agree that this is editorial -- forward to project editor. (effective
- duplicate of US 69)<tr valign="top">
- <td>
- UK 
- 199
-
- <td>
- 20.1.1, 20.1.2
-
- <td>
- 2
-
- <td>
- Te
-
- <td>
- The requirement
- that programs do not supply concept_maps should probably be
- users do not supply their own concept_map specializations.
- THe program will almost certainly supply concept_maps - the
- standard itself supplies a specialization for RvalueOf?
- references. Note that the term _program_ is defined in
- 3.5p1 and makes no account of the standard library being
- treated differently to user written code.
-
- 
-
- <td>
- Replace the term 'program' with 'user'.
-
- <td>
- 
-
- Agree change 'program' to 'user' in clauses 20.1.1 and 20.1.2<tr valign="top">
- <td>
- <a name="UK200">UK 
- 200</a>
-
- <td>
- 20.1.4
-
- <td>
- 
-
- <td>
- Te
-
- <td>
- All standard library use expects Predicates
- to be CopyConstructible, and this should be recognised
- easily without reatedly stating on every use-case.
-
- <td>
- Either require
- CopyConstructible<F> as part of Predicate, or create
- a refined concept, StdPredicate, used throughout the
- library that requires CopyConstructible as well as
- Callable. Consider making (Std)Predicate SemiRegular.
+<tr valign="top">
+<td>US67

- 
+<td>20.2.1

- <td>
- 
+<td>¶ 5 first sent.

- After further
- discussion of UK200, we do not think adding constraints to predicates is a
- good idea. Straw poll on UK200: status quo, 5 pro - 2 con; remove
- copy-constructible, 3 pro - 4 con; pred must be copy-constructible, 4 pro -
- 3 con; no consensus for moving away from the status quo. 
+<td>ed

- Also see UK245.<tr valign="top">
- <td>
- UK 
- 201
+<td>Some connective words are missing.

- <td>
- 20.1.5
+<td>Insert “corresponding to” before “an
+lvalue reference type.”

- <td>
- 
+<td>Yes. Forward to project editor.

- <td>
- Te
+<tr valign="top">
+<td>JP35

- <td>
- The Consistency axiom for
- LessThanComparable will not compile.
+<td>20.2.3

- <td>
- Add a requires
- clause to the Consistency axiomL requires
- HasLessEquals<T> &&
- HasGreaterEquals<T>, or split the Consistency axiom
- into two so that 'basic' consistency can be asserted
- regardless of the <=/>= requirement.
+<td>
+6th para, 1st line

- 
+<td>ed

- <td>
- 
+<td>
+Typo,

- 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>
- JP 33
+"stdforward" should be
+"std::forward"

- <td>
- 20.1.5
+<td>Correct typo.

- <td>
- 
+<td>Yes. Forward to project editor.

- <td>
- te
+<tr valign="top">
+<td>UK202

- <td>
- 
- LessThanComparable and EqualityComparable don't correspond
- to NaN.
+<td>20.2.4

- <td>
- Apply
- concept_map to these concepts at FloatingPointType
+<td>

- 
- 
+<td>Ed

- <td>
- 
+<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
+block.

- 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>
- US 66
+<td>Remove the std:: qualification from these
+references to pair.

- <td>
- 20.1.10
+<td>Yes. Forward to project editor.

- <td>
- 
+<tr valign="top">
+<td>US68

- <td>
- te
+<td>20.2.12

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

- <td>
- State that the “Regular” concept does not
- apply to floating-point types.
+<td>te/ed

- <td>
- 
+<td>The code defining the context is syntactically
+incorrect.

- Recommend that we handle the same as JP 33.<tr valign="top">
- <td>
- JP 34
+<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>
- 20.2
+<td>Editorial. The correct section is 20.1.12, not 20.2.12. Forward to project
+ editor.

- <td>
- 
- 1st para, 4th line
+<tr valign="top">
+<td>UK203

- 
+<td>20.3.2

- <td>
- ed
+<td>1-4

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

- <td>
- add
- followings
+<td>The ratio_xyz
+types have a misplaced '}'. For example: template <class
+R1, class R2> struct ratio_add { typedef see below}
+type; ;

- 
- #include <initializer_list> // for concept_map
+<td>Move the '}' to after the typedef: template
+<class R1, class R2> struct ratio_add { typedef see
+below type; };

- <td>
- 
+<td>Yes. Forward to project editor.

- Agree that the omission of <code>#include
- <initializer_list></initializer_list>
- </code>was not agreed to in a vote and that the editor should reinstate it.
- There is some disagreement as to whether it actually should be
- there. Some believed it did not belong because we do not guarantee that one
- header includes another anywhere else in the standard. However, the paper
- that was voted in explicitly did make that guarantee. Removing that
- guarantee is beyond the scope of this review.<tr valign="top">
- <td>
- US 67
+<tr valign="top">
+<td>JP36

- <td>
- 20.2.1
+<td>20.4.2.1

- <td>
- ¶ 5 first sent.
+<td>
+19th para, 6th line

- <td>
- ed
+<td>ed

- <td>
- Some connective words are missing.
+<td>
+Typo.

- <td>
- Insert “corresponding to” before “an
- lvalue reference type.”
+"it
+it" should be "it is"

- <td>
- 
+<td>
+Correct typo.

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

- <td>
- 20.2.3
+<tr valign="top">
+<td>UK204

- <td>
- 
- 6th para, 1st line
+<td>20.5

- 
+ [meta. 
+trans. 
+other]<td>Table 41

- <td>
- ed
+<td>Te

- <td>
- 
- Typo,
+<td>It is not
+possible to create a variant union based on a parameter
+pack expansion, e.g. to implement a classic discriminated
+union template.

- "stdforward" should be
- "std::forward"
+<td>Restore aligned_union template that was
+removed by LWG issue 856.

- <td>
- Correct typo.
+<td>Agree. The need for aligned_union is compelling enough to reinstate.

- <td>
- 
+<tr valign="top">
+<td><a name="US69">US69</a>

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

- <td>
- 20.2.4
+<td>

- <td>
- 
+<td>ed

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

- <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
- block.
+<td>Restructure Clause 20 so as to bring these similar
+components together.

- 
+<td>Editorial (effective duplicate of UK 198). Forward to project editor.

- <td>
- Remove the std:: qualification from these
- references to pair.
+<tr valign="top">
+<td>UK205

- <td>
- 
+<td>20.5.3

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

- <td>
- 20.2.12
+<td>Te

- <td>
- Integral 
- Like
+<td>
+integral_constant objects should be usable in
+integral-constant-expressions. The addition to the language
+of literal types and the enhanced rules for constant
+expressions make this possible.

- <td>
- te/ed
+<td>Add a constexpr conversion operator to
+class tempalate integral_constant: constexpr operator
+value_type() { return value; }

- <td>
- The code defining the context is syntactically
- incorrect.
+<td>Agree: Add a constexpr conversion operator to class template
+ integral_constant: <code>constexpr operator value_type() { return value; }</code>

- <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.
+<tr valign="top">
+<td>UK206

- <td>
- 
+<td>20.5.5

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

- <td>
- 20.3.2
+<td>Te

- <td>
- 1-4
+<td>Currently the
+std says: "In order to instantiate the template
+is_convertible<From, To>, the following code shall be
+well formed:" But the code shown is the requirement for the
+result of is_convertible to be a true_type, not a
+precondition on whether the template can be instantiated.

- <td>
- Ed
+<td>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:"

- <td>
- The ratio_xyz
- types have a misplaced '}'. For example: template <class
- R1, class R2> struct ratio_add { typedef see below}
- type; ;
+<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>UK207

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

- <td>
- 
+<td>Table 36

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

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

- <td>
- 
- 19th para, 6th line
+<td>Change:
+Example:remove_const<const volatile int>::type
+evaluates to volatile int, whereas remove_const<const
+int*> is const int*. —end example To:
+Example:remove_const<const volatile int>::type
+evaluates to volatile int, whereas remove_const<const
+int*>::type is const int*. —end example And
+change: Example:remove_volatile<const volatile
+int>::type evaluates to const int, whereas
+remove_volatile<volatile int*> is volatile int*.
+—end example To: Example:remove_volatile<const
+volatile int>::type evaluates to const int, whereas
+remove_volatile<volatile int*>::type is volatile
+int*. —end example And change:
+Example:remove_cv<const volatile int>::type evaluates
+to int, whereas remove_cv<const volatile int*> is
+const volatile int*. —end example To:
+Example:remove_cv<const volatile int>::type evaluates
+to int, whereas remove_cv<const volatile int*>::type
+is const volatile int*. —end example

- 
+<td>We tend to agree. Forward to project editor. Also recommend that the word
+ "is" be replaced with "evaluates to" in the same text.

- <td>
- ed
+<tr valign="top">
+<td>JP37

- <td>
- 
- Typo.
+<td>20.5.7

- "it
- it" should be "it is"
+<td>Table 41

- <td>
- 
- Correct typo.
+<td>ed

- <td>
- 
+<td>
+Typo.

- Yes. Forward to project editor.<tr valign="top">
- <td>
- UK 
- 204
+There isn't a
+period at the end of enable_if's comments.

- <td>
- 20.5
+
+ 

- [meta. 
- trans. 
- other]<td>
- Table 41
+If
+B is true, the member typedef type shall equal T;
+otherwise, there shall be no member typedef type

- <td>
- Te
+
+ 

- <td>
- It is not
- possible to create a variant union based on a parameter
- pack expansion, e.g. to implement a classic discriminated
- union template.
+
+should be

- 
+
+ 

- <td>
- Restore aligned_union template that was
- removed by LWG issue 856.
+If
+B is true, the member typedef type shall equal T;
+otherwise, there shall be no member typedef type.

- <td>
- 
+<td>Add
+”.”

- Agree. The need for aligned_union is compelling enough to reinstate.<tr valign="top">
- <td>
- <a name="US69">US 69</a>
+<td>Agree. Forward to project editor.

- <td>
- 20.5
+<tr valign="top">
+<td>US70

- <td>
- 
+<td>20.5 [meta]<td>

- <td>
- ed
+<td>te

- <td>
- This section, dealing with tuple<>, should be in
- the same section as the similar utility pair<>.
+<td>Specifications now expressed via narrative text are more
+accurately and clearly expressed via executable code.

- <td>
- Restructure Clause 20 so as to bring these similar
- components together.
+<td>Wherever
+concepts are available that directly match this
+section’s type traits, express the traits in terms of
+the concepts instead of via narrative text. Where the type
+traits do not quite match the corresponding concepts, bring
+the two into alignment so as to avoid two nearly-identical
+notions.

- <td>
- 
+

- Editorial (effective duplicate of UK 198). Forward to project editor.<tr valign="top">
- <td>
- UK 
- 205
+<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.

- <td>
- 20.5.3
+<tr valign="top">
+<td>US71

- <td>
- 
+<td>20.6.7 [meta. 
+trans. 
+other]<td>Table 51, last row, column 3

- <td>
- Te
+<td>ed

- <td>
- 
- integral_constant objects should be usable in
- integral-constant-expressions. The addition to the language
- of literal types and the enhanced rules for constant
- expressions make this possible.
+<td>The grammar is incorrect.

- 
+<td>Change “conversion are” to “conversion
+is”.

- <td>
- Add a constexpr conversion operator to
- class tempalate integral_constant: constexpr operator
- value_type() { return value; }
+<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.

- <td>
- 
+<tr valign="top">
+<td>DE20

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

- <td>
- 20.5.5
+<td>

- <td>
- para 4
+<td>ed

- <td>
- Te
+<td>DE20 The section heading and the first sentence use the term
+"template function", which is undefined.

- <td>
- Currently the
- std says: "In order to instantiate the template
- is_convertible<From, To>, the following code shall be
- well formed:" But the code shown is the requirement for the
- result of is_convertible to be a true_type, not a
- precondition on whether the template can be instantiated.
+<td>Replace "template function"
+by "function template".

- 
+

- <td>
- 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:"
+<td>Agree. Forward to the project editor.</tr>
+

- <td>
- 
+<tr valign="top">
+<td><a name="US72">US72</a>

- 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>
- UK 
- 207
-
- <td>
- 20.5.6.1
-
- <td>
- Table 36
-
- <td>
- Ed
-
- <td>
- suffix "::type" is missing from the some of
- the examples.
-
- <td>
- Change:
- Example:remove_const<const volatile int>::type
- evaluates to volatile int, whereas remove_const<const
- int*> is const int*. —end example To:
- Example:remove_const<const volatile int>::type
- evaluates to volatile int, whereas remove_const<const
- int*>::type is const int*. —end example And
- change: Example:remove_volatile<const volatile
- int>::type evaluates to const int, whereas
- remove_volatile<volatile int*> is volatile int*.
- —end example To: Example:remove_volatile<const
- volatile int>::type evaluates to const int, whereas
- remove_volatile<volatile int*>::type is volatile
- int*. —end example And change:
- Example:remove_cv<const volatile int>::type evaluates
- to int, whereas remove_cv<const volatile int*> is
- const volatile int*. —end example To:
- Example:remove_cv<const volatile int>::type evaluates
- to int, whereas remove_cv<const volatile int*>::type
- is const volatile int*. —end example
-
- 
-
- <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>
- JP 37
-
- <td>
- 20.5.7
-
- <td>
- Table 41
-
- <td>
- ed
-
- <td>
- 
- Typo.
-
- There isn't a
- period at the end of enable_if's comments.
-
- 
- 
-
- If
- B is true, the member typedef type shall equal T;
- otherwise, there shall be no member typedef type
-
- 
- 
-
- 
- should be
-
- 
- 
-
- If
- B is true, the member typedef type shall equal T;
- otherwise, there shall be no member typedef type.
-
- 
-
- <td>
- Add
- ”.”
-
- <td>
- 
-
- Agree. Forward to project editor.<tr valign="top">
- <td>
- US 70
-
- <td>
- 20.5 [meta]<td>
- 
-
- <td>
- te
-
- <td>
- Specifications now expressed via narrative text are more
- accurately and clearly expressed via executable code.
-
- <td>
- Wherever
- concepts are available that directly match this
- section’s type traits, express the traits in terms of
- the concepts instead of via narrative text. Where the type
- traits do not quite match the corresponding concepts, bring
- the two into alignment so as to avoid two nearly-identical
- notions.
+<td>20.6.12 [func.bind. 
+bind]<td>

- 
+<td>te

- <td>
- 
+<td>
+bind should support move-only functors and bound arguments.
+
+<td> <td>We look forward to a paper on this topic. We recommend
+no action until a paper is available. We do think that bind would
+require further overloads to support move semantics, if indeed move
+semantics are possible.Peter Dimov comments: I believe
+that what is meant here is that the CopyConstructible requirements on F
+and BoundArgs must be changed to MoveConstructible. I see no need for a
+paper.</tr>
+

- (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>
- US 71
-
- <td>
- 20.6.7 [meta. 
- trans. 
- other]<td>
- Table 51, last row, column 3
-
- <td>
- ed
-
- <td>
- The grammar is incorrect.
-
- <td>
- Change “conversion are” to “conversion
- is”.
-
- <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>
- <td>
- DE-20
-
- <td>
- 20.6.12 [bind]
-
- <td>
- 
-
- <td>
- ed
-
- <td>
- DE-20 The section heading and the first sentence use the term
- "template function", which is undefined.
-
- <td>
- Replace "template function"
- by "function template".
-
- 
-
- <td>
- 
-
- Agree. Forward to the project editor.</tr>
- <tr>
- <td valign="top">
- <a name="US72">US 72</a>
-
- <td valign="top">
- 20.6.12 [func.bind. 
- bind]<td valign="top">
- 
-
- <td valign="top">
- te
-
- <td valign="top">
- 
- bind should support move-only functors and bound arguments.
-
- <td valign="top">
-  <td valign="top">
- We look forward to a paper on this topic. We recommend
- no action until a paper is available. We do think that bind would
- require further overloads to support move semantics, if indeed move
- semantics are possible.Peter Dimov comments: I believe
- that what is meant here is that the CopyConstructible requirements on F
- and BoundArgs must be changed to MoveConstructible. I see no need for a
- paper.</tr>
- <tr>
- <td valign="top">
- JP 38
-
- <td valign="top">
- 20.6.12. 
- 1.3 [func. 
- bind. 
- bind]<td valign="top">
- 
-
- <td valign="top">
- te
-
- <td valign="top">
- 
- add the move requirement for bind's return type.
- For example, assume following th1 and th2,
-
- 
- 
- void f(vector<int> v) { } 
- 
- vector<int> v{ ... }; 
- thread th1([v]{ f(v); }); 
- thread th2(bind(f, v)); 
- 
- When function object are set to thread, v is moved to th1's
- lambda expression in a Move Constructor of lambda
- expression becuase th1's lambda expression has a Move
- Constructor. But bind of th2's return type doesn't have the
- requirement of Move, so it may not moved but copied.
-
- Add
- the requirement of move to get rid of this useless copy.
-
- And also, add
- the MoveConstructible as well as CopyConstructible.
-
- 
- 
-
- <td valign="top">
- Add
- the following requirements. 
- "it has a public move constructor
- that performs a member-wise move."
+<tr valign="top">
+<td>JP38

- Add
- the MoveConstructible.
+<td>20.6.12. 
+1.3 [func. 
+bind. 
+bind]<td>
+
+<td>te
+
+<td>
+add the move requirement for bind's return type.
+For example, assume following th1 and th2,
+
+
+ 
+void f(vector<int> v) { } 
+ 
+vector<int> v{ ... }; 
+thread th1([v]{ f(v); }); 
+thread th2(bind(f, v)); 
+ 
+When function object are set to thread, v is moved to th1's
+lambda expression in a Move Constructor of lambda
+expression becuase th1's lambda expression has a Move
+Constructor. But bind of th2's return type doesn't have the
+requirement of Move, so it may not moved but copied.
+
+Add
+the requirement of move to get rid of this useless copy.
+
+And also, add
+the MoveConstructible as well as CopyConstructible.
+
+
+ 
+
+<td>Add
+the following requirements. 
+"it has a public move constructor
+that performs a member-wise move."

- <td valign="top">
- 
+Add
+the MoveConstructible.

- We were not clear about what the submitter really intended. Requiring that
+<td>We were not clear about what the submitter really intended. Requiring that
 the result of bind be MoveConstructible?
 and/or CopyConstructible?
 might be a start, but we would like to communicate with the submitter.
 [NOTE: We would like to see a clarification of the wording for Returnable<t>
 that makes it clear that move-only types can be Returnable.] </t>

- 
+

 Peter Dimov comments: I believe that if US 72 is
 resolved as proposed by me above, the objects returned by bind will already
 be required to have a move constructor, otherwise bind would be unable to
 return them when F or a type in BoundArgs is move-only.</tr>
- <tr>
- <td valign="top">
- DE-21
-
- <td valign="top">
- 20.6.12. 
- 1.3 [func.bind. 
- bind]<td valign="top">
- 
-
- <td valign="top">
- te
-
- <td valign="top">
- 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 valign="top">
- Add the missing specification in the same section, or add a
- cross-reference indicating the section where the specification appears.
-
- <td valign="top">
- Agree. There are several differences (omissions) between
- N2691 [func.bind.bind] and N2800 [func.bind.bind]. Ask the project
- editor to review the changes. 
+
+
+<tr valign="top">
+<td>DE21
+
+<td>20.6.12. 
+1.3 [func.bind. 
+bind]<td>
+
+<td>te
+
+<td>DE21 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>Add the missing specification in the same section, or add a
+cross-reference indicating the section where the specification appears.
+
+<td>Agree. There are several differences (omissions) between
+N2691 [func.bind.bind] and N2800 [func.bind.bind]. Ask the project
+editor to review the changes. 

 </tr>
- <tr>
- <td valign="top">
- UK 
- 211
-
- <td valign="top">
- 20.6.12. 
- 2.3 [unique. 
- ptr. 
- single. 
- asgn]<td valign="top">
- 11
-
- <td valign="top">
- Te
-
- <td valign="top">
- The nullptr_t type was introduced to resolve the null
- pointer literal problem. It should be used for the assignemnt operator,
- as with the constructor and elsewhere through the library.
-
- 
-
- <td valign="top">
- Change signature here and in the synopsis to: unique_ptr&
- operator=(nullptr_t); Strike the sentance an note before the Effects
- clause.
+
+
+<tr valign="top">
+<td>UK211

- <td valign="top">
- Agree. 
+<td>20.6.12. 
+2.3 [unique. 
+ptr. 
+single. 
+asgn]<td>11
+
+<td>Te
+
+<td>The nullptr_t type was introduced to resolve the null
+pointer literal problem. It should be used for the assignemnt operator,
+as with the constructor and elsewhere through the library.
+
+<td>Change signature here and in the synopsis to: unique_ptr&
+operator=(nullptr_t); Strike the sentance an note before the Effects
+clause.
+
+<td>Agree. 

 </tr>
- <tr>
- <td valign="top">
- UK 
- 212
-
- <td valign="top">
- 20.6.13.7 [util. 
- dynamic. 
- safety]<td valign="top">
- 
-
- <td valign="top">
- Te
-
- <td valign="top">
- 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
- support features are really belongs in clause 18, with the contents
- declared in a header that deals with language-support of memory
- management.
-
- 
-
- <td valign="top">
- Move this specification to 18.5. Move the declarations
- into the header <new>.
-
- <td valign="top">
- Agree in principle, but not with the proposed
- resolution. We believe it belongs either a subsection of either 20
- [utilities] or 20.7 [memory] as part of the general reorganization of
- 20. The declaration should stay in
- <memory>. </memory>
- 
+
+
+<tr valign="top">
+<td>UK212
+
+<td>20.6.13.7 [util. 
+dynamic. 
+safety]<td>
+
+<td>Te
+
+<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
+support features are really belongs in clause 18, with the contents
+declared in a header that deals with language-support of memory
+management.
+
+<td>Move this specification to 18.5. Move the declarations
+into the header <new>.
+
+<td>Agree in principle, but not with the proposed
+resolution. We believe it belongs either a subsection of either 20
+[utilities] or 20.7 [memory] as part of the general reorganization of
+20. The declaration should stay in
+<memory>. </memory>
+ 

 </tr>
- <tr>
- <td valign="top">
- DE-22
-
- <td valign="top">
- 20.6.16.2 [func. 
- wrap. 
- func]<td valign="top">
- 
-
- <td valign="top">
- te
-
- <td valign="top">
- 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 valign="top">
- 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 valign="top">
- Agree. std::reference_wrapper has the same structure,
- and we suggest that std::function be presented in the same way as
- std::reference_wrapper. 
+
+
+<tr valign="top">
+<td>DE22
+
+<td>20.6.16.2 [func. 
+wrap. 
+func]<td>
+
+<td>te
+
+<td>DE22 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>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>Agree. std::reference_wrapper has the same structure,
+and we suggest that std::function be presented in the same way as
+std::reference_wrapper. 

 </tr>
- <tr>
- <td valign="top">
- US 73
-
- <td valign="top">
- 20.6.18 
- [expr.prim. 
- lambda], [func. 
- reference 
- closure]
-
- <td valign="top">
- 
-
- <td valign="top">
- te
-
- <td valign="top">
- The std::reference_closure template is redundant with
- std::function and should be removed.
-
- 
-
- 
- std::reference_closure is a premature optimization that provides a
- limited subset of the functionality of std::function intended to improve
- performance in a narrow use case. However, the “parallel application
- performance” benchmark used to motivate the inclusion of
- std::reference_closure was flawed in several ways:
-
- <ol start="3">
- <li>
- it failed to enable a common optimization in
- std::function (implemented by all vendors), exacting a large and
- unrealistic penalty for copying std::function instances, and
-
- <li>
- it failed to account for parallel scheduler overhead
- or realistically-sized work units, both of which would dominate the
- costs measured by the benchmark in any realistic application.
- </ol>
-
- 
-
- <td valign="top">
- Remove 20.7.18 [func.referenceclosure].
+

- 
+<tr valign="top">
+<td>US73

- Remove 5.1.1 paragraph 12.
+<td>20.6.18 
+[expr.prim. 
+lambda], [func. 
+reference 
+closure]

- <td valign="top">
- This requires attention from CWG and/or EWG. 
+<td>
+
+<td>te
+
+<td>The std::reference_closure template is redundant with
+std::function and should be removed.
+
+ 
+
+
+std::reference_closure is a premature optimization that provides a
+limited subset of the functionality of std::function intended to improve
+performance in a narrow use case. However, the “parallel application
+performance” benchmark used to motivate the inclusion of
+std::reference_closure was flawed in several ways:
+
+<ol start="3">
+ <li>
+ it failed to enable a common optimization in
+ std::function (implemented by all vendors), exacting a large and
+ unrealistic penalty for copying std::function instances, and
+
+ <li>
+ it failed to account for parallel scheduler overhead
+ or realistically-sized work units, both of which would dominate the
+ costs measured by the benchmark in any realistic application.
+ </ol>
+
+ 
+
+<td>Remove 20.7.18 [func.referenceclosure].
+
+ 
+
+Remove 5.1.1 paragraph 12.
+
+<td>This requires attention from CWG and/or EWG. 

 </tr>

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

- <td>
- 20.6.16.2 [func. 
- wrap.func]<td>
- 
+<tr valign="top">
+<td>JP39

- <td>
- te
+<td>20.6.16.2 [func. 
+wrap.func]<td>

- <td>
- 
- There are no requires corresponding to F of std::function.
+<td>te

- <td>
- 
- Correct as follows.
+<td>
+There are no requires corresponding to F of std::function.

- 
- template<class F, Allocator A>
- function(allocator_arg_t, const A&, F);
+<td>
+Correct as follows.

- 
- template<class F, Allocator A>
- function(allocator_arg_t, const A&, F&&);
+
+template<class F, Allocator A>
+function(allocator_arg_t, const A&, F);

- 
- 
+
+template<class F, Allocator A>
+function(allocator_arg_t, const A&, F&&);

- should be
+
+ 

- 
- 
+should be

- 
- template<class F, Allocator A>
+
+ 

- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
+
+template<class F, Allocator A>

- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
+
+requires CopyConstructible<F> &&
+Callable<F, ArgTypes...>

- 
- function(allocator_arg_t, const A&, F);
+
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>

- 
- template<class F, Allocator A>
+
+function(allocator_arg_t, const A&, F);

- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
+
+template<class F, Allocator A>

- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
+
+requires CopyConstructible<F> &&
+Callable<F, ArgTypes...>

- 
- function(allocator_arg_t, const A&, F&&);
+
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>

- 
+
+function(allocator_arg_t, const A&, F&&);

- <td>
- Agree with one correction: CopyConstructible should be
- ConstructibleWithAllocator. New proposed resolution:
- Correct as follows. 
- <pre> template<class F, Allocator A>
+<td>Agree with one correction: CopyConstructible should be
+ConstructibleWithAllocator. New proposed resolution:
+Correct as follows. 
+<pre> template<class F, Allocator A>
 function(allocator_arg_t, const A&, F);
 template<class F, Allocator A>
 function(allocator_arg_t, const A&, F&&);
</pre>
- should be 
- <pre> template<class F, Allocator A>
+should be 
+<pre> template<class F, Allocator A>
 requires ConstructibleWithAllocator<F, A>
 && Callable<F, ArgTypes...>
 && Convertible<Callable<F, ArgTypes...>
- ::result_type, R>
+ ::result_type, R>
 function(allocator_arg_t, const A&, F);

 template<class F, Allocator A>
 requires ConstructibleWithAllocator<F,A>
 && Callable<F, ArgTypes...>
 && Convertible<Callable<F, ArgTypes...>
- ::result_type, R>
+ ::result_type, R>
 function(allocator_arg_t,
- const A&, F&&);
+ const A&, F&&);
</pre>
- <tr valign="top">
- <td>
- JP 40
+

- <td>
- 20.6.16.2
+<tr valign="top">
+<td>JP40

- <td>
- 
+<td>20.6.16.2

- <td>
- ed
+<td>

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

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

- 
- template<class F, Allocator A>
- function(allocator_arg_t, const A&, F);
+<td>
+Correct as follows.

- 
- template<class F, Allocator A>
- function(allocator_arg_t, const A&, F&&);
+
+template<class F, Allocator A>
+function(allocator_arg_t, const A&, F);

- 
- 
+
+template<class F, Allocator A>
+function(allocator_arg_t, const A&, F&&);

- should be
+
+ 

- 
- 
+should be

- 
- template<class F, Allocator Alloc>
- function(allocator_arg_t, const Alloc &, F);
+
+ 

- 
- template<class F, Allocator Alloc>
- function(allocator_arg_t, const Alloc &,
- F&&);
+
+template<class F, Allocator Alloc>
+function(allocator_arg_t, const Alloc &, F);

- 
- 
+
+template<class F, Allocator Alloc>
+function(allocator_arg_t, const Alloc &,
+F&&);

- <td>
- 
+
+ 

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

- <td>
- 20.6.16.2
+<tr valign="top">
+<td><a name="JP41">JP41</a>

- <td>
- 
+<td>20.6.16.2

- <td>
- te
+<td>

- <td>
- 
- There are no requires corresponding to R and Args of
- UsesAllocator.
+<td>te

- <td>
- 
- Correct as follows.
+<td>
+There are no requires corresponding to R and Args of
+UsesAllocator.

- 
- template <class R, class... Args>
+<td>
+Correct as follows.

- 
- concept_map UsesAllocator<function<R(Args...)>,
- Alloc> {
+
+template <class R, class... Args>

- 
- typedef Alloc allocator_type;
+
+concept_map UsesAllocator<function<R(Args...)>,
+Alloc> {

- }
+
+typedef Alloc allocator_type;

- 
- 
+}

- should be
+
+ 

- 
- 
+should be

- 
- template <Returnable R,
- CopyConstructible... Args>
+
+ 

- 
- concept_map UsesAllocator<function<R(Args...)>,
- Alloc> {
+
+template <Returnable R,
+CopyConstructible... Args>

- 
- typedef Alloc allocator_type;
+
+concept_map UsesAllocator<function<R(Args...)>,
+Alloc> {

- }
+
+typedef Alloc allocator_type;

- <td>
- 
+}

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

- <td>
- 20.6.16.2
+<tr valign="top">
+<td>JP42

- <td>
- 
+<td>20.6.16.2

- <td>
- ed
+<td>

- <td>
- The requires
- are wrong.
+<td>ed

- R
- require Returnable, and ArgTypes requires CopyConstructible
- by a definition of function, then it's a mistake to
- designate followings by MoveConstructible.
+<td>The requires
+are wrong.

- <td>
- 
- Correct as follows.
+R
+require Returnable, and ArgTypes requires CopyConstructible
+by a definition of function, then it's a mistake to
+designate followings by MoveConstructible.

- 
- 
+<td>
+Correct as follows.

- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
+
+ 

- 
- bool operator==(const function<R(ArgTypes...)>&,
- nullptr_t);
+
+template <MoveConstructible R, MoveConstructible...
+ArgTypes>

- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
+
+bool operator==(const function<R(ArgTypes...)>&,
+nullptr_t);

- 
- bool operator==(nullptr_t, const
- function<R(ArgTypes...)>&);
+
+template <MoveConstructible R, MoveConstructible...
+ArgTypes>

- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
+
+bool operator==(nullptr_t, const
+function<R(ArgTypes...)>&);

- 
- bool operator!=(const function<R(ArgTypes...)>&,
- nullptr_t);
+
+template <MoveConstructible R, MoveConstructible...
+ArgTypes>

- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
+
+bool operator!=(const function<R(ArgTypes...)>&,
+nullptr_t);

- 
- bool operator!=(nullptr_t, const
- function<R(ArgTypes...)>&);
+
+template <MoveConstructible R, MoveConstructible...
+ArgTypes>

- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
+
+bool operator!=(nullptr_t, const
+function<R(ArgTypes...)>&);

- 
- void swap(function<R(ArgTypes...)>&,
- function<R(ArgTypes...)>&);
+
+template <MoveConstructible R, MoveConstructible...
+ArgTypes>

- 
- 
+
+void swap(function<R(ArgTypes...)>&,
+function<R(ArgTypes...)>&);

- should be
+
+ 

- 
- 
+should be

- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
+
+ 

- 
- bool operator==(const function<R(ArgTypes...)>&,
- nullptr_t);
+
+template <Returnable R,
+CopyConstructible... ArgTypes>

- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
+
+bool operator==(const function<R(ArgTypes...)>&,
+nullptr_t);

- 
- bool operator==(nullptr_t, const
- function<R(ArgTypes...)>&);
+
+template <Returnable R,
+CopyConstructible... ArgTypes>

- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
+
+bool operator==(nullptr_t, const
+function<R(ArgTypes...)>&);

- 
- bool operator!=(const function<R(ArgTypes...)>&,
- nullptr_t);
+
+template <Returnable R,
+CopyConstructible... ArgTypes>

- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
+
+bool operator!=(const function<R(ArgTypes...)>&,
+nullptr_t);

- 
- bool operator!=(nullptr_t, const
- function<R(ArgTypes...)>&);
+
+template <Returnable R,
+CopyConstructible... ArgTypes>

- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
+
+bool operator!=(nullptr_t, const
+function<R(ArgTypes...)>&);

- void
- swap(function<R(ArgTypes...)>&,
- function<R(ArgTypes...)>&);
+
+template <Returnable R,
+CopyConstructible... ArgTypes>

- 
- 
+void
+swap(function<R(ArgTypes...)>&,
+function<R(ArgTypes...)>&);

- <td>
- 
+
+ 

- As with JP 41, these constraints are redundant given that function<> is
+<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>
- UK 
- 208
-
- <td>
- 20.6.17
+ to "class". Note: this issue is also present in func.wrap.func.nullptr.

- <td>
- 1
+<tr valign="top">
+<td>UK208

- <td>
- Te
+<td>20.6.17

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

- <td>
- .
+<td>Te

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

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

- <td>
- 20.7
+<td>Consensus is that this is an expansion of the scope of C++0X and so we
+ recommend no action.

- <td>
- 
+<tr valign="top">
+<td>UK209

- <td>
- Te
+<td>20.7

- <td>
- Smart pointers cannot be used in
- constrained templates
+<td>

- <td>
- Provide
- constraints for smart pointers
+<td>Te

- 
+<td>Smart pointers cannot be used in
+constrained templates

- 
+<td>Provide
+constraints for smart pointers

- <td>
- 
+ 

- We look forward to a paper on this topic. We recommend no action until a
+<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.

 Peter Dimov comments: shared_ptr<T> and weak_ptr<T> support all types T for
 which T* is valid. In other words, a possible (partial) resolution is to
 change class T to PointeeType T for shared_ptr, weak_ptr and possibly
 enable_shared_from_this. 
- <tr valign="top">
- <td>
- UK 
- 213
-
- <td>
- 20.7.6
-
- <td>
- 
-
- <td>
- Te
-
- <td>
- std::allocator
- should be constrained to simplify its use on constrained
- contexts. This library component models allocation from
- free store via the new operator so choose constraints to
- match. The Allocator concept allows for a wider variety of
- allocators that users may choose to supply if their
- allocation model does not require operator new, without
- impacting the requirements of this template. 
-
- <td>
- The primary allocator template should be
- constrained to require ObjectType<T> and
- FreeStoreAllocatable<T>. Further operations to be
- constrained as required.
-
- <td>
- 
-
- [default.allocator]
-
- Agree as stated. A future paper will address additional related issues.<tr valign="top">
- <td>
- UK 
- 214
-
- <td>
- 20.7.8
-
- <td>
- 
-
- <td>
- Te
-
- <td>
- 
- raw_storage_iterator needs constraining as an iterator
- adaptor to be safely used in constrained templates 
-
- <td>
- Constrain the raw_storage_iterator template
-
- <td>
- 
-
- We look forward to a paper on this topic. We recommend no action until a
- paper is available.<tr valign="top">
- <td>
- UK 
- 210
-
- <td>
- 20.7.11
-
- <td>
- 
-
- <td>
- Te
-
- <td>
- Specialized algorithms for memory
- managenment need requirements to be easily usable in
- constrained templates
-
- <td>
- Provide
- constraints for all algorithms in 20.7.11
-
- 
-
- 
-
- <td>
- 
-
- We look forward to a paper on this topic. We recommend no action until a
- paper is available.<tr>
- <td>
- JP 44
-
- <td>
- 20.7.13.6 [util. 
- smartptr. 
- shared. 
- atomic]<td>
- 
-
- <td>
- te
-
- <td>
- The
- 1st parameter p and 2nd parameter v is now
- shared_ptr<T> *.
-
- It
- should be shared_ptr<T>&, or if these are
- shared_ptr<T>* then add the "p shall not be a null
- pointer" at the requires.
-
- <td>
- 
- Change shared_ptr<T>& or add the "p shall not be
- a null pionter" at the requires.
-
- <td>
- Agree. All of the
- functions need a requirement that p (or v) is a pointer to a valid
- object. 
+ 
+
+<tr valign="top">
+<td>UK213
+
+<td>20.7.6
+
+<td>
+
+<td>Te
+
+<td>std::allocator
+should be constrained to simplify its use on constrained
+contexts. This library component models allocation from
+free store via the new operator so choose constraints to
+match. The Allocator concept allows for a wider variety of
+allocators that users may choose to supply if their
+allocation model does not require operator new, without
+impacting the requirements of this template. 
+
+<td>The primary allocator template should be
+constrained to require ObjectType<T> and
+FreeStoreAllocatable<T>. Further operations to be
+constrained as required.
+
+<td>[default.allocator]
+
+ Agree as stated. A future paper will address additional related issues.
+
+<tr valign="top">
+<td>UK214
+
+<td>20.7.8
+
+<td>
+
+<td>Te
+
+<td>
+raw_storage_iterator needs constraining as an iterator
+adaptor to be safely used in constrained templates 
+
+<td>Constrain the raw_storage_iterator template
+
+<td>We look forward to a paper on this topic. We recommend no action until a
+ paper is available.
+
+<tr valign="top">
+<td>UK210
+
+<td>20.7.11
+
+<td>
+
+<td>Te
+
+<td>Specialized algorithms for memory
+managenment need requirements to be easily usable in
+constrained templates
+
+<td>Provide
+constraints for all algorithms in 20.7.11
+
+ 
+
+<td>We look forward to a paper on this topic. We recommend no action until a
+ paper is available.
+
+<tr valign="top">
+<td>JP44
+
+<td>20.7.13.6 [util. 
+smartptr. 
+shared. 
+atomic]<td>
+
+<td>te
+
+<td>The
+1st parameter p and 2nd parameter v is now
+shared_ptr<T> *.
+
+It
+should be shared_ptr<T>&, or if these are
+shared_ptr<T>* then add the "p shall not be a null
+pointer" at the requires.
+
+<td>
+Change shared_ptr<T>& or add the "p shall not be
+a null pionter" at the requires.
+
+<td>Agree. All of the
+functions need a requirement that p (or v) is a pointer to a valid
+object. 

 </tr>

- <tr valign="top">
- <td>
- US 74.1
-
- <td>
- 20.8
-
- <td>
- 
-
- <td>
- te
-
- <td>
- Scoped
- allocators represent a poor trade-off for standardization,
- since (1) scoped-allocator--aware containers can be
- implemented outside the C++ standard library but used with
- its algorithms, (2) scoped allocators only benefit a tiny
- proportion of the C++ community (since few C++ programmers
- even use today’s allocators), and (3) all C++ users,
- especially the vast majority of the C++ community that
- won’t ever use scoped allocators are forced to cope
- with the interface complexity introduced by scoped
- allocators. In essence, the larger community will suffer to
- support a very small subset of the community who can
- already implement their own data structures outside of the
- standard library. Therefore, scoped allocators should be
- removed from the working paper.
-
- Some evidence of
- the complexity introduced by scoped allocators:
-
- 20.3.3, 20.5:
- large increase in the number of pair and tuple constructors
-
- 23: confusing
- “AllocatableElement” requirements throughout. 
-
- <td>
- Remove support
- for scoped allocators from the working paper. This includes
- at least the following changes: 
-
- Remove 20.8.3
- [allocator.element.concepts] 
-
- Remove 20.8.7
- [allocator.adaptor] 
-
- Remove 20.8.10
- [construct.element] 
-
- In Clause 23:
- replace requirements naming the AllocatableElement concept
- with requirements naming CopyConstructible,
- MoveConstructible, DefaultConstructible, or Constructible,
- as appropriate. 
-
- <td>
- Resolved by
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
- N2840</a>, accepted in New Jersey.See <a href="#US65">US
- 65</a> for detailed notes. 
-
- <tr>
- <td>
- US 80
-
- <td>
- 20.8.2.1 [time.traits. 
- is_fp]<td>
- Heading
-
- <td>
- ed
-
- <td>
- The section heading does not describe the contents.
-
- <td>
- Change the
- heading “is_floating_point” to
- “treat_as_floating_point”. Optionally
- adjust the section’s label similarly.
+
+
+<tr valign="top">
+<td>US74.1
+
+<td>20.8
+
+<td>

- 
+<td>te

- <td>
- 
+<td>Scoped
+allocators represent a poor trade-off for standardization,
+since (1) scoped-allocator--aware containers can be
+implemented outside the C++ standard library but used with
+its algorithms, (2) scoped allocators only benefit a tiny
+proportion of the C++ community (since few C++ programmers
+even use today’s allocators), and (3) all C++ users,
+especially the vast majority of the C++ community that
+won’t ever use scoped allocators are forced to cope
+with the interface complexity introduced by scoped
+allocators. In essence, the larger community will suffer to
+support a very small subset of the community who can
+already implement their own data structures outside of the
+standard library. Therefore, scoped allocators should be
+removed from the working paper.
+
+Some evidence of
+the complexity introduced by scoped allocators:
+
+20.3.3, 20.5:
+large increase in the number of pair and tuple constructors
+
+23: confusing
+“AllocatableElement” requirements throughout. 
+
+<td>Remove support
+for scoped allocators from the working paper. This includes
+at least the following changes: 
+
+Remove 20.8.3
+[allocator.element.concepts] 
+
+Remove 20.8.7
+[allocator.adaptor] 
+
+Remove 20.8.10
+[construct.element] 
+
+In Clause 23:
+replace requirements naming the AllocatableElement concept
+with requirements naming CopyConstructible,
+MoveConstructible, DefaultConstructible, or Constructible,
+as appropriate. 
+
+<td>Resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
+N2840</a>, accepted in New Jersey.See <a href="#US65">US
+65</a> for detailed notes. 

- Agree. The section name and the section label
+
+
+<tr valign="top">
+<td>US80
+
+<td>20.8.2.1 [time.traits. 
+is_fp]<td>Heading
+
+<td>ed
+
+<td>The section heading does not describe the contents.
+
+<td>Change the
+heading “is_floating_point” to
+“treat_as_floating_point”. Optionally
+adjust the section’s label similarly.
+
+
+
+<td>Agree. The section name and the section label
 ([time.traits.is_fp]) are wrong. Forward to project editor.</tr>

- <tr valign="top">
- <td>
- US 74.2
+
+
+<tr valign="top">
+<td>US74.2

- <td>
- 20.8.2.2 [allocator. 
- concepts]<td>
- (a) syn-opsis (b) after ¶ 14
+<td>20.8.2.2 [allocator. 
+concepts]<td>(a) syn-opsis (b) after ¶ 14

- <td>
- te/ed
+<td>te/ed

- <td>
- A concept name is twice misspelled.
+<td>A concept name is twice misspelled.

- <td>
- Change “Hasconstructor” to
- “HasConstructor” (twice).
+<td>Change “Hasconstructor” to
+“HasConstructor” (twice).

- <td>
- 
+<td>Agree. Forward to project editor.

- Agree. Forward to project editor.<tr valign="top">
- <td>
- US 75
+<tr valign="top">
+<td>US75

- <td>
- 20.8.2.2
+<td>20.8.2.2

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <td>
- Allocator concepts are incomplete
+<td>Allocator concepts are incomplete

- <td>
- See paper:
- http://www.halpernwightsoftware.com/ 
+<td>See paper:
+http://www.halpernwightsoftware.com/ 
  WG21/n2810_allocator_defects.pdf

- 
+

- <td>
- 
+<td>

- 
+

- 
+

- 
+

 The referenced paper, N2810, was revised into
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
@@ -5061,8164 +3996,6714 @@
 consider at next meeting (con): 7 pro - 1 con - many abstain, consensus for
 moving as formal motion at this meeting. Also had strong support for
 proposals 1, 2 and 3 in N2834 (simplify pair). Pablo will submit a paper
- containing only those parts of N2834 in Frankfurt.<tr valign="top">
- <td>
- JP 43
+ containing only those parts of N2834 in Frankfurt.
+
+<tr valign="top">
+<td>JP43

- <td>
- 20.8.3
+<td>20.8.3

 [allocator. 
- element. 
- concepts]<td>
- 
+element. 
+concepts]<td>

- <td>
- ed
+<td>ed

- <td>
- 
- Typo.
+<td>
+Typo.

- 
- "alloc" should be "Alloc"
+
+"alloc" should be "Alloc"

- <td>
- 
- Correct as follows.
- 
+<td>
+Correct as follows.
+ 

- 
- auto concept UsesAllocator<typename T, typename
- Alloc> {
+
+auto concept UsesAllocator<typename T, typename
+Alloc> {

- 
- requires Allocator<alloc>;
+
+requires Allocator<alloc>;

- 
- typename allocator_type = T::allocator_type;
+
+typename allocator_type = T::allocator_type;

- 
-  
+
+ 

- 
- should be
+
+should be

-  
+ 

- 
- auto concept UsesAllocator<typename T, typename
- Alloc> {
+
+auto concept UsesAllocator<typename T, typename
+Alloc> {

- 
- requires Allocator<Alloc>;
+
+requires Allocator<Alloc>;

- typename
- allocator_type = T::allocator_type;
- 
+typename
+allocator_type = T::allocator_type;
+ 

- <td>
- 
+<td>Agree. Forward to project editor.

- Agree. Forward to project editor.<tr valign="top">
- <td>
- UK 
- 215
+<tr valign="top">
+<td>UK215

- <td>
- 20.8.3.3
+<td>20.8.3.3

 [time. 
- duration. 
- arithmetic]
-
- <td>
- 6,8
+duration. 
+arithmetic]

- <td>
- Ed
+<td>6,8

- <td>
- Extra pair of
- {}, presumably some formatting code gone awry :
- duration& operator-{-}();
+<td>Ed

- 
+<td>Extra pair of
+{}, presumably some formatting code gone awry :
+duration& operator-{-}();

- <td>
- Remove the {} or fix formatting
+<td>Remove the {} or fix formatting

- <td>
- 
+<td>Agree. Forward to project editor.

- Agree. Forward to project editor.<tr valign="top">
- <td>
- US 77
+<tr valign="top">
+<td>US77

- <td>
- 20.8.4
+<td>20.8.4

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <td>
- 
- Allocator-specific move and copy behavior for containers
- (N2525) complicates a little-used and already-complicated
- portion of the standard library (allocators), and breaks
- the conceptual model of move-constructor and
- move-assignment operations on standard containers being
- efficient operations. The extensions for allocator-specific
- move and copy behavior should be removed from the working
- paper.
+<td>
+Allocator-specific move and copy behavior for containers
+(N2525) complicates a little-used and already-complicated
+portion of the standard library (allocators), and breaks
+the conceptual model of move-constructor and
+move-assignment operations on standard containers being
+efficient operations. The extensions for allocator-specific
+move and copy behavior should be removed from the working
+paper.

- With the
- introduction of rvalue references, we are teaching
- programmers that moving from a standard container (e.g., a
- vector<string>) is an efficient, constant-time
- operation. The introduction of N2525 removed that
- guarantee; depending on the behavior of four different
- traits (20.8.4), the complexity of copy and move operations
- can be constant or linear time. This level of customization
- greatly increases the complexity of standard containers,
- and benefits only a tiny fraction of the C++ community. 
+With the
+introduction of rvalue references, we are teaching
+programmers that moving from a standard container (e.g., a
+vector<string>) is an efficient, constant-time
+operation. The introduction of N2525 removed that
+guarantee; depending on the behavior of four different
+traits (20.8.4), the complexity of copy and move operations
+can be constant or linear time. This level of customization
+greatly increases the complexity of standard containers,
+and benefits only a tiny fraction of the C++ community. 

- <td>
- Remove 20.8.4.
+<td>Remove 20.8.4.

- 
+ 

- Remove 20.8.5.
+Remove 20.8.5.

- 
+ 

- Remove all references to the facilities in
- 20.8.4 and 20.8.5 from clause 23.
+Remove all references to the facilities in
+20.8.4 and 20.8.5 from clause 23.

- <td>
- 
+<td>

- <tr valign="top">
- <td>
- US 78
+<tr valign="top">
+<td>US78

- <td>
- 20.8.12, 
- 20.8.13.2 [unique. 
- ptr], [util. 
- smartptr. 
- shared]<td>
- 
+<td>20.8.12, 
+20.8.13.2 [unique. 
+ptr], [util. 
+smartptr. 
+shared]<td>

- <td>
- te
+<td>te

- <td>
- There is presently no way to
- convert directly from a <code>shared_ptr</code> to a
- <code>unique_ptr</code>.
+<td>There is presently no way to
+convert directly from a <code>shared_ptr</code> to a
+<code>unique_ptr</code>.

- <td>
- Add
- an interface that performs the conversion. See the
- attached, Issues with the C++ Standard" paper under Chapter
- 20, "Conversion from <code>shared_ptr</code> to
- <code>unique_ptr".</code>
+<td>Add
+an interface that performs the conversion. See the
+attached, Issues with the C++ Standard" paper under Chapter
+20, "Conversion from <code>shared_ptr</code> to
+<code>unique_ptr".</code>

- 
+<td>We look forward to
+a paper on this topic. We recommend no action until a paper is
+available. We believe that the shared pointer must use the default deleter for the conversion to succeed.
+Peter Dimov comments: this is basically a request for shared_ptr<>::release
+in disguise, with all the associated problems. Not a good idea. 

- <td>
- We look forward to
- a paper on this topic. We recommend no action until a paper is
- available. We believe that the shared pointer must use the default deleter for the conversion to succeed.
- Peter Dimov comments: this is basically a request for shared_ptr<>::release
- in disguise, with all the associated problems. Not a good idea. 
+

- <tr valign="top">
- <td>
- US 79
+<tr valign="top">
+<td>US79

- <td>
- 20.8.12.2.1 [unique.ptr. 
- single.ctor]<td>
- 
+<td>20.8.12.2.1 [unique.ptr. 
+single.ctor]<td>

- <td>
- te
+<td>te

- <td>
- 
- [unique.ptr.single.ctor]/5 no longer requires for D not to
- be a pointer type.  This restriction needs to be put
- back in.  Otherwise we have a run time failure that
- could have been caught at compile time:
+<td>
+[unique.ptr.single.ctor]/5 no longer requires for D not to
+be a pointer type.  This restriction needs to be put
+back in.  Otherwise we have a run time failure that
+could have been caught at compile time:

- 
- 
+
+ 

- 
- unique_ptr<int, void(*)(void*)>
- p(malloc(sizeof(int)));  // should not compile
+
+unique_ptr<int, void(*)(void*)>
+p(malloc(sizeof(int)));  // should not compile

- 
- 
+
+ 

- 
- unique_ptr<int, void(*)(void*)>
- p(malloc(sizeof(int)), free);  // ok 
+
+unique_ptr<int, void(*)(void*)>
+p(malloc(sizeof(int)), free);  // ok 

- <td>
- 
+<td>

- <td>
- Agree. The unique_ptr(pointer
- p) Requires clause should be the same as the unique_ptr() 
- Requires clause. Note that unique_ptr [unique.ptr] needs concepts. 
+<td>Agree. The unique_ptr(pointer
+p) Requires clause should be the same as the unique_ptr() 
+Requires clause. Note that unique_ptr [unique.ptr] needs concepts. 

- <tr valign="top">
- <td>
- JP 45
+

- <td>
- 20.9 [time]<td>
- 
+<tr valign="top">
+<td>JP45

- <td>
- te
+<td>20.9 [time]<td>

- <td>
- 
- Rep, Period, Clock and Duration don't correspond to
- concept.
+<td>te

- 
- template <class Rep, class Period = ratio<1>>
- class duration;
+<td>
+Rep, Period, Clock and Duration don't correspond to
+concept.

- template
- <class Clock, class Duration = typename
- Clock::duration> class time_point;
+
+template <class Rep, class Period = ratio<1>>
+class duration;

- 
- 
+template
+<class Clock, class Duration = typename
+Clock::duration> class time_point;

- <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>
- We agree that this section needs concepts. We
- look forward to a paper on this topic. We recommend no action until a
- paper is available. 
+<td>
+Make concept for Rep, Period, Clock and Duration, and fix
+20.9 and wait_until and wait_for's template parameter at
+30.

- <tr valign="top">
- <td>
- US 81
+<td>We agree that this section needs concepts. We
+look forward to a paper on this topic. We recommend no action until a
+paper is available. 

- <td>
- 20.9.3
+

- <td>
- 
+<tr valign="top">
+<td>US81

- <td>
- te
+<td>20.9.3

- <td>
- 
- chrono::duration is missing the modulous operator for both
- member and non-member arithmetic. This operator is useful
- for finding the position of a duration within a bounded
- time frame. Having it be built in to duration is safer than
- requiring the client to extract and operate directly on the
- duration’s representation as the latter will not
- enforce the correct units of the operation.
+<td>

- 
- 
+<td>te

- Ex:
+<td>
+chrono::duration is missing the modulous operator for both
+member and non-member arithmetic. This operator is useful
+for finding the position of a duration within a bounded
+time frame. Having it be built in to duration is safer than
+requiring the client to extract and operate directly on the
+duration’s representation as the latter will not
+enforce the correct units of the operation.

- 
- 
+
+ 

- 
- milliseconds ms(...);
+Ex:

- 
- microseconds us(...);
+
+ 

- 
- 
+
+milliseconds ms(...);

- ms
- % us; // microseconds
+
+microseconds us(...);

- us
- % ms; // microseconds
+
+ 

- ms
- % 5; // milliseconds
+ms
+% us; // microseconds

- 5 %
- ms; // does not compile
+us
+% ms; // microseconds

- 
+ms
+% 5; // milliseconds

- <td>
- Add:
+5 %
+ms; // does not compile

- 
+<td>Add:

- 
- template <class Rep, class Period = ratio<1>>
+ 

- 
- class duration {
+
+template <class Rep, class Period = ratio<1>>

- 
- public:
+
+class duration {

- ...
+
+public:

- duration&
- operator%(const rep&);
+...

- duration&
- operator%(const duration&);
+duration&
+operator%(const rep&);

- ..
+duration&
+operator%(const duration&);

- };
+..

- 
+};

- template
- <class Rep1, class Period,
+ 

- class Rep2>
+template
+<class Rep1, class Period,

- 
- duration<typename common_type<
+class Rep2>

- Rep1,
- Rep2>::type, Period>
+
+duration<typename common_type<

- operator%(const
- duration<Rep1, Period>& d, const Rep2& s);
+Rep1,
+Rep2>::type, Period>

- 
+operator%(const
+duration<Rep1, Period>& d, const Rep2& s);

- template
- <class Rep1, class Period1,
+ 

- class Rep2,
- class Period2>
+template
+<class Rep1, class Period1,

- typename
- common_type<duration<Rep1, Period1>,
- duration<Rep2, Period2>>::type
+class Rep2,
+class Period2>

- operator%(const
- duration<Rep1, Period1>& lhs, const
- duration<Rep2, Period2>& rhs);
+typename
+common_type<duration<Rep1, Period1>,
+duration<Rep2, Period2>>::type

- 
+operator%(const
+duration<Rep1, Period1>& lhs, const
+duration<Rep2, Period2>& rhs);

- <td>
- [time.duration] Agree except that there is a typo in the
- proposed resolution. The member operators should be operator%=. This is
- also LWG
- issue 934. 
+<td>[time.duration] Agree except that there is a typo in the
+proposed resolution. The member operators should be operator%=. This is
+also LWG
+issue 934. 

- <tr valign="top">
- <td>
- US 82
+

- <td>
- 20.9.5.3
+<tr valign="top">
+<td>US82

- <td>
- after ¶ 1
+<td>20.9.5.3

- <td>
- ed
+<td>after ¶ 1

- <td>
- The code synopsis has a minor alignment error.
+<td>ed

- <td>
- Align “rep” with the other symbols defined
- in this synopsis.
+<td>The code synopsis has a minor alignment error.

- <td>
- 
+<td>Align “rep” with the other symbols defined
+in this synopsis.

- [time.clock.hires] Agree. Forward to project editor.<tr valign="top">
- <td>
- <a name="UK216">UK 
- 216</a>
+<td>[time.clock.hires] Agree. Forward to project editor.

- <td>
- 21
+<tr valign="top">
+<td><a name="UK216">UK216</a>

- <td>
- 
+<td>21

- <td>
- Te
+<td>

- <td>
- All the containers use concepts for their
- iterator usage, exect for basic_string. This needs fixing.
+<td>Te

- <td>
- Use concepts for iterator template
- parameters throughout the chapter.
+<td>All the containers use concepts for their
+iterator usage, exect for basic_string. This needs fixing.

- <td>
- 
+<td>Use concepts for iterator template
+parameters throughout the chapter.

- NB comments to be handled by Dave Abrahams and Howard Hinnant with advice
+<td>NB comments to be handled by Dave Abrahams and Howard Hinnant with advice
 from PJP: UK216 (which duplicates) JP46, JP48.
 <a href="#JP46">JP46</a> supplies extensive
- proposed wording; start there.<tr valign="top">
- <td>
- <a name="JP46">JP 46 </a>
+ proposed wording; start there.

- <td>
- 21.2, 21.3
+<tr valign="top">
+<td><a name="JP46">JP46 </a>

- <td>
- 
+<td>21.2, 21.3

- <td>
- te
+<td>

- <td>
- The
- basic_string does not use concept.
+<td>te

- <td>
- The
- "class Alloc" is changed to "Allocator Alloc".
+<td>The
+basic_string does not use concept.

- The
- "class InputIterator" is changed to "InputIterator Iter".
+<td>The
+"class Alloc" is changed to "Allocator Alloc".

- 
- 
+The
+"class InputIterator" is changed to "InputIterator Iter".

- //
- 21.3, basic_string:
+
+ 

- 
- template<class charT, class traits =
- char_traits<charT>,
+//
+21.3, basic_string:

- 
- Allocator Alloc = allocator<charT> >
+
+template<class charT, class traits =
+char_traits<charT>,

- 
- class basic_string;
+
+Allocator Alloc = allocator<charT> >

- 
-  
+
+class basic_string;

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(const
- basic_string<charT,traits,Alloc>& lhs,
+
+basic_string<charT,traits,Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+operator+(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>&&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
+
+basic_string<charT,traits,Alloc>&&

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+operator+(basic_string<charT,traits,Alloc>&&
+lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>&&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(const
- basic_string<charT,traits,Alloc>& lhs,
+
+basic_string<charT,traits,Alloc>&&

- 
- basic_string<charT,traits,Alloc>&&
- rhs);
+
+operator+(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+basic_string<charT,traits,Alloc>&&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>&&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
+
+basic_string<charT,traits,Alloc>&&

- 
- basic_string<charT,traits,Alloc>&&
- rhs);
+
+operator+(basic_string<charT,traits,Alloc>&&
+lhs,

- 
-  
+
+basic_string<charT,traits,Alloc>&&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(const charT* lhs,
+
+basic_string<charT,traits,Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+operator+(const charT* lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>&&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(const charT* lhs,
+
+basic_string<charT,traits,Alloc>&&

- 
- basic_string<charT,traits,Alloc>&&
- rhs);
+
+operator+(const charT* lhs,

- 
-  
+
+basic_string<charT,traits,Alloc>&&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(charT lhs, const
- basic_string<charT,traits,Alloc>& rhs);
+
+basic_string<charT,traits,Alloc>

- 
-  
+
+operator+(charT lhs, const
+basic_string<charT,traits,Alloc>& rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>&&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(charT lhs,
- basic_string<charT,traits,Alloc>&&
- rhs);
+
+basic_string<charT,traits,Alloc>&&

- 
-  
+
+operator+(charT lhs,
+basic_string<charT,traits,Alloc>&&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(const
- basic_string<charT,traits,Alloc>& lhs,
+
+basic_string<charT,traits,Alloc>

- 
- const charT* rhs);
+
+operator+(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const charT* rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>&&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
+
+basic_string<charT,traits,Alloc>&&

- 
- const charT* rhs);
+
+operator+(basic_string<charT,traits,Alloc>&&
+lhs,

- 
-  
+
+const charT* rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(const
- basic_string<charT,traits,Alloc>& lhs,
- charT rhs);
+
+basic_string<charT,traits,Alloc>

- 
-  
+
+operator+(const
+basic_string<charT,traits,Alloc>& lhs,
+charT rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_string<charT,traits,Alloc>&&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs, charT rhs);
+
+basic_string<charT,traits,Alloc>&&

- 
-  
+
+operator+(basic_string<charT,traits,Alloc>&&
+lhs, charT rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator==(const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator==(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator==(const charT* lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator==(const charT* lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator==(const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const charT* rhs);
+
+bool operator==(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const charT* rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator!=(const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator!=(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator!=(const charT* lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator!=(const charT* lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator!=(const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const charT* rhs);
+
+bool operator!=(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const charT* rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator< (const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator< (const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator< (const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const charT* rhs);
+
+bool operator< (const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const charT* rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator< (const charT* lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator< (const charT* lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator> (const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator> (const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator> (const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const charT* rhs);
+
+bool operator> (const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const charT* rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator> (const charT* lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator> (const charT* lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator<=(const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator<=(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator<=(const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const charT* rhs);
+
+bool operator<=(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const charT* rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator<=(const charT* lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator<=(const charT* lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator>=(const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator>=(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator>=(const
- basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const charT* rhs);
+
+bool operator>=(const
+basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+const charT* rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- bool operator>=(const charT* lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- const basic_string<charT,traits,Alloc>&
- rhs);
+
+bool operator>=(const charT* lhs,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+rhs);

- //
- 21.3.8.8: swap
+
+ 

- 
- template<class charT, class traits, Allocator
- Alloc>
+//
+21.3.8.8: swap

- 
- void swap(basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- basic_string<charT,traits,Alloc>& rhs);
+
+void swap(basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+basic_string<charT,traits,Alloc>& rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- void swap(basic_string<charT,traits,Alloc>&&
- lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- basic_string<charT,traits,Alloc>& rhs);
+
+void swap(basic_string<charT,traits,Alloc>&&
+lhs,

- 
-  
+
+basic_string<charT,traits,Alloc>& rhs);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- void swap(basic_string<charT,traits,Alloc>& lhs,
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- basic_string<charT,traits,Alloc>&& rhs);
+
+void swap(basic_string<charT,traits,Alloc>& lhs,

- 
-  
+
+basic_string<charT,traits,Alloc>&& rhs);

- //
- 21.3.8.9: inserters and extractors
+
+ 

- 
- template<class charT, class traits, Allocator
- Alloc>
+//
+21.3.8.9: inserters and extractors

- 
- basic_istream<charT,traits>&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator>>(basic_istream<charT,traits>&&
- is,
+
+basic_istream<charT,traits>&

- 
- basic_string<charT,traits,Alloc>& str);
+
+operator>>(basic_istream<charT,traits>&&
+is,

- 
-  
+
+basic_string<charT,traits,Alloc>& str);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_ostream<charT, traits>&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- operator<<(basic_ostream<charT,
- traits>&& os,
+
+basic_ostream<charT, traits>&

- 
- const basic_string<charT,traits,Alloc>&
- str);
+
+operator<<(basic_ostream<charT,
+traits>&& os,

- 
-  
+
+const basic_string<charT,traits,Alloc>&
+str);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_istream<charT,traits>&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- getline(basic_istream<charT,traits>&& is,
+
+basic_istream<charT,traits>&

- 
- basic_string<charT,traits,Alloc>& str,
+
+getline(basic_istream<charT,traits>&& is,

- 
- charT delim);
+
+basic_string<charT,traits,Alloc>& str,

- 
-  
+
+charT delim);

- 
- template<class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- basic_istream<charT,traits>&
+
+template<class charT, class traits, Allocator
+Alloc>

- 
- getline(basic_istream<charT,traits>&& is,
+
+basic_istream<charT,traits>&

- 
- basic_string<charT,traits,Alloc>& str);
+
+getline(basic_istream<charT,traits>&& is,

- 
-  
+
+basic_string<charT,traits,Alloc>& str);

- 
- 
+
+ 

- //
- 21.3 Class template basic_string
+
+ 

- 
- namespace std {
+//
+21.3 Class template basic_string

- 
- template<class charT, class traits =
- char_traits<charT>,
+
+namespace std {

- 
- Allocator Alloc = allocator<charT> >
+
+template<class charT, class traits =
+char_traits<charT>,

- 
- class basic_string {
+
+Allocator Alloc = allocator<charT> >

- 
- public:
+
+class basic_string {

- //
- types:
+
+public:

- 
- typedef traits traits_type;
+//
+types:

- 
- typedef typename traits::char_type value_type;
+
+typedef traits traits_type;

- 
- typedef Alloc allocator_type;
+
+typedef typename traits::char_type value_type;

- 
- typedef typename Alloc::size_type size_type;
+
+typedef Alloc allocator_type;

- 
- typedef typename Alloc::difference_type
- difference_type;
+
+typedef typename Alloc::size_type size_type;

- 
- typedef typename Alloc::reference reference;
+
+typedef typename Alloc::difference_type
+difference_type;

- 
- typedef typename Alloc::const_reference
- const_reference;
+
+typedef typename Alloc::reference reference;

- 
- typedef typename Alloc::pointer pointer;
+
+typedef typename Alloc::const_reference
+const_reference;

- 
- typedef typename Alloc::const_pointer const_pointer;
+
+typedef typename Alloc::pointer pointer;

- 
- typedef implementation-defined iterator; // See 23.1
+
+typedef typename Alloc::const_pointer const_pointer;

- 
- typedef implementation-defined const_iterator; // See 23.1
+
+typedef implementation-defined iterator; // See 23.1

- 
- typedef std::reverse_iterator<iterator>
- reverse_iterator;
+
+typedef implementation-defined const_iterator; // See 23.1

- 
- typedef std::reverse_iterator<const_iterator>
- const_reverse_iterator;
+
+typedef std::reverse_iterator<iterator>
+reverse_iterator;

- 
- static const size_type npos = -1;
+
+typedef std::reverse_iterator<const_iterator>
+const_reverse_iterator;

- 
-  
+
+static const size_type npos = -1;

- //
- 21.3.2 construct/copy/destroy:
+
+ 

- 
- explicit basic_string(const Alloc& a =
- Alloc());
+//
+21.3.2 construct/copy/destroy:

- 
- basic_string(const basic_string& str);
+
+explicit basic_string(const Alloc& a =
+Alloc());

- 
- basic_string(basic_string&& str);
+
+basic_string(const basic_string& str);

- 
- basic_string(const basic_string& str, size_type pos,
- size_type n = npos,
+
+basic_string(basic_string&& str);

- 
- const Alloc& a = Alloc());
+
+basic_string(const basic_string& str, size_type pos,
+size_type n = npos,

- 
- basic_string(const charT* s,
+
+const Alloc& a = Alloc());

- 
- size_type n, const Alloc& a = Alloc());
+
+basic_string(const charT* s,

- 
- basic_string(const charT* s, const Alloc& a =
- Alloc());
+
+size_type n, const Alloc& a = Alloc());

- 
- basic_string(size_type n, charT c, const Alloc&
- a = Alloc());
+
+basic_string(const charT* s, const Alloc& a =
+Alloc());

- 
- template<InputIterator Iter>
+
+basic_string(size_type n, charT c, const Alloc&
+a = Alloc());

- 
- basic_string(Iter begin, Iter end,
+
+template<InputIterator Iter>

- 
- const Alloc& a = Alloc());
+
+basic_string(Iter begin, Iter end,

- 
- basic_string(initializer_list<charT>, const
- Alloc& = Alloc());
+
+const Alloc& a = Alloc());

- 
- basic_string(const basic_string&, const
- Alloc&);
+
+basic_string(initializer_list<charT>, const
+Alloc& = Alloc());

- 
- basic_string(basic_string&&, const
- Alloc&);
+
+basic_string(const basic_string&, const
+Alloc&);

- 
- ~basic_string();
+
+basic_string(basic_string&&, const
+Alloc&);

- 
- basic_string& operator=(const basic_string& str);
+
+~basic_string();

- 
- basic_string& operator=(basic_string&& str);
+
+basic_string& operator=(const basic_string& str);

- 
- basic_string& operator=(const charT* s);
+
+basic_string& operator=(basic_string&& str);

- 
- basic_string& operator=(charT c);
+
+basic_string& operator=(const charT* s);

- 
- basic_string& operator=(initializer_list<charT>);
+
+basic_string& operator=(charT c);

- 
-  
+
+basic_string& operator=(initializer_list<charT>);

- //
- 21.3.3 iterators:
+
+ 

- ...
+//
+21.3.3 iterators:

- 
-  
+...

- //
- 21.3.4 capacity:
+
+ 

- ...
+//
+21.3.4 capacity:

- 
-  
+...

- //
- 21.3.5 element access:
+
+ 

- ...
+//
+21.3.5 element access:

- 
-  
+...

- //
- 21.3.6 modifiers:
+
+ 

- ...
+//
+21.3.6 modifiers:

- 
-  
+...

- 
- basic_string& append(const basic_string& str);
+
+ 

- 
- basic_string& append(const basic_string& str,
- size_type pos,
+
+basic_string& append(const basic_string& str);

- 
- size_type n);
+
+basic_string& append(const basic_string& str,
+size_type pos,

- 
- basic_string& append(const charT* s, size_type n);
+
+size_type n);

- 
- basic_string& append(const charT* s);
+
+basic_string& append(const charT* s, size_type n);

- 
- basic_string& append(size_type n, charT c);
+
+basic_string& append(const charT* s);

- 
- template<InputIterator Iter>
+
+basic_string& append(size_type n, charT c);

- 
- basic_string& append(Iter first, Iter
- last);
+
+template<InputIterator Iter>

- 
- basic_string& append(initializer_list<charT>);
+
+basic_string& append(Iter first, Iter
+last);

- 
- void push_back(charT c);
+
+basic_string& append(initializer_list<charT>);

- 
-  
+
+void push_back(charT c);

- 
- basic_string& assign(const basic_string& str);
+
+ 

- 
- basic_string& assign(basic_string&& str);
+
+basic_string& assign(const basic_string& str);

- 
- basic_string& assign(const basic_string& str,
- size_type pos,
+
+basic_string& assign(basic_string&& str);

- 
- size_type n);
+
+basic_string& assign(const basic_string& str,
+size_type pos,

- 
- basic_string& assign(const charT* s, size_type n);
+
+size_type n);

- 
- basic_string& assign(const charT* s);
+
+basic_string& assign(const charT* s, size_type n);

- 
- basic_string& assign(size_type n, charT c);
+
+basic_string& assign(const charT* s);

- 
- template<InputIterator Iter>
+
+basic_string& assign(size_type n, charT c);

- 
- basic_string& assign(Iter first, Iter
- last);
+
+template<InputIterator Iter>

- 
- basic_string& assign(initializer_list<charT>);
+
+basic_string& assign(Iter first, Iter
+last);

- 
-  
+
+basic_string& assign(initializer_list<charT>);

- 
- basic_string& insert(size_type pos1, const
- basic_string& str);
+
+ 

- 
- basic_string& insert(size_type pos1, const
- basic_string& str,
+
+basic_string& insert(size_type pos1, const
+basic_string& str);

- 
- size_type pos2, size_type n);
+
+basic_string& insert(size_type pos1, const
+basic_string& str,

- 
- basic_string& insert(size_type pos, const charT* s,
- size_type n);
+
+size_type pos2, size_type n);

- 
- basic_string& insert(size_type pos, const charT* s);
+
+basic_string& insert(size_type pos, const charT* s,
+size_type n);

- 
- basic_string& insert(size_type pos, size_type n, charT
- c);
+
+basic_string& insert(size_type pos, const charT* s);

- 
- iterator insert(const_iterator p, charT c);
+
+basic_string& insert(size_type pos, size_type n, charT
+c);

- 
- void insert(const_iterator p, size_type n, charT c);
+
+iterator insert(const_iterator p, charT c);

- 
- template<InputIterator Iter>
+
+void insert(const_iterator p, size_type n, charT c);

- 
- void insert(const_iterator p, Iter first,
- Iter last);
+
+template<InputIterator Iter>

- 
- void insert(const_iterator p,
- initializer_list<charT>);
+
+void insert(const_iterator p, Iter first,
+Iter last);

- 
-  
+
+void insert(const_iterator p,
+initializer_list<charT>);

- ...
+
+ 

- 
- basic_string& replace(size_type pos1, size_type n1,
+...

- 
- const basic_string& str);
+
+basic_string& replace(size_type pos1, size_type n1,

- 
- basic_string& replace(size_type pos1, size_type n1,
+
+const basic_string& str);

- 
- const basic_string& str,
+
+basic_string& replace(size_type pos1, size_type n1,

- 
- size_type pos2, size_type n2);
+
+const basic_string& str,

- 
- basic_string& replace(size_type pos, size_type n1,
- const charT* s,
+
+size_type pos2, size_type n2);

- 
- size_type n2);
+
+basic_string& replace(size_type pos, size_type n1,
+const charT* s,

- 
- basic_string& replace(size_type pos, size_type n1,
- const charT* s);
+
+size_type n2);

- 
- basic_string& replace(size_type pos, size_type n1,
- size_type n2,
+
+basic_string& replace(size_type pos, size_type n1,
+const charT* s);

- 
- charT c);
+
+basic_string& replace(size_type pos, size_type n1,
+size_type n2,

- 
- basic_string& replace(iterator i1, iterator i2,
+
+charT c);

- 
- const basic_string& str);
+
+basic_string& replace(iterator i1, iterator i2,

- 
- basic_string& replace(iterator i1, iterator i2, const
- charT* s,
+
+const basic_string& str);

- 
- size_type n);
+
+basic_string& replace(iterator i1, iterator i2, const
+charT* s,

- 
- basic_string& replace(iterator i1, iterator i2, const
- charT* s);
+
+size_type n);

- 
- basic_string& replace(iterator i1, iterator i2,
+
+basic_string& replace(iterator i1, iterator i2, const
+charT* s);

- 
- size_type n, charT c);
+
+basic_string& replace(iterator i1, iterator i2,

- 
- template<InputIterator Iter>
+
+size_type n, charT c);

- 
- basic_string& replace(iterator i1, iterator i2,
+
+template<InputIterator Iter>

- 
- Iter j1, Iter j2);
+
+basic_string& replace(iterator i1, iterator i2,

- 
- basic_string& replace(iterator, iterator,
- initializer_list<charT>);
+
+Iter j1, Iter j2);

- 
-  
+
+basic_string& replace(iterator, iterator,
+initializer_list<charT>);

- ...
+
+ 

- 
-  
+...

- //
- 21.3.7 string operations:
+
+ 

- ...
+//
+21.3.7 string operations:

- 
-  
+...

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- struct constructible_with_allocator_suffix<
+
+template <class charT, class traits, Allocator
+Alloc>

- 
- basic_string<charT, traits, Alloc> > :
- true_type { };
+
+struct constructible_with_allocator_suffix<

- 
- 
+
+basic_string<charT, traits, Alloc> > :
+true_type { };

- <td>
- 
+
+ 

- See UK 216<tr valign="top">
- <td>
- JP 47
+<td>See UK 216

- <td>
- 21.3
+<tr valign="top">
+<td>JP47

- <td>
- 
+<td>21.3

- <td>
- ed
+<td>

- <td>
- 
- Typo. Missing ”>”
+<td>ed

- 
- template <class charT, class traits, Allocator Alloc
+<td>
+Typo. Missing ”>”

- 
- 
+
+template <class charT, class traits, Allocator Alloc

- 
- should be
+
+ 

- 
- 
+
+should be

- 
- template <class charT, class traits, Allocator Alloc>
+
+ 

- 
+
+template <class charT, class traits, Allocator Alloc>

- <td>
- 
- Correct typo.
+<td>
+Correct typo.

- <td>
- 
+<td>

- <tr valign="top">
- <td>
- <a name="JP48">JP 48</a>
+<tr valign="top">
+<td><a name="JP48">JP48</a>

- <td>
- 21.3
+<td>21.3

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <td>
- 
- char_traits does not use concept.
+<td>
+char_traits does not use concept.

- For
- example, create CharTraits concept and change as follows:
+For
+example, create CharTraits concept and change as follows:

- 
- 
+
+ 

- 
- template<class charT, CharTraits traits =
- char_traits<charT>,
+
+template<class charT, CharTraits traits =
+char_traits<charT>,

- 
- class Allocator = allocator<charT> >
+
+class Allocator = allocator<charT> >

- class
- basic_string {
+class
+basic_string {

- 
- 
+
+ 

- <td>
- Add
- a concept for char_traits.
+<td>Add
+a concept for char_traits.

- <td>
- 
+<td>See UK 216

- See UK 216<tr valign="top">
- <td>
- UK 
- 217
+<tr valign="top">
+<td>UK217

- <td>
- 21.3
+<td>21.3

- <td>
- 
+<td>

- <td>
- Ed
+<td>Ed

- <td>
- basic_string refers to
- constructible_with_allocator_suffix, which I thought was
- removed?
+<td>basic_string refers to
+constructible_with_allocator_suffix, which I thought was
+removed?

- <td>
- Remove the
- lines: template <class charT, class traits, class Alloc
- struct constructible_with_allocator_suffix<
- basic_string<charT, traits, Alloc> > : true_type {
- };
+<td>Remove the
+lines: template <class charT, class traits, class Alloc
+struct constructible_with_allocator_suffix<
+basic_string<charT, traits, Alloc> > : true_type {
+};

- 
+<td>[Being reviewed by Editor]

- <td>
- 
+<tr valign="top">
+<td>UK218

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 218
+<td>21.3.1

- <td>
- 21.3.1
+<td>3

- <td>
- 3
+<td>Te

- <td>
- Te
+<td>The identity
+"&*(s.begin() + n) == &*s.begin() + n" relies on
+operator& doing the "right thing", which (AFAICS) there
+is no requirement for. See my comment under clauses
+"23.2.1, 23.2.6" (p1 in both cases) - this is the same
+issue, but I've created a separate comment for basic_string
+because it is in a different chapter.

- <td>
- The identity
- "&*(s.begin() + n) == &*s.begin() + n" relies on
- operator& doing the "right thing", which (AFAICS) there
- is no requirement for. See my comment under clauses
- "23.2.1, 23.2.6" (p1 in both cases) - this is the same
- issue, but I've created a separate comment for basic_string
- because it is in a different chapter.
+<td>See my recommendations for "23.2.1,
+23.2.6".

- 
+<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.

- <td>
- See my recommendations for "23.2.1,
- 23.2.6".
+<tr valign="top">
+<td>UK219

- <td>
- 
+<td>21.3.6.6 
+[string. 
+replace]

- 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>
- UK 
- 219
-
- <td>
- 21.3.6.6 
- [string. 
- replace]
-
- <td>
- 11
-
- <td>
- Ed
-
- <td>
- Effects refers to "whose first begin() - i1
- elements" However i1 is greater than begin()...
-
- <td>
- Effects refers to "whose first i1 - begin()
- elements"
-
- <td>
- 
-
- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 220
-
- <td>
- 21.3.8.9
-
- <td>
- 
-
- <td>
- Te
-
- <td>
- The
- operator<< for basic_string takes the output stream
- by r-value reference. This is different from the same
- operator for error_code (19.4.2.6), bitset (20.2.6.3),
- shared_ptr (20.7.13.2.8), complex (26.3.6) and sub_match
- (28.4)
-
- 
-
- <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>11
+
+<td>Ed
+
+<td>Effects refers to "whose first begin() - i1
+elements" However i1 is greater than begin()...
+
+<td>Effects refers to "whose first i1 - begin()
+elements"
+
+<td>[Being reviewed by Editor]
+
+<tr valign="top">
+<td>UK220
+
+<td>21.3.8.9

- <td>
- 
+<td>

- We did it differently for basic_string because otherwise rvalue strreaming
+<td>Te
+
+<td>The
+operator<< for basic_string takes the output stream
+by r-value reference. This is different from the same
+operator for error_code (19.4.2.6), bitset (20.2.6.3),
+shared_ptr (20.7.13.2.8), complex (26.3.6) and sub_match
+(28.4)
+
+<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>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>
- FR 33
+ fixed by N2831 if it's accepted.

- <td>
- 22.1.1 
+<tr valign="top">
+<td>FR33
+
+<td>22.1.1 
 [locale]

- <td>
- 3
+<td>3

- <td>
- ed
+<td>ed

- <td>
- ios_base::iostate err = 0;
+<td>ios_base::iostate err = 0;

- 
+

- iostate is a bitmask type and
- so could be an enumeration. Probably using
+iostate is a bitmask type and
+so could be an enumeration. Probably using

- goodbit is the solution.
+goodbit is the solution.

- <td>
- 
+<td>

- <td>
- 
+<td>[Being reviewed by Editor]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- JP 49
+<tr valign="top">
+<td>JP49

- <td>
- 22.1.3. 
- 2.2
+<td>22.1.3. 
+2.2

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <td>
- 
- codecvt does not use concept. For example, create
- CodeConvert concept and change as follows.
+<td>
+codecvt does not use concept. For example, create
+CodeConvert concept and change as follows.

- 
- template<CodeConvert Codecvt, class Elem =
- wchar_t> class wstring_convert {
+
+template<CodeConvert Codecvt, class Elem =
+wchar_t> class wstring_convert {

- <td>
- Add
- a concept for codecvt.
+<td>Add
+a concept for codecvt.

- <td>
- 
+<td>to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger

- to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger<tr valign="top">
- <td>
- JP 50
+<tr valign="top">
+<td>JP50

- <td>
- 22.1.3. 
- 2.2
+<td>22.1.3. 
+2.2

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <td>
- Add
- custom allocator parameter to wstring_convert, since we
- cannot allocate memory for strings from a custom allocator.
+<td>Add
+custom allocator parameter to wstring_convert, since we
+cannot allocate memory for strings from a custom allocator.

- <td>
- 
- Correct as follows.
+<td>
+Correct as follows.

- 
- template<class Codecvt, class Elem = wchar_t> class
- wstring_convert {
+
+template<class Codecvt, class Elem = wchar_t> class
+wstring_convert {

- 
- public:
+
+public:

- 
- typedef std::basic_string<char> byte_string;
+
+typedef std::basic_string<char> byte_string;

- 
- typedef std::basic_string<Elem> wide_string;
+
+typedef std::basic_string<Elem> wide_string;

- 
-  
+
+ 

- should be
+should be

- 
-  
+
+ 

- 
- template<class Codecvt, class Elem = wchar_t,
+
+template<class Codecvt, class Elem = wchar_t,

- 
- Allocator WideAllocator = allocator<Elem>,
+
+Allocator WideAllocator = allocator<Elem>,

- 
- Allocator ByteAllocator = allocator<char>>
+
+Allocator ByteAllocator = allocator<char>>

- 
- class wstring_convert {
+
+class wstring_convert {

- 
- public:
+
+public:

- 
- typedef std::basic_string<char,
- char_traits<char>, ByteAllocator>
- byte_string;
+
+typedef std::basic_string<char,
+char_traits<char>, ByteAllocator>
+byte_string;

- typedef
- std::basic_string<Elem, char_traits<Elem>,
- WideAllocator> wide_string;
+typedef
+std::basic_string<Elem, char_traits<Elem>,
+WideAllocator> wide_string;

- 
- 
+
+ 

- <td>
- 
+<td>to be handled by PJ Plauger

- to be handled by PJ Plauger<tr valign="top">
- <td>
- FI 4
+<tr valign="top">
+<td>FI4

- <td>
- 22.2.1.4.1
+<td>22.2.1.4.1

- 22.2.1.4.2
+22.2.1.4.2

- <td>
- 
+<td>

- <td>
- ed
+<td>ed

- <td>
- <tt>to_end and to_limit are both used. Only one is
- needed.</tt>
+<td><tt>to_end and to_limit are both used. Only one is
+needed.</tt>

- <td>
- Change to_limit to to_end.
+<td>Change to_limit to to_end.

- <td>
- 
+<td>[Being reviewed by Editor]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- FI 5
+<tr valign="top">
+<td>FI5

- <td>
- <tt>22.2. 
- 1.4.2</tt>
+<td><tt>22.2. 
+1.4.2</tt>

- <td>
- #3
+<td>#3

- <td>
- ed
+<td>ed

- <td>
- <tt>[ Note: As
- a result of operations on state, it can return ok or
- partial and set next == from and to_next != to. —end
- note ]</tt> 
- 
- 
+<td><tt>[ Note: As
+a result of operations on state, it can return ok or
+partial and set next == from and to_next != to. —end
+note ]</tt> 
+ 
+ 

- <tt>"next"
- should be "from_next."</tt>
+<tt>"next"
+should be "from_next."</tt>

- <tt>Also, the
- sentence applies to all the examples, including do_in and
- do_out.</tt>
+<tt>Also, the
+sentence applies to all the examples, including do_in and
+do_out.</tt>

- <tt>Reasoning: When reading one element of multibyte
- source data such as UTF-8, it is possible that from_next is
- incremented, to_next is unaltered, state is altered and
- return value is partial. 
- When reading one element of wide character data, the output
- can be several multibyte characters, so it is possible that
- from_next is unaltered, to_next is advanced, state is
- altered and return value is partial.</tt>
+<tt>Reasoning: When reading one element of multibyte
+source data such as UTF-8, it is possible that from_next is
+incremented, to_next is unaltered, state is altered and
+return value is partial. 
+When reading one element of wide character data, the output
+can be several multibyte characters, so it is possible that
+from_next is unaltered, to_next is advanced, state is
+altered and return value is partial.</tt>

- <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><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>
- 
+<td>[Being reviewed by Editor]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- FI 6
+<tr valign="top">
+<td>FI6

- <td>
- 22.2.1.5
+<td>22.2.1.5

- See also 
+See also 
 22.2.1.4 
 (1,2,3)

- <td>
- 
+<td>
+
+<td>te

- <td>
- te
+<td>
+<tt>codecvt_byname is only specified to work with locale
+names. There is no built-in means to find a codecvt with a
+character set's name. A locale and a character set are not
+the same. If the user has data which is encoded in a
+certain character set and she wants to create a codecvt
+which can convert from that character set to another one,
+she must iterate through locales to find one, or use
+external means (iconv, ICU's uconv). Specifying a locale
+with the character set is not a suitable solution, since
+there is no built-in mapping from character sets to
+locales. It is only possible to inquire the character set
+once the locale is known.</tt>

- <td>
- 
- <tt>codecvt_byname is only specified to work with locale
- names. There is no built-in means to find a codecvt with a
- character set's name. A locale and a character set are not
- the same. If the user has data which is encoded in a
- certain character set and she wants to create a codecvt
- which can convert from that character set to another one,
- she must iterate through locales to find one, or use
- external means (iconv, ICU's uconv). Specifying a locale
- with the character set is not a suitable solution, since
- there is no built-in mapping from character sets to
- locales. It is only possible to inquire the character set
- once the locale is known.</tt>
-
- 
-
- <td>
- <tt>There should be a built-in means to find a codecvt
- with a pair of character set names.</tt>
+

- <td>
- 
+<td><tt>There should be a built-in means to find a codecvt
+with a pair of character set names.</tt>

- Martin Sebor interested in solving this problem (also POSIX group), but
+<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>
- FI 7
+ for what looks like a new feature.
+
+<tr valign="top">
+<td>FI7

- <td>
- 22.2.1.4
+<td>22.2.1.4

- <td>
- 1,2,3
+<td>1,2,3

- <td>
- ed
+<td>ed

- <td>
- The word
- "codeset" is used, whereas the word "character set" is used
- elsewhere in the text. The words are intended to convey the
- same concept, so only one should be used (or always both
- together).
+<td>The word
+"codeset" is used, whereas the word "character set" is used
+elsewhere in the text. The words are intended to convey the
+same concept, so only one should be used (or always both
+together).

- 
+

- <td>
- Change "codeset" to "character set."
+<td>Change "codeset" to "character set."

- <td>
- 
+<td>[Being reviewed by Editor]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- JP 51
+<tr valign="top">
+<td>JP51

- <td>
- 22.2.5.1.1
+<td>22.2.5.1.1

- <td>
- 7th para, 1st
- line
+<td>7th para, 1st
+line

- <td>
- ed
+<td>ed

- <td>
- A
- parameter `end’ should be `fmtend’. 
- get() function had two `end’ parameters at N2321.
+<td>A
+parameter `end’ should be `fmtend’. 
+get() function had two `end’ parameters at N2321.

- 
- iter_type get (iter_type s, iter_type end, ios_base& f,
- ios_base::iostate& err, tm* t, const char_type* fmt,
- const char_type *end) const;
+
+iter_type get (iter_type s, iter_type end, ios_base& f,
+ios_base::iostate& err, tm* t, const char_type* fmt,
+const char_type *end) const;

- The function
- prototype of get() has been corrected at N2800, but a
- Requires statement still refers `end’ parameter.
+The function
+prototype of get() has been corrected at N2800, but a
+Requires statement still refers `end’ parameter.

- 
- 
+
+ 

- <td>
- 
- Correct as follows.
+<td>
+Correct as follows.

- 
- Requires: [fmt,end) shall be a valid range.
+
+Requires: [fmt,end) shall be a valid range.

- 
- 
+
+ 

- 
- should be
+
+should be

- 
- 
+ 
+ 

- 
- Requires: [fmt,fmtend) shall be a valid range.
+
+Requires: [fmt,fmtend) shall be a valid range.

- <td>
- 
+<td>[Being reviewed by Editor]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- JP 52
+<tr valign="top">
+<td>JP52

- <td>
- 22.2.5.1, 
- 22.2.5.2, 
- 22.2.6.1
+<td>22.2.5.1, 
+22.2.5.2, 
+22.2.6.1

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <td>
- 
- InputIterator does not use concept.
+<td>
+InputIterator does not use concept.

- <td>
- 
- Correct as follows.
+<td>
+Correct as follows.

- 
- 
+
+ 

- 
- 22.2.5.1
+
+22.2.5.1

- 
-  
+
+ 

- 
- template <class charT, class InputIterator =
- istreambuf_iterator<charT> >
+
+template <class charT, class InputIterator =
+istreambuf_iterator<charT> >

- 
- class time_get : public locale::facet, public time_base {
+
+class time_get : public locale::facet, public time_base {

- 
- public:
+
+public:

- 
- typedef charT char_type;
+
+typedef charT char_type;

- 
- typedef InputIterator iter_type;
+
+typedef InputIterator iter_type;

- 
-  
+
+ 

- 
- should be
+
+should be

- 
-  
+
+ 

- 
- template <class charT, InputIterator InputIter =
- istreambuf_iterator<charT> >
+
+template <class charT, InputIterator InputIter =
+istreambuf_iterator<charT> >

- 
- class time_get : public locale::facet, public time_base {
+
+class time_get : public locale::facet, public time_base {

- 
- public:
+
+public:

- 
- typedef charT char_type;
+
+typedef charT char_type;

- 
- typedef InputIter iter_type;
+
+typedef InputIter iter_type;

- 
-  
+
+ 

- 
-  
+
+ 

- 
- 22.2.5.2
+
+22.2.5.2

- 
-  
+
+ 

- 
- template <class charT, class InputIterator =
- istreambuf_iterator<charT> >
+
+template <class charT, class InputIterator =
+istreambuf_iterator<charT> >

- 
- class time_get_byname : public time_get<charT,
- InputIterator> {
+
+class time_get_byname : public time_get<charT,
+InputIterator> {

- 
- public:
+
+public:

- 
- typedef time_base::dateorder dateorder;
+
+typedef time_base::dateorder dateorder;

- 
- typedef InputIterator iter_type;
+
+typedef InputIterator iter_type;

- 
-  
+
+ 

- 
- should be
+
+should be

- 
-  
+
+ 

- 
- template <class charT, InputIterator InputIter =
- istreambuf_iterator<charT> >
+
+template <class charT, InputIterator InputIter =
+istreambuf_iterator<charT> >

- 
- class time_get_byname : public time_get<charT,
- InputIter> {
+
+class time_get_byname : public time_get<charT,
+InputIter> {

- 
- public:
+
+public:

- 
- typedef time_base::dateorder dateorder;
+
+typedef time_base::dateorder dateorder;

- 
- typedef InputIter iter_type;
+
+typedef InputIter iter_type;

- 
-  
+
+ 

- 
-  
+
+ 

- 
- 22.2.6.1
+
+22.2.6.1

- 
-  
+
+ 

- 
- template <class charT,
+
+template <class charT,

- 
- class InputIterator = istreambuf_iterator<charT> >
+
+class InputIterator = istreambuf_iterator<charT> >

- 
- class money_get : public locale::facet {
+
+class money_get : public locale::facet {

- 
- public:
+
+public:

- 
- typedef charT char_type;
+
+typedef charT char_type;

- 
- typedef InputIterator iter_type;
+
+typedef InputIterator iter_type;

- 
-  
+
+ 

- 
- should be
+
+should be

- 
-  
+
+ 

- 
- template <class charT,
+
+template <class charT,

- 
- InputIterator InputIter =
- istreambuf_iterator<charT> >
+
+InputIterator InputIter =
+istreambuf_iterator<charT> >

- 
- class money_get : public locale::facet {
+
+class money_get : public locale::facet {

- 
- public:
+
+public:

- 
- typedef charT char_type;
+
+typedef charT char_type;

- 
- typedef InputIter iter_type;
+
+typedef InputIter iter_type;

- 
+<td>to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger

- <td>
- 
+<tr valign="top">
+<td>JP53

- to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger<tr valign="top">
- <td>
- JP 53
+<td>22.2.5.3 , 
+22.2.5.4

- <td>
- 22.2.5.3 , 
- 22.2.5.4
+<td>

- <td>
- 
+<td>te

- <td>
- te
+<td>
+OutputIterator does not use concept.

- <td>
- 
- OutputIterator does not use concept.
+<td>
+Correct as follows.

- <td>
- 
- Correct as follows.
+
+ 

- 
-  
+
+22.2.5.3

- 
- 22.2.5.3
+
+ 

- 
-  
+
+template <class charT, class OutputIterator =
+ostreambuf_iterator<charT> >

- 
- template <class charT, class OutputIterator =
- ostreambuf_iterator<charT> >
+
+class time_put : public locale::facet {

- 
- class time_put : public locale::facet {
+
+public:

- 
- public:
+
+typedef charT char_type;

- 
- typedef charT char_type;
+
+typedef OutputIterator iter_type;

- 
- typedef OutputIterator iter_type;
+
+ 

- 
-  
+
+　should be

- 
- 　should be
+
+ 

- 
-  
+
+template <class charT, OutputIterator OutputIter
+= ostreambuf_iterator<charT> >

- 
- template <class charT, OutputIterator OutputIter
- = ostreambuf_iterator<charT> >
+
+class time_put : public locale::facet {

- 
- class time_put : public locale::facet {
+
+public:

- 
- public:
+
+typedef charT char_type;

- 
- typedef charT char_type;
+
+typedef OutputIter iter_type;

- 
- typedef OutputIter iter_type;
+
+ 

- 
-  
+
+ 

- 
-  
+
+22.2.5.4

- 
- 22.2.5.4
+
+ 

- 
-  
+
+template <class charT, class OutputIterator =
+ostreambuf_iterator<charT> >

- 
- template <class charT, class OutputIterator =
- ostreambuf_iterator<charT> >
+
+class time_put_byname : public time_put<charT,
+OutputIterator>

- 
- class time_put_byname : public time_put<charT,
- OutputIterator>
+{

- {
+
+public:

- 
- public:
+
+typedef charT char_type;

- 
- typedef charT char_type;
+
+typedef OutputIterator iter_type;

- 
- typedef OutputIterator iter_type;
+
+ 

- 
-  
+
+should be

- 
- should be
+
+ 

- 
-  
+
+template <class charT, OutputIterator OutputIter
+= ostreambuf_iterator<charT> >

- 
- template <class charT, OutputIterator OutputIter
- = ostreambuf_iterator<charT> >
+
+class time_put_byname : public time_put<charT,
+OutputIter>

- 
- class time_put_byname : public time_put<charT,
- OutputIter>
+{

- {
+
+public:

- 
- public:
+
+typedef charT char_type;

- 
- typedef charT char_type;
+typedef OutputIter
+iter_type;

- typedef OutputIter
- iter_type;
+<td>to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger

- <td>
- 
+<tr valign="top">
+<td>JP54

- to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger<tr valign="top">
- <td>
- JP 54
+<td>23

- <td>
- 23
+<td>
+2nd para, Table 79

- <td>
- 
- 2nd para, Table 79
+<td>ed

- 
+<td>
+There is not <forward_list> in Table 79.

- <td>
- ed
+<td>Add
+<forward_list> between <deque> and
+<list>.

- <td>
- 
- There is not <forward_list> in Table 79.
+<td>[Being reviewed by Editor]

- <td>
- Add
- <forward_list> between <deque> and
- <list>.
+<tr valign="top">
+<td>UK221

- <td>
- 
+<td>23

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 221
+<td>Table 79

- <td>
- 23
+<td>Ed

- <td>
- Table 79
+<td>The table is missing the new
+<forward_list> header.

- <td>
- Ed
+<td>Add
+<forward_list> to the table for sequence containers.
+Alternative (technical) solution might be to merge
+<forward_list> into <list>.

- <td>
- The table is missing the new
- <forward_list> header.
+<td>[Being reviewed by Editor]

- <td>
- Add
- <forward_list> to the table for sequence containers.
- Alternative (technical) solution might be to merge
- <forward_list> into <list>.
+<tr valign="top">
+<td>UK222

- 
+<td>23

- <td>
- 
+ [container. 
+require-ments]<td>
+
+<td>Te
+
+<td>It is not clear
+what purpose the Requirement tables serve in the Containers
+clause. Are they the definition of a library Container? Or
+simply a conventient shorthand to factor common semantics
+into a single place, simplifying the description of each
+subsequent container? This becomes an issue for
+'containers' like array, which does not meet the
+default-construct-to-empty requirement, or forward_list
+which does not support the size operation. Are these
+components no longer containers? Does that mean the
+remaining requirements don't apply? Or are these
+contradictions that need fixing, despite being a clear
+design decision?
+
+<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
+specific requirements if they call attention to them in
+their documentation. The introductory text for array should
+be expanded to mention a default constructed array is not
+empty, and forward_list introduction should mention it does
+not provide the required size operation as it cannot be
+implemented efficiently.
+
+<td>Agree in principle. We suggest proposed wording:
+
+<tr valign="top">
+<td>JP55
+
+<td>23.1.1
+
+<td>
+3rd para, 4th line
+
+<td>ed
+
+<td>It
+seems that “the MinimalAllocator concep” is the
+typo of “the MinimalAllocator concept”.
+
+<td>
+Change to … models the MinimalAllocator
+concept.

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 222
+<td>[Being reviewed by Editor]

- <td>
- 23
+<tr valign="top">
+<td>UK223
+
+<td>23.1.1

 [container. 
- require-ments]<td>
- 
+require-ments. 
+general]<td>3
+
+<td>Te
+
+<td>The library does
+not define the MinimalAllocator or ScopedAllocator
+concepts, these were part of an earlier Allocators proposal
+that was rejected.

- <td>
- Te
+<td>Remove the references to MinimalAllocator
+and ScopedAllocator, or add definitions for these concepts
+to clause 20.7.

- <td>
- It is not clear
- what purpose the Requirement tables serve in the Containers
- clause. Are they the definition of a library Container? Or
- simply a conventient shorthand to factor common semantics
- into a single place, simplifying the description of each
- subsequent container? This becomes an issue for
- 'containers' like array, which does not meet the
- default-construct-to-empty requirement, or forward_list
- which does not support the size operation. Are these
- components no longer containers? Does that mean the
- remaining requirements don't apply? Or are these
- contradictions that need fixing, despite being a clear
- design decision?
-
- 
-
- <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
- specific requirements if they call attention to them in
- their documentation. The introductory text for array should
- be expanded to mention a default constructed array is not
- empty, and forward_list introduction should mention it does
- not provide the required size operation as it cannot be
- implemented efficiently.
-
- <td>
- 
-
- Agree in principle. We suggest proposed wording:<tr valign="top">
- <td>
- JP 55
-
- <td>
- 23.1.1
-
- <td>
- 
- 3rd para, 4th line
-
- 
-
- <td>
- ed
-
- <td>
- It
- seems that “the MinimalAllocator concep” is the
- typo of “the MinimalAllocator concept”.
-
- <td>
- 
- Change to … models the MinimalAllocator
- concept.
-
- <td>
- 
-
- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 223
+<td>Agree. Proposed wording will be presented
+ in N2829 or D2840.

- <td>
- 23.1.1
+<tr valign="top">
+<td><a name="UK224">UK224</a>
+
+<td>23.1.1 

 [container. 
- require-ments. 
- general]<td>
- 3
-
- <td>
- Te
-
- <td>
- The library does
- not define the MinimalAllocator or ScopedAllocator
- concepts, these were part of an earlier Allocators proposal
- that was rejected.
-
- 
-
- <td>
- Remove the references to MinimalAllocator
- and ScopedAllocator, or add definitions for these concepts
- to clause 20.7.
-
- <td>
- 
-
- Agree. Proposed wording will be presented
- in N2829 or D2840.<tr valign="top">
- <td>
- <a name="UK224">UK 
- 224</a>
+require-ments. 
+general]<td>8
+
+<td>Te
+
+<td>This paragraph implicitly requires all
+containers in clause 23 to support allocators, which
+std::array does not.
+
+<td>Add an 'unless
+otherwise specified' rider somewhere in p8, or move the
+whole array container from clause 23 [containers] to clause
+20 [utilies] to accompany bitset, pair and tuple.
+
+<td>Agree except with moving array to clause
+ 20. Proposed wording will be presented in D2840.
+
+<tr valign="top">
+<td>UK225
+
+<td>23.1.1
+
+<td>Table 81
+
+<td>Ed
+
+<td>Inconsistent
+words used to say the same thing. Table 80 describes
+iterator/const_iterator typedef as returning an "iterator
+type whose value type is T". Table 81 expresses the same
+idea as an "iterator type pointing to T". Express identical
+ideas with the same words to avoid accidentally introducing
+subtlety and confusion
+
+<td>Change return types for
+X::(const)_reverse_iterator to say "iterator type whose
+value type is (const) T".

- <td>
- 23.1.1 
+<td>[Being reviewed by Editor]
+
+<tr valign="top">
+<td>UK226
+
+<td>23.1.1

 [container. 
- require-ments. 
- general]<td>
- 8
-
- <td>
- Te
-
- <td>
- This paragraph implicitly requires all
- containers in clause 23 to support allocators, which
- std::array does not.
-
- <td>
- Add an 'unless
- otherwise specified' rider somewhere in p8, or move the
- whole array container from clause 23 [containers] to clause
- 20 [utilies] to accompany bitset, pair and tuple.
-
- 
-
- <td>
- 
-
- Agree except with moving array to clause
- 20. Proposed wording will be presented in D2840.<tr valign="top">
- <td>
- UK 
- 225
-
- <td>
- 23.1.1
-
- <td>
- Table 81
-
- <td>
- Ed
-
- <td>
- Inconsistent
- words used to say the same thing. Table 80 describes
- iterator/const_iterator typedef as returning an "iterator
- type whose value type is T". Table 81 expresses the same
- idea as an "iterator type pointing to T". Express identical
- ideas with the same words to avoid accidentally introducing
- subtlety and confusion
-
- 
-
- <td>
- Change return types for
- X::(const)_reverse_iterator to say "iterator type whose
- value type is (const) T".
-
- <td>
- 
-
- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 226
+require-ments. 
+general]<td>10
+
+<td>Te
+
+<td><array>
+must be added to this list. In particular it doesn't
+satisfy: - no swap() function invalidates any references,
+pointers, or iterators referring to the elements of the
+containers being swapped. and probably doesn't satisfy:
+— no swap() function throws an exception.
+
+<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>Agree. The proposed resolution is
+ incomplete. Further work required.
+
+<tr valign="top">
+<td>UK227
+
+<td>23.1.1
+
+<td>Table 80
+
+<td>Ed
+
+<td>The post-condition for a = rv uses the word
+“construction” when it means
+“assignment”
+
+<td>Replace the word
+“construction” with the word
+“assignment”
+
+<td>[Being reviewed by Editor]
+
+<tr valign="top">
+<td>UK228
+
+<td>23.1.1
+
+<td>3
+
+<td>Ed
+
+<td>Line 4 contains
+a spelling mistake in the fragment "MinimalAllocator
+concep."
+
+<td>Replace "concep" with "concept"
+
+<td>[Being reviewed by Editor]
+
+<tr valign="top">
+<td>UK229
+
+<td>23.1.1
+
+<td>3
+
+<td>Ed

- <td>
- 23.1.1
+<td>The fragment "A container may directly call
+constructors" is not technically correct as constructors
+are not callable.
+
+<td>Replace "A
+container may directly call constructors and destructors
+for its stored objects" with something similar to "A
+container may directly construct its stored objects and
+call destructors for its stored objects"
+
+<td>[Being reviewed by Editor]
+
+<tr valign="top">
+<td>UK230
+
+<td>23.1.2

 [container. 
- require-ments. 
- general]<td>
- 10
+require-ments. 
+dataraces]<td>1

- <td>
- Te
+<td>Te

- <td>
- <array>
- must be added to this list. In particular it doesn't
- satisfy: - no swap() function invalidates any references,
- pointers, or iterators referring to the elements of the
- containers being swapped. and probably doesn't satisfy:
- — no swap() function throws an exception.
+<td>
+“implementations shall consider the following
+functions to be const” - what does this mean? I don't
+understand what it means by implementations considering the
+functions to be const – surely they are either
+declared const or not?

- 
+<td>Clarify what is meant and what requirements
+an implementation must satisfy.

- <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>After considerable discussion and
+ consideration, we do not feel this is a defect given the reference to [res.on.data.races].

- <td>
- 
+<tr valign="top">
+<td>JP56

- Agree. The proposed resolution is
- incomplete. Further work required.<tr valign="top">
- <td>
- UK 
- 227
+<td>23.1.3

- <td>
- 23.1.1
+<td>12th para, Table 84

- <td>
- Table 80
+<td>ed

- <td>
- Ed
+<td>
+`array’ is unstated in Table 84 - Optional sequence
+container operations.

- <td>
- The post-condition for a = rv uses the word
- “construction” when it means
- “assignment”
+<td>Add
+`array’ to Container field for the following
+Expression.

- <td>
- Replace the word
- “construction” with the word
- “assignment”
+a.front()

- 
+a.back()

- <td>
- 
+a[n]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 228
+a.at(n)

- <td>
- 23.1.1
+<td>[Being reviewed by Editor]

- <td>
- 3
+<tr valign="top">
+<td>UK231

- <td>
- Ed
+<td>23.1.3 [sequence. 
+reqmts]<td>9-11

- <td>
- Line 4 contains
- a spelling mistake in the fragment "MinimalAllocator
- concep."
+<td>Te

- 
+<td>These paragraphs
+are redundant now that Concepts define what it means to be
+an Iterator and guide overload resolution accordingly.

- <td>
- Replace "concep" with "concept"
+<td>Strike 23.1.3p9-11. Make sure
+std::basic_string has constraints similar to std::vector to
+meet this old guarantee.

- <td>
- 
+<td>Agree with issue and change to [sequence.reqmts]. The changes required to
+ [strings] will be part of the general concept support for that clause.

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 229
+<tr valign="top">
+<td>UK232

- <td>
- 23.1.1
+<td>23.1.3  [sequence. 
+reqmts]<td>Table 84

- <td>
- 3
+<td>Te

- <td>
- Ed
+<td>match_results
+may follow the requirements but is not listed a general
+purpose library container.

- <td>
- The fragment "A container may directly call
- constructors" is not technically correct as constructors
- are not callable.
+<td>Remove reference to match_results against
+a[n] operation

- <td>
- Replace "A
- container may directly call constructors and destructors
- for its stored objects" with something similar to "A
- container may directly construct its stored objects and
- call destructors for its stored objects"
+<td>Agree. <code>operator[]</code> is defined elsewhere.

- 
+<tr valign="top">
+<td>UK233

- <td>
- 
+<td>23.1.3  [sequence. 
+reqmts]<td>Table 84

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 230
+<td>Te

- <td>
- 23.1.2
+<td>Add references to the new containers.

- [container. 
- require-ments. 
- dataraces]<td>
- 1
-
- <td>
- Te
-
- <td>
- 
- “implementations shall consider the following
- functions to be const” - what does this mean? I don't
- understand what it means by implementations considering the
- functions to be const – surely they are either
- declared const or not?
-
- 
-
- <td>
- Clarify what is meant and what requirements
- an implementation must satisfy.
-
- <td>
- 
-
- After considerable discussion and
- consideration, we do not feel this is a defect given the reference to [res.on.data.races].<tr valign="top">
- <td>
- JP 56
-
- <td>
- 23.1.3
-
- <td>
- 12th para, Table 84
-
- <td>
- ed
-
- <td>
- 
- `array’ is unstated in Table 84 - Optional sequence
- container operations.
-
- <td>
- Add
- `array’ to Container field for the following
- Expression.
-
- a.front()
-
- a.back()
-
- a[n]
-
- a.at(n)
-
- <td>
- 
-
- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 231
-
- <td>
- 23.1.3 [sequence. 
- reqmts]<td>
- 9-11
-
- <td>
- Te
-
- <td>
- These paragraphs
- are redundant now that Concepts define what it means to be
- an Iterator and guide overload resolution accordingly.
-
- 
-
- <td>
- Strike 23.1.3p9-11. Make sure
- std::basic_string has constraints similar to std::vector to
- meet this old guarantee.
-
- <td>
- 
-
- Agree with issue and change to [sequence.reqmts]. The changes required to
- [strings] will be part of the general concept support for that clause.<tr valign="top">
- <td>
- UK 
- 232
-
- <td>
- 23.1.3  [sequence. 
- reqmts]<td>
- Table 84
-
- <td>
- Te
-
- <td>
- match_results
- may follow the requirements but is not listed a general
- purpose library container.
-
- 
-
- <td>
- Remove reference to match_results against
- a[n] operation
-
- <td>
- 
-
- Agree. <code>operator[]</code> is defined elsewhere.<tr valign="top">
- <td>
- UK 
- 233
-
- <td>
- 23.1.3  [sequence. 
- reqmts]<td>
- Table 84
-
- <td>
- Te
-
- <td>
- Add references to the new containers.
-
- <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(),
- a.emplace_front(args), a.push_front(t), a.push_front(rv),
- a.pop_front(). Add reference to basic_string to the row
- for: a.at(n).
-
- 
-
- <td>
- 
-
- Agree.<tr valign="top">
- <td>
- UK 
- 234
-
- <td>
- 23.1.3  [sequence. 
- reqmts]<td>
- Table 84
-
- <td>
- Te
-
- <td>
- Ther reference
- to iterator in semantics for back should also allow for
- const_iterator when called on a const-qualified container.
- This would be ugly to specify in the 03 standard, but is
- quite easy with the addition of auto in this new standard.
-
- 
-
- <td>
- Replace iterator with auto in semantics for
- back: { auto tmp = a.end(); --tmp; return *tmp; }
-
- <td>
- 
-
- Agree.<tr valign="top">
- <td>
- UK 
- 235
-
- <td>
- 23.1.3
-
- <td>
- 1
-
- <td>
- Ed
-
- <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>
- Change the text
- to read: “The library provides five basic kinds of
- sequence containers: array, deque, forward_list, list and
- vector”.
-
- 
-
- <td>
- 
-
- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 236
-
- <td>
- 23.1.3
-
- <td>
- 2
-
- <td>
- Ed
-
- <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
- straight forward ] (2) “vector is the type of
- sequence container that should be used by default” --
- As I understand it vector was considered first port of call
- because the things it has in common with the native array
- make programmers (especially those new to the container
- library) feel like they are on familiar territory. However,
- we now have the array container, so I think this should be
- recommended as the first port of call. (3) This paragraph
- is actually giving guidance on the use of the containers
- and should not be normative text
-
- 
-
- <td>
- Remove this paragraph
-
- <td>
- 
-
- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 237
-
- <td>
- 23.1.3
-
- <td>
- 2
-
- <td>
- Ed
-
- <td>
- vector, list, and deque offer the
- programmer different complexity trade-offs and should be
- used accordingly - this ignores array and forward_list
-
- <td>
- Modify the text
- to read: "array, deque, forward_list, list and vector offer
- the programmer different complexity trade-offs and should
- be used accordingly"
-
- 
-
- <td>
- 
-
- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 238
-
- <td>
- 23.1.4 [assoc-iative. 
- reqmts]<td>
- 6
-
- <td>
- Te
-
- <td>
- Leaving it
- unspecified whether or not iterator and const_iterator are
- the same type is dangerous, as user code may or may not
- violate the One Definition Rule by providing overloads for
- both types. It is probably too late to specify a single
- behaviour, but implementors should document what to expect.
- Observing that problems can be avoided by users restricting
- themselves to using const_iterator, add a note to that
- effect.
-
- 
-
- <td>
- Change 'unspecified' to 'implementation
- defined'. Add "[Note: As itererator and const_iterator have
- identical semantics in this case, and iterator is
- convertible to const_iterator, users can avoid violating
- the One Definition Rule by always using const_iterator in
- their function parameter lists -- end note]
-
- <td>
- 
-
- Agree with issue. Agree with adding the note but not with changing the
- normative text. We believe the note provides sufficient guidance.<tr valign="top">
- <td>
- UK 
- 239
-
- <td>
- 23.1.4  [assoc-iative. 
- reqmts]<td>
- 85
-
- <td>
- Te
-
- <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>
- Add below
- a.erase(q), a.extract(q), with the following notation:
- a.extract(q), Return type pair<key, iterator>
- Extracts the element pointed to by q and erases it from the
- set. Returns a pair containing the value pointed to by q
- and an iterator pointing to the element immediately
- following q prior to the element being erased. If no such
- element exists,returns a.end().
-
- 
-
- <td>
- 
-
- We look forward to a paper on this topic. We recommend no action until a
- paper is available. The paper would need to address exception safety.<tr valign="top">
- <td>
- UK 
- 240
-
- <td>
- 23.1.6.1 
- [container. 
- concepts. 
- free]<td>
- 12
-
- <td>
- Te
-
- <td>
- The axiom
- EmplacePushEquivalence should be asserting the stronger
- contract that emplace and insert return the same iterator
- value, not just iterators that dereference to the same
- value. This is a similar statement that is easier to
- express and should be equivalent - the idea that insert and
- emplace might return iterator values that do not compare
- equal but point to the same element should fail somewhere
- in the iterator concepts. Also, this axiom should be
- renamed to reflect its connection with insert, rather than
- push_front/push_back,
-
- 
-
- <td>
- Remove the * to deference the returned
- iterator either side of the == in the
- EmplacePushEquivalence axiom, rename the axiom
- EmplacementInsertionEquivalence : requires
- InsertionContainer<C> &&
- Constructible<value_type, Args...> axiom
- EmplacementInsertionEquivalence(C c, const_iterator
- position, Args... args) { emplace(c, position, args...) ==
- insert(c, position, value_type(args...)); }
+<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(),
+a.emplace_front(args), a.push_front(t), a.push_front(rv),
+a.pop_front(). Add reference to basic_string to the row
+for: a.at(n).

- <td>
- 
+<td>Agree.

- We look forward to a paper on this topic. We recommend no action until a
- paper is available. We suspect that there are other similar issues in this
- sub-clause (9, 10).<tr valign="top">
- <td>
- JP 57
+<tr valign="top">
+<td>UK234

- <td>
- 23.1.6.3
+<td>23.1.3  [sequence. 
+reqmts]<td>Table 84

- <td>
- 
- 1st para, 4th line
+<td>Te

- 
+<td>Ther reference
+to iterator in semantics for back should also allow for
+const_iterator when called on a const-qualified container.
+This would be ugly to specify in the 03 standard, but is
+quite easy with the addition of auto in this new standard.

- <td>
- ed
+<td>Replace iterator with auto in semantics for
+back: { auto tmp = a.end(); --tmp; return *tmp; }

- <td>
- 
- Typo, duplicated "to"
+<td>Agree.

- 
- "to to model insertion container concepts."
+<tr valign="top">
+<td>UK235

- <td>
- 
- Remove one.
+<td>23.1.3

- <td>
- 
+<td>1

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 241
+<td>Ed

- <td>
- 23.2.1
+<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>
- 
+<td>Change the text
+to read: “The library provides five basic kinds of
+sequence containers: array, deque, forward_list, list and
+vector”.

- <td>
- Te
+<td>[Being reviewed by Editor]

- <td>
- std::array does
- not have an allocator, so need to document an exception to
- the requirements of 23.1.1p3
+<tr valign="top">
+<td>UK236

- 
+<td>23.1.3

- <td>
- add exception to 23.1.1p3
+<td>2

- <td>
- 
+<td>Ed

- Duplicate of UK 224.<tr valign="top">
- <td>
- UK 
- 242
+<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
+straight forward ] (2) “vector is the type of
+sequence container that should be used by default” --
+As I understand it vector was considered first port of call
+because the things it has in common with the native array
+make programmers (especially those new to the container
+library) feel like they are on familiar territory. However,
+we now have the array container, so I think this should be
+recommended as the first port of call. (3) This paragraph
+is actually giving guidance on the use of the containers
+and should not be normative text

- <td>
- 23.2.1
+<td>Remove this paragraph

- <td>
- 3
+<td>[Being reviewed by Editor]

- <td>
- Ed
+<tr valign="top">
+<td>UK237

- <td>
- std:: qualification no longer needed for
- reverse_iterator.
+<td>23.1.3

- <td>
- remove std::
- qualification from std::reverse_iterator<iterator>
- and std::reverse_iterator<const_iterator>
+<td>2

- 
+<td>Ed

- <td>
- 
+<td>vector, list, and deque offer the
+programmer different complexity trade-offs and should be
+used accordingly - this ignores array and forward_list

- [Being reviewed by Editor]<tr valign="top">
- <td>
- UK 
- 243
+<td>Modify the text
+to read: "array, deque, forward_list, list and vector offer
+the programmer different complexity trade-offs and should
+be used accordingly"

- <td>
- 23.2.1 
- [array]<td>
- 3
+<td>[Being reviewed by Editor]

- <td>
- Te
+<tr valign="top">
+<td>UK238

- <td>
- Most containers,
- and types in general have 3 swaps: swap(T&, T&)
- swap(T&&, T&) swap(T&, T&&) But
- array only has swap(T&, T&).
+<td>23.1.4 [assoc-iative. 
+reqmts]<td>6

- 
+<td>Te

- <td>
- add the other two swaps.
+<td>Leaving it
+unspecified whether or not iterator and const_iterator are
+the same type is dangerous, as user code may or may not
+violate the One Definition Rule by providing overloads for
+both types. It is probably too late to specify a single
+behaviour, but implementors should document what to expect.
+Observing that problems can be avoided by users restricting
+themselves to using const_iterator, add a note to that
+effect.

- <td>
- 
+<td>Change 'unspecified' to 'implementation
+defined'. Add "[Note: As itererator and const_iterator have
+identical semantics in this case, and iterator is
+convertible to const_iterator, users can avoid violating
+the One Definition Rule by always using const_iterator in
+their function parameter lists -- end note]

- Agree. The proposed wording is forthcoming from Martin. We feel that these
- overloads of swap are more important for array than other containers because
- swap is not O(1) for array.
+<td>Agree with issue. Agree with adding the note but not with changing the
+ normative text. We believe the note provides sufficient guidance.

- HOWEVER in a later session discussing D2844, it was decided
- to remove all the r-value-ref <code>swap</code> overloads from containers.
- Therefore adding them to <code>array</code> has no benefit. So the final
- disposition is NAD.<tr valign="top">
- <td>
- UK 
- 244
+<tr valign="top">
+<td>UK239

- <td>
- 23.2.1, 
- 23.2.6 
- [array], [vector]
+<td>23.1.4  [assoc-iative. 
+reqmts]<td>85

- <td>
- 1
+<td>Te

- <td>
- Te
+<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>
- The validity of
- the expression &a[n] == &a[0] + n is contingent on
- operator& doing the “right thing” (as
- captured by the CopyConstructible requirements in table 30
- in C++2003). However this constraint has been lost in the
- Concepts of C++0x. This applies to vector and array (it
- actually applies to string also, but that's a different
- chapter, so I'll file a separate comment there and
- cross-reference).
-
- 
-
- <td>
- Define a ContiguousStrorage and apply it to
- vector,array and string. The Concept (supplied by Alisdair
- M) looks like this: Concept< typename C >
- ContiguousStrorage { requires Container<C>; typename
- value_type = C::value_type; value_type * data( C ); axiom
- Contiguous { C c; true = equal_ranges( data( c), data(c) +
- size(c), begin(c)); } };
-
- <td>
- 
-
- Agree with the issue but not the details of the proposed solution. Walter to
- provide wording for the new concept.<tr valign="top">
- <td>
- <a name="UK245">UK 
- 245</a>
-
- <td>
- 23.2.3
-
- <td>
- 2
-
- <td>
- Te
-
- <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
- solution would be to require these callable concepts to be
- CopyConstructible in clause 20, which would simplify the
- library specification in general. See earlier comment for
- details, that would render this one redundant.
-
- <td>
- Add
- CopyConstructible requirement to the following signatures:
- template <Predicate<auto, T> Pred> requires
- CopyConstructible<Pred> void remove_if(Pred pred);
- template <EquivalenceRelation<auto, T>
- BinaryPredicate> requires
- CopyConstructible<BinaryPredicate> void
- unique(BinaryPredicate binary_pred); template
- <StrictWeakOrder<auto, T> Compare> requires
- CopyConstructible<Compare> void
- merge(forward_list<T,Alloc>&& x, Compare
- comp); template <StrictWeakOrder<auto, T>
- Compare> requires CopyConstructible<Compare> void
- sort(Compare comp);
+<td>Add below
+a.erase(q), a.extract(q), with the following notation:
+a.extract(q), Return type pair<key, iterator>
+Extracts the element pointed to by q and erases it from the
+set. Returns a pair containing the value pointed to by q
+and an iterator pointing to the element immediately
+following q prior to the element being erased. If no such
+element exists,returns a.end().

- 
+<td>We look forward to a paper on this topic. We recommend no action until a
+ paper is available. The paper would need to address exception safety.

- 
+<tr valign="top">
+<td>UK240

- <td>
- 
+<td>23.1.6.1 
+[container. 
+concepts. 
+free]<td>12

- UK245 with additional comments on UK200 in clause 20: After further
- discussion of UK200, we do not think adding constraints to predicates is a
- good idea. Straw poll on
- UK245: status quo, 5 pro - 0 con; add copy-constructible, 1 pro - 3 con; no
- consensus for moving away from the status quo.
+<td>Te

- <tr valign="top">
- <td>
- JP 58
+<td>The axiom
+EmplacePushEquivalence should be asserting the stronger
+contract that emplace and insert return the same iterator
+value, not just iterators that dereference to the same
+value. This is a similar statement that is easier to
+express and should be equivalent - the idea that insert and
+emplace might return iterator values that do not compare
+equal but point to the same element should fail somewhere
+in the iterator concepts. Also, this axiom should be
+renamed to reflect its connection with insert, rather than
+push_front/push_back,

- <td>
- 23.2.3.2
+<td>Remove the * to deference the returned
+iterator either side of the == in the
+EmplacePushEquivalence axiom, rename the axiom
+EmplacementInsertionEquivalence : requires
+InsertionContainer<C> &&
+Constructible<value_type, Args...> axiom
+EmplacementInsertionEquivalence(C c, const_iterator
+position, Args... args) { emplace(c, position, args...) ==
+insert(c, position, value_type(args...)); }

- <td>
- 
- 1st line
- before 1st para
+<td>We look forward to a paper on this topic. We recommend no action until a
+ paper is available. We suspect that there are other similar issues in this
+ sub-clause (9, 10).

- 
+<tr valign="top">
+<td>JP57

- <td>
- ed
+<td>23.1.6.3

- <td>
- 
- Unnecessary "{" exists before a word iterator like
- "{iterator before_begin()".
+<td>
+1st para, 4th line

- <td>
- 
- Remove "{"
+<td>ed

- <td>
- 
+<td>
+Typo, duplicated "to"

- [Being reviewed by Editor]<tr valign="top">
- <td>
- JP 59
+
+"to to model insertion container concepts."

- <td>
- 23.2.4.4
+<td>
+Remove one.

- <td>
- 
+<td>[Being reviewed by Editor]

- <td>
- ed
+<tr valign="top">
+<td>UK241

- <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>23.2.1

- <td>
- 
- Correct as follows.
+<td>

- 
- void splice(const_iterator position,
- list<T,Allocator>&& x, iterator i);
+<td>Te

- 
- void splice(const_iterator position,
- list<T,Allocator>&& x,
+<td>std::array does
+not have an allocator, so need to document an exception to
+the requirements of 23.1.1p3

- 
- iterator first, iterator last);
+<td>add exception to 23.1.1p3

- 
- 
+<td>Duplicate of UK 224.

- 
- should be
+<tr valign="top">
+<td>UK242

- 
- 
+<td>23.2.1

- 
- void splice(const_iterator position,
- list<T,Allocator>&& x, const_iterator i);
+<td>3

- 
- void splice(const_iterator position,
- list<T,Allocator>&& x,
+<td>Ed

- const_iterator
- first, const_iterator last);
+<td>std:: qualification no longer needed for
+reverse_iterator.

- 
- 
+<td>remove std::
+qualification from std::reverse_iterator<iterator>
+and std::reverse_iterator<const_iterator>

- <td>
- 
+<td>[Being reviewed by Editor]

- [Being reviewed by Editor]<tr valign="top">
- <td>
- US 83
+<tr valign="top">
+<td>UK243

- <td>
- 23.2.6.2
+<td>23.2.1 
+[array]<td>3

- <td>
- 7
+<td>Te

- <td>
- ed
+<td>Most containers,
+and types in general have 3 swaps: swap(T&, T&)
+swap(T&&, T&) swap(T&, T&&) But
+array only has swap(T&, T&).

- <td>
- 
- "shrink_to_fint" should be "shrink_to_fit".
+<td>add the other two swaps.

- 
- 
+<td>Agree. The proposed wording is forthcoming from Martin. We feel that these
+ overloads of swap are more important for array than other containers because
+ swap is not O(1) for array.

- 
+ HOWEVER in a later session discussing D2844, it was decided
+ to remove all the r-value-ref <code>swap</code> overloads from containers.
+ Therefore adding them to <code>array</code> has no benefit. So the final
+ disposition is NAD.

- <td>
- 
+<tr valign="top">
+<td>UK244

- <td>
- [Being reviewed by Editor] 
+<td>23.2.1, 
+ 23.2.6 
+[array], [vector]

- <tr valign="top">
- <td>
- UK 
- 246
+<td>1

- <td>
- 23.3.2.2
+<td>Te

- <td>
- 
+<td>The validity of
+the expression &a[n] == &a[0] + n is contingent on
+operator& doing the “right thing” (as
+captured by the CopyConstructible requirements in table 30
+in C++2003). However this constraint has been lost in the
+Concepts of C++0x. This applies to vector and array (it
+actually applies to string also, but that's a different
+chapter, so I'll file a separate comment there and
+cross-reference).
+
+<td>Define a ContiguousStrorage and apply it to
+vector,array and string. The Concept (supplied by Alisdair
+M) looks like this: Concept< typename C >
+ContiguousStrorage { requires Container<C>; typename
+value_type = C::value_type; value_type * data( C ); axiom
+Contiguous { C c; true = equal_ranges( data( c), data(c) +
+size(c), begin(c)); } };
+
+<td>Agree with the issue but not the details of the proposed solution. Walter to
+ provide wording for the new concept.
+
+<tr valign="top">
+<td><a name="UK245">UK245</a>
+
+<td>23.2.3
+
+<td>2
+
+<td>Te
+
+<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
+solution would be to require these callable concepts to be
+CopyConstructible in clause 20, which would simplify the
+library specification in general. See earlier comment for
+details, that would render this one redundant.
+
+<td>Add
+CopyConstructible requirement to the following signatures:
+template <Predicate<auto, T> Pred> requires
+CopyConstructible<Pred> void remove_if(Pred pred);
+template <EquivalenceRelation<auto, T>
+BinaryPredicate> requires
+CopyConstructible<BinaryPredicate> void
+unique(BinaryPredicate binary_pred); template
+<StrictWeakOrder<auto, T> Compare> requires
+CopyConstructible<Compare> void
+merge(forward_list<T,Alloc>&& x, Compare
+comp); template <StrictWeakOrder<auto, T>
+Compare> requires CopyConstructible<Compare> void
+sort(Compare comp);

- <td>
- Ed
+ 

- <td>
- The content of
- this sub-clause is purely trying to describe in words the
- effect of the requires clauses on these operations, now
- that we have Concepts. As such, the desctiption is more
- confusing than the signature itself. The semantic for these
- functions is adequately covered in the requirements tables
- in 23.1.4.
+<td>UK245 with additional comments on UK200 in clause 20: After further
+ discussion of UK200, we do not think adding constraints to predicates is a
+ good idea. Straw poll on
+ UK245: status quo, 5 pro - 0 con; add copy-constructible, 1 pro - 3 con; no
+ consensus for moving away from the status quo.

- 
+

- <td>
- Strike 23.3.2.2 entirely. (but do NOT
- strike these signatures from the class template
- definition!)
+<tr valign="top">
+<td>JP58

- <td>
- [Being reviewed by Editor] 
+<td>23.2.3.2

- <tr valign="top">
- <td>
- UK 
- 247
+<td>
+1st line
+before 1st para

- <td>
- 24.1
+<td>ed

- <td>
- 
+<td>
+Unnecessary "{" exists before a word iterator like
+"{iterator before_begin()".

- <td>
- Ge
+<td>
+Remove "{"

- <td>
- Iterator
- concepts are not extensive enough to merit a whole new
- header, and should be merged into <concpts>. This is
- particularly important for supporting the new for loop
- syntax which requires access to the Range concept. The
- required header to enable this syntax shoud have a simple
- name, like <concepts>, rather than something awkward
- to type like <iterator_concepts>.
+<td>[Being reviewed by Editor]

- 
+<tr valign="top">
+<td>JP59

- <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>23.2.4.4

- <td>
- NAD. We believe the separate header to have value. 
+<td>

- <tr valign="top">
- <td>
- UK 
- 248
+<td>ed

- <td>
- 24.1
+<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>
- 6
+<td>
+Correct as follows.

- <td>
- Ed
+
+void splice(const_iterator position,
+list<T,Allocator>&& x, iterator i);

- <td>
- The text "so for
- any iterator type there is an iterator value that points
- past the last element of a corresponding container" is
- slightly misleading. Iterators can refer into generalised
- ranges and sequences, not just containers. A broader term
- than 'container' should be used.
+
+void splice(const_iterator position,
+list<T,Allocator>&& x,

- 
+
+iterator first, iterator last);

- <td>
- Replace the reference to container with a
- more appropriate concept
+
+ 

- <td>
- [Being reviewed by Editor] 
+
+should be

- <tr valign="top">
- <td>
- UK 
- 250
+
+ 

- <td>
- 24.1.1
+
+void splice(const_iterator position,
+list<T,Allocator>&& x, const_iterator i);

- <td>
- 
+
+void splice(const_iterator position,
+list<T,Allocator>&& x,

- <td>
- Te
+const_iterator
+first, const_iterator last);

- <td>
- A default implementation should be supplied
- for the post-increment operator to simplify implementation
- of iterators by users.
+
+ 

- <td>
- Copy the Effects clause into the concept
- description as the default implementation. Assumes a
- default value for postincrement_result
+<td>[Being reviewed by Editor]

- <td>
- Howard will open an issue. 
+<tr valign="top">
+<td>US83

- <tr valign="top">
- <td>
- UK 
- 251
+<td>23.2.6.2

- <td>
- 24.1.1
+<td>7

- <td>
- 3
+<td>ed

- <td>
- Te
+<td>
+"shrink_to_fint" should be "shrink_to_fit".

- <td>
- The
- post-increment operator is dangerous for a general
- InputIterator. The multi-pass guarantees that make it
- meaningful are defined as part of the ForwardIterator
- refinement. Any change will affect only constrained
- templates that have not yet been written, so should not
- break existing user iterators which remain free to add
- these operations. This change will also affect the
- generalised OutputIterator, although there is no percieved
- need for the post-increment operator in this case either.
+
+ 

- 
+<td>

- <td>
- Move declaration of postincrement operator
- and postincrement_result type from Interator concept to the
- ForwardIterator concept
+<td>[Being reviewed by Editor] 

- <td>
- Alisdair will open an issue. 
+

- <tr valign="top">
- <td>
- UK 
- 252
+<tr valign="top">
+<td>UK246

- 
+<td>23.3.2.2

- <td>
- 24.1.2
+<td>

- <td>
- 3
+<td>Ed

- <td>
- Ed
+<td>The content of
+this sub-clause is purely trying to describe in words the
+effect of the requires clauses on these operations, now
+that we have Concepts. As such, the desctiption is more
+confusing than the signature itself. The semantic for these
+functions is adequately covered in the requirements tables
+in 23.1.4.

- <td>
- istream_iterator is not a class, but a
- class template
+<td>Strike 23.3.2.2 entirely. (but do NOT
+strike these signatures from the class template
+definition!)

- <td>
- Change 'class' to 'class template' in the
- note.
+<td>[Being reviewed by Editor] 

- <td>
- [Being reviewed by Editor] 
+

- <tr valign="top">
- <td>
- UK 
- 253
+<tr valign="top">
+<td>UK247

- <td>
- 24.1.3
+<td>24.1

- <td>
- 1
+<td>

- <td>
- Ed
+<td>Ge

- <td>
- First sentance
- does not make gramatical sense, Seems to be missing the
- words 'if it' by comparison with similar sentance in other
- subsections
+<td>Iterator
+concepts are not extensive enough to merit a whole new
+header, and should be merged into <concpts>. This is
+particularly important for supporting the new for loop
+syntax which requires access to the Range concept. The
+required header to enable this syntax shoud have a simple
+name, like <concepts>, rather than something awkward
+to type like <iterator_concepts>.
+
+<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>NAD. We believe the separate header to have value. 

- <td>
- Add the words 'if it' : "X satisfies the
- requirements of an output iterator IF IT meets the
- syntactic and semantic requirements"
+

- <td>
- [Being reviewed by Editor] 
+<tr valign="top">
+<td>UK248

- <tr valign="top">
- <td>
- UK 
- 254
+<td>24.1

- <td>
- 24.1.3
+<td>6

- <td>
- 5
+<td>Ed

- <td>
- Te
+<td>The text "so for
+any iterator type there is an iterator value that points
+past the last element of a corresponding container" is
+slightly misleading. Iterators can refer into generalised
+ranges and sequences, not just containers. A broader term
+than 'container' should be used.

- <td>
- This
- postcondition for pre-increment operator should be written
- as an axiom
+<td>Replace the reference to container with a
+more appropriate concept

- 
+<td>[Being reviewed by Editor] 

- <td>
- Move the postcondition into the concept
- definition as an axiom
+

- <td>
- deferred until we know whether we have axioms. 
+<tr valign="top">
+<td>UK250

- <tr valign="top">
- <td>
- UK 
- 255
+<td>24.1.1

- <td>
- 24.1.4
+<td>

- <td>
- 4
+<td>Te

- <td>
- Te
+<td>A default implementation should be supplied
+for the post-increment operator to simplify implementation
+of iterators by users.

- <td>
- This
- postcondition for pre-increment operator should be written
- as an axiom
+<td>Copy the Effects clause into the concept
+description as the default implementation. Assumes a
+default value for postincrement_result

- 
+<td>Howard will open an issue. 

- <td>
- Move the postcondition into the concept
- definition as an axiom
+

- <td>
- deferred until we know whether we have axioms. 
+<tr valign="top">
+<td>UK251

- <tr valign="top">
- <td>
- UK 
- 256
+<td>24.1.1

- <td>
- 24.1.5
+<td>3

- <td>
- 3, 4, 5
+<td>Te

- <td>
- Te
+<td>The
+post-increment operator is dangerous for a general
+InputIterator. The multi-pass guarantees that make it
+meaningful are defined as part of the ForwardIterator
+refinement. Any change will affect only constrained
+templates that have not yet been written, so should not
+break existing user iterators which remain free to add
+these operations. This change will also affect the
+generalised OutputIterator, although there is no percieved
+need for the post-increment operator in this case either.
+
+<td>Move declaration of postincrement operator
+and postincrement_result type from Interator concept to the
+ForwardIterator concept

- <td>
- The relationship between pre- and post-
- decrement should be expressed as an axiom.
+<td>Alisdair will open an issue. 

- <td>
- Move the text
- specification of pre/post-conditions and behaviour into an
- axiom within the BidirectionalIterator concept
+

- 
+<tr valign="top">
+<td>UK252

- <td>
- deferred until we know whether we have axioms. 
+

- <tr valign="top">
- <td>
- UK 
- 257
+<td>24.1.2

- <td>
- 24.1.5
+<td>3

- <td>
- 
+<td>Ed

- <td>
- Te
+<td>istream_iterator is not a class, but a
+class template

- <td>
- There is a
- reasonable default for postdecrement_result type, which is
- X. X is required to be regular, therefore CopyConstructible
- and a valid ResultType. Together with the next comment this
- simplifies user defined iterator implentations
+<td>Change 'class' to 'class template' in the
+note.

- 
+<td>[Being reviewed by Editor] 

- <td>
- Add the default : typename
- postincrement_result = X;
+

- <td>
- NAD, postdecrement_result is deduced. 
+<tr valign="top">
+<td>UK253

- <tr valign="top">
- <td>
- UK 
- 258
+<td>24.1.3

- <td>
- 24.1.5
+<td>1

- <td>
- 
+<td>Ed

- <td>
- Te
+<td>First sentance
+does not make gramatical sense, Seems to be missing the
+words 'if it' by comparison with similar sentance in other
+subsections

- <td>
- A default
- implementation should be supplied for the post-decrement
- operator to simplify implementation of iterators by users.
+<td>Add the words 'if it' : "X satisfies the
+requirements of an output iterator IF IT meets the
+syntactic and semantic requirements"

- 
+<td>[Being reviewed by Editor] 

- <td>
- Copy the Effects clause into the concept
- description as the default implementation. Assumes a
- default value for postincrement_result
+

- <td>
- Howard will open an issue. 
+<tr valign="top">
+<td>UK254

- <tr valign="top">
- <td>
- UK 
- 259
+<td>24.1.3

- <td>
- 24.1.5
+<td>5

- <td>
- 
+<td>Te

- <td>
- Te
+<td>This
+postcondition for pre-increment operator should be written
+as an axiom

- <td>
- 
- postdecrement_result is effectively returning a copy of the
- original iterator value, so should have similar
- constraints, rather than just HasDereference. If Concepts
- do not support this circularity of definition suggest that
- concepts feature may want a little more work
+<td>Move the postcondition into the concept
+definition as an axiom

- 
+<td>deferred until we know whether we have axioms. 

- <td>
- Add the requirement: requires Iterator<
- postdecrement_result >;
+

- <td>
- NAD unless Alisdair comes back with more motivation. 
+<tr valign="top">
+<td>UK255

- <tr valign="top">
- <td>
- UK 
- 260
+<td>24.1.4

- <td>
- 24.1.5
+<td>4

- <td>
- 6
+<td>Te

- <td>
- Te
+<td>This
+postcondition for pre-increment operator should be written
+as an axiom

- <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>Move the postcondition into the concept
+definition as an axiom

- <td>
- Move the Effects
- clause into the BidirectionalIterator concept definition as
- an axiom, and as the default implementation for the
- operation.
+<td>deferred until we know whether we have axioms. 

- 
+

- <td>
- deferred for axiom decision. 
+<tr valign="top">
+<td>UK256

- <tr valign="top">
- <td>
- UK 
- 249
+<td>24.1.5

- <td>
- 24.1.6
+<td>3, 4, 5

- <td>
- 2
+<td>Te

- <td>
- Te
+<td>The relationship between pre- and post-
+decrement should be expressed as an axiom.

- <td>
- The semantic for
- operator+= should also be provided as a default
- implementation to simplify implementation of user-defined
- iterators
+<td>Move the text
+specification of pre/post-conditions and behaviour into an
+axiom within the BidirectionalIterator concept

- 
+<td>deferred until we know whether we have axioms. 

- <td>
- Copy the text from the effects clause into
- the RandomAccessIterator concept as the default
- implementaiton.
+

- <td>
- NAD, violates complexity requirements. 
+<tr valign="top">
+<td>UK257

- <tr valign="top">
- <td>
- UK 
- 261
+<td>24.1.5

- <td>
- 24.1.6
+<td>

- <td>
- 
+<td>Te

- <td>
- Te
+<td>There is a
+reasonable default for postdecrement_result type, which is
+X. X is required to be regular, therefore CopyConstructible
+and a valid ResultType. Together with the next comment this
+simplifies user defined iterator implentations

- <td>
- To simplify user
- defined random access iterator types, the
- subscript_reference type should default to reference
+<td>Add the default : typename
+postincrement_result = X;

- 
+<td>NAD, postdecrement_result is deduced. 

- <td>
- typename subscript_reference = reference;
+

- <td>
- NAD, subscript reference isn’t used.In
- c++std-lib-23104, 
- Daniel Krügler
- commented,
- this [proposed change] would disable "auto-deduction" of
- the return type of any operator[]as described by [concept.map.assoc]/4+5.<tr valign="top">
- <td>
- UK 
- 262
+<tr valign="top">
+<td>UK258

- <td>
- 24.1.6
+<td>24.1.5

- <td>
- 3, 4
+<td>

- <td>
- Te
+<td>Te

- <td>
- Effects and post-conditions for operator+
- are more useful if expressed as axioms, and supplied as
- default implementations.
+<td>A default
+implementation should be supplied for the post-decrement
+operator to simplify implementation of iterators by users.

- <td>
- Move the effects
- and Postcondition definitions into the RandomAccessIterator
- concept and copy the code in the specification as the
- default implementation of these operations.
+<td>Copy the Effects clause into the concept
+description as the default implementation. Assumes a
+default value for postincrement_result

- 
+<td>Howard will open an issue. 

- <td>
- default implementation already in Standard; axiom part
- deferred. 
+

- <tr valign="top">
- <td>
- UK 
- 263
+<tr valign="top">
+<td>UK259

- <td>
- 24.1.6
+<td>24.1.5

- <td>
- 5
+<td>

- <td>
- Te
+<td>Te

- <td>
- This requirement on operator-= would be
- better expressed as a default implementation in the
- concept, with a matching axiom
+<td>
+postdecrement_result is effectively returning a copy of the
+original iterator value, so should have similar
+constraints, rather than just HasDereference. If Concepts
+do not support this circularity of definition suggest that
+concepts feature may want a little more work

- <td>
- Move the
- specification for operator-= from the returns clause into
- an axiom and default implementation within the
- RandomAccessIterator concept
+<td>Add the requirement: requires Iterator<
+postdecrement_result >;

- 
+<td>NAD unless Alisdair comes back with more motivation. 

- <td>
- Alisdair will open an issue, axiom part deferred. 
+

- <tr valign="top">
- <td>
- UK 
- 264
+<tr valign="top">
+<td>UK260

- <td>
- 24.1.6
+<td>24.1.5

- <td>
- 6
+<td>6

- <td>
- Te
+<td>Te

- <td>
- Effects clauses are better expressed as
- axioms where possible.
+<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>
- Move code in
- operator- effects clause into RandomAccessIterator concept
- as both a default implementation and an axiom
+<td>Move the Effects
+clause into the BidirectionalIterator concept definition as
+an axiom, and as the default implementation for the
+operation.

- 
+<td>deferred for axiom decision. 

- <td>
- deferred/axiom. 
+

- <tr valign="top">
- <td>
- UK 
- 265
+<tr valign="top">
+<td>UK249

- <td>
- 24.1.6
+<td>24.1.6

- <td>
- 8
+<td>2

- <td>
- Te
+<td>Te

- <td>
- This effects
- clause is nonesense. It looks more like an axiom stating
- equivalence, and certainly an effects clause cannot change
- the state of two arguments passed by const reference
+<td>The semantic for
+operator+= should also be provided as a default
+implementation to simplify implementation of user-defined
+iterators

- 
+<td>Copy the text from the effects clause into
+the RandomAccessIterator concept as the default
+implementaiton.

- <td>
- Strike the Effects clause
+<td>NAD, violates complexity requirements. 

- <td>
- Doug will open issue…strike effect, returns n. 
+

- <tr valign="top">
- <td>
- UK 
- 266
+<tr valign="top">
+<td>UK261

- <td>
- 24.1.6
+<td>24.1.6

- <td>
- 9
+<td>

- <td>
- Te
+<td>Te

- <td>
- This sentance should be provided as a
- default definition, along with a matching axiom
+<td>To simplify user
+defined random access iterator types, the
+subscript_reference type should default to reference

- <td>
- Move the Returns
- clause into the spefication for RandomAccessIterator
- operator- as a default implementation. Move the Effects
- clause as the matching axiom.
+<td>typename subscript_reference = reference;

- 
+<td>NAD, subscript reference isn’t used.In
+c++std-lib-23104, 
+Daniel Krügler
+commented,
+this [proposed change] would disable "auto-deduction" of
+the return type of any operator[]as described by [concept.map.assoc]/4+5.

- <td>
- default definition is not implementable; axiom part
- deferred. 
+<tr valign="top">
+<td>UK262

- <tr valign="top">
- <td>
- UK 
- 267
+<td>24.1.6

- <td>
- 24.1.6
+<td>3, 4

- <td>
- 24.1.6
+<td>Te

- <td>
- Te
+<td>Effects and post-conditions for operator+
+are more useful if expressed as axioms, and supplied as
+default implementations.

- <td>
- The code in the
- Requires clause for RandomAccessIterator operator[] would
- be better expressed as an axiom.
+<td>Move the effects
+and Postcondition definitions into the RandomAccessIterator
+concept and copy the code in the specification as the
+default implementation of these operations.

- 
+<td>default implementation already in Standard; axiom part
+deferred. 

- <td>
- Rewrite the Requires clause as an axiom in
- the RandomAccessIterator concept
+

- <td>
- deferred/axiom. 
+<tr valign="top">
+<td>UK263

- <tr valign="top">
- <td>
- UK 
- 268
+<td>24.1.6

- <td>
- 24.1.6
+<td>5

- <td>
- 12
+<td>Te

- <td>
- Ed
+<td>This requirement on operator-= would be
+better expressed as a default implementation in the
+concept, with a matching axiom

- <td>
- This note is
- potentialy confusing as __far enters the syntax as a clear
- language extension, but the note treats it as a regular
- part of the grammar. It might be better expressed using
- attributes in the current wording.
+<td>Move the
+specification for operator-= from the returns clause into
+an axiom and default implementation within the
+RandomAccessIterator concept

- 
+<td>Alisdair will open an issue, axiom part deferred. 

- <td>
- Clean up the note to either avoid using
- language extension, or spell out this is a constraint to
- support extensions.
+

- <td>
- [Being reviewed by Editor] 
+<tr valign="top">
+<td>UK264

- <tr valign="top">
- <td>
- JP 60
+<td>24.1.6

- <td>
- 24.1.8
+<td>6

- <td>
- 1st para
+<td>Te

- <td>
- te
+<td>Effects clauses are better expressed as
+axioms where possible.

- <td>
- 
- Capability of an iterator is too much restricted by
- concept.
+<td>Move code in
+operator- effects clause into RandomAccessIterator concept
+as both a default implementation and an axiom

- 
- 
+<td>deferred/axiom. 

- 
- Concept of std::Range is defined as:
+

- 
- 
+<tr valign="top">
+<td>UK265

- 
- concept Range<typename T> {
+<td>24.1.6

- 
- InputIterator iterator;
+<td>8

- 
- iterator begin(T&);
+<td>Te

- 
- iterator end(T&);
+<td>This effects
+clause is nonesense. It looks more like an axiom stating
+equivalence, and certainly an effects clause cannot change
+the state of two arguments passed by const reference

- }
+<td>Strike the Effects clause

- 
- 
+<td>Doug will open issue…strike effect, returns n. 

- So
- the following code generates an error.
+

- 
- 
+<tr valign="top">
+<td>UK266

- 
- template <std::Range Rng>
+<td>24.1.6

- 
- void sort(Rng& r)
+<td>9

- {
+<td>Te

- 
- // error! Rng::iterator does not satisfy requirements of a
- random
+<td>This sentance should be provided as a
+default definition, along with a matching axiom

- 
- // access iterator.
+<td>Move the Returns
+clause into the spefication for RandomAccessIterator
+operator- as a default implementation. Move the Effects
+clause as the matching axiom.

- 
- std::sort(begin(r), end(r));
+<td>default definition is not implementable; axiom part
+deferred. 

- }
+

- 
- 
+<tr valign="top">
+<td>UK267

- 
- std::vector<int> v; // vector::iterator is a random
- access iterator.
+<td>24.1.6

- 
- sort(v);
+<td>24.1.6

- 
- 
+<td>Te

- 
- This is because the concept of an iterator of std::Range is
- InputIterator. For this reason, a random access iterator
- loses its capability when passed to a std::Range parameter.
+<td>The code in the
+Requires clause for RandomAccessIterator operator[] would
+be better expressed as an axiom.

- 
- 
+<td>Rewrite the Requires clause as an axiom in
+the RandomAccessIterator concept

- To
- be able to work the above code, we need to write as
- follows:
+<td>deferred/axiom. 

- 
- 
+

- 
- template <std::Range T>
+<tr valign="top">
+<td>UK268

- 
- requires std::RandomAccessIterator<T::iterator>
- &&
+<td>24.1.6

- 
- std::ShuffleIterator<T::iterator> &&
+<td>12

- 
- std::LessThanComparable<T::iterator::value_type>
+<td>Ed

- 
- void sort(T& r)
+<td>This note is
+potentialy confusing as __far enters the syntax as a clear
+language extension, but the note treats it as a regular
+part of the grammar. It might be better expressed using
+attributes in the current wording.

- {
+<td>Clean up the note to either avoid using
+language extension, or spell out this is a constraint to
+support extensions.

- 
- sort(begin(r), end(r));
+<td>[Being reviewed by Editor] 

- }
+

- 
- 
+<tr valign="top">
+<td>JP60

- 
- std::vector<int> v;
+<td>24.1.8

- 
- sort(v);
+<td>1st para

- 
- 
+<td>te

- It
- needs quiet a few amount of codes like this only to recover
- random access capability from InputIterator concept.
+<td>
+Capability of an iterator is too much restricted by
+concept.

- 
- 
+
+ 

- We
- can write the following valid code with Boost.Range, which
- is implemented with using C++03 SFINAE.
+
+Concept of std::Range is defined as:

- 
- 
+
+ 

- 
- template <class Range>
+
+concept Range<typename T> {

- 
- void sort(Range& r)
+
+InputIterator iterator;

- {
+
+iterator begin(T&);

- 
- std::sort(boost::begin(r), boost::end(r));
+
+iterator end(T&);

- }
+}

- 
- 
+
+ 

- 
- std::vector<int> v;
+So
+the following code generates an error.

- 
- sort(v); // OK
+
+ 

- 
- 
+
+template <std::Range Rng>

- One of the
- motivation to introduce concepts are supporting template
- programming techniques by language directly to eliminate
- hacky techniques such as tag-dispatch, SFINAE and Type
- Traints. But SFINAE will be kept using because it needs
- quite a few amount of codes without using SFAINAE.
+
+void sort(Rng& r)

- 
- 
+{

- <td>
- Add
- InputRange, OutputRange, ForwardRange, BidirectionalRange
- and RandomAccessRange.
+
+// error! Rng::iterator does not satisfy requirements of a
+random

- <td>
- NAD, beyond the scope of the Standard because we are not
- supplying range-based algorithms. 
+
+// access iterator.

- <tr valign="top">
- <td>
- UK 
- 269
+
+std::sort(begin(r), end(r));

- <td>
- 24.3
+}

- <td>
- 3
+
+ 

- <td>
- Ed
+
+std::vector<int> v; // vector::iterator is a random
+access iterator.

- <td>
- 'decrements for
- negative n' seems to imply a negative number of decrement
- operations, which is odd.
+
+sort(v);

- 
+
+ 

- <td>
- Need simple, clearer wording
+
+This is because the concept of an iterator of std::Range is
+InputIterator. For this reason, a random access iterator
+loses its capability when passed to a std::Range parameter.

- <td>
- [Being reviewed by Editor] 
+
+ 

- <tr valign="top">
- <td>
- UK 
- 270
+To
+be able to work the above code, we need to write as
+follows:

- <td>
- 24.3
+
+ 

- <td>
- 4
+
+template <std::Range T>

- <td>
- Te
+
+requires std::RandomAccessIterator<T::iterator>
+&&

- <td>
- The reachability
- constraint in p5 means that a negavite result, implying
- decrements operations in p4, is not possible
+
+std::ShuffleIterator<T::iterator> &&

- 
+
+std::LessThanComparable<T::iterator::value_type>

- <td>
- Split the two overloads into separate
- descriptions, where reachability is permitted to be in
- either direction for RandomAccessIterator
+
+void sort(T& r)

- <td>
- Howard will open an issue. 
+{

- <tr valign="top">
- <td>
- UK 
- 271
+
+sort(begin(r), end(r));

- <td>
- 24.3
+}

- <td>
- 6,7
+
+ 

- <td>
- Te
+
+std::vector<int> v;

- <td>
- next/prev return
- an incremented iterator without changing the value of the
- original iterator. However, even this may invalidate an
- InputIterator. A ForwardIterator is required to guarantee
- the 'multipass' property.
+
+sort(v);

- 
+
+ 

- <td>
- Replace InputIterator constraint with
- FOrwardIterator in next and prev function templates.
+It
+needs quiet a few amount of codes like this only to recover
+random access capability from InputIterator concept.

- <td>
- Alisdair will open an issue. 
+
+ 

- <tr valign="top">
- <td>
- UK 
- 272
+We
+can write the following valid code with Boost.Range, which
+is implemented with using C++03 SFINAE.

- <td>
- 24.4
+
+ 

- <td>
- 
+
+template <class Range>

- <td>
- Te
+
+void sort(Range& r)

- <td>
- reverse_iterator
- and move_iterator use different formulations for their
- comparison operations. move_iterator merely requires the
- minimal set of operations, < and ==, from its underlying
- iterator and synthesizes all oprations from these two.
- reverse_iterator relies on the undelying iterator to
- support all comparision operations directly. In practice,
- move_iterator can only be implemented this way as it must
- support iterator types that are merely InputIterators, and
- so SemiRegular and not Regular. However, reserse_iterator
- has an existing specification and any change of semantic
- could change behaviour of conforming programs today -
- although an iterator that yields different results for (a
- > b) than (b < a) may fall foul of some semantic
- consistency requirements, even if the syntax is met.
+{

- 
+
+std::sort(boost::begin(r), boost::end(r));

- <td>
- Rephrase the reverse_iterator comparison
- operations using only operators < and ==, as per the
- move_iterator specification.
+}

- <td>
- NAD, no consensus. 
+
+ 

- <tr valign="top">
- <td>
- UK 
- 274
+
+std::vector<int> v;

- <td>
- 24.4, 24.5
+
+sort(v); // OK

- <td>
- 
+
+ 

- <td>
- Ed
+One of the
+motivation to introduce concepts are supporting template
+programming techniques by language directly to eliminate
+hacky techniques such as tag-dispatch, SFINAE and Type
+Traints. But SFINAE will be kept using because it needs
+quite a few amount of codes without using SFAINAE.

- <td>
- The subclauses
- for standard iterator adaptors could be better organised.
- There are essentially 3 kinds of iterator wrappers
- provided, stream iterators adapt streams and get their own
- subsection. insert iterators adapt containers, and get
- their own subsection but it is inserted into the middle of
- 24.4 Predifined iterators. reverse_iterator and
- move_iterator adpat other iterators, but their presentation
- is split by insert iterators
+
+ 

- 
+<td>Add
+InputRange, OutputRange, ForwardRange, BidirectionalRange
+and RandomAccessRange.

- <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>NAD, beyond the scope of the Standard because we are not
+supplying range-based algorithms. 

- <td>
- [Being reviewed by Editor] 
+

- <tr valign="top">
- <td>
- UK 
- 275
+<tr valign="top">
+<td>UK269

- <td>
- 24.4.1.1
+<td>24.3

- <td>
- 
+<td>3

- <td>
- Te
+<td>Ed

- <td>
- The constructor
- template taking a single Iterator argument will be selected
- for Copy Initialization instead of the non-template
- constructor taking a single Iterator argument selected by
- Direct Initialization.
+<td>'decrements for
+negative n' seems to imply a negative number of decrement
+operations, which is odd.

- 
+<td>Need simple, clearer wording

- <td>
- The reverse_iterator template constructor
- taking a single Iterator argument should be explicit.
+<td>[Being reviewed by Editor] 

- <td>
- NAD, withdrawn by submitter. 
+

- <tr valign="top">
- <td>
- UK 
- 276
+<tr valign="top">
+<td>UK270

- <td>
- 24.4.1.1
+<td>24.3

- <td>
- 
+<td>4

- <td>
- Ed
+<td>Te

- <td>
- It is odd to
- have a mix of declaration stlyes for operator+ overloads.
- Prefer if either all are member functions, or all are
- 'free' functions.
+<td>The reachability
+constraint in p5 means that a negavite result, implying
+decrements operations in p4, is not possible

- 
+<td>Split the two overloads into separate
+descriptions, where reachability is permitted to be in
+either direction for RandomAccessIterator

- <td>
- Make the member operators taking a
- difference_type argument non-member operators
+<td>Howard will open an issue. 

- <td>
- NAD, not editorial, withdrawn by submitter. 
+

- <tr valign="top">
- <td>
- UK 
- 277
+<tr valign="top">
+<td>UK271

- <td>
- 24.4.1.2.1
+<td>24.3

- <td>
- 1
+<td>6,7

- <td>
- Te
+<td>Te

- <td>
- The default
- constructor default-initializes current, rather than
- value-initializes. This means that when Iterator
- corresponds to a trivial type, the current member is left
- un-initialized, even when the user explictly requests value
- intialization! At this point, it is not safe to perform any
- operations on the reverse_iterator other than assign it a
- new value or destroy it. Note that this does correspond to
- the basic definition of a singular iterator.
+<td>next/prev return
+an incremented iterator without changing the value of the
+original iterator. However, even this may invalidate an
+InputIterator. A ForwardIterator is required to guarantee
+the 'multipass' property.

- 
+<td>Replace InputIterator constraint with
+FOrwardIterator in next and prev function templates.

- <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
- select value initialization and copy the iterator value. or
- iii/ Add a note to the description emphasizing the singular
- nature of a value-initialized reserve iterator.
+<td>Alisdair will open an issue. 

- <td>
- agree with option i, Alisdair will open an issue. 
+

- <tr valign="top">
- <td>
- UK 
- 278
+<tr valign="top">
+<td>UK272

- <td>
- 24.4.1.2.1
+<td>24.4

- <td>
- 3
+<td>

- <td>
- Te
+<td>Te

- <td>
- There is an
- inconsistency between the constructor taking an iterator
- and the constructor template taking a reverse_iterator
- where one passes by value, and the other by const
- reference. The by-value form is preferred as it allows for
- efficient moving when copy elision fails to kick in.
+<td>reverse_iterator
+and move_iterator use different formulations for their
+comparison operations. move_iterator merely requires the
+minimal set of operations, < and ==, from its underlying
+iterator and synthesizes all oprations from these two.
+reverse_iterator relies on the undelying iterator to
+support all comparision operations directly. In practice,
+move_iterator can only be implemented this way as it must
+support iterator types that are merely InputIterators, and
+so SemiRegular and not Regular. However, reserse_iterator
+has an existing specification and any change of semantic
+could change behaviour of conforming programs today -
+although an iterator that yields different results for (a
+> b) than (b < a) may fall foul of some semantic
+consistency requirements, even if the syntax is met.
+
+<td>Rephrase the reverse_iterator comparison
+operations using only operators < and ==, as per the
+move_iterator specification.

- 
+<td>NAD, no consensus. 

- <td>
- Change the const reverse_iterator
- & parameter to pass-by-value
+

- <td>
- NAD, we don’t believe that copy elision is a
- sufficiently high priority for iterator types. 
+<tr valign="top">
+<td>UK274

- <tr valign="top">
- <td>
- UK 
- 279
+<td>24.4, 24.5

- <td>
- 24.4.1. 
- 2.12, 
- 24.4.3. 
- 2.12
+<td>

- <td>
- 
+<td>Ed

- <td>
- Te
+<td>The subclauses
+for standard iterator adaptors could be better organised.
+There are essentially 3 kinds of iterator wrappers
+provided, stream iterators adapt streams and get their own
+subsection. insert iterators adapt containers, and get
+their own subsection but it is inserted into the middle of
+24.4 Predifined iterators. reverse_iterator and
+move_iterator adpat other iterators, but their presentation
+is split by insert iterators
+
+<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>
- The reason the
- return type became unspecified is LWG issue 386. This
- reasoning no longer applies as there are at least two ways
- to get the right return type with the new language
- facilities added since the previous standard.
+<td>[Being reviewed by Editor] 

- 
+

- <td>
- Specify the return type using either
- decltype or the Iter concept map
+<tr valign="top">
+<td>UK275

- <td>
- under discussion. This is a general question about all
- iterator adapters. 
+<td>24.4.1.1

- <tr valign="top">
- <td>
- UK 
- 280
+<td>

- <td>
- 24.4.1. 
- 2.4
+<td>Te

- <td>
- 
+<td>The constructor
+template taking a single Iterator argument will be selected
+for Copy Initialization instead of the non-template
+constructor taking a single Iterator argument selected by
+Direct Initialization.

- <td>
- Ed
+<td>The reverse_iterator template constructor
+taking a single Iterator argument should be explicit.

- <td>
- The presence of
- the second iterator value is surprising for many readers
- who underestimate the size of a reverse_iterator object.
- Adding the exposition only member that is required by the
- semantic will reduce confusion.
+<td>NAD, withdrawn by submitter. 

- 
+

- <td>
- Add reverse_iterator expsoition only member
- tmp as a comment to class declaration, as a private member
+<tr valign="top">
+<td>UK276

- <td>
- [Being reviewed by Editor] 
+<td>24.4.1.1

- <tr valign="top">
- <td>
- UK 
- 281
+<td>

- <td>
- 24.4.1. 
- 2.5
+<td>Ed

- <td>
- 
+<td>It is odd to
+have a mix of declaration stlyes for operator+ overloads.
+Prefer if either all are member functions, or all are
+'free' functions.

- <td>
- Te
+<td>Make the member operators taking a
+difference_type argument non-member operators

- <td>
- The current
- specification for return value will always be a true
- pointer type, but reverse_iterator supports proxy iterators
- where the pointer type may be some kind of 'smart pointer'
+<td>NAD, not editorial, withdrawn by submitter. 

- 
+

- <td>
- Replace the existing returns specification
- with a copy of the operator* specification that returns
- this->tmp.operator->
+<tr valign="top">
+<td>UK277

- <td>
- study group formed to come up with a suggested
- resolution. 
+<td>24.4.1.2.1

- <tr valign="top">
- <td>
- UK 
- 282
+<td>1

- <td>
- 24.4.2.1, 
- 24.4.2.2.2, 
- 24.4.2.3, 
- 24.4.2.4.2, 
- 24.4.2.5, 
- 24.4.2.6.2
+<td>Te

- <td>
- n/a
+<td>The default
+constructor default-initializes current, rather than
+value-initializes. This means that when Iterator
+corresponds to a trivial type, the current member is left
+un-initialized, even when the user explictly requests value
+intialization! At this point, it is not safe to perform any
+operations on the reverse_iterator other than assign it a
+new value or destroy it. Note that this does correspond to
+the basic definition of a singular iterator.
+
+<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
+select value initialization and copy the iterator value. or
+iii/ Add a note to the description emphasizing the singular
+nature of a value-initialized reserve iterator.

- <td>
- Te
+<td>agree with option i, Alisdair will open an issue. 

- <td>
- Insert iterators of move-only types will
- move from lvalues
+

- <td>
- Add an additional constrained overload for
- operator= that requires
- !CopyConstructible<Cont::value_type> and mark it
- =delete.
+<tr valign="top">
+<td>UK278

- <td>
- deferred to discussion of N2831. 
+<td>24.4.1.2.1

- <tr valign="top">
- <td>
- UK 
- 283
+<td>3

- <td>
- 24.4.2.5, 
- 24.4.2.6.4
+<td>Te

- <td>
- 
+<td>There is an
+inconsistency between the constructor taking an iterator
+and the constructor template taking a reverse_iterator
+where one passes by value, and the other by const
+reference. The by-value form is preferred as it allows for
+efficient moving when copy elision fails to kick in.

- <td>
- Te
+<td>Change the const reverse_iterator
+& parameter to pass-by-value

- <td>
- postincrement operator overloads
- traditionally return by value - insert_iterator is declared
- as return by reference. The change is harmless in this
- case, but either front/back_insert_iterator should take the
- matching change for consistency, or this function should
- return-by-value
+<td>NAD, we don’t believe that copy elision is a
+sufficiently high priority for iterator types. 

- <td>
- change operator++(int) overload to return
- by value, not reference. Affects both class summary and
- operator definition in p
+

- <td>
- NAD. This is compatible with C++03; and we lack a
- consensus for change. 
+<tr valign="top">
+<td>UK279

- <tr valign="top">
- <td>
- JP 61
+<td>24.4.1. 
+2.12, 
+24.4.3. 
+2.12

- <td>
- 24.4.3.2.1
+<td>

- <td>
- 2nd para, 1st
- line
+<td>Te

- <td>
- ed
+<td>The reason the
+return type became unspecified is LWG issue 386. This
+reasoning no longer applies as there are at least two ways
+to get the right return type with the new language
+facilities added since the previous standard.

- <td>
- 
- Typo.
+<td>Specify the return type using either
+decltype or the Iter concept map

- 
- "intializing" should be "initializing"
+<td>under discussion. This is a general question about all
+iterator adapters. 

- <td>
- Add
- "i"
+

- <td>
- [Being reviewed by Editor] 
+<tr valign="top">
+<td>UK280

- <tr valign="top">
- <td>
- UK 
- 284
+<td>24.4.1. 
+2.4

- <td>
- 24.5
+<td>

- <td>
- 
+<td>Ed

- <td>
- Te
+<td>The presence of
+the second iterator value is surprising for many readers
+who underestimate the size of a reverse_iterator object.
+Adding the exposition only member that is required by the
+semantic will reduce confusion.

- <td>
- The stream
- iterators need constraining with concepts/requrires
- clauses.
+<td>Add reverse_iterator expsoition only member
+tmp as a comment to class declaration, as a private member

- 
+<td>[Being reviewed by Editor] 

- <td>
- Provide constraints
+

- <td>
- We agree. To be handled by Howard, Martin and PJ. 
+<tr valign="top">
+<td>UK281

- <tr valign="top">
- <td>
- UK 
- 285
+<td>24.4.1. 
+2.5

- <td>
- 24.5.1
+<td>

- <td>
- 1,2
+<td>Te

- <td>
- Ed
+<td>The current
+specification for return value will always be a true
+pointer type, but reverse_iterator supports proxy iterators
+where the pointer type may be some kind of 'smart pointer'

- <td>
- Much of the
- content of p1 and the whole of p2 is a redundant
- redefinition of InputIterator. It should be simplified
+<td>Replace the existing returns specification
+with a copy of the operator* specification that returns
+this->tmp.operator->

- 
+<td>study group formed to come up with a suggested
+resolution. 

- <td>
- Strike p2. Simplify p1 and add a
- cross-reference to the definition of InputIterator concept.
+

- <td>
- [Being reviewed by Editor] 
+<tr valign="top">
+<td>UK282

- <tr valign="top">
- <td>
- UK 
- 286
+<td>24.4.2.1, 
+24.4.2.2.2, 
+24.4.2.3, 
+24.4.2.4.2, 
+24.4.2.5, 
+24.4.2.6.2

- <td>
- 24.5.1
+<td>n/a

- <td>
- 3
+<td>Te

- <td>
- Ed
+<td>Insert iterators of move-only types will
+move from lvalues

- <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
- constructor but relying on the implicit copy-assign
- operator is confusing.
+<td>Add an additional constrained overload for
+operator= that requires
+!CopyConstructible<Cont::value_type> and mark it
+=delete.

- 
+<td>deferred to discussion of N2831. 

- <td>
- Either provide a similar definition to the
- copy-assign operator as for the copy constructor, or strike
- the copy constructor
+

- <td>
- [Being reviewed by Editor] 
+<tr valign="top">
+<td>UK283

- <tr valign="top">
- <td>
- UK 
- 287
+<td>24.4.2.5, 
+24.4.2.6.4

- <td>
- 24.5.1.1
+<td>

- <td>
- 2
+<td>Te

- <td>
- Te
+<td>postincrement operator overloads
+traditionally return by value - insert_iterator is declared
+as return by reference. The change is harmless in this
+case, but either front/back_insert_iterator should take the
+matching change for consistency, or this function should
+return-by-value

- <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
- initialized? If it is initialized by reading the stream,
- what happens if the initialization is deferred until first
- dereference, when ideally the iterator value should have
- been that of an end-of-stream iterator which is not safely
- dereferencable?
+<td>change operator++(int) overload to return
+by value, not reference. Affects both class summary and
+operator definition in p

- 
+<td>NAD. This is compatible with C++03; and we lack a
+consensus for change. 

- <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>
- Martin will address with existing LWG
- issue 788. 
+<tr valign="top">
+<td>JP61

- <tr valign="top">
- <td>
- UK 
- 288
+<td>24.4.3.2.1

- <td>
- 24.5.1.1
+<td>2nd para, 1st
+line

- <td>
- 3
+<td>ed

- <td>
- Ed
+<td>
+Typo.

- <td>
- The provided specification is vacuous,
- offering no useful information.
+
+"intializing" should be "initializing"

- <td>
- Either strike
- the specification of the copy constructor, or simply
- replace it with an = default definition.
+<td>Add
+"i"

- 
+<td>[Being reviewed by Editor] 

- <td>
- [Being reviewed by Editor] 
+

- <tr valign="top">
- <td>
- UK 
- 289
+<tr valign="top">
+<td>UK284

- <td>
- 24.5.1.2
+<td>24.5

- <td>
- 6
+<td>

- <td>
- Ed
+<td>Te

- <td>
- It is very hard
- to pick up the correct specification for
- istream_iterator::operator== as the complete specification
- requires reading two quite disconnected paragraphs,
- 24.5.1p3, and 24.5.1.2p6. Reading just the specifaction of
- the operation itself suggests that end-of-stream iterators
- are indistinguishable from 'valid' stream iterators, which
- is a very dangerous misreading.
+<td>The stream
+iterators need constraining with concepts/requrires
+clauses.

- 
+<td>Provide constraints

- <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>We agree. To be handled by Howard, Martin and PJ. 

- <td>
- [Being reviewed by Editor] 
+

- <tr valign="top">
- <td>
- UK 
- 290
+<tr valign="top">
+<td>UK285

- <td>
- 24.5.2
+<td>24.5.1

- <td>
- 1
+<td>1,2

- <td>
- Te
+<td>Ed

- <td>
- The character
- type of a string delimiter for an ostream_iterator should
- be const charT *, the type of the elements, not char *, a
- narrow character string.
+<td>Much of the
+content of p1 and the whole of p2 is a redundant
+redefinition of InputIterator. It should be simplified

- 
+<td>Strike p2. Simplify p1 and add a
+cross-reference to the definition of InputIterator concept.

- <td>
- Replace char * with const charT *
+<td>[Being reviewed by Editor] 

- <td>
- We agree and believe it to be editorial. 
+

- <tr valign="top">
- <td>
- UK 
- 291
+<tr valign="top">
+<td>UK286

- <td>
- 24.5.2.2
+<td>24.5.1

- <td>
- 2
+<td>3

- <td>
- Te
+<td>Ed

- <td>
- ostream_iterator
- postincrement operator returns by reference rather than by
- value. This may be a small efficiency gain, but it is
- otherwise unconventional. Prefer return-by-value.
+<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
+constructor but relying on the implicit copy-assign
+operator is confusing.

- 
+<td>Either provide a similar definition to the
+copy-assign operator as for the copy constructor, or strike
+the copy constructor

- <td>
- ostream_iterator operator++(int);
+<td>[Being reviewed by Editor] 

- <td>
- NAD. This is compatible with C++03; and we lack a
- consensus for change. 
+

- <tr valign="top">
- <td>
- FR 34
+<tr valign="top">
+<td>UK287

- <td>
- 24.5.3 
- [istream- 
- buf. 
- iterator]
+<td>24.5.1.1

- <td>
- 
+<td>2

- <td>
- ed
+<td>Te

- <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>It is not clear
+what the intial state of an istream_iterator should be. Is
+_value_ initialized by reading the stream, or default/value
+initialized? If it is initialized by reading the stream,
+what happens if the initialization is deferred until first
+dereference, when ideally the iterator value should have
+been that of an end-of-stream iterator which is not safely
+dereferencable?
+
+<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>Martin will address with existing LWG
+issue 788. 

- <td>
- 
+

- <td>
- [Being reviewed by Editor] 
+<tr valign="top">
+<td>UK288

- <tr valign="top">
- <td>
- UK 
- 292
+<td>24.5.1.1

- <td>
- 24.5.3
+<td>3

- <td>
- 1
+<td>Ed

- <td>
- Ed
+<td>The provided specification is vacuous,
+offering no useful information.

- <td>
- Prefer the use
- of the new nullptr constant to the zero literal when using
- a null pointer in text.
+<td>Either strike
+the specification of the copy constructor, or simply
+replace it with an = default definition.

- 
+<td>[Being reviewed by Editor] 

- <td>
- Change istreambuf_iterator(0) to
- istreambuf_iterator(nullptr)
+
+
+<tr valign="top">
+<td>UK289
+
+<td>24.5.1.2
+
+<td>6
+
+<td>Ed
+
+<td>It is very hard
+to pick up the correct specification for
+istream_iterator::operator== as the complete specification
+requires reading two quite disconnected paragraphs,
+24.5.1p3, and 24.5.1.2p6. Reading just the specifaction of
+the operation itself suggests that end-of-stream iterators
+are indistinguishable from 'valid' stream iterators, which
+is a very dangerous misreading.

- <td>
- [Being reviewed by Editor] 
+<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.

- <tr valign="top">
- <td>
- UK 
- 293
+<td>[Being reviewed by Editor] 

- <td>
- 24.5.3
+

- <td>
- 2,3,4
+<tr valign="top">
+<td>UK290

- <td>
- Ed
+<td>24.5.2

- <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>1

- <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
- stream iterators are always equal. An end of stream
- iterator is not equal to a non-end of stream iterator. 4.
- As istreambuf_iterator() is an InputIterator but not a
- ForwardIterator, istreambuf_iterators object can be used
- only for one-pass algorithms. It is not possible to assign
- a character via an input iterator.
+<td>Te

- 
+<td>The character
+type of a string delimiter for an ostream_iterator should
+be const charT *, the type of the elements, not char *, a
+narrow character string.

- <td>
- [Being reviewed by Editor] 
+<td>Replace char * with const charT *

- <tr valign="top">
- <td>
- UK 
- 294
+<td>We agree and believe it to be editorial. 

- <td>
- 24.5.3.2
+

- <td>
- 2
+<tr valign="top">
+<td>UK291

- <td>
- Te
+<td>24.5.2.2

- <td>
- Implicit converting constructors can be
- invoked at surprising times, so there should always be a
- good reason for declaring one.
+<td>2

- <td>
- Mark the two
- single-argument constructors take a stream or stream buffer
- as explicit. The proxy constructor should remain implicit.
- explicit
- istreambuf_iterator(basic_istream<charT,traits>&
- s) throw(); explicit
- istreambuf_iterator(basic_streambuf<charT,traits>* s)
- throw();
+<td>Te

- 
+<td>ostream_iterator
+postincrement operator returns by reference rather than by
+value. This may be a small efficiency gain, but it is
+otherwise unconventional. Prefer return-by-value.

- <td>
- NAD. This could potentially [break] C++03-conforming
- programs. 
+<td>ostream_iterator operator++(int);

- <tr valign="top">
- <td>
- UK 
- 295
+<td>NAD. This is compatible with C++03; and we lack a
+consensus for change. 

- <td>
- 25
+

- <td>
- 
+<tr valign="top">
+<td>FR34

- <td>
- Te
+<td>24.5.3 
+[istream- 
+buf. 
+iterator]

- <td>
- THere is a level
- of redundancy in the library specification for many
- algorithms that can be eliminated with the combination of
- concepts and default parameters for function templates.
- Eliminating redundancy simplified specification and reduces
- the risk of inttroducing accidental inconsistencies.
+<td>

- 
+<td>ed

- <td>
- Adopt n2743, or an update of that paper.
+<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>
- NAD, this change would break code that takes the address
- of an algorithm. 
+

- <tr valign="top">
- <td>
- JP 62
+<td>

- <td>
- 25, 25.3.1.5, 
- 26.3.6.5
+<td>[Being reviewed by Editor] 

- <td>
- 
+

- <td>
- te
+<tr valign="top">
+<td>UK292

- <td>
- 
- The return types of is_sorted_until function and
- is_heap_until function are iterator. But basically, the
- return type of is_xxx function is bool. And the return type
- of lower_bound function and upper_bound is iterator.
+<td>24.5.3

- 
- So we think that it is reasonable to change those two
- functions.
+<td>1

- 
+<td>Ed

- <td>
- 
- Change "is_sorted_until" to "sorted_bound"
+<td>Prefer the use
+of the new nullptr constant to the zero literal when using
+a null pointer in text.

- 
- Change "is_heap" to "heap_bound"
+<td>Change istreambuf_iterator(0) to
+istreambuf_iterator(nullptr)

- <td>
- no consensus to make the change. 
+<td>[Being reviewed by Editor] 

- <tr valign="top">
- <td>
- UK 
- 296
+

- <td>
- 25.1.8
+<tr valign="top">
+<td>UK293

- <td>
- 1
+<td>24.5.3

- <td>
- Te
+<td>2,3,4

- <td>
- The 'Returns' of
- adjacent_find requires only HasEqualTo, or a Predicate.
- Requiring EqualityComparable or EquivalenceRelation seems
- too strong and not useful.
+<td>Ed

- 
+<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>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
+stream iterators are always equal. An end of stream
+iterator is not equal to a non-end of stream iterator. 4.
+As istreambuf_iterator() is an InputIterator but not a
+ForwardIterator, istreambuf_iterators object can be used
+only for one-pass algorithms. It is not possible to assign
+a character via an input iterator.

- <td>
- Change EqualityComparable to HasEqualTo and
- EquivalnceRelation to Predicate
+<td>[Being reviewed by Editor] 

- <td>
- no consensus to make the change. 
+

- <tr valign="top">
- <td>
- UK 
- 297
+<tr valign="top">
+<td>UK294

- <td>
- 25.2.11
+<td>24.5.3.2

- <td>
- 6
+<td>2

- <td>
- Ed
+<td>Te

- <td>
- The definition
- of rotate_copy is very complicated. It is equivalent to:
- return copy(first, middle, copy(middle, last, result));
+<td>Implicit converting constructors can be
+invoked at surprising times, so there should always be a
+good reason for declaring one.
+
+<td>Mark the two
+single-argument constructors take a stream or stream buffer
+as explicit. The proxy constructor should remain implicit.
+explicit
+istreambuf_iterator(basic_istream<charT,traits>&
+s) throw(); explicit
+istreambuf_iterator(basic_streambuf<charT,traits>* s)
+throw();

- 
+<td>NAD. This could potentially [break] C++03-conforming
+programs. 

- <td>
- Change 'effects' to, returns, requires,
- complexity to: effects: equivalent to: return copy(first,
- middle, copy(middle, last, result));
+

- <td>
- Editor requests guidance: we agree that it is editorial. 
+<tr valign="top">
+<td>UK295

- <tr valign="top">
- <td>
- UK 
- 298
+<td>25

- <td>
- 25.2.13
+<td>

- <td>
- 13
+<td>Te

- <td>
- Te
+<td>THere is a level
+of redundancy in the library specification for many
+algorithms that can be eliminated with the combination of
+concepts and default parameters for function templates.
+Eliminating redundancy simplified specification and reduces
+the risk of inttroducing accidental inconsistencies.

- <td>
- partition_point requires a partitioned
- array
+<td>Adopt n2743, or an update of that paper.

- <td>
- requires: is_partitioned(first, last, pred)
- != false;
+<td>NAD, this change would break code that takes the address
+of an algorithm. 

- <td>
- We agree with the suggested change and believe that it
- is editorial. 
+

- <tr valign="top">
- <td>
- UK 
- 299
+<tr valign="top">
+<td>JP62

- <td>
- 25.2.2
+<td>25, 25.3.1.5, 
+26.3.6.5

- <td>
- 
+<td>

- <td>
- Ed
+<td>te

- <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>
+The return types of is_sorted_until function and
+is_heap_until function are iterator. But basically, the
+return type of is_xxx function is bool. And the return type
+of lower_bound function and upper_bound is iterator.

- <td>
- Change way signature is declared:
- template<InputIterator InIter, OutputIterator<auto,
- RvalueOf<InIter::reference>::type> OutIter>
- OutIter move(InIter first, InIter last, OutIter result);
+
+So we think that it is reasonable to change those two
+functions.

- <td>
- [Being reviewed by Editor] 
+ 

- <tr valign="top">
- <td>
- UK 
- 300
+<td>
+Change "is_sorted_until" to "sorted_bound"

- <td>
- 25.2.3
+
+Change "is_heap" to "heap_bound"

- <td>
- 
+<td>no consensus to make the change. 

- <td>
- Te
+

- <td>
- Since publishing
- the original standard, we have learned that swap is a
- fundamental operation, and several common idioms rely on it
- - especially those related to exception safety. As such it
- belongs in the common <utility> header rather than
- the broader <algorithm> header, and likewise should
- move to clause 20. For backwards compatiblility the
- algorithm header should be required to #include
- <utility>, which would be covered in the resolution
- of LWG issue 343. There are already dependencies in
- <algorithm> on types declared in this header, so this
- comment does not create a new dependency.
+<tr valign="top">
+<td>UK296

- 
+<td>25.1.8

- <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>1

- <td>
- no consensus to make the change. 
+<td>Te

- <tr valign="top">
- <td>
- UK 
- 301
+<td>The 'Returns' of
+adjacent_find requires only HasEqualTo, or a Predicate.
+Requiring EqualityComparable or EquivalenceRelation seems
+too strong and not useful.

- <td>
- 25.2.5
+<td>Change EqualityComparable to HasEqualTo and
+EquivalnceRelation to Predicate

- <td>
- 
+<td>no consensus to make the change. 

- <td>
- Te
+

- <td>
- replace and
- replace_if have the requirement: OutputIterator<Iter,
- Iter::reference> Which implies they need to copy some
- values in the range the algorithm is iterating over. This
- is not however the case, the only thing that happens is
- const T&s might be copied over existing elements (hence
- the OutputIterator<Iter, const T&>
+<tr valign="top">
+<td>UK297

- 
+<td>25.2.11

- <td>
- Remove OutputIterator<Iter,
- Iter::reference> from replace and replace_if
+<td>6

- <td>
- agreed. Howard will open an issue. 
+<td>Ed

- <tr valign="top">
- <td>
- UK 
- 302
+<td>The definition
+of rotate_copy is very complicated. It is equivalent to:
+return copy(first, middle, copy(middle, last, result));

- <td>
- 25.3
+<td>Change 'effects' to, returns, requires,
+complexity to: effects: equivalent to: return copy(first,
+middle, copy(middle, last, result));

- <td>
- 4
+<td>Editor requests guidance: we agree that it is editorial. 

- <td>
- Ed
+

- <td>
- the concept
- StrictWeakOrder covers the definition of a strict weak
- ordering, described in paragraph 4.
+<tr valign="top">
+<td>UK298

- 
+<td>25.2.13

- <td>
- Remove 4, and mention StrictWeakOrder in
- paragraph 1.
+<td>13

- <td>
- [Being reviewed by Editor] 
+<td>Te

- <tr valign="top">
- <td>
- UK 
- 303
+<td>partition_point requires a partitioned
+array

- <td>
- 25.3
+<td>requires: is_partitioned(first, last, pred)
+!= false;

- <td>
- 6
+<td>We agree with the suggested change and believe that it
+is editorial. 

- <td>
- Ed
+

- <td>
- This paragraph just describes
- is_partitioned
+<tr valign="top">
+<td>UK299

- <td>
- 6 A sequence
- [start,finish) is partitioned with respect to an expression
- f(e) if is_partitioned(start, finish, e) != false
+<td>25.2.2

- 
+<td>

- <td>
- [Being reviewed by Editor] 
+<td>Ed

- <tr valign="top">
- <td>
- UK 
- 304
+<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>
- 25.3.6
+<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>
- 
+<td>[Being reviewed by Editor] 

- <td>
- Ed
+

- <td>
- The requires
- clauses of push_heap, pop_heap and make_heap are
- inconsistently formatted, dispite being identical
+<tr valign="top">
+<td>UK300

- 
+<td>25.2.3

- <td>
- Format them identically.
+<td>

- <td>
- [Being reviewed by Editor] 
+<td>Te

- <tr valign="top">
- <td>
- UK 
- 305
+<td>Since publishing
+the original standard, we have learned that swap is a
+fundamental operation, and several common idioms rely on it
+- especially those related to exception safety. As such it
+belongs in the common <utility> header rather than
+the broader <algorithm> header, and likewise should
+move to clause 20. For backwards compatiblility the
+algorithm header should be required to #include
+<utility>, which would be covered in the resolution
+of LWG issue 343. There are already dependencies in
+<algorithm> on types declared in this header, so this
+comment does not create a new dependency.
+
+<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>
- 25.3.7
+<td>no consensus to make the change. 

- <td>
- 1, 9, 17
+

- <td>
- Te
+<tr valign="top">
+<td>UK301

- <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>25.2.5

- <td>
- Strike the !IsSameType<T, Compare>
- constraint on min/max/minmax algorithms
+<td>

- <td>
- agreed. We request that someone from the UK open an
- issue. 
+<td>Te

- <tr valign="top">
- <td>
- US 84
+<td>replace and
+replace_if have the requirement: OutputIterator<Iter,
+Iter::reference> Which implies they need to copy some
+values in the range the algorithm is iterating over. This
+is not however the case, the only thing that happens is
+const T&s might be copied over existing elements (hence
+the OutputIterator<Iter, const T&>

- <td>
- 26
+<td>Remove OutputIterator<Iter,
+Iter::reference> from replace and replace_if

- <td>
- 
+<td>agreed. Howard will open an issue. 

- <td>
- ge
+

- <td>
- 
- Parts of the numerics chapter are not concept enabled.
+<tr valign="top">
+<td>UK302

- 
+<td>25.3

- <td>
- 
+<td>4

- <td>
- The portions of this comment dealing
- with random numbers are resolved by
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
- N2836</a>, which was accepted in New Jersey. 
+<td>Ed

- <tr valign="top">
- <td>
- FR 35
+<td>the concept
+StrictWeakOrder covers the definition of a strict weak
+ordering, described in paragraph 4.

- <td>
- 26.3 
- [Complex 
- numbers]
+<td>Remove 4, and mention StrictWeakOrder in
+paragraph 1.

- <td>
- 
+<td>[Being reviewed by Editor] 

- <td>
- te
+

- <td>
- Instantiations of the class
- template complex<> have to be allowed for integral
- types, to reflect existing practice and ISO standards
- (LIA-III).
+<tr valign="top">
+<td>UK303

- 
+<td>25.3

- <td>
- 
+<td>6

- <td>
- 
+<td>Ed

- <tr valign="top">
- <td>
- UK 
- 306
+<td>This paragraph just describes
+is_partitioned

- <td>
- 26.4
+<td>6 A sequence
+[start,finish) is partitioned with respect to an expression
+f(e) if is_partitioned(start, finish, e) != false

- <td>
- 
+<td>[Being reviewed by Editor] 

- <td>
- Te
+

- <td>
- Random number
- library component cannot be used in constrained templates
+<tr valign="top">
+<td>UK304

- 
+<td>25.3.6

- <td>
- Provide constraints for the random number
- library
+<td>

- <td>
- Resolved by
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
- N2836</a>, which was accepted in New Jersey. 
+<td>Ed

- <tr valign="top">
- <td>
- JP 63
+<td>The requires
+clauses of push_heap, pop_heap and make_heap are
+inconsistently formatted, dispite being identical

- <td>
- 26.4.8.5.1
+<td>Format them identically.

- <td>
- 
+<td>[Being reviewed by Editor] 
+
+
+
+<tr valign="top">
+<td>UK305
+
+<td>25.3.7
+
+<td>1, 9, 17
+
+<td>Te
+
+<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>Strike the !IsSameType<T, Compare>
+constraint on min/max/minmax algorithms
+
+<td>agreed. We request that someone from the UK open an
+issue. 
+
+
+
+<tr valign="top">
+<td>US84
+
+<td>26
+
+<td>
+
+<td>ge
+
+<td>
+Parts of the numerics chapter are not concept enabled.
+
+<td>
+
+<td>The portions of this comment dealing
+with random numbers are resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
+N2836</a>, which was accepted in New Jersey. 
+
+
+
+<tr valign="top">
+<td>FR35
+
+<td>26.3 
+[Complex 
+ numbers]

- <td>
- te
+<td>

- <td>
- No
- constructor of discrete_distribution that accepts
- initializer_list.
+<td>te

- 
- discrete_distribution initialize distribution by a given
- range (iterators), but temporary variable of a container or
- an array is needed in the following case.
+<td>Instantiations of the class
+template complex<> have to be allowed for integral
+types, to reflect existing practice and ISO standards
+(LIA-III).

- 
- 
+

- int
- ar[] = {1, 2, 3};
+<td>

- 
- discrete_distribution<> dist(ar, ar+3);
+<td>

- 
- 
+<tr valign="top">
+<td>UK306

- Other libraries
- also accept initializer_list, so change
- discrete_distribution library to accept initializer_list
- too.
+<td>26.4

- 
- 
+<td>

- <td>
- Add
- the following constructer.
+<td>Te

- 
- discrete_distribution(initializer_list<result_type>);
+<td>Random number
+library component cannot be used in constrained templates

- <td>
- Resolved by
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
- N2836</a>, which was accepted in New Jersey.
- This comment is also covered by
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">
- issue 874</a>. [Suggested by 
- Daniel Krügler
- and confirmed by the submitter.] 
+<td>Provide constraints for the random number
+library

- <tr valign="top">
- <td>
- JP 64
+<td>Resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
+N2836</a>, which was accepted in New Jersey. 

- <td>
- 26.5.2
+

- <td>
- 
+<tr valign="top">
+<td>JP63

- <td>
- te
+<td>26.4.8.5.1

- <td>
- 
- “valarray<T>& operator+=
- (initializer_list<T>);” is not defined.
+<td>

- 
- 
+<td>te

- <td>
- Add
- valarray<T>& operator+=
- (initializer_list<T>);
+<td>No
+constructor of discrete_distribution that accepts
+initializer_list.

- <td>
- 
+
+discrete_distribution initialize distribution by a given
+range (iterators), but temporary variable of a container or
+an array is needed in the following case.

- <tr valign="top">
- <td>
- UK 
- 307
+
+ 

- <td>
- 26.7
+int
+ar[] = {1, 2, 3};

- <td>
- Footnote 288
+
+discrete_distribution<> dist(ar, ar+3);

- <td>
- Ed
+
+ 

- <td>
- The footnote
- refers to TR1, which is not a defined term in this
- standard. Drop the reference to TR1, those templates are a
- regular part of the standard now and how they were
- introduced is no longer relevant.
+Other libraries
+also accept initializer_list, so change
+discrete_distribution library to accept initializer_list
+too.

- 
+
+ 

- <td>
- Drop the reference to TR1.
+<td>Add
+the following constructer.

- <td>
- [Being reviewed by Editor] 
+
+discrete_distribution(initializer_list<result_type>);

- <tr valign="top">
- <td>
- US 85
+<td>Resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
+N2836</a>, which was accepted in New Jersey.
+This comment is also covered by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">
+issue 874</a>. [Suggested by 
+Daniel Krügler
+and confirmed by the submitter.] 

- <td>
- 27
+

- <td>
- 
+<tr valign="top">
+<td>JP64

- <td>
- ge
+<td>26.5.2

- <td>
- The
- input/output chapter is not concept enabled.
+<td>

- 
+<td>te

- <td>
- 
+<td>
+“valarray<T>& operator+=
+(initializer_list<T>);” is not defined.

- <td>
- 
+
+ 

- <tr valign="top">
- <td>
- UK 
- 308
+<td>Add
+valarray<T>& operator+=
+(initializer_list<T>);

- <td>
- 27
+<td>

- <td>
- 
+<tr valign="top">
+<td>UK307

- <td>
- Te
+<td>26.7

- <td>
- 
- iostreams library cannot be used from
- constrained templates
+<td>Footnote 288

- 
+<td>Ed

- <td>
- Provide constraints for the iostreams
- library, clause 27
+<td>The footnote
+refers to TR1, which is not a defined term in this
+standard. Drop the reference to TR1, those templates are a
+regular part of the standard now and how they were
+introduced is no longer relevant.

- <td>
- 
+<td>Drop the reference to TR1.

- <tr valign="top">
- <td>
- JP 65
+<td>[Being reviewed by Editor] 

- <td>
- 27.4.4
+

- <td>
- 
+<tr valign="top">
+<td>US85

- <td>
- te
+<td>27

- <td>
- Switch from
- “unspecified-bool-type” to　“explicit operator bool()
- const”.
+<td>

- 
- 
+<td>ge

- <td>
- 
- Replace "operator unspecified-bool-type() const;"
- with "explicit operator bool() const;"
+<td>The
+input/output chapter is not concept enabled.

- <td>
- 
+<td>

- <tr valign="top">
- <td>
- JP 66
+<td>

- <td>
- 27.4.4.3
+<tr valign="top">
+<td>UK308

- <td>
- 1st para
+<td>27

- <td>
- te
+<td>

- <td>
- Switch from
- “unspecified-bool-type” to　“explicit operator bool()
- const”
+<td>Te

- 
- 
+<td>
+iostreams library cannot be used from
+constrained templates

- <td>
- 
- Replace "operator unspecified-bool-type() const;"
- with "explicit operator bool() const;"
+<td>Provide constraints for the iostreams
+library, clause 27

- <td>
- 
+<td>

- <tr valign="top">
- <td>
- FR 36
+<tr valign="top">
+<td>JP65

- <td>
- 27.6.1.2.2 
- [istream. 
- formatted. 
- arithmetic]
+<td>27.4.4

- <td>
- 1, 2, and 3
+<td>

- <td>
- ed
+<td>te

- <td>
- iostate err = 0;
+<td>Switch from
+“unspecified-bool-type” to　“explicit operator bool()
+const”.

- 
+
+ 

- iostate is a bitmask type and
- so could be an enumeration. Probably using
+<td>
+Replace "operator unspecified-bool-type() const;"
+with "explicit operator bool() const;"

- goodbit is the solution.
+<td>

- 
+<tr valign="top">
+<td>JP66

- <td>
- 
+<td>27.4.4.3

- <td>
- [Being reviewed by Editor] 
+<td>1st para

- <tr valign="top">
- <td>
- FR 37
+<td>te

- <td>
- 27.6.1.2.2 
- [istream. 
- formatted. 
- arithmetic]
+<td>Switch from
+“unspecified-bool-type” to　“explicit operator bool()
+const”

- <td>
- 3
+
+ 

- <td>
- ed
+<td>
+Replace "operator unspecified-bool-type() const;"
+with "explicit operator bool() const;"

- <td>
- else if (lval <
- numeric_limits<int>::min()
+<td>

- ||
- numeric_limits<int>::max() < lval))
+<tr valign="top">
+<td>FR36

- 
+<td>27.6.1.2.2 
+[istream. 
+formatted. 
+arithmetic]

- The parentheses aren't
- balanced.
+<td>1, 2, and 3

- 
+<td>ed

- <td>
- 
+<td>iostate err = 0;

- <td>
- [Being reviewed by Editor] 
+

- <tr valign="top">
- <td>
- JP 67
+iostate is a bitmask type and
+so could be an enumeration. Probably using

- <td>
- 27.7.1
+goodbit is the solution.

- <td>
- 
+

- <td>
- te
+<td>

- <td>
- 
- basic_stringbuf dose not use concept.
+<td>[Being reviewed by Editor] 

- <td>
- 
- Replace “class Allocator” to “Allocator
- Alloc”.
+

- 
-   Correct as follows.
+<tr valign="top">
+<td>FR37

- 
- 
+<td>27.6.1.2.2 
+[istream. 
+formatted. 
+arithmetic]

- 
- namespace std {
+<td>3

- 
- template <class charT, class traits =
- char_traits<charT>,
+<td>ed

- 
- Allocator Alloc = allocator<charT> >
+<td>else if (lval <
+numeric_limits<int>::min()

- 
- class basic_stringbuf : public
- basic_streambuf<charT,traits> {
+||
+numeric_limits<int>::max() < lval))

- 
- public:
+

- ...
+The parentheses aren't
+balanced.

- 
- 
+

- //
- 27.7.1.1 Constructors:
+<td>

- 
- explicit basic_stringbuf(ios_base::openmode which
+<td>[Being reviewed by Editor] 

- =
- ios_base::in | ios_base::out);
+

- 
- explicit basic_stringbuf
+<tr valign="top">
+<td>JP67

- 
- (const basic_string<charT,traits,Alloc>&
- str,
+<td>27.7.1

- 
- ios_base::openmode which = ios_base::in | ios_base::out);
+<td>

- 
- basic_stringbuf(basic_stringbuf&& rhs);
+<td>te

- 
-  
+<td>
+basic_stringbuf dose not use concept.

- ...
+<td>
+Replace “class Allocator” to “Allocator
+Alloc”.

- 
-  
+
+  Correct as follows.

- 
-  
+
+ 

- //
- 27.7.1.3 Get and set:
+
+namespace std {

- 
- basic_string<charT,traits,Alloc> str() const;
+
+template <class charT, class traits =
+char_traits<charT>,

- 
- void str(const
- basic_string<charT,traits,Alloc>& s);
+
+Allocator Alloc = allocator<charT> >

- 
-  
+
+class basic_stringbuf : public
+basic_streambuf<charT,traits> {

- ...
+
+public:

- };
+...

- 
-  
+
+ 

- 
- template <class charT, class traits, Allocator
- Alloc>
+//
+27.7.1.1 Constructors:

- 
- void swap(basic_stringbuf<charT, traits,
- Alloc>& x,
+
+explicit basic_stringbuf(ios_base::openmode which

- 
- basic_stringbuf<charT, traits, Alloc>& y);
+=
+ios_base::in | ios_base::out);

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+explicit basic_stringbuf

- 
- void swap(basic_stringbuf<charT, traits,
- Alloc>&& x,
+
+(const basic_string<charT,traits,Alloc>&
+str,

- 
- basic_stringbuf<charT, traits, Alloc>& y);
+
+ios_base::openmode which = ios_base::in | ios_base::out);

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+basic_stringbuf(basic_stringbuf&& rhs);

- 
- void swap(basic_stringbuf<charT, traits,
- Alloc>& x,
+
+ 

- 
- basic_stringbuf<charT, traits,
- Alloc>&& y);
+...

- }
+
+ 

- 
- 
+
+ 

- <td>
- 
+//
+27.7.1.3 Get and set:

- <tr valign="top">
- <td>
- JP 68
+
+basic_string<charT,traits,Alloc> str() const;

- <td>
- 27.7.2
+
+void str(const
+basic_string<charT,traits,Alloc>& s);

- <td>
- 
+
+ 

- <td>
- te
+...

- <td>
- 
- basic_istringstream dose not use concept.
+};

- <td>
- 
- Replace “class Allocator” to “Allocator
- Alloc”.
+
+ 

- 
-   Correct as follows.
+
+template <class charT, class traits, Allocator
+Alloc>

- 
-  
+
+void swap(basic_stringbuf<charT, traits,
+Alloc>& x,

- 
- namespace std {
+
+basic_stringbuf<charT, traits, Alloc>& y);

- 
- template <class charT, class traits =
- char_traits<charT>,
+
+template <class charT, class traits, Allocator
+Alloc>

- 
- Allocator Alloc = allocator<charT> >
+
+void swap(basic_stringbuf<charT, traits,
+Alloc>&& x,

- 
- class basic_istringstream : public
- basic_istream<charT,traits> {
+
+basic_stringbuf<charT, traits, Alloc>& y);

- 
- public:
+
+template <class charT, class traits, Allocator
+Alloc>

- 
- typedef charT char_type;
+
+void swap(basic_stringbuf<charT, traits,
+Alloc>& x,

- 
- typedef typename traits::int_type int_type;
+
+basic_stringbuf<charT, traits,
+Alloc>&& y);

- 
- typedef typename traits::pos_type pos_type;
+}

- 
- typedef typename traits::off_type off_type;
+
+ 

- 
- typedef traits traits_type;
+<td>

- 
- typedef Alloc allocator_type;
+<tr valign="top">
+<td>JP68

- 
- 
+<td>27.7.2

- //
- 27.7.2.1 Constructors:
+<td>

- 
- explicit basic_istringstream(ios_base::openmode which =
- ios_base::in);
+<td>te

- 
- explicit basic_istringstream(
+<td>
+basic_istringstream dose not use concept.

- 
- const basic_string<charT,traits,Alloc>&
- str,
+<td>
+Replace “class Allocator” to “Allocator
+Alloc”.

- 
- ios_base::openmode which = ios_base::in);
+
+  Correct as follows.

- 
- basic_istringstream(basic_istringstream&& rhs);
+
+ 

- 
-  
+
+namespace std {

- //
- 27.7.2.2 Assign and swap:
+
+template <class charT, class traits =
+char_traits<charT>,

- 
- basic_istringstream&
- operator=(basic_istringstream&& rhs);
+
+Allocator Alloc = allocator<charT> >

- 
- void swap(basic_istringstream&& rhs);
+
+class basic_istringstream : public
+basic_istream<charT,traits> {

- 
-  
+
+public:

- //
- 27.7.2.3 Members:
+
+typedef charT char_type;

- 
- basic_stringbuf<charT,traits,Alloc>* rdbuf()
- const;
+
+typedef typename traits::int_type int_type;

- 
-  
+
+typedef typename traits::pos_type pos_type;

- 
- basic_string<charT,traits,Alloc> str() const;
+
+typedef typename traits::off_type off_type;

- 
- void str(const
- basic_string<charT,traits,Alloc>& s);
+
+typedef traits traits_type;

- 
-  
+
+typedef Alloc allocator_type;

- 
- private:
+
+ 

- //
- basic_stringbuf<charT,traits,Alloc> sb;
- exposition only
+//
+27.7.2.1 Constructors:

- };
+
+explicit basic_istringstream(ios_base::openmode which =
+ios_base::in);

- 
-  
+
+explicit basic_istringstream(

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+const basic_string<charT,traits,Alloc>&
+str,

- 
- void swap(basic_istringstream<charT, traits,
- Alloc>& x,
+
+ios_base::openmode which = ios_base::in);

- 
- basic_istringstream<charT, traits, Alloc>&
- y);
+
+basic_istringstream(basic_istringstream&& rhs);

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- void swap(basic_istringstream<charT, traits,
- Alloc>&& x,
+//
+27.7.2.2 Assign and swap:

- 
- basic_istringstream<charT, traits, Alloc>&
- y);
+
+basic_istringstream&
+operator=(basic_istringstream&& rhs);

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+void swap(basic_istringstream&& rhs);

- 
- void swap(basic_istringstream<charT, traits,
- Alloc>& x,
+
+ 

- 
- basic_istringstream<charT, traits,
- Alloc>&& y);
+//
+27.7.2.3 Members:

- }
+
+basic_stringbuf<charT,traits,Alloc>* rdbuf()
+const;

- 
+
+ 

- <td>
- 
+
+basic_string<charT,traits,Alloc> str() const;

- <tr valign="top">
- <td>
- JP 69
+
+void str(const
+basic_string<charT,traits,Alloc>& s);

- <td>
- 27.7.3
+
+ 

- <td>
- 
+
+private:

- <td>
- te
+//
+basic_stringbuf<charT,traits,Alloc> sb;
+exposition only

- <td>
- 
- basic_ostringstream dose not use concept.
+};

- <td>
- 
- Replace “class Allocator” to “Allocator
- Alloc”.
+
+ 

- 
-   Correct as follows.
+
+template <class charT, class traits, Allocator
+Alloc>

- 
- 
+
+void swap(basic_istringstream<charT, traits,
+Alloc>& x,

- 
- namespace std {
+
+basic_istringstream<charT, traits, Alloc>&
+y);

- 
- template <class charT, class traits =
- char_traits<charT>,
+
+template <class charT, class traits, Allocator
+Alloc>

- 
- Allocator Alloc = allocator<charT> >
+
+void swap(basic_istringstream<charT, traits,
+Alloc>&& x,

- 
- class basic_ostringstream : public
- basic_ostream<charT,traits> {
+
+basic_istringstream<charT, traits, Alloc>&
+y);

- 
- public:
+
+template <class charT, class traits, Allocator
+Alloc>

- //
- types:
+
+void swap(basic_istringstream<charT, traits,
+Alloc>& x,

- 
- typedef charT char_type;
+
+basic_istringstream<charT, traits,
+Alloc>&& y);

- 
- typedef typename traits::int_type int_type;
+}

- 
- typedef typename traits::pos_type pos_type;
+<td>

- 
- typedef typename traits::off_type off_type;
+<tr valign="top">
+<td>JP69

- 
- typedef traits traits_type;
+<td>27.7.3

- 
- typedef Alloc allocator_type;
+<td>

- 
-  
+<td>te

- //
- 27.7.3.1 Constructors/destructor:
+<td>
+basic_ostringstream dose not use concept.

- 
- explicit basic_ostringstream(ios_base::openmode which =
- ios_base::out);
+<td>
+Replace “class Allocator” to “Allocator
+Alloc”.

- 
- explicit basic_ostringstream(
+
+  Correct as follows.

- 
- const basic_string<charT,traits,Alloc>&
- str,
+
+ 

- 
- ios_base::openmode which = ios_base::out);
+
+namespace std {

- 
- basic_ostringstream(basic_ostringstream&& rhs);
+
+template <class charT, class traits =
+char_traits<charT>,

- 
-  
+
+Allocator Alloc = allocator<charT> >

- //
- 27.7.3.2 Assign/swap:
+
+class basic_ostringstream : public
+basic_ostream<charT,traits> {

- 
- basic_ostringstream&
- operator=(basic_ostringstream&& rhs);
+
+public:

- 
- void swap(basic_ostringstream&& rhs);
+//
+types:

- 
-  
+
+typedef charT char_type;

- //
- 27.7.3.3 Members:
+
+typedef typename traits::int_type int_type;

- 
- basic_stringbuf<charT,traits,Alloc>* rdbuf()
- const;
+
+typedef typename traits::pos_type pos_type;

- 
- basic_string<charT,traits,Alloc> str() const;
+
+typedef typename traits::off_type off_type;

- 
- void str(const
- basic_string<charT,traits,Alloc>& s);
+
+typedef traits traits_type;

- 
- private:
+
+typedef Alloc allocator_type;

- //
- basic_stringbuf<charT,traits,Alloc> sb;
- exposition only
+
+ 

- };
+//
+27.7.3.1 Constructors/destructor:

- 
-  
+
+explicit basic_ostringstream(ios_base::openmode which =
+ios_base::out);

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+explicit basic_ostringstream(

- 
- void swap(basic_ostringstream<charT, traits,
- Alloc>& x,
+
+const basic_string<charT,traits,Alloc>&
+str,

- 
- basic_ostringstream<charT, traits, Alloc>&
- y);
+
+ios_base::openmode which = ios_base::out);

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+basic_ostringstream(basic_ostringstream&& rhs);

- 
- void swap(basic_ostringstream<charT, traits,
- Alloc>&& x,
+
+ 

- 
- basic_ostringstream<charT, traits, Alloc>&
- y);
+//
+27.7.3.2 Assign/swap:

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+basic_ostringstream&
+operator=(basic_ostringstream&& rhs);

- 
- void swap(basic_ostringstream<charT, traits,
- Alloc>& x,
+
+void swap(basic_ostringstream&& rhs);

- 
- basic_ostringstream<charT, traits,
- Alloc>&& y);
+
+ 

- }
+//
+27.7.3.3 Members:

- 
- 
+
+basic_stringbuf<charT,traits,Alloc>* rdbuf()
+const;

- <td>
- 
+
+basic_string<charT,traits,Alloc> str() const;

- <tr valign="top">
- <td>
- JP 71
+
+void str(const
+basic_string<charT,traits,Alloc>& s);

- <td>
- 27.7.3
+
+private:

- <td>
- 
+//
+basic_stringbuf<charT,traits,Alloc> sb;
+exposition only

- <td>
- ed
+};

- <td>
- 
- Typo.
+
+ 

- "template" is missing in
- "class basic_ostringstream" of the title of the chapter.
+
+template <class charT, class traits, Allocator
+Alloc>

- <td>
- 
- Correct as follows.
+
+void swap(basic_ostringstream<charT, traits,
+Alloc>& x,

- 
- 27.7.3 Class basic_ostringstream
+
+basic_ostringstream<charT, traits, Alloc>&
+y);

- 
- 
+
+template <class charT, class traits, Allocator
+Alloc>

- 
- should be
+
+void swap(basic_ostringstream<charT, traits,
+Alloc>&& x,

- 
- 
+
+basic_ostringstream<charT, traits, Alloc>&
+y);

- 27.7.3 Class template
- basic_ostringstream
+
+template <class charT, class traits, Allocator
+Alloc>

- <td>
- [Being reviewed by Editor] 
+
+void swap(basic_ostringstream<charT, traits,
+Alloc>& x,

- <tr valign="top">
- <td>
- JP 72
+
+basic_ostringstream<charT, traits,
+Alloc>&& y);

- <td>
- 27.7.4
+}

- <td>
- 
+
+ 

- <td>
- te
+<td>

- <td>
- 
- basic_stringstream dose not use concept.
+<tr valign="top">
+<td>JP71

- <td>
- 
- Replace "class Allocator" to "Allocator Alloc".
+<td>27.7.3

- 
-   Correct as follows.
+<td>

- 
-  
+<td>ed

- 
- namespace std {
+<td>
+Typo.

- 
- template <class charT, class traits =
- char_traits<charT>,
+"template" is missing in
+"class basic_ostringstream" of the title of the chapter.

- 
- Allocator Alloc = allocator<charT> >
+<td>
+Correct as follows.

- 
- class basic_stringstream
+
+27.7.3 Class basic_ostringstream

- :
- public basic_iostream<charT,traits> {
+
+ 

- 
- public:
+
+should be

- //
- types:
+
+ 

- 
- typedef charT char_type;
+27.7.3 Class template
+basic_ostringstream

- 
- typedef typename traits::int_type int_type;
+<td>[Being reviewed by Editor] 

- 
- typedef typename traits::pos_type pos_type;
+

- 
- typedef typename traits::off_type off_type;
+<tr valign="top">
+<td>JP72

- 
- typedef traits traits_type;
+<td>27.7.4

- 
- typedef Alloc allocator_type;
+<td>

- 
-  
+<td>te

- //
- constructors/destructor
+<td>
+basic_stringstream dose not use concept.

- 
- explicit basic_stringstream(
+<td>
+Replace "class Allocator" to "Allocator Alloc".

- 
- ios_base::openmode which = ios_base::out|ios_base::in);
+
+  Correct as follows.

- 
- explicit basic_stringstream(
+
+ 

- 
- const basic_string<charT,traits,Alloc>&
- str,
+
+namespace std {

- 
- ios_base::openmode which = ios_base::out|ios_base::in);
+
+template <class charT, class traits =
+char_traits<charT>,

- 
- basic_stringstream(basic_stringstream&& rhs);
+
+Allocator Alloc = allocator<charT> >

- 
-  
+
+class basic_stringstream

- //
- 27.7.5.1 Assign/swap:
+:
+public basic_iostream<charT,traits> {

- 
- void swap(basic_stringstream&& rhs);
+
+public:

- 
-  
+//
+types:

- //
- Members:
+
+typedef charT char_type;

- 
- basic_stringbuf<charT,traits,Alloc>* rdbuf()
- const;
+
+typedef typename traits::int_type int_type;

- 
- basic_string<charT,traits,Alloc> str() const;
+
+typedef typename traits::pos_type pos_type;

- 
- void str(const
- basic_string<charT,traits,Alloc>& str);
+
+typedef typename traits::off_type off_type;

- 
- private:
+
+typedef traits traits_type;

- //
- basic_stringbuf<charT, traits> sb; exposition only
+
+typedef Alloc allocator_type;

- };
+
+ 

- 
-  
+//
+constructors/destructor

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+explicit basic_stringstream(

- 
- void swap(basic_stringstream<charT, traits,
- Alloc>& x,
+
+ios_base::openmode which = ios_base::out|ios_base::in);

- 
- basic_stringstream<charT, traits, Alloc>&
- y);
+
+explicit basic_stringstream(

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+const basic_string<charT,traits,Alloc>&
+str,

- 
- void swap(basic_stringstream<charT, traits,
- Alloc>&& x,
+
+ios_base::openmode which = ios_base::out|ios_base::in);

- 
- basic_stringstream<charT, traits, Alloc>&
- y);
+
+basic_stringstream(basic_stringstream&& rhs);

- 
- template <class charT, class traits, Allocator
- Alloc>
+
+ 

- 
- void swap(basic_stringstream<charT, traits,
- Alloc>& x,
+//
+27.7.5.1 Assign/swap:

- 
- basic_stringstream<charT, traits,
- Alloc>&& y);
+
+void swap(basic_stringstream&& rhs);

- }
+
+ 

- <td>
- 
+//
+Members:

- <tr valign="top">
- <td>
- JP 73
+
+basic_stringbuf<charT,traits,Alloc>* rdbuf()
+const;

- <td>
- 27.8.1.14
+
+basic_string<charT,traits,Alloc> str() const;

- <td>
- 
+
+void str(const
+basic_string<charT,traits,Alloc>& str);

- <td>
- te
+
+private:

- <td>
- It is a problem
- from C++98, fstream cannot appoint a filename of wide
- character string(const wchar_t and const wstring&).
+//
+basic_stringbuf<charT, traits> sb; exposition only

- 
- 
+};

- <td>
- Add
- interface corresponding to wchar_t, char16_t and char32_t.
+
+ 

- <td>
- 
+
+template <class charT, class traits, Allocator
+Alloc>

- <tr valign="top">
- <td>
- US 86
+
+void swap(basic_stringstream<charT, traits,
+Alloc>& x,

- <td>
- 28
+
+basic_stringstream<charT, traits, Alloc>&
+y);

- <td>
- 
+
+template <class charT, class traits, Allocator
+Alloc>

- <td>
- ge
+
+void swap(basic_stringstream<charT, traits,
+Alloc>&& x,

- <td>
- The
- regular expressions chapter is not concept enabled.
+
+basic_stringstream<charT, traits, Alloc>&
+y);

- 
+
+template <class charT, class traits, Allocator
+Alloc>

- <td>
- 
+
+void swap(basic_stringstream<charT, traits,
+Alloc>& x,

- <td>
- US86, UK309, UK310: We believe that an issue can be
- opened and we await a volunteer. 
+
+basic_stringstream<charT, traits,
+Alloc>&& y);

- <tr valign="top">
- <td>
- UK 
- 309
+}

- <td>
- 28
+<td>

- <td>
- 
+<tr valign="top">
+<td>JP73

- <td>
- Te
+<td>27.8.1.14

- <td>
- Regular
- expressions cannot be used in constrained templates
+<td>

- 
+<td>te

- <td>
- Provide constraints for the regular
- expression library, clause 28
+<td>It is a problem
+from C++98, fstream cannot appoint a filename of wide
+character string(const wchar_t and const wstring&).

- <td>
- US86, UK309, UK310: We believe that an issue can be
- opened and we await a volunteer. 
+
+ 

- <tr valign="top">
- <td>
- UK 
- 310
+<td>Add
+interface corresponding to wchar_t, char16_t and char32_t.

- <td>
- 28
+<td>

- <td>
- 
+<tr valign="top">
+<td>US86

- <td>
- Te
+<td>28

- <td>
- The regex chapter uses iterators in the old
- pre-concept style, it should be changed to use concepts
- instead.
+<td>

- <td>
- Use concepts for iterator template
- arguments throughout.
+<td>ge

- <td>
- US86, UK309, UK310: We believe that an issue can be
- opened and we await a volunteer.<tr valign="top">
- <td>
- UK 
- 314
+<td>The
+regular expressions chapter is not concept enabled.

- <td>
- 28.4
+<td>

- <td>
- 
+<td>US86, UK309, UK310: We believe that an issue can be
+opened and we await a volunteer. 

- <td>
- Te
+

- <td>
- The swap
- overloads for regex classes are only supplied for l-value
- references. Other sections of the library (eg 21 strings or
- 23 containers) provide two extra overloads taking an
- r-value reference as the first and second argument
- respectively.
+<tr valign="top">
+<td>UK309

- 
+<td>28

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

- <td>
- deferred to discussion of N2831. 
+<td>Te

- <tr valign="top">
- <td>
- UK 
- 315
+<td>Regular
+expressions cannot be used in constrained templates

- <td>
- 28.4
+<td>Provide constraints for the regular
+expression library, clause 28

- <td>
- p6
+<td>US86, UK309, UK310: We believe that an issue can be
+opened and we await a volunteer. 

- <td>
- Te
+

- <td>
- 6 Effects:
- string_type str(first, last); return
- use_facet<collate<charT> >(
- getloc()).transform(&*str.begin(), &*str.end()); Is
- it legal to dereference str.end() ?
+<tr valign="top">
+<td>UK310

- 
+<td>28

- <td>
- Reword to effect clause to use legal
- iterator dereferences
+<td>

- <td>
- We believe that this is editorial. 
+<td>Te

- <tr valign="top">
- <td>
- UK 
- 316
+<td>The regex chapter uses iterators in the old
+pre-concept style, it should be changed to use concepts
+instead.

- <td>
- 28.4 ff
+<td>Use concepts for iterator template
+arguments throughout.

- <td>
- 
+<td>US86, UK309, UK310: We believe that an issue can be
+opened and we await a volunteer.

- <td>
- Te
+<tr valign="top">
+<td>UK314

- <td>
- The constructors
- for regex classes do not have an r-value overload.
+<td>28.4

- 
+<td>

- <td>
- Add the missing r-value constructors to
- regex classes.
+<td>Te

- <td>
- We agree and await assistance from the UK. 
+<td>The swap
+overloads for regex classes are only supplied for l-value
+references. Other sections of the library (eg 21 strings or
+23 containers) provide two extra overloads taking an
+r-value reference as the first and second argument
+respectively.

- <tr valign="top">
- <td>
- UK 
- 317
+<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>
- 28.8
+<td>deferred to discussion of N2831. 

- <td>
- 
+

- <td>
- Te
+<tr valign="top">
+<td>UK315

- <td>
- basic_string has both a constructor and an
- assignment operator that accepts an initializer list,
- basic_regex should have the same.
+<td>28.4

- <td>
- In the
- basic_regex synopsis, after: basic_regex&
- operator=(const charT* ptr); add: basic_regex&
- operator=(initializer_list<charT> il); And after
- paragraph 20 add: basic_regex&
- operator=(initializer_list<charT> il); Effects:
- returns assign(il.begin(), il.end());
+<td>p6

- 
+<td>Te

- <td>
- UK317, JP74: Alisdair will open an issue. 
+<td>6 Effects:
+string_type str(first, last); return
+use_facet<collate<charT> >(
+getloc()).transform(&*str.begin(), &*str.end()); Is
+it legal to dereference str.end() ?

- <tr valign="top">
- <td>
- JP 74
+<td>Reword to effect clause to use legal
+iterator dereferences

- <td>
- 28.8
+<td>We believe that this is editorial. 

- <td>
- 
+

- <td>
- te
+<tr valign="top">
+<td>UK316

- <td>
- 
- “basic_regx & operator=
- (initializer_list<T>);” is not defined.
+<td>28.4 ff

- 
- 
+<td>

- <td>
- Add
- basic_regx & operator= (initializer_list<T>);
+<td>Te

- <td>
- UK317, JP74: Alisdair will open an issue. 
+<td>The constructors
+for regex classes do not have an r-value overload.

- <tr valign="top">
- <td>
- UK 
- 318
+<td>Add the missing r-value constructors to
+regex classes.

- <td>
- 28.8.2
+<td>We agree and await assistance from the UK. 

- <td>
- para 22
+

- <td>
- Ed
+<tr valign="top">
+<td>UK317

- <td>
- Constructor
- definition should appear with the other constructors not
- after assignment ops.
+<td>28.8

- 
+<td>

- <td>
- Move para 22 to just after para 17.
+<td>Te

- <td>
- 
+<td>basic_string has both a constructor and an
+assignment operator that accepts an initializer list,
+basic_regex should have the same.

- <tr valign="top">
- <td>
- UK 
- 319
+<td>In the
+basic_regex synopsis, after: basic_regex&
+operator=(const charT* ptr); add: basic_regex&
+operator=(initializer_list<charT> il); And after
+paragraph 20 add: basic_regex&
+operator=(initializer_list<charT> il); Effects:
+returns assign(il.begin(), il.end());

- <td>
- 28.12.2
+<td>UK317, JP74: Alisdair will open an issue. 

- <td>
- 
+

- <td>
- Te
+<tr valign="top">
+<td>JP74

- <td>
- It was always expected that
- regex_token_iterator would be constructible from an array
- literal: indeed ideally this is the prefered method of
- initializing such an object. However, the best we could do
- in C++0x was: template <std::size_t N>
- regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re, const
- int (&submatches)[N], regex_constants::match_flag_type
- m = regex_constants::match_default); Now that we have
- initializer_lists we should use them to remove this
- particular wart.
+<td>28.8

- <td>
- To the synopsis
- for regex_token_iterator, after template <std::size_t
- N> regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re, const
- int (&submatches)[N], regex_constants::match_flag_type
- m = regex_constants::match_default); add
- regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re,
- initializer_list<int> submatches,
- regex_constants::match_flag_type m =
- regex_constants::match_default); In 28.12.2.1 add the
- declaration: regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re,
- initializer_list<int> submatches,
- regex_constants::match_flag_type m =
- regex_constants::match_default); And to the end of para 3
- add: The forth constructor initializes the member subs to
- hold a copy of the sequence of integer values in the range
- [submatches.begin(), submatches.end()).
+<td>

- 
+<td>te

- <td>
- We agree. Alisdair will open an issue.In
- c++std-lib-23130, 
- Daniel Krügler
- pointed out that this comment is already covered by
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">
- issue 909</a>. 
+<td>
+“basic_regx & operator=
+(initializer_list<T>);” is not defined.

- <tr valign="top">
- <td>
- US 87
+
+ 

- <td>
- 29
+<td>Add
+basic_regx & operator= (initializer_list<T>);

- <td>
- 
+<td>UK317, JP74: Alisdair will open an issue. 

- <td>
- ge
+

- <td>
- The
- atomics chapter is not concept enabled. The adopted paper,
- N2427, did have those concepts.
+<tr valign="top">
+<td>UK318

- 
+<td>28.8.2

- <td>
- 
+<td>para 22

- <td>
- Create an issue for concepts in the atomics chapter. See
- N2427. Needs to also consider issues
- 923 and
- 924. 
+<td>Ed

- <tr valign="top">
- <td>
- UK 
- 311
+<td>Constructor
+definition should appear with the other constructors not
+after assignment ops.
+
+<td>Move para 22 to just after para 17.
+
+<td>
+
+<tr valign="top">
+<td>UK319
+
+<td>28.12.2
+
+<td>
+
+<td>Te
+
+<td>It was always expected that
+regex_token_iterator would be constructible from an array
+literal: indeed ideally this is the prefered method of
+initializing such an object. However, the best we could do
+in C++0x was: template <std::size_t N>
+regex_token_iterator(BidirectionalIterator a,
+BidirectionalIterator b, const regex_type& re, const
+int (&submatches)[N], regex_constants::match_flag_type
+m = regex_constants::match_default); Now that we have
+initializer_lists we should use them to remove this
+particular wart.
+
+<td>To the synopsis
+for regex_token_iterator, after template <std::size_t
+N> regex_token_iterator(BidirectionalIterator a,
+BidirectionalIterator b, const regex_type& re, const
+int (&submatches)[N], regex_constants::match_flag_type
+m = regex_constants::match_default); add
+regex_token_iterator(BidirectionalIterator a,
+BidirectionalIterator b, const regex_type& re,
+initializer_list<int> submatches,
+regex_constants::match_flag_type m =
+regex_constants::match_default); In 28.12.2.1 add the
+declaration: regex_token_iterator(BidirectionalIterator a,
+BidirectionalIterator b, const regex_type& re,
+initializer_list<int> submatches,
+regex_constants::match_flag_type m =
+regex_constants::match_default); And to the end of para 3
+add: The forth constructor initializes the member subs to
+hold a copy of the sequence of integer values in the range
+[submatches.begin(), submatches.end()).
+
+<td>We agree. Alisdair will open an issue.In
+c++std-lib-23130, 
+Daniel Krügler
+pointed out that this comment is already covered by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">
+issue 909</a>. 

- <td>
- 29
+

- <td>
- 
+<tr valign="top">
+<td>US87

- <td>
- Te
+<td>29

- <td>
- Atomic types
- cannot be used generically in a constrained template
+<td>

- 
+<td>ge

- <td>
- Provide constraints for the atomics
- library, clause 29
+<td>The
+atomics chapter is not concept enabled. The adopted paper,
+N2427, did have those concepts.

- <td>
- Duplicate of US 87. 
+<td>

- <tr valign="top">
- <td>
- UK 
- 312
+<td>Create an issue for concepts in the atomics chapter. See
+N2427. Needs to also consider issues
+923 and
+924. 

- <td>
- 29
+

- <td>
- 
+<tr valign="top">
+<td>UK311

- <td>
- Te
+<td>29

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

- <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
- to <stdatomic.h> and replace the use of
- <cstdatomic> with <atomic>. If and when WG14
- adds atomic operations to C we can add corresponding
- headers to table 14 with a TR.
+<td>Te

- <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. 
+<td>Atomic types
+cannot be used generically in a constrained template

- <tr valign="top">
- <td>
- JP 75
+<td>Provide constraints for the atomics
+library, clause 29

- <td>
- 29
+<td>Duplicate of US 87. 

- <td>
- 
+

- <td>
- ed
+<tr valign="top">
+<td>UK312

- <td>
- A
- definition of enum or struct is the style of C using
- typedef.
+<td>29

- <td>
- 
- Change to a style of C++.
+<td>

- 
- Correct as follows.
+<td>Te

- 
- 
+<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>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
+to <stdatomic.h> and replace the use of
+<cstdatomic> with <atomic>. If and when WG14
+adds atomic operations to C we can add corresponding
+headers to table 14 with a TR.
+
+<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. 

- 
- 29.1
+

- 
-  
+<tr valign="top">
+<td>JP75

- 
- namespace std {
+<td>29

- 
- typedef enum memory_order {
+<td>

- 
- memory_order_relaxed, memory_order_consume,
- memory_order_acquire,
+<td>ed

- 
- memory_order_release, memory_order_acq_rel,
- memory_order_seq_cst
+<td>A
+definition of enum or struct is the style of C using
+typedef.

- }
- memory_order;
+<td>
+Change to a style of C++.

- }
+
+Correct as follows.

- 
- 
+
+ 

- 
- should be
+
+29.1

- 
- 
+
+ 

- 
- namespace std {
+
+namespace std {

- 
- enum memory_order {
+
+typedef enum memory_order {

- 
- memory_order_relaxed, memory_order_consume,
- memory_order_acquire,
+
+memory_order_relaxed, memory_order_consume,
+memory_order_acquire,

- 
- memory_order_release, memory_order_acq_rel,
- memory_order_seq_cst
+
+memory_order_release, memory_order_acq_rel,
+memory_order_seq_cst

- };
+}
+memory_order;

- }
+}

- 
- 
+
+ 

- 
- 29.3.1
+
+should be

- 
- 
+
+ 

- 
- namespace std {
+
+namespace std {

- 
- typedef struct atomic_bool {
+
+enum memory_order {

- ...
+
+memory_order_relaxed, memory_order_consume,
+memory_order_acquire,

- }
- atomic_bool;
+
+memory_order_release, memory_order_acq_rel,
+memory_order_seq_cst

- }
+};

- 
- 
+}

- 
- should be
+
+ 

- 
- 
+
+29.3.1

- 
- namespace std {
+
+ 

- 
- struct atomic_bool {
+
+namespace std {

- ...
+
+typedef struct atomic_bool {

- };
+...

- }
+}
+atomic_bool;

- 
- 
+}

- 
- namespace std {
+
+ 

- 
- typedef struct atomic_itype {
+
+should be

- ...
+
+ 

- }
- atomic_itype;
+
+namespace std {

- }
+
+struct atomic_bool {

- 
- 
+...

- 
- should be
+};

- 
- 
+}

- 
- namespace std {
+
+ 

- 
- struct atomic_itype {
+
+namespace std {

- ...
+
+typedef struct atomic_itype {

- };
+...

- }
+}
+atomic_itype;

- 
- 
+}

- 
- 29.3.2
+
+ 

- 
- 
+
+should be

- 
- namespace std {
+
+ 

- 
- typedef struct atomic_address {
+
+namespace std {

- ...
+
+struct atomic_itype {

- }
- atomic_address;
+...

- }
+};

- 
- 
+}

- 
- should be
+
+ 

- 
- 
+
+29.3.2

- 
- namespace std {
+
+ 

- 
- struct atomic_address {
+
+namespace std {

- ...
+
+typedef struct atomic_address {

- };
+...

- }
+}
+atomic_address;

- 
- 
+}

- 
- 29.5
+
+ 

- 
- 
+
+should be

- 
- namespace std {
+
+ 

- 
- typedef struct atomic_flag {
+
+namespace std {

- ...
+
+struct atomic_address {

- }
- atomic_flag;
+...

- }
+};

- 
- 
+}

- 
- should be
+
+ 

- 
- 
+
+29.5

- 
- namespace std {
+
+ 

- 
- struct atomic_flag {
+
+namespace std {

- ...
+
+typedef struct atomic_flag {

- };
+...

- }
+}
+atomic_flag;

- <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>
- UK 
- 313
+
+ 

- <td>
- 29.1
+
+should be

- <td>
- 
+
+ 

- <td>
- Te
+
+namespace std {

- <td>
- seq_cst fences don't necessarily guarantee
- ordering
- http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926
+
+struct atomic_flag {

- <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
- modify M, if there are memory_order_seq_cst fences X and Y
- such that A is sequenced before X, Y is sequenced before B,
- and X precedes Y in S, then B occurs later than A in the
- modifiction order of M.
+...

- 
+};

- <td>
- Hans to make proposal. See LWG
- Issue 926.
- UK 313 Update and LWG
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">
- 926</a>: Accept proposed resolution, correcting
- spelling. Move to review state. Hans to ask additional review from cpp-threads. 
+}

- <tr valign="top">
- <td>
- US 88
+<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. 

- <td>
- 29.2
+

- <td>
- 
+<tr valign="top">
+<td>UK313

- <td>
- te
+<td>29.1

- <td>
- The "lockfree" facilities do
- not tell the programmer enough.
+<td>

- <td>
- 
- Expand the "lockfree" facilities. See the attached paper
- "Issues with the C++ Standard" under Chapter 29,
- "atomics.lockfree doesn't tell the programmer enough"
+<td>Te

- 
+<td>seq_cst fences don't necessarily guarantee
+ordering
+http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926
+
+<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
+modify M, if there are memory_order_seq_cst fences X and Y
+such that A is sequenced before X, Y is sequenced before B,
+and X precedes Y in S, then B occurs later than A in the
+modifiction order of M.
+
+<td>Hans to make proposal. See LWG
+Issue 926.
+UK 313 Update and LWG
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">
+926</a>: Accept proposed resolution, correcting
+spelling. Move to review state. Hans to ask additional review from cpp-threads. 

- <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.See wiki for further
- comments. 
+

- <tr valign="top">
- <td>
- US 89
+<tr valign="top">
+<td>US88

- <td>
- 29.3.1
+<td>29.2

- <td>
- Table 122
+<td>

- <td>
- te
+<td>te

- <td>
- The
- types in the table "Atomics for standard typedef types"
- should be typedefs, not classes. These semantics are
- necessary for compatibility with C.
+<td>The "lockfree" facilities do
+not tell the programmer enough.

- 
+<td>
+Expand the "lockfree" facilities. See the attached paper
+"Issues with the C++ Standard" under Chapter 29,
+"atomics.lockfree doesn't tell the programmer enough"

- <td>
- Change the classes to
- typedefs.
+<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.See wiki for further
+comments. 

- <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>
- US 90
+

- <td>
- 29.4
+<tr valign="top">
+<td>US89

- <td>
- 
+<td>29.3.1

- <td>
- te
+<td>Table 122

- <td>
- Are atomic functions allowed
- to have non-volatile overloads?
+<td>te

- <td>
- 
- Allow non-volatile overloads. See the attached paper
- "Issues with the C++ Standard, under Chapter 29, "Are
- atomic functions allowed to have non-volatile overloads?"
+<td>The
+types in the table "Atomics for standard typedef types"
+should be typedefs, not classes. These semantics are
+necessary for compatibility with C.

- 
+<td>Change the classes to
+typedefs.

- <td>
- Create an issue. Assigned to Lawrence Crowl. Should
- explicitly consider the process shared issue. 
+<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>
- US 91
+<tr valign="top">
+<td>US90

- <td>
- 29.4
+<td>29.4

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <td>
- Whether or not a failed
- compare_exchange is a RMW operation (as used in 1.10
- [intro.multithread]) is unclear.
+<td>Are atomic functions allowed
+to have non-volatile overloads?

- <td>
- 
- Make failing compare_exchange operations not be RMW. See
- the attached paper under "atomic RMW status of failed
- compare_exchange"
+<td>
+Allow non-volatile overloads. See the attached paper
+"Issues with the C++ Standard, under Chapter 29, "Are
+atomic functions allowed to have non-volatile overloads?"

- 
+<td>Create an issue. Assigned to Lawrence Crowl. Should
+explicitly consider the process shared issue. 

- <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>
- US 92
+<tr valign="top">
+<td>US91

- <td>
- 29.4
+<td>29.4

- <td>
- 
+<td>

- <td>
- te
+<td>te

- <td>
- The effect of
- memory_order_consume with atomic RMW operations is unclear.
+<td>Whether or not a failed
+compare_exchange is a RMW operation (as used in 1.10
+[intro.multithread]) is unclear.

- <td>
- 
- Follow the lead of fences [atomics.fences], and promote
- memory_order_consume to memory_order_acquire with RMW
- operations.
+<td>
+Make failing compare_exchange operations not be RMW. See
+the attached paper under "atomic RMW status of failed
+compare_exchange"

- 
+<td>Create an issue, goes to review. Attention: Howard.
+Group agrees with the resolution as proposed by Anthony Williams in the
+attached note. 

- <td>
- Create an issue. Assigned to Lawrence. Resolution
- requires proposed wording.Later: Mark as Not A Defect.
- We can not see the issue being suggested by the comment. 
+

- <tr valign="top">
- <td>
- JP 76
+<tr valign="top">
+<td>US92

- <td>
- 30
+<td>29.4

- <td>
- 
+<td>

- <td>
- ed
+<td>te

- <td>
- A
- description for "Throws: Nothing." are not unified.
+<td>The effect of
+memory_order_consume with atomic RMW operations is unclear.

- At
- the part without throw, "Throws: Nothing." should be
- described.
+<td>
+Follow the lead of fences [atomics.fences], and promote
+memory_order_consume to memory_order_acquire with RMW
+operations.

- <td>
- Add
- "Throws: Nothing." to the following.
+<td>Create an issue. Assigned to Lawrence. Resolution
+requires proposed wording.Later: Mark as Not A Defect.
+We can not see the issue being suggested by the comment. 

- 
- 30.2.1.6 , 1st paragraph
+

- 
- 30.3.3.1 , 4th paragraph
+<tr valign="top">
+<td>JP76

- 
- 30.3.3.2.1 , 6th paragraph
+<td>30

- 
- 30.4.1 , 7th and 8th paragraph
+<td>

- 30.4.2 ,
- 6th,
- 7th,19th,21th and 25th
- paragraph
+<td>ed

- 
- 
+<td>A
+description for "Throws: Nothing." are not unified.

- <td>
- Pass on to editor. 
+At
+the part without throw, "Throws: Nothing." should be
+described.

- <tr valign="top">
- <td>
- <a name="US93">US 93</a>
+<td>Add
+"Throws: Nothing." to the following.

- <td>
- 30
+
+30.2.1.6 , 1st paragraph

- <td>
- 
+
+30.3.3.1 , 4th paragraph

- <td>
- ge
+
+30.3.3.2.1 , 6th paragraph

- <td>
- The
- thread chapter is not concept enabled.
+
+30.4.1 , 7th and 8th paragraph

- 
+30.4.2 ,
+6th,
+7th,19th,21th and 25th
+paragraph

- <td>
- 
+
+ 

- <td>
- Create an issue. Need to find volunteers to work on
- this. 
+<td>Pass on to editor. 

- <tr valign="top">
- <td>
- UK 
- 320 F
+

- <td>
- 30
+<tr valign="top">
+<td><a name="US93">US 93</a>

- <td>
- 
+<td>30

- <td>
- Te
+<td>

- <td>
- Threads library cannot be used in
- constrained templates
+<td>ge

- <td>
- Provide constraints for the threads
- library, clause 30
+<td>The
+thread chapter is not concept enabled.

- <td>
- Duplicate of US 93. 
+<td>

- <tr valign="top">
- <td>
- UK 
- 321
+<td>Create an issue. Need to find volunteers to work on
+this. 

- <td>
- 30
+

- <td>
- 
+<tr valign="top">
+<td>UK320

- <td>
- Ed
+<td>30

- <td>
- Throughout this
- clause, the term Requires: is used to introduce compile
- time requirements, which we expect to be replaced with
- concepts and requires in code. Run-time preconditions are
- introduced with the term "Preconditions:" which is not a
- defined part of the library documentation structure
- (17.5.2.4). However, this is exactly the direction that BSI
- would like to see the organisation move, replacing
- Requires: clauses with Preconditions: clasues throught the
- library. See comment against clause 17 for more details.
+<td>

- 
+<td>Te

- <td>
- Decument Preconditions: paragraphs in
- 17.5.2.4, and use consistently through rest of the library.
+<td>Threads library cannot be used in
+constrained templates

- <td>
- Pass on to editor. 
+<td>Provide constraints for the threads
+library, clause 30

- <tr valign="top">
- <td>
- US 94
+<td>Duplicate of US 93. 

- <td>
- 30.1.2
+

- <td>
- 1
+<tr valign="top">
+<td>UK321

- <td>
- te
+<td>30

- <td>
- The first sentence of para 1 suggests that no other
- library function is permitted to call operating system or
- low level APIs.
+<td>

- <td>
- Rewrite para 1
- as: “ Some functions described
- in this Clause are specified to throw exceptions of type
- system_error (19.4.5
- ). Such exceptions shall be thrown if
- a call to an operating system or underlying API results in
- an error that prevents the library function from satisfying
- its postconditions or from returning a meaningful
- value.”
+<td>Ed

- 
+<td>Throughout this
+clause, the term Requires: is used to introduce compile
+time requirements, which we expect to be replaced with
+concepts and requires in code. Run-time preconditions are
+introduced with the term "Preconditions:" which is not a
+defined part of the library documentation structure
+(17.5.2.4). However, this is exactly the direction that BSI
+would like to see the organisation move, replacing
+Requires: clauses with Preconditions: clasues throught the
+library. See comment against clause 17 for more details.

- <td>
- 
+<td>Decument Preconditions: paragraphs in
+17.5.2.4, and use consistently through rest of the library.

- Reclassify as editorial. Pass on to editor, wording roughly as proposed.<tr valign="top">
- <td>
- US 95
+<td>Pass on to editor. 

- <td>
- 30.1.3
+

- <td>
- 1
+<tr valign="top">
+<td>US94

- <td>
- te
+<td>30.1.2

- <td>
- “native_handle_type” is a typedef, not a
- class member.
+<td>1

- <td>
- Several classes
- described in this Clause have a member native_handle (of
- type native_handle_type) . The
+<td>te

- 
- presence of this member and its semantics is implementation
- defined. [ Note: This member allows implementations to
- provide access to implementation details. The name of the
- member and the type are specified to facilitate portable
- compile-time detection. Actual use of this member or the
- corresponding type is inherently non-portable. —end
- note ]
+<td>The first sentence of para 1 suggests that no other
+library function is permitted to call operating system or
+low level APIs.

- 
+<td>Rewrite para 1
+as: “ Some functions described
+in this Clause are specified to throw exceptions of type
+system_error (19.4.5
+). Such exceptions shall be thrown if
+a call to an operating system or underlying API results in
+an error that prevents the library function from satisfying
+its postconditions or from returning a meaningful
+value.”

- <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>
- US 96
+<td>Reclassify as editorial. Pass on to editor, wording roughly as proposed.

- <td>
- 30.1.4
+<tr valign="top">
+<td>US95

- <td>
- 2
+<td>30.1.3

- <td>
- te
+<td>1

- <td>
- There is no definition here for monotonic clock.
+<td>te

- <td>
- Implementations
- should use a monotonic clock to measure time for
- these functions. A monotonic clock measures real time, but
- cannot be set, and is guaranteed to have no negative clock
- jumps.
+<td>“native_handle_type” is a typedef, not a
+class member.

- 
+<td>Several classes
+described in this Clause have a member native_handle (of
+type native_handle_type) . The

- <td>
- 
+
+presence of this member and its semantics is implementation
+defined. [ Note: This member allows implementations to
+provide access to implementation details. The name of the
+member and the type are specified to facilitate portable
+compile-time detection. Actual use of this member or the
+corresponding type is inherently non-portable. —end
+note ]

- There is a good definition. NAD. There are other problems here (see issue
- 859). 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>
- UK 
- 322
+<td>Not a defect. native_handle_type is a typedef, but it is also a member of
+ the classes in question.

- <td>
- 30.1.4
+<tr valign="top">
+<td>US96

- <td>
- 2
+<td>30.1.4

- <td>
- Te
+<td>2

- <td>
- Not all systms
- can provide a monotonic clock. How are they expected to
- treat a _for function?
+<td>te

- 
+<td>There is no definition here for monotonic clock.

- <td>
- Add at least a note explaining the intent
- for systems that do not support a monotonic clock.
+<td>Implementations
+should use a monotonic clock to measure time for
+these functions. A monotonic clock measures real time, but
+cannot be set, and is guaranteed to have no negative clock
+jumps.

- <td>
- 
+<td>There is a good definition. NAD. There are other problems here (see issue
+ 859). 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].

- 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>
- UK 
- 323
+<tr valign="top">
+<td>UK322

- <td>
- 30.2.1
+<td>30.1.4

- <td>
- 1
+<td>2

- <td>
- Te
+<td>Te

- <td>
- The presence of
- a non-explicit variadic template constructor alongside an
- explicit single-argument constructor can lead to behaviour
- that is not intended: the variadic constructor will be
- selected for implicit conversions, defeating the purpose of
- the explicit single-argument constructor. Additionally the
- single-argument constructor is redundant; the variadic
- constructor can provide identical functionality with one
- *fewer* copies if the supplied func is an lvalue.
+<td>Not all systms
+can provide a monotonic clock. How are they expected to
+treat a _for function?

- 
+<td>Add at least a note explaining the intent
+for systems that do not support a monotonic clock.

- <td>
- Mark constructor template <class F,
- class ...Args> thread(F&& f, Args&&...
- args); as explicit and remove the single-argument
- constructor.
+<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.

- <td>
- 
+<tr valign="top">
+<td>UK323

- Create an issue, goes to review. Attention: Howard. Group agrees with the
- proposed resolution.<tr valign="top">
- <td>
- UK 
- 324
+<td>30.2.1

- <td>
- 30.2.1.1
+<td>1

- <td>
- 
+<td>Te

- <td>
- Te
+<td>The presence of
+a non-explicit variadic template constructor alongside an
+explicit single-argument constructor can lead to behaviour
+that is not intended: the variadic constructor will be
+selected for implicit conversions, defeating the purpose of
+the explicit single-argument constructor. Additionally the
+single-argument constructor is redundant; the variadic
+constructor can provide identical functionality with one
+*fewer* copies if the supplied func is an lvalue.

- <td>
- thread::id
- objects should be as useable in hashing containers as they
- are in ordered associative containers.
+<td>Mark constructor template <class F,
+class ...Args> thread(F&& f, Args&&...
+args); as explicit and remove the single-argument
+constructor.

- 
+<td>Create an issue, goes to review. Attention: Howard. Group agrees with the
+ proposed resolution.

- <td>
- Add thread::id
- support for std::hash
+<tr valign="top">
+<td>UK324

- 
+<td>30.2.1.1

- 
+<td>

- 
+<td>Te

- <td>
- 
+<td>thread::id
+objects should be as useable in hashing containers as they
+are in ordered associative containers.

- Not a defect. See [unord.hash], where std::thread:id is already listed as a
- required specialization for std::hash().<tr valign="top">
- <td>
- JP 77
+<td>Add thread::id
+support for std::hash

- <td>
- 30.2.1.2
+ 

- <td>
- 
+ 

- <td>
- te
+<td>Not a defect. See [unord.hash], where std::thread:id is already listed as a
+ required specialization for std::hash().

- <td>
- 
- "CopyConstructible" and "MoveConstructible" in
- "Requires: F and each Ti in Args shall be
- CopyConstructible if an lvalue and otherwise
- MoveConstructible." are reflected by interface.
+<tr valign="top">
+<td>JP77

- 
- 
+<td>30.2.1.2

- <td>
- Add
- a concept for constructor of thread.
+<td>

- <td>
- 
+<td>te

- Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td>
- JP 78
+<td>
+"CopyConstructible" and "MoveConstructible" in
+"Requires: F and each Ti in Args shall be
+CopyConstructible if an lvalue and otherwise
+MoveConstructible." are reflected by interface.

- <td>
- 30.2.1.2
+
+ 

- <td>
- 
- 4th para, 1st line
+<td>Add
+a concept for constructor of thread.

- 
+<td>Subset of US 93. Should be addressed under the issue corresponding to US 93.

- <td>
- ed
+<tr valign="top">
+<td>JP78

- <td>
- In
- "F and each Ti in Args", 'Ti' is not clear.
+<td>30.2.1.2

- <td>
- 
- Replace "Ti" with "args"
+<td>
+4th para, 1st line

- <td>
- 
+<td>ed

- Pass on to editor.<tr valign="top">
- <td>
- US 97
+<td>In
+"F and each Ti in Args", 'Ti' is not clear.

- <td>
- 30.2.1.3
+<td>
+Replace "Ti" with "args"

- <td>
- 1
+<td>Pass on to editor.

- <td>
- te
+<tr valign="top">
+<td>US97

- <td>
- detach-on-destruction may result in
- “escaped” threads accessing objects with
- bounded lifetime after the end of their lifetime.
+<td>30.2.1.3

- <td>
- See document WG21 N2802=08-0312 written by Hans Boehm.
+<td>1

- <td>
- 
+<td>te

- Create an issue. To be discussed in full library group.
+<td>detach-on-destruction may result in
+“escaped” threads accessing objects with
+bounded lifetime after the end of their lifetime.

- Later: straw poll 10-0, put N2802 Alternative 2 on formal motions page.<tr valign="top">
- <td>
- US 98
+<td>See document WG21 N2802=08-0312 written by Hans Boehm.

- <td>
- 30.2.1.3, 
- 30.2.1.4
+<td>Create an issue. To be discussed in full library group.

- <td>
- 
+ Later: straw poll 10-0, put N2802 Alternative 2 on formal motions page.

- <td>
- 
+<tr valign="top">
+<td>US98

- <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>30.2.1.3, 
+30.2.1.4

- <td>
- 
- Change destruction behavior to undefined behavior, with a
- note strongly encouraging termination. See the attached
- paper "Issues with the C++ Standard" under Chapter 30,
- "Implicit thread detach is harmful".
+<td>

- 
+<td>

- <td>
- 
+<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.

- Duplicate of US 97.<tr valign="top">
- <td>
- UK 
- 325
+<td>
+Change destruction behavior to undefined behavior, with a
+note strongly encouraging termination. See the attached
+paper "Issues with the C++ Standard" under Chapter 30,
+"Implicit thread detach is harmful".

- <td>
- 30.3.3
+<td>Duplicate of US 97.

- <td>
- 2
+<tr valign="top">
+<td>UK325

- <td>
- Te
+<td>30.3.3

- <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>2

- <td>
- Replace the
- extern declarations: extern const defer_lock_t defer_lock;
- extern const try_to_lock_t try_to_lock; extern const
- adopt_lock_t adopt_lock; with constexpr values constexpr
- defer_lock_t defer_lock{}; constexpr try_to_lock_t
- try_to_lock{}; constexpr adopt_lock_t adopt_lock{};
+<td>Te

- 
+<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>
- 
+<td>Replace the
+extern declarations: extern const defer_lock_t defer_lock;
+extern const try_to_lock_t try_to_lock; extern const
+adopt_lock_t adopt_lock; with constexpr values constexpr
+defer_lock_t defer_lock{}; constexpr try_to_lock_t
+try_to_lock{}; constexpr adopt_lock_t adopt_lock{};

- Create an issue. Move to review, attention: Howard. The current
+<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>
- UK 
- 326
-
- <td>
- 30.3.3.2.1
-
- <td>
- 7
-
- <td>
- Te
-
- <td>
- The precondition
- that the mutex is not owned by this thread offers
- introduces the risk of un-necessary undefined behaviour
- into the program. The only time it matters whether the
- current thread owns the mutex is in the lock operation, and
- that will happen subsequent to construction in this case.
- The lock operation has the identical pre-condition, so
- there is nothing gained by asserting that precondition
- earlier and denying the program the right to get into a
- valid state before calling lock.
-
- 
-
- <td>
- Strike 30.3.3.2.1p7
-
- <td>
- 
-
- Create an issue. Move to review, attention: Howard. Proposed resolution is
- fine.<tr valign="top">
- <td>
- UK 
- 327
-
- <td>
- 30.3.3.2.2
-
- <td>
- 4, 9, 14, 19
-
- <td>
- Te
-
- <td>
- Not clear what
- the specification for error condition
- resource_deadlock_would_occur means. It is perfectly
- possible for this thread to own the mutex without setting
- owns to true on this specific lock object. It is also
- possible for lock operations to succeed even if the thread
- does own the mutex, if the mutex is recursive. Likewise, if
- the mutex is not recursive and the mutex has been locked
- externally, it is not always possible to know that this
- error condition should be raised, depending on the host
- operating system facilities. It is possible that 'i.e.' was
- supposed to be 'e.g.' and that suggests that recursive
- locks are not allowed. That makes sense, as the
- exposition-only member owns is boolean and not a integer to
- count recursive locks.
-
- 
-
- <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.
+ "hack".
+
+<tr valign="top">
+<td>UK326
+
+<td>30.3.3.2.1
+
+<td>7

- <td>
- 
+<td>Te
+
+<td>The precondition
+that the mutex is not owned by this thread offers
+introduces the risk of un-necessary undefined behaviour
+into the program. The only time it matters whether the
+current thread owns the mutex is in the lock operation, and
+that will happen subsequent to construction in this case.
+The lock operation has the identical pre-condition, so
+there is nothing gained by asserting that precondition
+earlier and denying the program the right to get into a
+valid state before calling lock.
+
+<td>Strike 30.3.3.2.1p7
+
+<td>Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.
+
+<tr valign="top">
+<td>UK327
+
+<td>30.3.3.2.2
+
+<td>4, 9, 14, 19
+
+<td>Te
+
+<td>Not clear what
+the specification for error condition
+resource_deadlock_would_occur means. It is perfectly
+possible for this thread to own the mutex without setting
+owns to true on this specific lock object. It is also
+possible for lock operations to succeed even if the thread
+does own the mutex, if the mutex is recursive. Likewise, if
+the mutex is not recursive and the mutex has been locked
+externally, it is not always possible to know that this
+error condition should be raised, depending on the host
+operating system facilities. It is possible that 'i.e.' was
+supposed to be 'e.g.' and that suggests that recursive
+locks are not allowed. That makes sense, as the
+exposition-only member owns is boolean and not a integer to
+count recursive locks.
+
+<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.

- Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock
+<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>
- UK 
- 328
-
- <td>
- 30.3.3.2.2
-
- <td>
- 20
-
- <td>
- Te
-
- <td>
- There is a missing precondition that owns
- is true, or an if(owns) test is missing from the effect
- clause
-
- <td>
- Add a
- precondition that owns == true. Add an error condition to
- detect a violation, rather than yield undefined behaviour.
-
- 
-
- <td>
- 
-
- Handle in same issue as UK 327. Also uncertain that the proposed resolution
- is the correct one.<tr valign="top">
- <td>
- UK 
- 329
-
- <td>
- 30.5
-
- <td>
- 
-
- <td>
- Te
-
- <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>
- Provide a simple
- function along the lines of: template< typename F,
- typename ... Args > requires Callable< F, Args...
- > future< Callable::result_type > async(
- F&& f, Args && ... ); Semantics are similar
- to creating a thread object with a packaged_task invoking f
- with forward<Args>(args...) but details are left
- unspecified to allow different scheduling and thread
- spawning implementations. It is unspecified whether a task
- submitted to async is run on its own thread or a thread
- previously used for another async task. If a call to async
- succeeds, it shall be safe to wait for it from any thread.
- The state of thread_local variables shall be preserved
- during async calls. No two incomplete async tasks shall see
- the same value of this_thread::get_id(). [Note: this
- effectively forces new tasks to be run on a new thread, or
- a fixed-size pool with no queue. If the library is unable
- to spawn a new thread or there are no free worker threads
- then the async call should fail.]
+ example, try_lock should have different wording from lock.

- 
+<tr valign="top">
+<td>UK328

- <td>
- 
+<td>30.3.3.2.2

- The concurrency subgroup has revisited this issue and decided that it could
+<td>20
+
+<td>Te
+
+<td>There is a missing precondition that owns
+is true, or an if(owns) test is missing from the effect
+clause
+
+<td>Add a
+precondition that owns == true. Add an error condition to
+detect a violation, rather than yield undefined behaviour.
+
+<td>Handle in same issue as UK 327. Also uncertain that the proposed resolution
+ is the correct one.
+
+<tr valign="top">
+<td>UK329
+
+<td>30.5
+
+<td>
+
+<td>Te
+
+<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>Provide a simple
+function along the lines of: template< typename F,
+typename ... Args > requires Callable< F, Args...
+> future< Callable::result_type > async(
+F&& f, Args && ... ); Semantics are similar
+to creating a thread object with a packaged_task invoking f
+with forward<Args>(args...) but details are left
+unspecified to allow different scheduling and thread
+spawning implementations. It is unspecified whether a task
+submitted to async is run on its own thread or a thread
+previously used for another async task. If a call to async
+succeeds, it shall be safe to wait for it from any thread.
+The state of thread_local variables shall be preserved
+during async calls. No two incomplete async tasks shall see
+the same value of this_thread::get_id(). [Note: this
+effectively forces new tasks to be run on a new thread, or
+a fixed-size pool with no queue. If the library is unable
+to spawn a new thread or there are no free worker threads
+then the async call should fail.]
+
+<td>The concurrency subgroup has revisited this issue and decided that it could
 be considered a defect according to the Kona compromise. A task group was
 formed lead by Lawrence Crowl <crowl_at_[hidden]> and Bjarne Stroustrup <bs_at_[hidden]>
 to write a paper for Frankfort proposing a simple asynchronous launch
@@ -13230,865 +10715,660 @@
 Bjarne in c++std-lib-23121: I think that what we agreed was that to avoid
 deadlock async() would almost certainly be specified to  launch in a
 different thread from the thread that executed async(), but I don't think it
- was a specific design constraint.<tr valign="top">
- <td>
- UK 
- 330
-
- <td>
- 30.5.1
-
- <td>
- 
-
- <td>
- Ed
-
- <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.
+ was a specific design constraint.

- <td>
- Remove the
- reference to constructible_with_allocator_prefix in 30.5.1
- Remove paragraph 30.5.7
+<tr valign="top">
+<td>UK330

- 
+<td>30.5.1

- <td>
- 
+<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>
- <a name="JP79">JP 79 </a>
+<td>Ed

- <td>
- 30.5.1
+<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>
- 
+<td>Remove the
+reference to constructible_with_allocator_prefix in 30.5.1
+Remove paragraph 30.5.7

- <td>
- te
+<td>Related to JP 79 and therefore subset of US 93. Should be addressed under
+ the issue corresponding to US 93.

- <td>
- The
- concept of UsesAllocator and Allocator should be used.
+<tr valign="top">
+<td><a name="JP79">JP79 </a>

- <td>
- 
- Correct as follows.
+<td>30.5.1

- 
-  
+<td>

- 
- template <class R, class Alloc>
+<td>te

- 
- struct uses_allocator<promise<R>, Alloc>;
+<td>The
+concept of UsesAllocator and Allocator should be used.

- 
- template <class R>
+<td>
+Correct as follows.

- 
- struct
- constructible_with_allocator_prefix<promise<R>
- >;
+
+ 

- 
-  
+
+template <class R, class Alloc>

- 
- should be
+
+struct uses_allocator<promise<R>, Alloc>;

- 
-  
+
+template <class R>

- 
- template<class R, Allocator Alloc>
+
+struct
+constructible_with_allocator_prefix<promise<R>
+>;

- concept_map
- UsesAllocator<promise<R>, Alloc>;
+
+ 

- 
- 
+
+should be

- <td>
- 
+
+ 

- Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td>
- UK 
- 331
+
+template<class R, Allocator Alloc>

- <td>
- 30.5.3
+concept_map
+UsesAllocator<promise<R>, Alloc>;

- <td>
- 
+
+ 

- <td>
- Te
+<td>Subset of US 93. Should be addressed under the issue corresponding to US 93.

- <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
- constructor then it can be made private and accessed
- through friendship. Otherwise it should be documented for
- public consumption.
+<tr valign="top">
+<td>UK331

- 
+<td>30.5.3

- <td>
- Declare the constructor as private with a
- note about intended friendship, or remove the
- exposition-only comment and document the semantics.
+<td>

- <td>
- 
+<td>Te

- Create an issue. Assigned to Detlef. Suggested resolution probably makes
- sense.<tr valign="top">
- <td>
- UK 
- 332
+<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
+constructor then it can be made private and accessed
+through friendship. Otherwise it should be documented for
+public consumption.

- <td>
- 30.5.4
+<td>Declare the constructor as private with a
+note about intended friendship, or remove the
+exposition-only comment and document the semantics.

- <td>
- 
+<td>Create an issue. Assigned to Detlef. Suggested resolution probably makes
+ sense.

- <td>
- Ed
+<tr valign="top">
+<td>UK332

- <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
- construct a future is via the promise API which is
- documented after the presentation of future. Most library
- clauses feature a small description of their components and
- intended use, it would be most useful in this case.
+<td>30.5.4

- 
+<td>

- <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>Ed

- <td>
- 
+<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
+construct a future is via the promise API which is
+documented after the presentation of future. Most library
+clauses feature a small description of their components and
+intended use, it would be most useful in this case.

- Pass on to editor. Detlef has volunteered to provide some wording.<tr valign="top">
- <td>
- UK 
- 333
+<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>
- 30.5.4
+<td>Pass on to editor. Detlef has volunteered to provide some wording.

- <td>
- 5
+<tr valign="top">
+<td>UK333

- <td>
- Ge
+<td>30.5.4

- <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>5

- <td>
- Requires fully baked concepts for clause 30
+<td>Ge

- <td>
- 
+<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.

- Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td>
- UK 
- 334
+<td>Requires fully baked concepts for clause 30

- <td>
- 30.5.4
+<td>Subset of US 93. Should be addressed under the issue corresponding to US 93.

- <td>
- 5
+<tr valign="top">
+<td>UK334

- <td>
- Te
+<td>30.5.4

- <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
- for the future to become ready.
+<td>5

- 
+<td>Te

- <td>
- Effects: If is_ready() would return false,
- block on the asynchronous result associated with *this.
+<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
+for the future to become ready.

- <td>
- 
+<td>Effects: If is_ready() would return false,
+block on the asynchronous result associated with *this.

- Create an issue. Move to review, attention: Howard. Proposed resolution is
- fine.<tr valign="top">
- <td>
- UK 
- 335
+<td>Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.

- <td>
- 30.5.4
+<tr valign="top">
+<td>UK335

- <td>
- 
+<td>30.5.4

- <td>
- Te
+<td>

- <td>
- 
- std::unique_future is MoveConstructible, so you can
- transfer the association with an asynchronous result from
- one instance to another. However, there is no way to
- determine whether or not an instance has been moved from,
- and therefore whether or not it is safe to wait for it.
- std::promise<int> p; std::unique_future<int>
- uf(p.get_future()); std::unique_future<int>
- uf2(std::move(uf)); uf.wait(); // oops, uf has no result to
- wait for.
+<td>Te

- 
+<td>
+std::unique_future is MoveConstructible, so you can
+transfer the association with an asynchronous result from
+one instance to another. However, there is no way to
+determine whether or not an instance has been moved from,
+and therefore whether or not it is safe to wait for it.
+std::promise<int> p; std::unique_future<int>
+uf(p.get_future()); std::unique_future<int>
+uf2(std::move(uf)); uf.wait(); // oops, uf has no result to
+wait for.

- <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>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>
- 
+<td>Create an issue. Requires input from Howard. Probably NAD.

- Create an issue. Requires input from Howard. Probably NAD.<tr valign="top">
- <td>
- UK 
- 336
+<tr valign="top">
+<td>UK336

- <td>
- 30.5.4
+<td>30.5.4

- <td>
- 
+<td>

- <td>
- Te
+<td>Te

- <td>
- It is possible
- to transfer ownership of the asynchronous result from one
- unique_future instance to another via the move-constructor.
- However, it is not possible to transfer it back, and nor is
- it possible to create a default-constructed unique_future
- instance to use as a later move target. This unduly limits
- the use of unique_future in code. Also, the lack of a
- move-assignment operator restricts the use of unique_future
- in containers such as std::vector - vector::insert requires
- move-assignable for example.
+<td>It is possible
+to transfer ownership of the asynchronous result from one
+unique_future instance to another via the move-constructor.
+However, it is not possible to transfer it back, and nor is
+it possible to create a default-constructed unique_future
+instance to use as a later move target. This unduly limits
+the use of unique_future in code. Also, the lack of a
+move-assignment operator restricts the use of unique_future
+in containers such as std::vector - vector::insert requires
+move-assignable for example.

- 
+<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>
- 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>Create an issue. Detlef will look into it.

- <td>
- 
+<tr valign="top">
+<td>JP80

- Create an issue. Detlef will look into it.<tr valign="top">
- <td>
- JP 80
+<td>30.5.4 , 
+30.5.5

- <td>
- 30.5.4 , 
- 30.5.5
+<td>

- <td>
- 
+<td>ed

- <td>
- ed
+<td>
+Typo, duplicated ">"

- <td>
- 
- Typo, duplicated ">"
+"class
+Period>>"

- "class
- Period>>"
+
+ 

- 
- 
+<td>
+Remove one

- <td>
- 
- Remove one
+<td>Pass on to editor.

- <td>
- 
+<tr valign="top">
+<td>UK337

- Pass on to editor.<tr valign="top">
- <td>
- UK 
- 337
+<td>30.5.5

- <td>
- 30.5.5
+<td>

- <td>
- 
+<td>Te

- <td>
- Te
+<td>shared_future
+should support an efficient move constructor that can avoid
+unnecessary manipulation of a reference count, much like
+shared_ptr

- <td>
- shared_future
- should support an efficient move constructor that can avoid
- unnecessary manipulation of a reference count, much like
- shared_ptr
+<td>Add a move constructor

- 
+<td>Create an issue. Detlef will look into it.

- <td>
- Add a move constructor
+<tr valign="top">
+<td>UK338

- <td>
- 
+<td>30.5.5

- Create an issue. Detlef will look into it.<tr valign="top">
- <td>
- UK 
- 338
+<td>

- <td>
- 30.5.5
+<td>Te

- <td>
- 
+<td>shared_future is currently
+CopyConstructible, but not CopyAssignable. This is
+inconsistent with shared_ptr, and will surprise users.
+Users will then write work-arounds to provide this
+behaviour. We should provide it simply and efficiently as
+part of shared_future. Note that since the shared_future
+member functions for accessing the state are all declared
+const, the original usage of an immutable shared_future
+value that can be freely copied by multiple threads can be
+retained by declaring such an instance as "const
+shared_future".

- <td>
- Te
+<td>Remove "=delete"
+from the copy-assignment operator of shared_future. Add a
+move-constructor shared_future(shared_future&&
+rhs), and a move-assignment operator shared_future&
+operator=(shared_future&& rhs). The postcondition
+for the copy-assignment operator is that *this has the same
+associated state as rhs. The postcondition for the
+move-constructor and move assignment is that *this has the
+same associated as rhs had before the
+constructor/assignment call and that rhs has no associated
+state.

- <td>
- shared_future is currently
- CopyConstructible, but not CopyAssignable. This is
- inconsistent with shared_ptr, and will surprise users.
- Users will then write work-arounds to provide this
- behaviour. We should provide it simply and efficiently as
- part of shared_future. Note that since the shared_future
- member functions for accessing the state are all declared
- const, the original usage of an immutable shared_future
- value that can be freely copied by multiple threads can be
- retained by declaring such an instance as "const
- shared_future".
+<td>Create an issue. Detlef will look into it.

- <td>
- Remove "=delete"
- from the copy-assignment operator of shared_future. Add a
- move-constructor shared_future(shared_future&&
- rhs), and a move-assignment operator shared_future&
- operator=(shared_future&& rhs). The postcondition
- for the copy-assignment operator is that *this has the same
- associated state as rhs. The postcondition for the
- move-constructor and move assignment is that *this has the
- same associated as rhs had before the
- constructor/assignment call and that rhs has no associated
- state.
+<tr valign="top">
+<td>UK339

- 
+<td>30.5.6

- <td>
- 
+<td>6, 7

- Create an issue. Detlef will look into it.<tr valign="top">
- <td>
- UK 
- 339
+<td>Te

- <td>
- 30.5.6
+<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>
- 6, 7
+<td>Strike 6. 7
+Postcondition: associated state of *this is the same as the
+associated state of rhs before the call. rhs has no
+associated state.

- <td>
- Te
+<td>Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.

- <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
+<tr valign="top">
+<td>UK340

- <td>
- Strike 6. 7
- Postcondition: associated state of *this is the same as the
- associated state of rhs before the call. rhs has no
- associated state.
+<td>30.5.6

- 
+<td>11, 12, 13

- <td>
- 
+<td>Te

- Create an issue. Move to review, attention: Howard. Proposed resolution is
- fine.<tr valign="top">
- <td>
- UK 
- 340
+<td>There is an
+implied postcondition that the state of the promise is
+transferred into the future leaving the promise with no
+associated state. It should be spelled out.

- <td>
- 30.5.6
+<td>Postcondition: *this has no associated
+state.

- <td>
- 11, 12, 13
+<td>Create an issue. Move to review, attention: Howard. Proposed resolution is
+ fine.

- <td>
- Te
+<tr valign="top">
+<td>UK341

- <td>
- There is an
- implied postcondition that the state of the promise is
- transferred into the future leaving the promise with no
- associated state. It should be spelled out.
+<td>30.5.6

- 
+<td>

- <td>
- Postcondition: *this has no associated
- state.
+<td>Te

- <td>
- 
+<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

- Create an issue. Move to review, attention: Howard. Proposed resolution is
- fine.<tr valign="top">
- <td>
- UK 
- 341
+<td>Change promise::swap to take an rvalue
+reference.

- <td>
- 30.5.6
+<td>Create an issue. Detlef will look into it. Probably ready as it.

- <td>
- 
+<tr valign="top">
+<td>UK342

- <td>
- Te
+<td>30.5.6

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

- <td>
- Change promise::swap to take an rvalue
- reference.
+<td>Te

- <td>
- 
+<td>std::promise is
+missing a non-member overload of swap. This is inconsistent
+with other types that provide a swap member function

- Create an issue. Detlef will look into it. Probably ready as it.<tr valign="top">
- <td>
- UK 
- 342
+<td>Add a non-member overload void
+swap(promise&& x,promise&& y){ x.swap(y); }

- <td>
- 30.5.6
+<td>Create an issue. Move to review, attention: Howard. Detlef will also look
+ into it.

- <td>
- 
+<tr valign="top">
+<td>UK343

- <td>
- Te
+<td>30.5.6

- <td>
- std::promise is
- missing a non-member overload of swap. This is inconsistent
- with other types that provide a swap member function
+<td>3

- 
+<td>Te

- <td>
- Add a non-member overload void
- swap(promise&& x,promise&& y){ x.swap(y); }
+<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>
- 
+<td>Remove the
+constructor with the signature template <class
+Allocator> promise(allocator_arg_t, const Allocator&
+a, promise& rhs);

- Create an issue. Move to review, attention: Howard. Detlef will also look
- into it.<tr valign="top">
- <td>
- UK 
- 343
+<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.

- <td>
- 30.5.6
+<tr valign="top">
+<td>JP81

- <td>
- 3
+<td>30.5.8

- <td>
- Te
+<td>

- <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>ed

- <td>
- Remove the
- constructor with the signature template <class
- Allocator> promise(allocator_arg_t, const Allocator&
- a, promise& rhs);
+<td>
+There are not requirements for F and a concept of Allocator
+dose not use.

- 
+<td>
+Correct as follows.

- <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>
- JP 81
+
+template <class F>

- <td>
- 30.5.8
+
+explicit packaged_task(F f);

- <td>
- 
+
+template <class F, class Allocator>

- <td>
- ed
+
+explicit packaged_task(allocator_arg_t, const
+Allocator& a, F f);

- <td>
- 
- There are not requirements for F and a concept of Allocator
- dose not use.
+
+template <class F>

- <td>
- 
- Correct as follows.
+
+explicit packaged_task(F&& f);

- 
- 
+
+template <class F, class Allocator>

- 
- template <class F>
+
+explicit packaged_task(allocator_arg_t, const
+Allocator& a, F&& f);

- 
- explicit packaged_task(F f);
+
+ 

- 
- template <class F, class Allocator>
+
+should be

- 
- explicit packaged_task(allocator_arg_t, const
- Allocator& a, F f);
+
+ 

- 
- template <class F>
+
+template <class F>

- 
- explicit packaged_task(F&& f);
+
+requires CopyConstructible<F> &&
+Callable<F, ArgTypes...>

- 
- template <class F, class Allocator>
+
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>

- 
- explicit packaged_task(allocator_arg_t, const
- Allocator& a, F&& f);
+
+explicit packaged_task(F f);

- 
-  
+
+ 

- 
- should be
+
+template <class F, Allocator Alloc>

- 
-  
+
+requires CopyConstructible<F> &&
+Callable<F, ArgTypes...>

- 
- template <class F>
+
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>

- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
+
+explicit packaged_task(allocator_arg_t, const
+Alloc& a, F f);

- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
+
+ 

- 
- explicit packaged_task(F f);
+
+template <class F>

- 
-  
+
+requires CopyConstructible<F> &&
+Callable<F, ArgTypes...>

- 
- template <class F, Allocator Alloc>
+
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>

- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
+
+explicit packaged_task(F&& f);

- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
+
+ 

- 
- explicit packaged_task(allocator_arg_t, const
- Alloc& a, F f);
+
+template <class F, Allocator Alloc>

- 
-  
+
+requires CopyConstructible<F> &&
+Callable<F, ArgTypes...>

- 
- template <class F>
+
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>

- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
+explicit
+packaged_task(allocator_arg_t, const Alloc& a,
+F&& f);

- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
+<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.

- 
- explicit packaged_task(F&& f);
+<tr valign="top">
+<td>DE23

- 
-  
+<td>Annex B

- 
- template <class F, Allocator Alloc>
+<td>p2

- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
+<td>te

- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
+<td>DE23 Recursive
+use of constexpr functions appears to be permitted. Since
+such functions may be required to be evaluated at
+compile-time, Annex B "implementation quantities" should
+specify a maximum depth of recursion.

- explicit
- packaged_task(allocator_arg_t, const Alloc& a,
- F&& f);
+<td>In Annex B, specify a recursion depth of 256 or a larger
+value.

- <td>
- 
+<td>Create issue, share with DE 25. See
+ N2826. Attention: core group.

- 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>
- DE-23
+<tr valign="top">
+<td>DE24

- <td>
- Annex B
+<td>Annex B

- <td>
- p2
+<td>p2

- <td>
- te
+<td>te

- <td>
- DE-23 Recursive
- use of constexpr functions appears to be permitted. Since
- such functions may be required to be evaluated at
- compile-time, Annex B "implementation quantities" should
- specify a maximum depth of recursion.
+<td>DE24 The
+number of placeholders for "bind" is implementation-defined
+in 20.7.12.1.4, but no minimum is suggested in Annex B. 

- <td>
- In Annex B, specify a recursion depth of 256 or a larger
- value.
+<td>Add a miminum of 10 placeholders to Annex B.

- <td>
- 
+<td>Create issue, proposed resolution as in comment. Attention: LWG subgroup 2.
+ Note the section in N2800 is actually 20.6.12.1.4 [func.bind.place].

- Create issue, share with DE 25. See
- N2826. Attention: core group.<tr valign="top">
- <td>
- DE-24
+<tr valign="top">
+<td>DE25

- <td>
- Annex B
+<td>Annex B

- <td>
- p2
+<td>p2

- <td>
- te
+<td>te

- <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>DE25
+Specifying a minimum of 17 recursively nested template
+instantiations is too small for practical purposes. The
+limit is too high to effectively limit compiler resource
+usage, see
+http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf
+. The conclusion is that the metric "number of recursively
+nested template instantiations" is inapposite.

- <td>
- Add a miminum of 10 placeholders to Annex B.
+<td>Remove the bullet "Recursively nested template
+instantiations [17]".

- <td>
- 
+<td>Create issue, share with DE 23. Attention: core group.

- Create issue, proposed resolution as in comment. Attention: LWG subgroup 2.
- Note the section in N2800 is actually 20.6.12.1.4 [func.bind.place].<tr valign="top">
- <td>
- DE-25
+<tr valign="top">
+<td>FR38

- <td>
- Annex B
+<td>C.2 
+[diffs. 
+library]

- <td>
- p2
+<td>1

- <td>
- te
+<td>ed

- <td>
- DE-25
- Specifying a minimum of 17 recursively nested template
- instantiations is too small for practical purposes. The
- limit is too high to effectively limit compiler resource
- usage, see
- http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf
- . The conclusion is that the metric "number of recursively
- nested template instantiations" is inapposite.
+<td>What is ISO/IEC 1990:9899/DAM
+1? My guess is that's a typo for ISO/IEC

- <td>
- Remove the bullet "Recursively nested template
- instantiations [17]".
+9899/Amd.1:1995 which I'd
+have expected to be referenced here (the tables

- <td>
- 
+make reference to things
+which were introduced by Amd.1).

- Create issue, share with DE 23. Attention: core group.<tr valign="top">
- <td>
- FR 38
+<td>One need probably a reference
+to the document which introduce char16_t and

- <td>
- C.2 
- [diffs. 
- library]
+char32_t in C (ISO/IEC TR 19769:2004?).

- <td>
- 1
-
- <td>
- ed
-
- <td>
- What is ISO/IEC 1990:9899/DAM
- 1? My guess is that's a typo for ISO/IEC
-
- 9899/Amd.1:1995 which I'd
- have expected to be referenced here (the tables
+<td>Create issue. Document in question should be C99, not C90+ammendment1. The
+ rest of the section requires careful review for completeness. Example <cstdint>
+ 18.3.1 [csdtint.sym]. Assign to C liasons.

- make reference to things
- which were introduced by Amd.1).
+<tr valign="top">
+<td>UK344

- <td>
- One need probably a reference
- to the document which introduce char16_t and
+<td>Appendix D

- char32_t in C (ISO/IEC TR 19769:2004?).
+<td>

- <td>
- 
+<td>Ge

- Create issue. Document in question should be C99, not C90+ammendment1. The
- rest of the section requires careful review for completeness. Example <cstdint>
- 18.3.1 [csdtint.sym]. Assign to C liasons.<tr valign="top">
- <td>
- UK 
- 344
-
- <td>
- Appendix D
-
- <td>
- 
-
- <td>
- Ge
-
- <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>
- 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>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>
- 
+<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.

- Deals with deprecation, needs to be discussed in general group. Attention:
+<td>Deals with deprecation, needs to be discussed in general group. Attention:
 Bill Plauger

 Update 2009-03-04: Mark as NAD. Compiler switches are outside the domain of
- the standard.<tr valign="top">
- <td>
- FR 39
+ the standard.

- <td>
- Index
+<tr valign="top">
+<td>FR39

- <td>
- 
+<td>Index

- <td>
- ed
+<td>

- <td>
- Some definitions seem not
- indexed (such as /trivially copyable/ or
+<td>ed

- /sequenced before/), indexing
- them would be useful (and marking specially the page -- say
- bold or italic -- which reference to the definition would
- increase the usefulness; having a separate index of all
- definitions is something which could also be considered).
+<td>Some definitions seem not
+indexed (such as /trivially copyable/ or

- <td>
- 
+/sequenced before/), indexing
+them would be useful (and marking specially the page -- say
+bold or italic -- which reference to the definition would
+increase the usefulness; having a separate index of all
+definitions is something which could also be considered).

- <td>
- 
+<td>

- Pass to the editor.</table><hr>
\ No newline at end of file
+<td> Pass to the editor.
+</table><hr>
\ No newline at end of file

Next message: aschoedl_at_[hidden]: "[Boost-commit] svn:boost r51684 - sandbox/partition_point/boost/partition_point"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51682 - sandbox/committee/LWG"

Date view	Thread view	Subject view	Author view

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