Boost-Commit :

Date view	Thread view	Subject view	Author view

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

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

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

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

Modified: sandbox/committee/LWG/0xCD1_Comments.html
==============================================================================
--- sandbox/committee/LWG/0xCD1_Comments.html (original)
+++ sandbox/committee/LWG/0xCD1_Comments.html 2009-03-03 08:30:05 EST (Tue, 03 Mar 2009)
@@ -1,6 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<meta name="generator" content=
"Microsoft FrontPage 5.0">
+<meta name="generator" content="Microsoft FrontPage 5.0">
<meta http-equiv="CONTENT-TYPE" content=
"text/html; charset=us-ascii">
<title>C++0x CD1 NB Comments</title>
@@ -26,66 +27,58 @@
cellspacing="0" style="border-collapse: collapse">
<tr valign="top">
<td>
-1
+1
<td>
-2
+2
<td>
-3
+3
<td>
-4
+4
<td>
-5
+5
<td>
-6
+6
<td>
-7
+7
<tr valign="top">
<td>
-MB1 
+MB1 
<td>
-Clause No./ 
+Clause No./ 
Subclause No./ 
-Annex (e.g. 3.1)
+Annex (e.g. 3.1)
<td>
-Paragraph/ 
-Figure/Table/Note (e.g. Table 1)
+Paragraph/ 
+Figure/Table/Note (e.g. Table 1)
<td>
-Type of com-ment2
+Type of com-ment2
<td>
-Comment (justification
-for change) by the MB
+Comment (justification
+for change) by the MB
<td>
-Proposed change by the
-MB
+Proposed change by the
+MB
<td>

-Disposition
+Disposition
 
<tr valign="top">
<td>
-FR 1
+FR 1
<td>
-General Comment
+General Comment
<td>
 
<td>
-ge
+ge
<td>
-Interactions between several new features
+Interactions between several new features
appear obscure, and very few examples are offered to guide
understanding of the formal text on interaction between these new
-additions.
-We worry about the complexity of the
-programming model so created.
+additions.
+We worry about the complexity of the
+programming model so created.
 
<td>
 
@@ -93,226 +86,204 @@
 
<tr valign="top">
<td>
-US 1
+US 1
<td>
-1-16
+1-16
<td>
 
<td>
-ge/te
+ge/te
<td>
-The active issues identified in WG21
+The active issues identified in WG21
N2803, C++ Standard Core Language Active Issues, must be addressed
-and appropriate action taken.
+and appropriate action taken.
 

-<a href=
-"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html></a>
+<a href=
+"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html>
 
<td>
-Appropriate action would include making
+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.
+to the CD, or deferring the issue to a later point in time.
 
<td>
 
<tr valign="top">
<td>
-CA-1
+CA-1
<td>
 
<td>
 
<td>
-Ge
+Ge
<td>
-There are quite a number
+There are quite a number
of defects for the current CD recorded in SC22/WG21-N2803 and
-N2806
+N2806
<td>
-Consider these comments
-and update ISO/IEC CD 14882 accordingly
+Consider these comments
+and update ISO/IEC CD 14882 accordingly
<td>
 
<tr valign="top">
<td>
-DE-1
+DE-1
<td>
-1 through 16
+1 through 16
<td>
 
<td>
-ge/te
+ge/te
<td>
-DE-1 Consider addressing a
+DE-1 Consider addressing a
significant part of the unresolved core language issues presented
in WG21 document N2791 "C++ Standard Core Language Active Issues,
Revision 59", available at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
-.
+.
<td>
 
<td>
 
<tr valign="top">
<td>
-CH 2
+CH 2
<td>
-all
+all
<td>
 
<td>
-te
+te
<td>
-The issues on the issues
-lists shall be addressed before the standard becomes final.
+The issues on the issues
+lists shall be addressed before the standard becomes final.
<td>
 
<td>
 
<tr valign="top">
<td>
-US 3
+US 3
<td>
-all
+all
<td>
 
<td>
-ed
+ed
<td>
-Latin abbreviations are
-presented incorrectly.
+Latin abbreviations are
+presented incorrectly.
<td>

-Italicize all Latin
+Italicize all Latin
abbreviations, append commas after each occurrence of i.e.
and e.g., and remove extraneous space after each such
-abbreviation.
+abbreviation.
 
<td>
 
<tr valign="top">
<td>
-FR 3
+FR 3
<td>
-1 [intro.scope]
+1 [intro.scope]
<td>
-2
+2
<td>
-ed
+ed
<td>
-C++ is split at the end of line.
+C++ is split at the end of line.
<td>
 
<td>
 
<tr valign="top">
<td>
-US 4
+US 4
<td>
-1.1
+1.1
<td>
-2
+2
<td>
-ed
+ed
<td>
-There is a bad line break in "C++".
+There is a bad line break in "C++".
<td>
 
<td>
 
<tr valign="top">
<td>
-UK 1
+UK 1
<td>
-1.1
+1.1
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-List of
+List of
additional facilities over C has been extended with this standard,
-so should be mentioned in the introductory material.
+so should be mentioned in the introductory material.
<td>
-Add the
+Add the
following to the list in 1.1p2: atomic operations concurrency
-alignment control user-defined literals attributes
+alignment control user-defined literals attributes
<td>
 
<tr valign="top">
<td>
-FR 4
+FR 4
<td>
-1.2 [intro.refs]
+1.2 [intro.refs]
<td>
-1
+1
<td>
-ed
+ed
<td>
-Is the lack of reference to ISO/CEI
-9899/AC3:2007 voluntary?
+Is the lack of reference to ISO/CEI
+9899/AC3:2007 voluntary?
<td>
 
<td>
 
<tr valign="top">
<td>
-UK 2
+UK 2
<td>
-1.2
+1.2
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-We recommend taking
+We recommend taking
the latest update to each listed standard, yet the C standard is
quite deliberately held back to the 1990 version without
-comment.+
+comment.+
 
<td>
-... not sure
-...
+... not sure
+...
<td>
 
<tr valign="top">
<td>
-UK 3
+UK 3
<td>
-1.3.1
+1.3.1
<td>
 
<td>
-Ed
+Ed
<td>
-The
+The
definition of an argument does not seem to cover many assumed use
-cases, and we believe that is not intentional.
+cases, and we believe that is not intentional.
<td>
-Revise the definition of argument to answer
+Revise the definition of argument to answer
question such as: Are lambda-captures arguments? Are type names in
a throw-spec arguments? 'Argument' to casts, typeid, alignof,
alignas, decltype and sizeof? why in x[arg] : arg is not an
@@ -322,249 +293,227 @@
template 'arguments'? what are 'default arguments'? can attributes
have arguments? what about concepts, requires clauses and
concept_map instantiations? What about user-defined literals where
-parens are not used?
+parens are not used?
 
<td>
 
<tr valign="top">
<td>
-UK 4
+UK 4
<td>
-1.3.3
+1.3.3
<td>
 
<td>
-Te
+Te
<td>
-This
+This
definition is essentially worthless, as it says nothing about what
distinguished a diagnostic message from other output messages
-provided by the implementation
+provided by the implementation
<td>
-... add something about the diagnostic message
+... add something about the diagnostic message
being a message issues by the implementation when translating a
-program that violates the rules of the standard. ...
+program that violates the rules of the standard. ...
 
<td>
 
<tr valign="top">
<td>
-FR 5
+FR 5
<td>
-1.3.4
-[defns.dynamic.type]
+1.3.4
+[defns.dynamic.type]
<td>
 
<td>
-te
+te
<td>
-"The dynamic type of an rvalue expression is
-its static type." Is this true with rvalue references?
+"The dynamic type of an rvalue expression is
+its static type." Is this true with rvalue references?
<td>
 
<td>
 
<tr valign="top">
<td>
-US 5
+US 5
<td>
-1.3.5
+1.3.5
<td>
 
<td>
-te
+te
<td>
-The wording is unclear as
+The wording is unclear as
to whether it is the input or the implementation "that is not a
-well-formed program".
+well-formed program".
<td>
-Reword to clarify that it
-is the input that is here considered not well-formed.
+Reword to clarify that it
+is the input that is here considered not well-formed.
<td>
 
<tr valign="top">
<td>
-FR 6
+FR 6
<td>
-1.3.6
-[defns.impl.defined]
+1.3.6
+[defns.impl.defined]
<td>
 
<td>
-ed
+ed
<td>
-There is a page break between the title and the
-paragraph.
+There is a page break between the title and the
+paragraph.
<td>
 
<td>
 
<tr valign="top">
<td>
-FR 7
+FR 7
<td>
-1.3.13
-[defns.undefined]
+1.3.13
+[defns.undefined]
<td>
 
<td>
-ed
+ed
<td>
-[intro.execution]/5 explicitly allows non
-causal undefined behaviour,
+[intro.execution]/5 explicitly allows non
+causal undefined behaviour,
<td>
-Adding it to the note outlying possible
-undefined behaviours.
+Adding it to the note outlying possible
+undefined behaviours.
<td>
 
<tr valign="top">
<td>
-US 6
+US 6
<td>
-1.3.14
+1.3.14
<td>
 
<td>
-ge
+ge
<td>
-Unspecified behavior does not clearly
+Unspecified behavior does not clearly
state whether or not undefined behavior is permitted. (The standard
says that "usually, the range of possible behaviors is delineated",
but what happens if the range is not delineated? Is a crash, or
-worse, allowed?)
+worse, allowed?)
 
<td>
-Clearly state whether or not Unspecified behavior
-includes undefined behavior.
+Clearly state whether or not Unspecified behavior
+includes undefined behavior.
<td>
 
<tr valign="top">
<td>
-FR 8
+FR 8
<td>
-1.4
-[intro.compliance]
+1.4
+[intro.compliance]
<td>
-8
+8
<td>
-ed
+ed
<td>
-The paragraph as its stands seems to require
+The paragraph as its stands seems to require
that violations of the ODR (which make a program ill-formed) are
required to be diagnosed if the program also uses an extension
-which defines some cases of ODR.
+which defines some cases of ODR.
<td>
 
<td>
 
<tr valign="top">
<td>
-UK 5
+UK 5
<td>
-1.5
+1.5
<td>
 
<td>
-Ge
+Ge
<td>
-Missing
+Missing
checklist of implementation defined behaviour (see ISO/IEC TR
-10176, 4.1.1p6)
+10176, 4.1.1p6)
<td>
-Provide a new
-annex with the missing checklist
+Provide a new
+annex with the missing checklist
<td>
 
<tr valign="top">
<td>
-UK 6
+UK 6
<td>
-1.5
+1.5
<td>
 
<td>
-Ge
+Ge
<td>
-Missing annex
+Missing annex
describing potential incompatibility to previous edition of the
-standard (see ISO/IEC TR 10176, 4.1.1p9)
+standard (see ISO/IEC TR 10176, 4.1.1p9)
<td>
-Provide a new
+Provide a new
annex with the missing documentation. See n2733(08-0243) for a
-starting point
+starting point
<td>
 
<tr valign="top">
<td>
-US 7
+US 7
<td>
-1.5
+1.5
<td>
-2
+2
<td>
-ed
+ed
<td>
-There is no mention of
-Clause 17.
+There is no mention of
+Clause 17.
<td>
-Include Clause 17 among
-the list of Clauses that specify the Standard Library.
+Include Clause 17 among
+the list of Clauses that specify the Standard Library.
<td>
 
<tr valign="top">
<td>
-US 8
+US 8
<td>
-1.5
+1.5
<td>
-2
+2
<td>
-te
+te
<td>

-The paragraph omits to
+The paragraph omits to
mention concepts and concept maps among its list of entities
-defined in the Standard Library.
+defined in the Standard Library.
 
<td>
-Mention concepts and
-concept maps among the list of entities.
+Mention concepts and
+concept maps among the list of entities.
<td>
 
<tr valign="top">
<td>
-US 9
+US 9
<td>
-1.6
+1.6
<td>
-1
+1
<td>
-ed
+ed
<td>
-The syntax description does not account
-for lines that wrap.
+The syntax description does not account
+for lines that wrap.
 
<td>
 
@@ -572,226 +521,216 @@
 
<tr valign="top">
<td>
-US 10
+US 10
<td>
-1.7
+1.7
<td>
-3
+3
<td>
-ed
+ed
<td>
-The term thread is used before defined.
+The term thread is used before defined.
<td>
-Reference
-1.10 [intro.multithread].
+Reference
+1.10 [intro.multithread].
<td>
 
<tr valign="top">
<td>
-US 11
+US 11
<td>
-1.7
+1.7
<td>
-¶ 3 last sent.
+¶ 3 last sent.
<td>
-ed
+ed
<td>
-The phrase “threads
+The phrase “threads
of execution” should be accompanied by a reference to
-[intro.multithread].
+[intro.multithread].
<td>
-Insert the recommended
-reference.
+Insert the recommended
+reference.
<td>
 
<tr valign="top">
<td>
-US 12
+US 12
<td>
-1.7
+1.7
<td>
-¶ 3 first
-sent.
+¶ 3 first
+sent.
<td>
-te
+te
<td>
-A memory location is not
-an object as the sentence claims.
+A memory location is not
+an object as the sentence claims.
<td>
-Clarify that a memory
+Clarify that a memory
location “holds” an object rather than that it
-“is” an object.
+“is” an object.
<td>
 
<tr valign="top">
<td>
-US 13
+US 13
<td>
-1.7
+1.7
<td>
-¶ 3 last sent.
+¶ 3 last sent.
<td>
-te
+te
<td>
-It is unclear what is
+It is unclear what is
meant by memory locations that are "separate": are they distinct?
-non-overlapping? how much "separation" is needed?
+non-overlapping? how much "separation" is needed?
<td>
-Provide either a better
+Provide either a better
definition of “separate” or reword (this and subsequent
-paragraphs) to avoid this term.
+paragraphs) to avoid this term.
<td>
 
<tr valign="top">
<td>
-US 14
+US 14
<td>
-1.7
+1.7
<td>
-¶ 4
+¶ 4
<td>
-te
+te
<td>
-The phrase "no matter what
+The phrase "no matter what
the sizes of the intervening bit-fields happen to be" contradicts
the claim of separation "by a zero-length bit-field
-declaration".
+declaration".
<td>
-Delete the “no
+Delete the “no
matter…” phrase, or resolve the contradiction in a
-different way.
+different way.
<td>
 
<tr valign="top">
<td>
-US 15
+US 15
<td>
-1.7
+1.7
<td>
-¶ 5
+¶ 5
<td>
-te
+te
<td>
-A struct does not
-“contain” memory locations.
+A struct does not
+“contain” memory locations.
<td>
-Reword so that a struct is
-“held in” one or more memory locations.
+Reword so that a struct is
+“held in” one or more memory locations.
<td>
 
<tr valign="top">
<td>
-US 16
+US 16
<td>
-1.9
+1.9
<td>
 
<td>
 
<td>
-The discussion of
+The discussion of
observable behavior in 1.9 is not consistent with the addition of
threads to the language. Volatile reads and writes and other
observable actions no longer occur in a single
-"sequence”.
+"sequence”.
<td>
-Remove/replace various
-occurrences of "sequence" in 1.9.
+Remove/replace various
+occurrences of "sequence" in 1.9.
<td>
 
<tr valign="top">
<td>
-UK 8
+UK 8
<td>
-1.9
+1.9
<td>
-5
+5
<td>
-Te
+Te
<td>
-With parallel
+With parallel
execution there is no longer the idea of a single execution
sequence for a program. Instead, a program may be considered a set
-of exectution sequences.
+of exectution sequences.
<td>
-Update first
+Update first
sentance as: A conforming implementation executing a well-formed
program shall produce the same observable behavior as one of the
possible SETS OF execution sequences of the corresponding instance
of the abstract machine CONFORMING TO THE MEMORY MODEL (1.10) with
-the same program and the same input.
+the same program and the same input.
<td>
 
<tr valign="top">
<td>
-UK 7
+UK 7
<td>
-1.9
+1.9
<td>
-6
+6
<td>
-Te
+Te
<td>
-Does the term
+Does the term
'sequence' imply all reads/writes through volatile memory much be
serialized, and cannot occur in parallel on truly parallel
hardware? Allow for multiple concurrent sequences where each
sequence is constrained by this observable behaviour rule, and
multiple sequences are constrained by the memory model and
-happens-before relationships defined in 1.10
+happens-before relationships defined in 1.10
<td>
-Replace
-'sequence' with 'sequences'.
+Replace
+'sequence' with 'sequences'.
<td>
 
<tr valign="top">
<td>
-FR 9
+FR 9
<td>
-1.9
-[intro.execution]
+1.9
+[intro.execution]
<td>
-16
+16
<td>
-ed
+ed
<td>
-This example use int *v while the other
-examples seems to use notation like int* v.
+This example use int *v while the other
+examples seems to use notation like int* v.
<td>
 
<td>
 
<tr valign="top">
<td>
-US 17
+US 17
<td>
-1.10
+1.10
<td>
-1
+1
<td>
-Ge
+Ge
<td>
-This definition of “thread” is poor,
+This definition of “thread” is poor,
and assumes the user already knows what multi-threaded means
(probably true!). In particular, it does not deal adequately with
-the concept that all threads share the same address space.
+the concept that all threads share the same address space.
<td>

-Replace first sentence of
-para 1 as follows:
+Replace first sentence of
+para 1 as follows:
Under a hosted implementation, a C++ program can
+"margin-top: 0.04in; margin-bottom: 0.04in">Under a hosted implementation, a C++ program can
have more than one thread of execution (a.k.a. thread) running
concurrently. Each thread is a single flow of control within a
program. Anything whose address may be determined by a thread,
@@ -799,99 +738,90 @@
new or by any dynamic allocator, directly addressable storage
obtained through implementation-defined functions, and automatic
variables, are accessible to all threads in the same
-program.
+program.
 
<td>
 
<tr valign="top">
<td>
-UK 9
+UK 9
<td>
-2.1
+2.1
<td>
-2,
-4
+2,
+4
<td>
-Te
+Te
<td>
-Undefined
+Undefined
behaviour is a drastic way to silently ignore minor issues. The
cases in this paragraph could be easily defined. In this case opt
for conditionally supported behaviour, which mandates a diagnostic
if the compiler is not prepared to handle the syntax
-consistently.
+consistently.
<td>
-Replace undefined behaviour with conditionally
+Replace undefined behaviour with conditionally
supported behavior. Conditional behaviour may be implementation
defined, although suggest there is a reasonable default in each
case. For creating a universal-character name, splice text to
create a universal-character. In the case of a file ending without
a newline, treat as if the newline was implictly added, with an
-empty line to follow if the last character was a back-slash.
+empty line to follow if the last character was a back-slash.
 
<td>
 
<tr valign="top">
<td>
-UK 10
+UK 10
<td>
-2.1
+2.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-Implementation defined seems unnecessarily
+Implementation defined seems unnecessarily
burdensome for negligible gain. I am yet to see code that depended
on whether non-empty sequences of whitespace were concatenated.
-Better left unspecified.
+Better left unspecified.
 
<td>
-How the
+How the
compiler treats non-empty sequences of whitespace should be left
-unspecified, rather than implementation-defined.
+unspecified, rather than implementation-defined.
<td>
 
<tr valign="top">
<td>
-FR 10
+FR 10
<td>
-2.1 [lex.phases]/5 and 2.2
-[lex.charset]/3
+2.1 [lex.phases]/5 and 2.2
+[lex.charset]/3
<td>
 
<td>
-te
+te
<td>
-[defns.multibyte] "the extended character
-set."
-[lex.charset]/3 cited below implies that
-there is an extended character set per locale.
-[lex.phases]/5 "Each [...]
+[defns.multibyte] "the extended character
+set."
+[lex.charset]/3 cited below implies that
+there is an extended character set per locale.
+[lex.phases]/5 "Each [...]
universal-character-name [...] is converted to the corresponding
-member of the execution character set"
-[lex.charset]/3 "The values of the members
+member of the execution character set"
+[lex.charset]/3 "The values of the members
of the execution character sets are implementation defined, and any
-additional members are locale-specific."
+additional members are locale-specific."
 
-Together they seem to imply that what is
+Together they seem to imply that what is
locale-specific is if a value is valid or not for the current
locale, not the representation of a given universal
-character.
+character.
 
-This is not the behaviour of at least some
+This is not the behaviour of at least some
compilers I've access to which are allowing different codes for the
same abstract character in different locale. During phase 5, they
-are using an implementation defined char set.
+are using an implementation defined char set.
 
 
<td>
@@ -901,492 +831,424 @@
<tr valign="top">
<td>
UK
-11
+"margin-right: -0.18in; margin-bottom: 0in">UK
+11
<td>
-2.3
+2.3
<td>
 
<td>
-Te
+Te
<td>
-Trigraphs are
+Trigraphs are
a complicated solution to an old problem, that cause more problems
than they solve in the modern environment. Unexpected trigraphs in
string literals and occasionally in comments can be very confusing
-for the non-expert.
+for the non-expert.
<td>
-Deprecate the
-whole of 2.3 and move it to appendix D.
+Deprecate the
+whole of 2.3 and move it to appendix D.
<td>
 
<tr valign="top">
<td>
UK
-12
+"margin-right: -0.18in; margin-bottom: 0in">UK
+12
<td>
-2.4,
-2.8
+2.4,
+2.8
<td>
-2
+2
<td>
-Te
+Te
<td>
-This undefined behaviour in token concatenation is
+This undefined behaviour in token concatenation is
worrying and we believe hard to justify. An implementation should
either support this in a defined way, or issue a diagnosic.
Documenting existing practice should not break existing
implementations, although unconditionally requiring a diagnostic
-would lead to more portable programs.
+would lead to more portable programs.
 
<td>
-Replace
+Replace
undefined behaviour with conditionally supported behaviour with
-implementation defined semantics.
+implementation defined semantics.
<td>
 
<tr valign="top">
<td>
-US 18
+US 18
<td>
-2.4
+2.4
<td>
-¶ 2
+¶ 2
<td>
-ed
+ed
<td>
-The paragraph begins with
-an empty line.
+The paragraph begins with
+an empty line.
<td>
-Delete the empty
-line.
+Delete the empty
+line.
<td>
 
<tr valign="top">
<td>
-FR 11
+FR 11
<td>
-2.4 [lex.pptokens]
+2.4 [lex.pptokens]
<td>
-3
+3
<td>
-ed
+ed
<td>
-There are spurious empty lines.
+There are spurious empty lines.
<td>
 
<td>
 
<tr valign="top">
<td>
-FR 12
+FR 12
<td>
-2.5 [lex.digraph] and 2.11
-[lex.key]/2
+2.5 [lex.digraph] and 2.11
+[lex.key]/2
<td>
 
<td>
-te
+te
<td>
-The alternative representations are reserved as
-such even in attribute. Is that what is wanted?
+The alternative representations are reserved as
+such even in attribute. Is that what is wanted?
<td>
 
<td>
 
<tr valign="top">
<td>
-FI 2
+FI 2
<td>
-2.5
+2.5
<td>
-Table 2
+Table 2
<td>
-te
+te
<td>
-Add eq, for spelling out
-== in order to distinguish it from the assignment operator.
+Add eq, for spelling out
+== in order to distinguish it from the assignment operator.
<td>
-See eq-keyword.doc,
-eq-keyword.ppt
+See eq-keyword.doc,
+eq-keyword.ppt
<td>
 
<tr valign="top">
<td>
UK
-13
+"margin-right: -0.18in; margin-bottom: 0in">UK
+13
<td>
-2.9
+2.9
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-This text is
+This text is
confusing in isolation, as it implies pp-numbers do not have a
value in translation phase 4 when evaluating #if preprocessor
-expressions.
+expressions.
<td>
-Add a note
+Add a note
with a cross-refernce to 16.1 that a pp-number may briefly acquire
a value during translation phase 4 while evaluating #if
-expressions.
+expressions.
<td>
 
<tr valign="top">
<td>
UK
-14
+"margin-right: -0.18in; margin-bottom: 0in">UK
+14
<td>
-2.11
+2.11
<td>
-table
-3
+table
+3
<td>
-Ed
+Ed
<td>
-The table is nearly sorted, but not quite. It was
-sorted in previous versions of the standard.
+The table is nearly sorted, but not quite. It was
+sorted in previous versions of the standard.
 
<td>
-Sort the
-table.
+Sort the
+table.
<td>
 
<tr valign="top">
<td>
-JP 1
+JP 1
<td>
-2.11
+2.11
<td>
-Table 3
+Table 3
<td>
-ed
+ed
<td>
-Keywords in the table are
+Keywords in the table are
listed disorderly. Also, a part of a frame of the table is not
-drawn.
+drawn.
<td>
-Sort it in alphabetical order. Complete the table
-frame.
+Sort it in alphabetical order. Complete the table
+frame.
<td>
 
<tr valign="top">
<td>
-US 19
+US 19
<td>
-2.13.1
+2.13.1
<td>
-Table 5, rows “l or
-L” and “ll or LL”
+Table 5, rows “l or
+L” and “ll or LL”
<td>
-te
+te
<td>
-The final entry in the
-last column (“unsigned long int”) is incorrect.
+The final entry in the
+last column (“unsigned long int”) is incorrect.
<td>
-Replace the incorrect
-entries by “unsigned long long int”.
+Replace the incorrect
+entries by “unsigned long long int”.
<td>
 
<tr valign="top">
<td>
-US 20
+US 20
<td>
-2.13.1, 2.13.3
+2.13.1, 2.13.3
<td>
 
<td>
-te
+te
<td>
-Long strings of digits in literals are a
+Long strings of digits in literals are a
continuing problem in the production and maintenance of
-programs.
+programs.
<td>
-Adopt the 1983 technology of Ada and use
-underscores to separate digits. Adopt the 1983 technology of Ada and use
+underscores to separate digits. <a href=
"http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2007%2Fn2281.html"
-target="_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html></a>
+target="_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html>
 
<td>
 
<tr valign="top">
<td>
UK
-15
+"margin-right: -0.18in; margin-bottom: 0in">UK
+15
<td>
-2.13.2
+2.13.2
<td>
-2
+2
<td>
-Te
+Te
<td>
-Inconsistency
+Inconsistency
between definition of a multicharacter literal and a wide character
-literal containing multiple c-chars.
+literal containing multiple c-chars.
<td>
-Define the term multicharacter wide literal for a
+Define the term multicharacter wide literal for a
wchar_t literal containing multiple elements, and specify its type
-is integer (or wider)
+is integer (or wider)
 
<td>
 
<tr valign="top">
<td>
UK
-16
+"margin-right: -0.18in; margin-bottom: 0in">UK
+16
<td>
-2.13.2
+2.13.2
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-Not
+Not
immediately clear why the question mark needs escaping. A note
-would help.
+would help.
<td>
-Add a note explaining that the ? character may
-need escaping to avoid accidentally creating a trigraph.
+Add a note explaining that the ? character may
+need escaping to avoid accidentally creating a trigraph.
 
<td>
 
<tr valign="top">
<td>
-JP 2
+JP 2
<td>
-2.13.4
+2.13.4
<td>
-1st paragraph, 2nd line
+1st paragraph, 2nd line
 
<td>
-ed
+ed
<td>
-Typo, R"..." should be R"[...]"
+Typo, R"..." should be R"[...]"
<td>
-Correct typo.
+Correct typo.
<td>
 
<tr valign="top">
<td>
-JP 3
+JP 3
<td>
-2.13.4
+2.13.4
<td>
-2nd paragraph
+2nd paragraph
<td>
-te
+te
<td>
-We think that the
-explanation of d-char-sequence is not enough.
+We think that the
+explanation of d-char-sequence is not enough.
<td>
-Add the following.
+Add the following.
<ol>
<li>
Add the following to the explanation of
-d-char-sequence, more easily to understand.</ol>
+"margin-bottom: 0in; widows: 0; orphans: 0">Add the following to the explanation of
+d-char-sequence, more easily to understand.</ol>
...prefix is a raw string literal.
+"margin-left: 0.67in; margin-bottom: 0in">...prefix is a raw string literal.
The d-char-sequence is used as delimiter.
+"margin-left: 0.67in; margin-bottom: 0in">The d-char-sequence is used as delimiter.
The terminating d-char-sequence of ...
+"margin-left: 0.67in; margin-bottom: 0in">The terminating d-char-sequence of ...
<ol start="2">
<li>
Add the following note that there are square
-brackets in r-char-sequence.</ol>
+"margin-bottom: 0in; widows: 0; orphans: 0">Add the following note that there are square
+brackets in r-char-sequence.</ol>
[Note:
+"margin-left: 0.67in; margin-bottom: 0in">[Note:
char foo[] = R”delimiter[[a-z]
+"margin-left: 0.83in; margin-bottom: 0in">char foo[] = R”delimiter[[a-z]
specifies a range which matches any lowercase letter from "a" to
-"z".]delimiter”;
+"z".]delimiter”;
 
the expression statement behaves exactly the same
-as
+"margin-left: 0.67in; margin-bottom: 0in">the expression statement behaves exactly the same
+as
 
char foo[]="[a-z] specifies a range which matches
-any lowercase letter from \"a\" to \"z\".";
+"margin-left: 0.83in; margin-bottom: 0in">char foo[]="[a-z] specifies a range which matches
+any lowercase letter from \"a\" to \"z\".";
- end note]
+"text-indent: 0.69in; margin-bottom: 0in">- end note]
 
<td>
 
<tr valign="top">
<td>
-JP 4
+JP 4
<td>
-2.13.4
+2.13.4
<td>
-3rd paragraph, 1st line of example
+3rd paragraph, 1st line of example
<td>
-ed
+ed
<td>
-Typo. Lack of a necessary backslash in
-the first line of the example as follows:
+Typo. Lack of a necessary backslash in
+the first line of the example as follows:
 
-const char *p = R"[a
-b
-c]";
+const char *p = R"[a
+b
+c]";
 
-should be
+should be
 
-const char *p = R"[a\
-b
-c]";
+const char *p = R"[a\
+b
+c]";
<td>
-Correct typo.
+Correct typo.
<td>
 
<tr valign="top">
<td>
-US 21
+US 21
<td>
-2.13.4
+2.13.4
<td>
-¶ 3
+¶ 3
<td>
-ed
+ed
<td>
-The paragraph, marked as a
-Note, contains an embedded example not marked as such.
+The paragraph, marked as a
+Note, contains an embedded example not marked as such.
<td>
-Denote the code (and
-perhaps also its commentary) as an Example.
+Denote the code (and
+perhaps also its commentary) as an Example.
<td>
 
<tr valign="top">
<td>
-US 22
+US 22
<td>
-2.13.4
+2.13.4
<td>
-¶ 3
+¶ 3
<td>
-te
+te
<td>
-The code does not have the
-effect predicted by its accompanying narrative.
+The code does not have the
+effect predicted by its accompanying narrative.
<td>
-Append a backslash to the
-first line of the code.
+Append a backslash to the
+first line of the code.
<td>
 
<tr valign="top">
<td>
-JP 5
+JP 5
<td>
-2.13.4
+2.13.4
<td>
-11th paragraph, Table 7
+11th paragraph, Table 7
 
<td>
-te
+te
<td>
-It is not explicit how to
-combine raw-string and non-raw-string.
+It is not explicit how to
+combine raw-string and non-raw-string.
<td>
-Add rules containing
-raw-string in the table 7.
+Add rules containing
+raw-string in the table 7.
<td>
 
<tr valign="top">
<td>
-FR 13
+FR 13
<td>
-2.13.4 [lex.string]
+2.13.4 [lex.string]
<td>
-3
+3
<td>
-ed
+ed
<td>
-Shouldn't the assert be
-assert(std::strcmp(p, "a\nb\nc") == 0);
+Shouldn't the assert be
+assert(std::strcmp(p, "a\nb\nc") == 0);
<td>
 
<td>
@@ -1394,19 +1256,16 @@
<tr valign="top">
<td>
UK
-17
+"margin-right: -0.18in; margin-bottom: 0in">UK
+17
<td>
-2.13.4
+2.13.4
<td>
-10
+10
<td>
-Te
+Te
<td>
-It would be preferred for attempts to modify
+It would be preferred for attempts to modify
string literals to be diagnosable errors. This is not possible due
to the deprecated implicit conversion to pointer to null-terminated
character sequence of non-const characters. If this deprecated
@@ -1414,30 +1273,27 @@
are always accessed through const types, and the compiler can
enforce the no modification rule. The only exception would be using
const_cast to cast away constness, but this is already covered
-under the const_cast rules so needs no further detail here.
+under the const_cast rules so needs no further detail here.
 
<td>
-(asssuming
+(asssuming
deprecated conversion to non-const array is removed or can be
-turned off) Strike the sentence on undefined behaviour.
+turned off) Strike the sentence on undefined behaviour.
<td>
 
<tr valign="top">
<td>
UK
-18
+"margin-right: -0.18in; margin-bottom: 0in">UK
+18
<td>
-2.13.4
+2.13.4
<td>
 
<td>
-Te
+Te
<td>
-The addition of static_assert (7p4) to the
+The addition of static_assert (7p4) to the
language raises the need to concatenate string representations of
integral constant expressions (typically from a sizeof or alignof
expression) with narrow string literals to provide an informative
@@ -1445,93 +1301,82 @@
expressions and especially not floating point values or formatting
flags. Likewise, the need is purely to support static_assert so
only narrow string literal support is required, although
-generalizing to other literal types would be useful.
+generalizing to other literal types would be useful.
 
<td>
-Define a
+Define a
syntax to support string-ization of integral constant expressions
in a form eligible for string literal concatenation, 2.13.4p6.
Suggested syntax: I" integral-constant-expression ". There is no
raw variant, although it could combine with type specifier in the
same way that the R prefix does, supporting u8I, uI, UI and
-LI.
+LI.
<td>
 
<tr valign="top">
<td>
UK
-19
+"margin-right: -0.18in; margin-bottom: 0in">UK
+19
<td>
-2.13.4
+2.13.4
<td>
 
<td>
-Ed
+Ed
<td>
-The grammar
+The grammar
for string literal is becoming unwieldy and could easily be
refactored into the type optional specifier and the string
-contents.
+contents.
<td>
-Refactor string-literal grammar as: (note -
+Refactor string-literal grammar as: (note -
current Drupal view loses formatting which is vital to clearly read
the grammar) string-literal: string-literal-type-specifierOPT
string-literal-body string-literal-type-specifier: one of u8 u U L
-string-literal-body: " s-char-sequenceOPT " R raw-string
+string-literal-body: " s-char-sequenceOPT " R raw-string
 
<td>
 
<tr valign="top">
<td>
-FR 14
+FR 14
<td>
-3 [basic]
+3 [basic]
<td>
-7
+7
<td>
-ed
+ed
<td>
-"In general it is necessary to determine
+"In general it is necessary to determine
whether a name denotes one of these entities before parsing the
-program that contains it."
+program that contains it."
<td>
-Would prefer
-"... before continuing to parse the
-program that contains it."
+Would prefer
+"... before continuing to parse the
+program that contains it."

-or even
-"... to complete the parsing of the
-program that contains it."
-as some names denotes entities declared after
-the first occurrence.
+or even
+"... to complete the parsing of the
+program that contains it."
+as some names denotes entities declared after
+the first occurrence.
<td>
 
<tr valign="top">
<td>
-FR 15
+FR 15
<td>
-3 [basic]
+3 [basic]
<td>
-8
+8
<td>
-ed
+ed
<td>
-/operator-function-id/,
+/operator-function-id/,
/conversion-function-id/, /template-id/ are followed by a space and
then a "s" while usually such production names aren't followed by a
-space when put in plural (see /identifier/).
+space when put in plural (see /identifier/).
 
<td>
 
@@ -1540,211 +1385,194 @@
<tr valign="top">
<td>
UK
-20
+"margin-right: -0.18in; margin-bottom: 0in">UK
+20
<td>
-3
+3
<td>
 
<td>
-Ge
+Ge
<td>
-Chapter 3 ("Basic concepts") provides common
+Chapter 3 ("Basic concepts") provides common
definitions used in the rest of the document. Now that we have
concepts as a primary feature, the title of this chapter can be
confusing as it does not refer to the language feature but to
-definitions used in the document.
+definitions used in the document.
 
<td>
-Change the
-title to "Basic definitions".
+Change the
+title to "Basic definitions".
<td>
 
<tr valign="top">
<td>
UK
-21
+"margin-right: -0.18in; margin-bottom: 0in">UK
+21
<td>
-3
+3
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-Concepts is
+Concepts is
now the name of a specific feature of the language, the term now
risks confusion and ambiguity when used in the more general
-sense.
+sense.
<td>
-Rename the
+Rename the
chapter Basic ???. THe note in p2 specifically needs similar
-rewording
+rewording
<td>
 
<tr valign="top">
<td>
UK
-22
+"margin-right: -0.18in; margin-bottom: 0in">UK
+22
<td>
-3
+3
<td>
-6
+6
<td>
-Te
+Te
<td>
-References are frequently considered variables,
-but this definition only applies to objects.
+References are frequently considered variables,
+but this definition only applies to objects.
 
<td>
-Add "or
-reference" after both uses of "object"
+Add "or
+reference" after both uses of "object"
<td>
 
<tr valign="top">
<td>
UK
-23
+"margin-right: -0.18in; margin-bottom: 0in">UK
+23
<td>
-3.1
+3.1
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-alias-declarations are not definitions and should
-be added to the list
+alias-declarations are not definitions and should
+be added to the list
 
<td>
-Add
-alias-declaration after typedef declaration.
+Add
+alias-declaration after typedef declaration.
<td>
 
<tr valign="top">
<td>
UK
-24
+"margin-right: -0.18in; margin-bottom: 0in">UK
+24
<td>
-3.1
+3.1
<td>
-2
+2
<td>
-Te
+Te
<td>
-The current words suggest the declaration of a
+The current words suggest the declaration of a
static integral constant data member of a class cannot be a
definition. Trying to fix this wording in-place will be verbose and
risk raising more confusion than it solves, so suggest a footnote
-to call out the special case
+to call out the special case
 
<td>
-Add a
+Add a
footnote attached to the static data membmer rule: *static data
member delcarations of intergral type may also be definitions if a
-constant integral expression is provided for an initializer.
+constant integral expression is provided for an initializer.
<td>
 
<tr valign="top">
<td>
UK
-25
+"margin-right: -0.18in; margin-bottom: 0in">UK
+25
<td>
-3.1
+3.1
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-Example is misleading as implicitly defined
+Example is misleading as implicitly defined
default constructor uses default initialization, not value
initialization, for non-static data members. In the case of
std::String this makes no difference, but it makes a big difference
-for fundamental types and pointers.
+for fundamental types and pointers.
 
<td>
-Remove the :
+Remove the :
s() from the illustrated default constructor: struct C {
std::string s; C() { } C(const C& x): s(x.s) { } C&
operator=(const C& x) { s = x.s; return *this; } ~C() { }
-};
+};
<td>
 
<tr valign="top">
<td>
UK
-26
+"margin-right: -0.18in; margin-bottom: 0in">UK
+26
<td>
-3.2
+3.2
<td>
-1
+1
<td>
-Te
+Te
<td>
-THe one definition rule should cover references,
+THe one definition rule should cover references,
and unless the term 'variable' is extended to cover references the
-list in this paragraph is incomplete.
+list in this paragraph is incomplete.
 
<td>
-Either
+Either
include references in the definition of 'variable' (see earlier
-comment) or add reference to the list in this paragraph.
+comment) or add reference to the list in this paragraph.
<td>
 
<tr valign="top">
<td>
UK
-27
+"margin-right: -0.18in; margin-bottom: 0in">UK
+27
<td>
-3.2
+3.2
<td>
-4
+4
<td>
-Ed
+Ed
<td>
-A class type must be complete when catching
-exceptions, even by reference or pointer. See 15.3.
+A class type must be complete when catching
+exceptions, even by reference or pointer. See 15.3.
 
<td>
-Add "when
-used in an exception-handler (15.3)" to the list.
+Add "when
+used in an exception-handler (15.3)" to the list.
<td>
 
<tr valign="top">
<td>
-FR 16
+FR 16
<td>
-3.3 [Declarative regions
-and scopes.]
+3.3 [Declarative regions
+and scopes.]
<td>
 
<td>
-te
+te
<td>
-The scope of function parameters is
-defined, but what is the scope of template parameters?
+The scope of function parameters is
+defined, but what is the scope of template parameters?
 
<td>
 
@@ -1753,72 +1581,63 @@
<tr valign="top">
<td>
UK
-28
+"margin-right: -0.18in; margin-bottom: 0in">UK
+28
<td>
-3.3.1
+3.3.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-Class templates are not classes, so we should
-include this case.
+Class templates are not classes, so we should
+include this case.
 
<td>
-ammend
-"class" to "class or class template"
+ammend
+"class" to "class or class template"
<td>
 
<tr valign="top">
<td>
UK
-29
+"margin-right: -0.18in; margin-bottom: 0in">UK
+29
<td>
-3.3.10
+3.3.10
<td>
-3
+3
<td>
-Te
+Te
<td>
-operators and
+operators and
conversion functions do not have names, yet are susceptible to
'name hiding' within a class - indeed we rely on this for the
-implicitly declared copy-assignment operator.
+implicitly declared copy-assignment operator.
<td>
-Add the additional phrase "The declaration of an
+Add the additional phrase "The declaration of an
operator or conversion function in a derived class (Clause 10)
hides the declaration of an operator or conversion function of a
-base class of the same operator or type;"
+base class of the same operator or type;"
 
<td>
 
<tr valign="top">
<td>
-FR 17
+FR 17
<td>
-3.5 [Program and
-linkage]
+3.5 [Program and
+linkage]
<td>
 
<td>
-te
+te
<td>
-This section does not specify whether
-concept names have linkage.
-Do they or not? If concept names do not
+This section does not specify whether
+concept names have linkage.
+Do they or not? If concept names do not
have linkage, then a note is appropriate, and that would be a bit
-surprising and curious. What is the rationale?
+surprising and curious. What is the rationale?
 
<td>
 
@@ -1826,63 +1645,58 @@
 
<tr valign="top">
<td>
-UK 
-30
+UK 
+30
<td>
-3.5
+3.5
<td>
-2
+2
<td>
-Te
+Te
<td>
-This
+This
paragraph implies concepts have no linkage (do they need it?) and
that the entities behind names without linkage cannot be used in
-other scopes. This maybe a bigger problem for concept maps?
+other scopes. This maybe a bigger problem for concept maps?
<td>
-Add a note to
-clarify that concepts don't need linkage.
+Add a note to
+clarify that concepts don't need linkage.
<td>
 
<tr valign="top">
<td>
-UK 
-31
+UK 
+31
<td>
-3.5
+3.5
<td>
-4
+4
<td>
-Te
+Te
<td>
-What is the
+What is the
linkage of names declared inside a namespace, in turn declared
inside an anonymous namespace? It is not clear why such a namespace
has no linkage, and there is no language suggesting its memmbers
should lose linkage with it, which we assume is the intended
-consequence.
+consequence.
<td>
-Clarify rules
+Clarify rules
for namespaces inside nested namespaces, or remove the
-restriction.
+restriction.
<td>
 
<tr valign="top">
<td>
-US 23
+US 23
<td>
-3.5
+3.5
<td>
-6
+6
<td>
-ed
+ed
<td>
-Bad paragraph break.
+Bad paragraph break.
 
<td>
 
@@ -1890,44 +1704,38 @@
 
<tr valign="top">
<td>
-FR 18
+FR 18
<td>
-3.5 [basic.link]
+3.5 [basic.link]
<td>
-6
+6
<td>
-ed
+ed
<td>
-The paragraph number is not aligned with the
-text.
+The paragraph number is not aligned with the
+text.
<td>
 
<td>
 
<tr valign="top">
<td>
-FR 19
+FR 19
<td>
-3.6 [Start and
-termination]
+3.6 [Start and
+termination]
<td>
 
<td>
-te
+te
<td>
-This section completely ignores the real
+This section completely ignores the real
world and practical case of dynamically linked or loaded libraries.
In current computing environments, they are ubiquitous and they
-cannot be ignored in
-practical C++ programs. The
-Standard
-should address this aspect.
+cannot be ignored in
+practical C++ programs. The
+Standard
+should address this aspect.
 
<td>
 
@@ -1935,207 +1743,177 @@
 
<tr valign="top">
<td>
-UK 
-32
+UK 
+32
<td>
-3.6.1
+3.6.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-Do we really
+Do we really
want to allow: constexpr int main() { return 0; } as a valid
-program?
+program?
<td>
-Add constexpr to the list of ill-formed things to
-annotate main
+Add constexpr to the list of ill-formed things to
+annotate main
 
<td>
 
<tr valign="top">
<td>
-US 24
+US 24
<td>
-3.6.1
+3.6.1
<td>
-4
+4
<td>
-te
+te
<td>
-std::quick_exit is not referenced.
+std::quick_exit is not referenced.
<td>
-Reference std::quick_exit as well as std::exit in
-saying that automatic objects are not destroyed. It should
-not
-do so in saying that calling
+Reference std::quick_exit as well as std::exit in
+saying that automatic objects are not destroyed. It should 
+not do so in saying that calling
std::quick_exit is undefined from within destructors for static or
-thread duration objects.
+thread duration objects.
 
<td>
 
<tr valign="top">
<td>
-US 25
+US 25
<td>
-3.6.3
+3.6.3
<td>
-¶ 2 last sent.
+¶ 2 last sent.
<td>
-ed
+ed
<td>
-The parenthesized phrase,
+The parenthesized phrase,
introduced via “i.e.” is in the nature of an
-example.
+example.
<td>
-Change “i.e.”
-to “e.g.”
+Change “i.e.”
+to “e.g.”
<td>
 
<tr valign="top">
<td>
-JP 6
+JP 6
<td>
-3.7.4.1
+3.7.4.1
<td>
-4th paragraph, 4th line
+4th paragraph, 4th line
<td>
-ed
+ed
<td>
-Typo.
-Lack of a comma right after
+Typo.
+Lack of a comma right after
“(3.7.2)” in the sentence while there are commas after
any other recitations like “(3.7.1)”. It is just a
-unification matter.
+unification matter.
 
-[ Note: in particular, a global
+[ Note: in particular, a global
allocation function is not called to allocate storage for objects
with static storage duration (3.7.1), for objects or references
with thread storage duration (3.7.2) for objects of type
std::type_info (5.2.8), or for the copy of an object thrown by a
-throw expression (15.1). -end note ]
+throw expression (15.1). -end note ]
 
should be
+"text-indent: 0.13in; margin-bottom: 0in">should be
 
-[ Note: in particular, a global
+[ Note: in particular, a global
allocation function is not called to allocate storage for objects
with static storage duration (3.7.1), for objects or references
with thread storage duration (3.7.2), for objects of type
std::type_info (5.2.8), or for the copy of an object thrown by a
-throw expression (15.1). -end note ]
+throw expression (15.1). -end note ]
 
<td>
-Correct typo.
+Correct typo.
<td>
 
<tr valign="top">
<td>
-DE-3
+DE-3
<td>
-3.7.4.3
+3.7.4.3
<td>
 
<td>
-te
+te
<td>

-DE-3 It is unclear whether
+DE-3 It is unclear whether
the following code has well-defined behavior; none of the bullets
-in the second paragraph seem to apply.
+in the second paragraph seem to apply.
int& i = *new
-int(5);
-delete &i;
+"margin-top: 0.04in; margin-bottom: 0.04in">int& i = *new
+int(5);
+delete &i;
<td>
-Clarify that &i is
-considered a safely-derived pointer value.
+Clarify that &i is
+considered a safely-derived pointer value.
<td>
 
<tr valign="top">
<td>
-US 26
+US 26
<td>
-3.8
+3.8
<td>
-1 and 5
+1 and 5
<td>
-te
+te
<td>
-Use of object fields during destruction is
-excessively and erroneously constrained.
+Use of object fields during destruction is
+excessively and erroneously constrained.
<td>
-See the attached document "Issues with
+See the attached document "Issues with
the C++ Standard" under Chapter 3 "Use of objects, especially from
-other threads, during destruction".
+other threads, during destruction".
 
<td>
 
<tr valign="top">
<td>
-US 27
+US 27
<td>
-3.9
+3.9
<td>
-¶ 9 first
-sent.
+¶ 9 first
+sent.
<td>
-ed
+ed
<td>
-There is a
-superfluous/extraneous “and”.
+There is a
+superfluous/extraneous “and”.
<td>
-Delete “and”
-from the phrase “and std::nullptr_t”.
+Delete “and”
+from the phrase “and std::nullptr_t”.
<td>
 
<tr valign="top">
<td>
-FR 20
+FR 20
<td>
-3.9 [Types]
+3.9 [Types]
<td>
 
<td>
-te
+te
<td>
-The phrase 'effective type' is defined and
+The phrase 'effective type' is defined and
used in a way that is incompatible with C99. Such a deliberate
incompatible choice of terminology is both unfortunate and
confusing, given past practice of the committee to maintain greater
compatibility with C99. We strongly suggest that the phrase
-'effective type' not be used in such an incompatible way.
+'effective type' not be used in such an incompatible way.
 
<td>
 
@@ -2143,509 +1921,405 @@
 
<tr valign="top">
<td>
-JP 7
+JP 7
<td>
-3.9.2
+3.9.2
<td>
-3rd paragraph, 13th line
+3rd paragraph, 13th line
<td>
-ed
+ed
<td>
-over-aligned type was
+over-aligned type was
added as new notion. So it is preferable to add the link after
-that.
+that.
<td>
-Add (3.11) after over-aligned type as
-the link.
-[ Note:
-pointers to over-aligned types(3.11) have no special representation, but their
+Add (3.11) after over-aligned type as
+the link.
+[ Note:
+pointers to over-aligned types(3.11) have no special representation, but their
range of valid values is restricted by the extended alignment
requirement. This International Standard specifies only two ways of
obtaining such a pointer: taking the address of a valid object with
-an over-aligned type(3.11), and using one of the runtime pointer alignment
+an over-aligned type(3.11), and using one of the runtime pointer alignment
functions. An implementation may provide other means of obtaining a
-valid pointer value for an over-aligned type(3.11).—end note ]
+valid pointer value for an over-aligned type(3.11).—end note ]
<td>
 
<tr valign="top">
<td>
-US 28
+US 28
<td>
-3.9.3
+3.9.3
<td>
-¶ 5 first
-sent.
+¶ 5 first
+sent.
<td>
-ed
+ed
<td>

-The closing braces of the
-first two sets are preceded by extraneous space.
+The closing braces of the
+first two sets are preceded by extraneous space.
 
<td>
-Delete the extra
-spaces.
+Delete the extra
+spaces.
<td>
 
<tr valign="top">
<td>
-DE 4
+DE 4
<td>
-4.2
+4.2
<td>
-p2
+p2
<td>
-te
+te
<td>
-DE-4 The deprecated
+DE-4 The deprecated
conversion from string literals to pointer to non-const character
types should be limited to those conversions and types of string
literals that were already present in ISO/IEC 14882:2003, or the
-deprecated conversions should be removed entirely.
+deprecated conversions should be removed entirely.
<td>

-Consider applying the
+Consider applying the
proposed resolution presented in core issue 693 in WG21 document
N2714 “C++ Standard Core Language Active Issues, Revision
58“, available at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2714.html
; or remove only the conversions to "pointer to char16_t", "pointer
-to char32_t" in 4.2 paragraph 2 and 15.1 paragraph 3.
+to char32_t" in 4.2 paragraph 2 and 15.1 paragraph 3.
 
<td>
 
<tr valign="top">
<td>
-CH 1
+CH 1
<td>
-4.9 and 5.2.9
+4.9 and 5.2.9
<td>
 
<td>
-te
+te
<td>
-With respect to the target
+With respect to the target
type, pointer to members should behave like normal pointers (least
-surprise principle).
+surprise principle).
<td>

-The standard should allow
-implicit conversions from ``pointer to member of <tt>T</tt> of type cv <tt>D</tt>'' to ``pointer to member of
-<tt>T</tt> of type cv
+The standard should allow
+implicit conversions from ``pointer to member of <tt>T</tt> of type cv <tt>D</tt>'' to ``pointer to member of
+<tt>T</tt> of type cv
B'', where D is of class type and B is a public base of D, It
-should allow explicit conversion the other way around.
+should allow explicit conversion the other way around.
 
<td>
 
<tr valign="top">
<td>
-DE-5
+DE-5
<td>
-4.11, 5.3.1, 5.5
+4.11, 5.3.1, 5.5
<td>
 
<td>
-te
+te
<td>
-DE-5 Ref-qualification has
-not been integrated with pointer-to-members.
+DE-5 Ref-qualification has
+not been integrated with pointer-to-members.
<td>

-Review implicit conversions
+Review implicit conversions
(4.11), forming pointer-to-members (5.3.1), and dereferencing
pointer-to-members (5.5) for type-safety concerns in the presence
-of ref-qualifiers on the member.
+of ref-qualifiers on the member.
 
<td>
 
<tr valign="top">
<td>
-UK 
-33
+UK 
+33
<td>
-4.13
+4.13
<td>
-1
+1
<td>
-Te
+Te
<td>
-We have: "No
+We have: "No
two signed integer types shall have the same rank ..." "the rank of
char shall equal the rank of signed char" Can we therefore deduce
-that char may not be signed?
+that char may not be signed?
<td>
-Replace the first sentence with "No two signed
+Replace the first sentence with "No two signed
integer types shall have the same rank, even if they have the same
representation, except that signed char shall have the same rank as
-char even if char is signed (3.9.1/1)."
+char even if char is signed (3.9.1/1)."
 
<td>
 
<tr valign="top">
<td>
-UK 
-34
+UK 
+34
<td>
-4.13
+4.13
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-6th bullet, "the rank of char" - first letter
-should be capitalised for consistency with the other bullets
+6th bullet, "the rank of char" - first letter
+should be capitalised for consistency with the other bullets
 
<td>
-The rank of
-char
+The rank of
+char
<td>
 
<tr valign="top">
<td>
-UK 
-36
+UK 
+36
<td>
-5.1
+5.1
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-Primary expressions are literals, names, names
+Primary expressions are literals, names, names
qualified by the scope resolution operator ::, and lambda
expressions. The immediately following grammar flatly contradicts
-this - this and (e) are also lambda expressions.
+this - this and (e) are also lambda expressions.
 
<td>
-Delete this
-paragraph.
+Delete this
+paragraph.
<td>
 
<tr valign="top">
<td>
-UK 
-37
+UK 
+37
<td>
-5.1
+5.1
<td>
-11
+11
<td>
-Ed
+Ed
<td>
-Member function templates are not member
-functions, so should also be listed in the 3rd bullet
+Member function templates are not member
+functions, so should also be listed in the 3rd bullet
 
<td>
-Add member
-function templates to the 3rd bullet
+Add member
+function templates to the 3rd bullet
<td>
 
<tr valign="top">
<td>
-UK 
-38
+UK 
+38
<td>
-5.1
+5.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-this might be
+this might be
useful in a few more places than it is permitted, specifically in
decltype expressions within a class. Two examples that would be
ill-formed at class scope without changes: typedef decltype( *this
) this_type; decltype( [this]{ return this->memfun(); } )
-my_lambda;
+my_lambda;
<td>
-... words to
-follow ...
+... words to
+follow ...
<td>
 
<tr valign="top">
<td>
-JP 8
+JP 8
<td>
-5.1
+5.1
<td>
-7th paragraph, Syntax rules
+7th paragraph, Syntax rules
<td>
-te
+te
<td>
-In the current syntax definition, a
+In the current syntax definition, a
scope operator(::) cannot be applied to decltype, but it should be.
It would be useful in the case to obtain member type(nested-type)
-from an instance as follows:
-vector<int> v;
-decltype(v)::value_type i = 0; // int i =
-0;
-<td>
-Add “decltype ( expression ) ::
-“ to nested-name-specifier syntax like below.
- 
-nested-name-specifier:
-type-name ::
-namespace-name ::
-nested-name-specifier identifier ::
-nested-name-specifier templateopt
-simple-template-id ::
+from an instance as follows:
+vector<int> v;
+decltype(v)::value_type i = 0; // int i =
+0;
+<td>
+Add “decltype ( expression ) ::
+“ to nested-name-specifier syntax like below.
+ 
+nested-name-specifier:
+type-name ::
+namespace-name ::
+nested-name-specifier identifier ::
nested-name-specifieropt concept-id ::
+"text-indent: 0.13in; margin-bottom: 0in">nested-name-specifier templateopt
+simple-template-id ::
decltype ( expression ) ::
+"text-indent: 0.13in; margin-bottom: 0in">nested-name-specifieropt concept-id ::
+decltype ( expression ) ::
 
<td>
 
<tr valign="top">
<td>
-JP 9
+JP 9
<td>
-5.1.1
+5.1.1
<td>
 
<td>
-te
+te
<td>
-It would be preferable that
+It would be preferable that
“&&” could be specified in a lambda expression
-to declare move capture.
+to declare move capture.
 
-Here is an example from N2709.
+Here is an example from N2709.
 
-template<typename F>
-std::unique_future<typename
-std::result_of<F()>::type> spawn_task(F f){
-typedef typename
-std::result_of<F()>::type result_type;
- 
-struct local_task {
-std::promise<result_type>
-promise;
-F func;
-local_task(local_task const&
-other)=delete;
-local_task(F func_):
-func(func_)
-{}
- 
-local_task(local_task&&
-other):
-promise(std::move(other.promise)),
-f(std::move(other.f))
-{}
- 
-void operator() {
-try
-{
-promise.set_value(f());
-}
-catch(...)
-{
-promise.set_exception(std::current_exception());
-}
-}
-};
- 
-local_task task(std::move(f));
- 
-std::unique_future<result_type>
-res(task.promise.get_future());
-std::thread(std::move(task));
-return res;
-}
- 
-This can be rewritten simply as follows
-if move capture can be used in a lambda expression.
- 
-template<typename F>
-std::unique_future<typename
-std::result_of<F()>::type> spawn_task(F f){
-typedef typename
-std::result_of<F()>::type result_type;
- 
-std::promise<result_type>
-promise;
-std::unique_future<result_type>
-res(promise.get_future());
-std::thread([&&promise,
-&&f]() {
-try
-{
-promise.set_value(f());
-}
-catch(...)
-{
-promise.set_exception(std::current_exception());
-}
-});
-return res;
-}
- 
-<td>
-Add move capture in a lambda
-expression.
+template<typename F>
+std::unique_future<typename
+std::result_of<F()>::type> spawn_task(F f){
+typedef typename
+std::result_of<F()>::type result_type;
+ 
+struct local_task {
+std::promise<result_type>
+promise;
+F func;
+local_task(local_task const&
+other)=delete;
+local_task(F func_):
+func(func_)
+{}
+ 
+local_task(local_task&&
+other):
+promise(std::move(other.promise)),
+f(std::move(other.f))
+{}
+ 
+void operator() {
+try
+{
+promise.set_value(f());
+}
+catch(...)
+{
+promise.set_exception(std::current_exception());
+}
+}
+};
+ 
+local_task task(std::move(f));
+ 
+std::unique_future<result_type>
+res(task.promise.get_future());
+std::thread(std::move(task));
+return res;
+}
+ 
+This can be rewritten simply as follows
+if move capture can be used in a lambda expression.
+ 
+template<typename F>
+std::unique_future<typename
+std::result_of<F()>::type> spawn_task(F f){
+typedef typename
+std::result_of<F()>::type result_type;
+ 
+std::promise<result_type>
+promise;
+std::unique_future<result_type>
+res(promise.get_future());
+std::thread([&&promise,
+&&f]() {
+try
+{
+promise.set_value(f());
+}
+catch(...)
+{
+promise.set_exception(std::current_exception());
+}
+});
+return res;
+}
+ 
+<td>
+Add move capture in a lambda
+expression.
 
<td>
 
<tr valign="top">
<td>
-JP 10
-<td>
-5.1.1
+JP 10
+<td>
+5.1.1
<td>
 
<td>
-te
+te
<td>
-In the current syntax definition, a
+In the current syntax definition, a
returned type of a function object cannot be obtained by using
result_of from an unnamed function object generated by a lambda
-expression because it doesn’t have result type.
+expression because it doesn’t have result type.
 
-template <class F>
-void foo(F f)
-{
-typedef std::result_of<F()>::type
-result; // error
-}
-foo([]{});
+template <class F>
+void foo(F f)
+{
+typedef std::result_of<F()>::type
+result; // error
+}
+foo([]{});
 
If “Callable” or
+"margin-left: 0in; margin-bottom: 0in">If “Callable” or
“Predicate” concept is specified, a returned type can
be obtained from a function object without result_type. But it is
-preferable to be able to obtain it with template.
+preferable to be able to obtain it with template.
 
<td>
-Add result_type to the syntax of an
-unnamed function object generated by a lambda expression.
+Add result_type to the syntax of an
+unnamed function object generated by a lambda expression.
 
<td>
 
<tr valign="top">
<td>
-US 29
+US 29
<td>
-5.1.1
+5.1.1
<td>
 
<td>
-te
+te
<td>
-The standard does not state whether or
-not direct recursion of lambdas is possible.
+The standard does not state whether or
+not direct recursion of lambdas is possible.
 
<td>
 
@@ -2653,23 +2327,18 @@
 
<tr valign="top">
<td>
-US 30
+US 30
<td>
-5.1.1
+5.1.1
<td>
 
<td>
-te
+te
<td>
-The standard does not clarify the meaning of
-<code>this</code> in lambdas. Does it mean
+The standard does not clarify the meaning of 
+<code>this</code> in lambdas. Does it mean
this lambda, or this class within which the lambda is
nested?
 
@@ -2679,23 +2348,19 @@
 
<tr valign="top">
<td>
-US 31
+US 31
<td>
-5.1.1
+5.1.1
<td>
 
<td>
-te
+te
<td>
-The current wording does not specify how context
-capturing and name resolution take place when the inner lambda refers to the
-outer lambda's locals variables and parameters.
+capturing and name resolution take place when the inner lambda refers to the
+outer lambda's locals variables and parameters.
 
<td>
 
@@ -2703,25 +2368,23 @@
 
<tr valign="top">
<td>
-UK 
-45
+UK 
+45
<td>
-5.1.1
+5.1.1
<td>
-para
-2
+para
+2
<td>
-Te
+Te
<td>
-Lambda is a
+Lambda is a
language feature with an apparent dependency on <functional>.
This increases dependency of language on library, and is
inconsistent with the definition of freestanding in
-17.6.2.4.
+17.6.2.4.
<td>
-Change the text "a closure object behaves as a
+Change the text "a closure object behaves as a
function object" to "a closure object is a built-in object which
behaves as a function object"; and after "context.", insert " A
closure object may be used without any need for
@@ -2729,28 +2392,23 @@
namely that lambdas can be used in freestanding implementations and
don't increase dependency of language on library. (Marked as
technical comment anyway because this clarity is technically
-important).
+important).
 
<td>
 
<tr valign="top">
<td>
-US 32
+US 32
 
<td>
-5.1.1
+5.1.1
<td>
-3
+3
<td>
-ed
+ed
<td>
-The final italic "this" in the paragraph
-should be a teletype "this".
+The final italic "this" in the paragraph
+should be a teletype "this".
 
<td>
 
@@ -2758,39 +2416,36 @@
 
<tr valign="top">
<td>
-UK 
-39
+UK 
+39
<td>
-5.1.1
+5.1.1
<td>
-11
+11
<td>
-Te
+Te
<td>
-This
+This
paragraph lists all the special member functions for the class
representing a lambda. But it omits the destructor, which is
-awkward.
+awkward.
<td>
-Add "F has an
-implicitly-declared destructor".
+Add "F has an
+implicitly-declared destructor".
<td>
 
<tr valign="top">
<td>
-UK 
-40
+UK 
+40
<td>
-5.1.1
+5.1.1
<td>
-12
+12
<td>
-Te
+Te
<td>
-If one or more names in the effective capture set
+If one or more names in the effective capture set
are preceded by &, the effect of invoking a closure object or a
copy after the innermost block scope of the context of the lambda
expression has been exited is undefined. That is too restrictive.
@@ -2798,697 +2453,650 @@
variables referenced has ended. This should be safe and legal;
currently it has undefined behaviour: int i;
reference_closure<void ()> f; if (blah) { f = [&i]() { };
-} if (f) f();
+} if (f) f();
 
<td>
-If one or
+If one or
more names in the effective capture set are preceded by &, the
effect of invoking a closure object or a copy after the lifetime of
-any of the variables referenced has ended is undefined.
+any of the variables referenced has ended is undefined.
<td>
 
<tr valign="top">
<td>
-UK 
-41
+UK 
+41
<td>
-5.1.1
+5.1.1
<td>
-12
+12
<td>
-Te
+Te
<td>
-For argument
+For argument
dependant lookup (3.4.2) the associated namespaces for a class
include its bases, and associated namespaces of its bases.
Requiring the result of a lambda expression *to dervide from*
std::reference_closure means that ADL will look in namespace std
when the lambda capture is entirely by reference, which might have
surprising results. Also, relying on the idea of implicitly slicing
-objects is uncomfortable.
+objects is uncomfortable.
<td>
-Replace
-inheritance with implicit conversion.
+Replace
+inheritance with implicit conversion.
<td>
 
<tr valign="top">
<td>
-UK 
-42
+UK 
+42
<td>
-5.1.1
+5.1.1
<td>
 
<td>
-Te
+Te
<td>
-A lambda with
+A lambda with
an empty capture list has identical semantics to a regular function
type. By requiring this mapping we get an efficient lambda type
with a known API that is also compatible with existing operating
-system and C library functions.
+system and C library functions.
<td>
-Add a new paragraph: "A lambda expression with an
+Add a new paragraph: "A lambda expression with an
empty capture set shall be convertible to pointer to function type
R(P), where R is the return type and P is the parameter-type-list
of the lambda expression." Additionally it might be good to (a)
allow conversion to function reference (b) allow extern "C"
-function pointer types
+function pointer types
 
<td>
 
<tr valign="top">
<td>
-UK 
-43
+UK 
+43
<td>
-5.1.1
+5.1.1
<td>
-12
+12
<td>
-Te
+Te
<td>
-The note spells out the intent that objects from
+The note spells out the intent that objects from
lambda-expressions with an effective capture list of references
should be implemented as a pair of pointers. However, nothing in
the rest of 5.1.1 lifts the requirement of to declare a reference
member for each captured name, and a non-normative note is not
-enough to relax that.
+enough to relax that.
 
<td>
-... provvide
-exceptions in the right places ...
+... provvide
+exceptions in the right places ...
<td>
 
<tr valign="top">
<td>
-UK 
-44
+UK 
+44
<td>
-5.1.1
+5.1.1
<td>
-12
+12
<td>
-Te
+Te
<td>
-There is a strong similarity between a [&]{}
+There is a strong similarity between a [&]{}
lambda capturing a stack frame, and a [this]{} lambda binding a
member function to a class instance. The reference_closure
requirement should be extended to the second case, although we need
some syntax to create such an object that is distinct from the
existing pointer-to-member syntax. This would be a cleaner
-alternative to the new std::mem_fn library component.
+alternative to the new std::mem_fn library component.
 
<td>
-Extend
+Extend
reference_closure requirement to cover [this] lambdas. Consider a
-simple syntax for creating such bound expressions.
+simple syntax for creating such bound expressions.
<td>
 
<tr valign="top">
<td>
-UK 
-46
+UK 
+46
<td>
-5.1.1
+5.1.1
<td>
-para
-12
+para
+12
<td>
-Te
+Te
<td>
-The
+The
requirement that a lambda meeting appropriate conditions be an
object derived from reference_closure makes lambda the language
feature dependent on <functional>, which increases dependency
of the language on the library and bloats the definition of
-freestanding C++.
+freestanding C++.
<td>
-Replace text "is publicly derived from" with
+Replace text "is publicly derived from" with
"shall be implemented in a manner indistinguishable from". This
places an ABI constraint on reference closures such that compiler
and library implementer have to do compatible things. But it cuts
-the dependency of lambda syntax on <functional>.
+the dependency of lambda syntax on <functional>.
 
<td>
 
<tr valign="top">
<td>
-DE-6
+DE-6
<td>
-5.1.1, 20.7.18
+5.1.1, 20.7.18
<td>
 
<td>
-te
+te
<td>
-DE-6 Some uses of lambda
+DE-6 Some uses of lambda
expressions refer to specializations of the unconstrained class
-template std::reference_closure (5.1.1). If the
+template std::reference_closure (5.1.1). If the
lambda expression appears in a constrained context and the return
type or a parameter type for the lambda depend on a template
-parameter (see 14.10), such a use is ill-formed.
+parameter (see 14.10), such a use is ill-formed.
<td>
-In 20.7.18, for the class
-template std::reference_closure, require
-Returnable for R and VariableType for each of the ArgTypes.
+In 20.7.18, for the class
+template std::reference_closure, require Returnable for R and VariableType for each of the ArgTypes.
<td>
 
<tr valign="top">
<td>
-DE-7
+DE-7
<td>
-5.1.1
+5.1.1
<td>
-p10
+p10
<td>
-ed
+ed
<td>
-DE-7 The note at the end
-of paragraph 10 appears to be garbled.
+DE-7 The note at the end
+of paragraph 10 appears to be garbled.
<td>
-Remove "or references" in
-the note.
+Remove "or references" in
+the note.
<td>
 
<tr valign="top">
<td>
-DE-8
+DE-8
<td>
-5.1.1
+5.1.1
<td>
-p10
+p10
<td>
-te
+te
<td>
-DE-8 The construction of
+DE-8 The construction of
the function call operator signature is missing specifications for
-the ref-qualifier and the attribute-specifier.
+the ref-qualifier and the attribute-specifier.
<td>
-Add bullets that say that
-the ref-qualifier and the attribute-specifier are absent.
+Add bullets that say that
+the ref-qualifier and the attribute-specifier are absent.
<td>
 
<tr valign="top">
<td>
-US 33
+US 33
<td>
-5.1.1
+5.1.1
<td>
-11
+11
<td>
-Ge
+Ge
<td>
-There is no definition of
+There is no definition of
“move constructor” or “move
-operation”
+operation”
<td>

-Since this is the first place
+Since this is the first place
the terms are used, a definition should either be added here, or a
-cross reference to one.
+cross reference to one.
 
<td>
 
<tr valign="top">
<td>
-DE-9
+DE-9
<td>
-5.1.1
+5.1.1
<td>
 
<td>
-te
+te
<td>
-DE-9 There is not a single
+DE-9 There is not a single
example of a lambda-expression in the standard. See also core issue
720 in WG21 document N2791 "C++ Standard Core Language Active
Issues, Revision 59", available at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
-.
+.
<td>
-Add a few well-chosen
-examples.
+Add a few well-chosen
+examples.
<td>
 
<tr valign="top">
<td>
-UK 
-52
+UK 
+52
<td>
-5.2
+5.2
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-This
+This
paragraph seens out of place, assignment expressions are covered in
-5.17
+5.17
<td>
-Move p3 to
-subsection 5.17
+Move p3 to
+subsection 5.17
<td>
 
<tr valign="top">
<td>
-UK 
-53
+UK 
+53
<td>
-5.2.1
+5.2.1
<td>
 
<td>
-Te
+Te
<td>
-The
+The
definition in p1 makes no allowance for overloaded operator[] that
treats the expression as a simple function call, and does not
support the interchangability of arguments. Howver p2 relies on
this definition when describing the use of brace-init-lists inside
-[].
+[].
<td>
-Insert a new
+Insert a new
p2 describing the changed semantics for overloaded operator[]. This
should be a note to avoid introducing normative text that could
potentially conflict with the later definiton of these
-semantics.
+semantics.
<td>
 
<tr valign="top">
<td>
-UK 
-59
+UK 
+59
<td>
-5.2.2
+5.2.2
<td>
-7
+7
<td>
-Te
+Te
<td>
-When there is
+When there is
no parameter for a given argument, the argument is passed in such a
way that the receiving function can obtain the value of the
argument by invoking va_arg. That shouldn't apply to parameter
packs. template <class ... Types> void f(Types ... pack);
-f(1, 2, 3);
+f(1, 2, 3);
<td>
-Clarify that
-this sentence only applies where the ellipsis is used.
+Clarify that
+this sentence only applies where the ellipsis is used.
<td>
 
<tr valign="top">
<td>
-UK 
-60
+UK 
+60
<td>
-5.2.5
+5.2.5
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-In the
+In the
remainder of 5.2.5, cq represents either const or the absence of
const vq represents either volatile or the absence of
-volatile.
+volatile.
<td>
-Add "and"
-before vq
+Add "and"
+before vq
<td>
 
<tr valign="top">
<td>
-UK 
-61
+UK 
+61
<td>
-5.2.5
+5.2.5
<td>
-p1
+p1
<td>
-Ed
+Ed
<td>
-Together with
+Together with
footnote 60 there may be confusion that the postfix expression is
always evaluated - even when part of an unevaluated operand. We
believe the standard does not require this, and a comment in the
-existing note would be a useful clarification.
+existing note would be a useful clarification.
<td>
-Clarify in
+Clarify in
footnote 60 that this will not happen if the whole expression is an
-unevaluated operand.
+unevaluated operand.
<td>
 
<tr valign="top">
<td>
-UK 
-62
+UK 
+62
<td>
-5.2.5
+5.2.5
<td>
-4
+4
<td>
-Te
+Te
<td>
-In the final
+In the final
bullet, what does 'not an lvalue' mean? Does it imply rvalue, or
are there other possible meanings? Should clauses that trigger on
-rvalues pick up on this?
+rvalues pick up on this?
<td>
-Replace 'not
-an lvalue' with 'is an rvalue'.
+Replace 'not
+an lvalue' with 'is an rvalue'.
<td>
 
<tr valign="top">
<td>
-DE-10
+DE-10
<td>
-5.2.5
+5.2.5
<td>
 
<td>
-te
+te
<td>
-DE-10 If E1.E2 is
+DE-10 If E1.E2 is
referring to a non-static member function, the potential
-ref-qualification on E2 should be taken into account.
+ref-qualification on E2 should be taken into account.
<td>
-Adjust the presentation of
-the types involved as appropriate.
+Adjust the presentation of
+the types involved as appropriate.
<td>
 
<tr valign="top">
<td>
-UK 
-63
+UK 
+63
<td>
-5.2.6
+5.2.6
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-Paragraph 2
-is missing its number.
+Paragraph 2
+is missing its number.
<td>
-Add
-one.
+Add
+one.
<td>
 
<tr valign="top">
<td>
-UK 
-64
+UK 
+64
<td>
-5.2.7
+5.2.7
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-A new name R
+A new name R
is introduced for use in paragraphs 3 and 4. But R is the same as
-T.
+T.
<td>
-Replace R with T and replace "the required result
+Replace R with T and replace "the required result
type (which, for convenience, will be called R in this
-description)" with "T".
+description)" with "T".
 
<td>
 
<tr valign="top">
<td>
-UK 
-65
+UK 
+65
<td>
-5.2.7
+5.2.7
<td>
-8
+8
<td>
-Te
+Te
<td>
-In the first two bullets we have "the result is a
+In the first two bullets we have "the result is a
pointer (an lvalue referring) to". But para 2 makes clear that a
dynamic_cast of an rvalue references produces a rvalue. (Can an
-lvalue refer to anything anyway?)
+lvalue refer to anything anyway?)
 
<td>
-Replace "an
-lvalue referring to" with "reference", twice.
+Replace "an
+lvalue referring to" with "reference", twice.
<td>
 
<tr valign="top">
<td>
-UK 
-66
+UK 
+66
<td>
-5.2.8
+5.2.8
<td>
-1
+1
<td>
-Te
+Te
<td>
-typeid may return "an implementation-defined class
+typeid may return "an implementation-defined class
derived from std :: type_info". The derivation must be
-public.
+public.
 
<td>
-an
+an
implementation-defined class publicly derived from std ::
-type_info
+type_info
<td>
 
<tr valign="top">
<td>
-UK 
-67
+UK 
+67
<td>
-5.2.9
+5.2.9
<td>
-1, 2,
-3
+1, 2,
+3
<td>
-Te
+Te
<td>
-Paragraph 1
+Paragraph 1
specifies when the result of static_cast is an lvalue; repeating it
-is unnecessary.
+is unnecessary.
<td>
-In para 2, delete "It is an lvalue if the type
+In para 2, delete "It is an lvalue if the type
cast to is an lvalue reference; otherwise, it is an rvalue." and
"The result is an rvalue.". In para 3, delete "The result is an
lvalue if T is an lvalue reference type (8.3.2), and an rvalue
-otherwise."
+otherwise."
 
<td>
 
<tr valign="top">
<td>
-UK 
-54
+UK 
+54
<td>
-5.2.10
+5.2.10
<td>
-3,
-6
+3,
+6
<td>
-Te
+Te
<td>
-Para 3: "The
+Para 3: "The
mapping performed by reinterpret_cast is implementation-defined.".
Para 6: "... the result of such a pointer conversion is
-unspecified." Which is it?
+unspecified." Which is it?
<td>
-In para 6, replace unspecified with
+In para 6, replace unspecified with
implementation-defined. Alternatively, delete paragraph 3, since
-individual cases are labelled appropriately.
+individual cases are labelled appropriately.
 
<td>
 
<tr valign="top">
<td>
-UK 
-55
+UK 
+55
<td>
-5.2.10
+5.2.10
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-dynamic_cast
+dynamic_cast
and reinterpret_cast crossreference 5.2.11 without creating an
extra note. The second half of the note is unrelated to the
-crossrefernce, and would serve as well in normative text.
+crossrefernce, and would serve as well in normative text.
<td>
-Strike the note about definition of casting away
+Strike the note about definition of casting away
constness, preserve the cross-reference. The second sentance on
reintrepret_cast to its own type should move out of the note into
-the normative text.
+the normative text.
 
<td>
 
<tr valign="top">
<td>
-UK 
-56
+UK 
+56
<td>
-5.2.10
+5.2.10
<td>
-5
+5
<td>
-Ed
+Ed
<td>
-The notion of safely derived pointers means this
+The notion of safely derived pointers means this
conversion may not be as safe in the revised standard as the
original. It would be good to call attention to the changed
-semantics with a note.
+semantics with a note.
 
<td>
-Add: [Note:
+Add: [Note:
the result of such a conversion will not be a safely-derived
-pointer value (3.7.4.3) -- end note]
+pointer value (3.7.4.3) -- end note]
<td>
 
<tr valign="top">
<td>
-UK 
-57
+UK 
+57
<td>
-5.2.10
+5.2.10
<td>
-8
+8
<td>
-Ed
+Ed
<td>
-Conditionally
+Conditionally
supported behaviour gives a wide range or permission, so clarify
relationship between safely-derived object pointers and function
-pointers in a note.
+pointers in a note.
<td>
-Add: [Note:
+Add: [Note:
In such cases, the implementation shall also define whether a
safely-derived object pointer cast to a function pointer can be
-safely cast back -- end note]
+safely cast back -- end note]
<td>
 
<tr valign="top">
<td>
-UK 
-58
+UK 
+58
<td>
-5.2.11
+5.2.11
<td>
-9
+9
<td>
-Te
+Te
<td>
-Casting from an lvalue of type T1 to an lvalue of
+Casting from an lvalue of type T1 to an lvalue of
type T2 using a reference cast casts away constness if a cast from
an rvalue of type “pointer to T1” to the type
“pointer to T2” casts away constness. That doesn't
-cover rvalue references.
+cover rvalue references.
 
<td>
-Replace
-lvalue with "lvalue or rvalue" twice.
+Replace
+lvalue with "lvalue or rvalue" twice.
<td>
 
<tr valign="top">
<td>
-US 34
+US 34
 
<td>
-5.3
+5.3
<td>
-1
+1
<td>
-ed
+ed
<td>
-The list of unary operator should be in teletype
-font.
+The list of unary operator should be in teletype
+font.
<td>
 
<td>
 
<tr valign="top">
<td>
-UK 
-68
+UK 
+68
<td>
-5.3.1
+5.3.1
<td>
-2-9
+2-9
<td>
-Te
+Te
<td>
-All the unary
+All the unary
operands other than * return rvalues - but this is not
-stated.
+stated.
<td>
-Add a paragraph 1a "The following unary operators
-all produce results that are rvalues."
+Add a paragraph 1a "The following unary operators
+all produce results that are rvalues."
 
<td>
 
<tr valign="top">
<td>
-UK 
-69
+UK 
+69
<td>
-5.3.1
+5.3.1
<td>
-2
+2
<td>
-Te
+Te
<td>
-If we cannot bind references/take address of
+If we cannot bind references/take address of
functions in concept_maps, does that mean we cannot use generic
bind in constrained templates? Launch threads with expressions
found via concept map lookup? Hit problems creating std::function
@@ -3496,215 +3104,195 @@
explicitly name a concept map? Does it only kick in if we rely on
the implicit function implementation provided by a concept_map, so
some types will work and others won't for the same
-algorithm?!
+algorithm?!
 
<td>
-... unknown
-...
+... unknown
+...
<td>
 
<tr valign="top">
<td>
-UK 
-70
+UK 
+70
<td>
-5.3.3
+5.3.3
<td>
-1
+1
<td>
-Te
+Te
<td>
-The sizeof operator shall not be applied to ... an
+The sizeof operator shall not be applied to ... an
enumeration type before all its enumerators have been declared We
-should allow enum E : int; sizeof(E).
+should allow enum E : int; sizeof(E).
 
<td>
-Change "an
+Change "an
enumeration type" to "an enumeration type whose underlying type is
-not fixed".
+not fixed".
<td>
 
<tr valign="top">
<td>
-UK 
-71
+UK 
+71
<td>
-5.3.4
+5.3.4
<td>
-2
+2
<td>
-Te
+Te
<td>
-The type of
+The type of
an allocated object wih the type specifier auto is determined by
the rules of copy initialization, but the initialization applied
will be direct initialization. This would affect classes which
declare their copy constructor explicit, for instance. For
consistency, use the same form of initiailization for the deduction
-as the new expression.
+as the new expression.
<td>
-Replace T x =
-e; with T x(e);
+Replace T x =
+e; with T x(e);
<td>
 
<tr valign="top">
<td>
-UK 
-72
+UK 
+72
<td>
-5.3.4
+5.3.4
<td>
-7
+7
<td>
-Te
+Te
<td>
-The library headers have been carefully structured
+The library headers have been carefully structured
to limit the dependencies between core language and specific
headers. The exception thrown should be catchable by a handler for
a type lised in <exception> header in cluase 18. This might
be accomplished by moving length_error into the <exception>
header, but its dependency on logic_error with its std::string
constructors suggest this is not a good idea. Prefer to pick an
-existing exception instead.
+existing exception instead.
 
<td>
-Throw
-std::bad_alloc instead of std::length_error.
+Throw
+std::bad_alloc instead of std::length_error.
<td>
 
<tr valign="top">
<td>
-UK 
-73
+UK 
+73
<td>
-5.3.4
+5.3.4
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-A class type with conversion operator can only be
+A class type with conversion operator can only be
used if the conversion type is constexpr and the class is a literal
type. Adding the single word 'literal' before class type will
-clarify this.
+clarify this.
 
<td>
-Add 'literal'
-before 'class type'
+Add 'literal'
+before 'class type'
<td>
 
<tr valign="top">
<td>
-UK 
-74
+UK 
+74
<td>
-5.3.4
+5.3.4
<td>
-8
+8
<td>
-Ed
+Ed
<td>
-operators, like constructors and destructors, do
+operators, like constructors and destructors, do
not have names. However, in certain circumstances they can be
treated as if they had a name, but usually the stanadard is very
clear not to actually describe their name as a distinct
-property.
+property.
 
<td>
-Change "the
+Change "the
allocation function’s name is operator new" to "the
allocation function is named operator new" and similarly for
-operator delete.
+operator delete.
<td>
 
<tr valign="top">
<td>
-UK 
-35
+UK 
+35
<td>
-5.3.4
+5.3.4
<td>
-9
+9
<td>
-Ed
+Ed
<td>
-Missing
+Missing
period in middle of paragraph between "in the scope of T" and "If
-this lookup fails"
+this lookup fails"
<td>
-Add a period between "in the scope of T" and "If
-this lookup fails"
+Add a period between "in the scope of T" and "If
+this lookup fails"
 
<td>
 
<tr valign="top">
<td>
-UK 
-75
+UK 
+75
<td>
-5.3.5
+5.3.5
<td>
-8
+8
<td>
-Ed
+Ed
<td>
-A paragraph strarting with [Note... is easily
-skipped when reading, missing the normative text at the end.
+A paragraph strarting with [Note... is easily
+skipped when reading, missing the normative text at the end.
 
<td>
-Swap order of
-the note and normative text.
+Swap order of
+the note and normative text.
<td>
 
<tr valign="top">
<td>
-FR 21
+FR 21
<td>
-5.3.6 [Alignof
+5.3.6 [Alignof
<td>
 
<td>
-te
+te
<td>
-Should not the type of alignof-expression be of
-type std::max_align_t?
+Should not the type of alignof-expression be of
+type std::max_align_t?
<td>
 
<td>
 
<tr valign="top">
<td>
-US 35
+US 35
<td>
-5.8
+5.8
<td>
-2 and 3
+2 and 3
<td>
-ed
+ed
<td>
-There is curious spacing in the
+There is curious spacing in the
expressions "E1 <<E2" and "E1 >>E2". This is a
-formatting change since previous versions of the Standard.
+formatting change since previous versions of the Standard.
 
<td>
 
@@ -3712,177 +3300,163 @@
 
<tr valign="top">
<td>
-UK 
-47
+UK 
+47
<td>
-5.14 /
-5.15
+5.14 /
+5.15
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-Why are the descriptions of order of evaluation of
+Why are the descriptions of order of evaluation of
expressions and side effects different between && and ||
operators. The interaction with the memory model should be
identical, so identical words should be used to avoid accidential
-inconsistencies in interpretation.
+inconsistencies in interpretation.
 
<td>
-Pick one form
-of wording as 'the best' and apply it in both places.
+Pick one form
+of wording as 'the best' and apply it in both places.
<td>
 
<tr valign="top">
<td>
-UK 
-48
+UK 
+48
<td>
-5.18
+5.18
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-The defining feature of the comma operator is the
+The defining feature of the comma operator is the
guaranteed sequencing of two expressions. This guarantee is lost
when presented with an overloaded operator, and this change is
-subtle enough to call attention to it.
+subtle enough to call attention to it.
 
<td>
-Add: [Note:
+Add: [Note:
There are no guarantees on the order of value computation for an
-overloaded comma operator -- end note]
+overloaded comma operator -- end note]
<td>
 
<tr valign="top">
<td>
-UK 
-49
+UK 
+49
<td>
-5.19
+5.19
<td>
-2
+2
<td>
-Te
+Te
<td>
-Is an
+Is an
implementation permitted to reject this? constexpr int f() { return
f(); } int a[f()]; AFAICT it is well-formed; f() seems to satisfy
all the rules to make it a constant expression. I would hate
compilation to become a potentially non-terminating
-experience.
+experience.
<td>
-Add an escape clause to allow the implementation
+Add an escape clause to allow the implementation
to reject excessively deep nesting of constexpr function
evaluations. (This can possibly be a note, since it is arguable
that this point is handled by the general rule on resource limits
in 1.4/2. A sufficiently smart compiler could use tail recursion
above, meaning that it would never run out of memory given this
-program though.)
+program though.)
 
<td>
 
<tr valign="top">
<td>
-UK 
-50
+UK 
+50
<td>
-5.19
+5.19
<td>
-2
+2
<td>
-Te
+Te
<td>
-The following
+The following
should be valid: enum E { foo = 4}; const E c = foo; int a[c]; But
currently it is not - c is not an lvalue of effective integral type
-(4th bullet). (See also 7.1.6.1/2)
+(4th bullet). (See also 7.1.6.1/2)
<td>
-Change "effective integral type" to "effective
+Change "effective integral type" to "effective
integral or enumeration type" in the 4th bullet, 1st
-sub-bullet.
+sub-bullet.
 
<td>
 
<tr valign="top">
<td>
-UK 
-51
+UK 
+51
<td>
-5.19
+5.19
<td>
-2
+2
<td>
-Te
+Te
<td>
-typeid expressions can never be constant, whether
+typeid expressions can never be constant, whether
or not the operand is a polymorphic class type. The result of the
expression is a reference, and the typeinfo class that the
reference refers to is polymorphic, with a virtual destructor - it
-can never be a literal type.
+can never be a literal type.
 
<td>
-Strike the
+Strike the
words "whose operand is of a polymorphic class type" on the bullet
-for typeid expressions.
+for typeid expressions.
<td>
 
<tr valign="top">
<td>
-UK 
-76
+UK 
+76
<td>
-6.3
+6.3
<td>
 
<td>
-Ed
+Ed
<td>
-Do we really
-need two different terms that say the same thing?
+Do we really
+need two different terms that say the same thing?
<td>
-Pick either 'block' or 'compound statement' as the
+Pick either 'block' or 'compound statement' as the
preferred term and use it consistently throughout the
-standard.
+standard.
 
<td>
 
<tr valign="top">
<td>
-FR 22
+FR 22
<td>
-6.4.2 [The switch
-statement]
+6.4.2 [The switch
+statement]
<td>
 
<td>
-te
+te
<td>
-The constant-expression in
+The constant-expression in
 
-case constant-expression
+case constant-expression
 
-should be allowed to be of any constant
+should be allowed to be of any constant
expression of literal type for which a constexpr comparison
operator (operator< and operator==) is in scope. Now that
constant expressions of other integral types are evaluated at
compile time, the restriction for case-labels is at best
-artificial.
+artificial.
 
<td>
 
@@ -3890,179 +3464,158 @@
 
<tr valign="top">
<td>
-UK 
-77
+UK 
+77
<td>
-6.5
+6.5
<td>
-5
+5
<td>
-Ed
+Ed
<td>
-The terms i/o operation, synchronize operation and
+The terms i/o operation, synchronize operation and
atomic operation have very specific meanings within the standard.
The paragraph would be much easier to understand with the terms
-crossreferenced.
+crossreferenced.
 
<td>
-Profide a
+Profide a
cross-reference for the terms: i/o operation, synchronize operation
-and atomic operation
+and atomic operation
<td>
 
<tr valign="top">
<td>
-JP 11
+JP 11
<td>
-6.5.4
+6.5.4
<td>
-1st paragraph, 5th line
+1st paragraph, 5th line
<td>
-ed
+ed
<td>
-There is no _RangeT type
+There is no _RangeT type
in the equivalent code to “range-base for” statement.
-It existed in N2049.
+It existed in N2049.
<td>
-Add a typedef for _RangeT in the example
-as follows:
+Add a typedef for _RangeT in the example
+as follows:
 
-{
+{

-    typedef
-decltype( expression ) _RangeT;
+    typedef
+decltype( expression ) _RangeT;

-    auto
-&& __range = ( expression );
+    auto
+&& __range = ( expression );

-    for ( auto
-__begin = std::Range<_RangeT>:: begin(__range),
+    for ( auto
+__begin = std::Range<_RangeT>:: begin(__range),

-           
-__end =
-std::Range<_RangeT>:: end(__range);
+            __end =
+std::Range<_RangeT>:: end(__range);

-          __begin != __end;
+          __begin != __end;

-          ++__begin )
+          ++__begin )

-    {
+    {

-        for-range-declaration = *__begin;
+        for-range-declaration = *__begin;

-        statement
+        statement

-    }
-}
+    }
+}
 
<td>
 
<tr valign="top">
<td>
-UK 
-78
+UK 
+78
<td>
-6.5.4
+6.5.4
<td>
-2
+2
<td>
-Te
+Te
<td>
-Including the
+Including the
header <iterator_concepts> is far too unwieldy to enable an
-important and (expected to be) frequently used syntax.
+important and (expected to be) frequently used syntax.
<td>
-Merge <iterator_concepts> into
+Merge <iterator_concepts> into
<concepts> and change 6.5.4p2 to refer to <concepts>,
or make the Range concept fundamental along with the other support
concepts in 14.9.4 and strike any reference to including a
-header.
+header.
 
<td>
 
<tr valign="top">
<td>
-UK 
-79
+UK 
+79
<td>
-6.5.4
+6.5.4
<td>
 
<td>
-Te
+Te
<td>
-The definition of for (for-range-declaration :
+The definition of for (for-range-declaration :
expression) statement is expanded in terms which require a Range
concept, and the program is ill-formed if <iterator_concepts>
isn't included. For users, iterating through old-fashioned arrays,
this is a sledge-hammer to crack a nut and compares poorly with
other languages. It's also not possible to implement this without
-adversely impacting the freestanding definition in 17.6.2.4.
+adversely impacting the freestanding definition in 17.6.2.4.
 
<td>
-When
+When
expression is an array a of length N whose length is known at
compile time, expand range-for as 'for (... p=a, p!=a+N, p++) ...'
without requiring the Range concept or <iterator_concepts>.
Also, when expression is an initializer_list, expand range-for
-similarly without requiring <iterator_concepts>.
+similarly without requiring <iterator_concepts>.
<td>
 
<tr valign="top">
<td>
-DE-11
+DE-11
<td>
-6.9
+6.9
<td>
-p1
+p1
<td>
-te
+te
<td>

-DE-11 A sentence in paragraph
+DE-11 A sentence in paragraph
1 reads: "Outside of a constrained context, the late-checked block
has no effect." This, at face value, specifies that the
compound-statement of such a late-checked block is never
-executed, which appears to be unintended.
+executed, which appears to be unintended.
 
<td>
-State that such a
-late-checked block has the same meaning as if the late_check keyword were absent.
+State that such a
+late-checked block has the same meaning as if the late_check keyword were absent.
<td>
 
<tr valign="top">
<td>
-UK 
-80
+UK 
+80
<td>
-7
+7
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-Many of the sections and major subsections open
+Many of the sections and major subsections open
with a sentence summarising the content. I'm not sure this is
necessary; this isn't a tutorial. The problem with these summaries
is that because they omit much of the detail, they tend to be
@@ -4070,249 +3623,227 @@
improved by omitting them. There's a prime example here:
"Declarations specify how names are to be interpreted." Not true
for static_assert, an asm declaration nor an anonymous bit
-field.
+field.
 
<td>
-Strike the
-first sentence.
+Strike the
+first sentence.
<td>
 
<tr valign="top">
<td>
-UK 
-81
+UK 
+81
<td>
-7
+7
<td>
-4
+4
<td>
-Te
+Te
<td>
-String literal concatenation happens in phase 6,
+String literal concatenation happens in phase 6,
before parsing, so it is legal and useful to use it for the string
literal in a static_assert. It would be useful to add a note
-mentioning this.
+mentioning this.
 
<td>
-Add a note:
+Add a note:
Multiple adjacent string literals may be used instead of a single
-/string-literal/; see [lex.phases].
+/string-literal/; see [lex.phases].
<td>
 
<tr valign="top">
<td>
-UK 
-82
+UK 
+82
<td>
-7
+7
<td>
-2
+2
<td>
-Te
+Te
<td>
-Paragraph 2 talks about declarations that can have
+Paragraph 2 talks about declarations that can have
nested declarations within them. It doesn't mention scoped
enumerations - but according to 7.2/11, "Each scoped enumerator is
-declared in the scope of the enumeration."
+declared in the scope of the enumeration."
 
<td>
-Add "scoped
-enumeration" to the list in the second sentence.
+Add "scoped
+enumeration" to the list in the second sentence.
<td>
 
<tr valign="top">
<td>
-UK 
-83
+UK 
+83
<td>
-7.1
+7.1
<td>
-2
+2
<td>
-Te
+Te
<td>
-The longest sequence of decl-specifiers that could
+The longest sequence of decl-specifiers that could
possibly be a type name is taken as the decl-specifier-seq of a
declaration. But many sequences of decl-specifiers cannot possibly
be a type name - eg the sequence "friend int", or "typedef
-int".
+int".
 
<td>
-Not sure. I
-understand the rule, just not how to say it.
+Not sure. I
+understand the rule, just not how to say it.
<td>
 
<tr valign="top">
<td>
-UK 
-84
+UK 
+84
<td>
-7.1
+7.1
<td>
-1
+1
<td>
-Te
+Te
<td>
-The grammar includes alignment-specifier as a
+The grammar includes alignment-specifier as a
production for decl-specifier, but there is no production for
alignment-specifier. I suspect this is a holdover from before
-alignment was handled as an attribute.
+alignment was handled as an attribute.
 
<td>
-Delete the
-production (including the duplicate in A6)
+Delete the
+production (including the duplicate in A6)
<td>
 
<tr valign="top">
<td>
-FI 3
+FI 3
<td>
-7.1
+7.1
<td>
-[dcl.spec.auto]
+[dcl.spec.auto]
<td>
-te
+te
<td>

-While it’s considered
+While it’s considered
too late for this standard revision, consider loosening the
restrictions for auto specifier and making it more a mirror of a
-deduced template function parameter.
+deduced template function parameter.
 
<td>
-See
-restricted-auto.ppt
+See
+restricted-auto.ppt
<td>
 
<tr valign="top">
<td>
-UK 
-85
+UK 
+85
<td>
-7.1.1
+7.1.1
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-... the init-declarator-list of the declaration
+... the init-declarator-list of the declaration
shall not be empty (except for global anonymous unions, which shall
be declared static). Global here means "declared at namespace
scope". (cf 9.5/3 "Anonymous unions declared in a named namespace
-or in the global namespace shall be declared static.").
+or in the global namespace shall be declared static.").
 
<td>
-Replace
-"global" with "namespace scope".
+Replace
+"global" with "namespace scope".
<td>
 
<tr valign="top">
<td>
-UK 
-86
+UK 
+86
<td>
-7.1.1
+7.1.1
<td>
-2,3
+2,3
<td>
-Te
+Te
<td>
-The register keyword serves very little function,
+The register keyword serves very little function,
offering no more than a hint that a note says is typically ignored.
It should be deprecated in this version of the standard, freeing
the reserved name up for use in a future standard, much like auto
has been re-used this time around for being similarly
-useless.
+useless.
 
<td>
-Deprecate
-current usage of the register keyword.
+Deprecate
+current usage of the register keyword.
<td>
 
<tr valign="top">
<td>
-UK 
-87
+UK 
+87
<td>
-7.1.1
+7.1.1
<td>
-1, 4,
-5
+1, 4,
+5
<td>
-Te
+Te
<td>
-Why require two keywords, where one on its own
+Why require two keywords, where one on its own
becomes ill-formed? thread_local should imply 'static' in this
case, and the combination of keywords should be banned rather than
required. This would also eliminate the one of two exceptions
-documented in 7.1.1p1.
+documented in 7.1.1p1.
 
<td>
-Drop
+Drop
requirement to combine static keyword with thread_local at
-block-scope inside a function definition.
+block-scope inside a function definition.
<td>
 
<tr valign="top">
<td>
-US 36
+US 36
<td>
-7.1.1
+7.1.1
<td>
-4
+4
<td>
-te
+te
<td>
-The permission to use thread_local
-static data members is missing.
+The permission to use thread_local
+static data members is missing.
 
<td>
-Add the static members as a permitted use.
+Add the static members as a permitted use.
<td>
 
<tr valign="top">
<td>
-FR 23
+FR 23
<td>
-7.1.5 [constexpr]
+7.1.5 [constexpr]
<td>
 
<td>
-te
+te
<td>
-'constexpr' functions should be allowed to
+'constexpr' functions should be allowed to
take const reference parameters, as long as their uses are in a
context where a constant expression may be required. For example,
-the following should be allowed
+the following should be allowed
 
-template<typename T, int N>
-int size(const T(&)[N]) { return N;
-}
+template<typename T, int N>
+int size(const T(&)[N]) { return N;
+}
 
-int a[] = { 41,42,43,44 };
-enum { v = size(a) };
+int a[] = { 41,42,43,44 };
+enum { v = size(a) };
 
<td>
 
@@ -4320,38 +3851,33 @@
 
<tr valign="top">
<td>
-JP 12
+JP 12
<td>
-7.1.5
+7.1.5
<td>
 
<td>
-te
+te
<td>

-It should be allowed to
-define constexpr recursively.
-There is an explanation in N2235,
+It should be allowed to
+define constexpr recursively.
+There is an explanation in N2235,
Generalized Constant Expressions—Revision 5, as
-follows.
+follows.
 
We (still) prohibit recursion in all its form in
+"margin-left: 0.39in; margin-bottom: 0in">We (still) prohibit recursion in all its form in
constant expressions. That is not strictly necessary because an
implementation limit on recursion depth in constant expression
evaluation would save us from the possibility of the compiler
recursing forever. However, until we see a convincing use case for
-recursion, we don’t propose to allow it.
+recursion, we don’t propose to allow it.
 
-Then, here are the use cases where
-allowing recursion for constexpr is very useful.
+Then, here are the use cases where
+allowing recursion for constexpr is very useful.
 
-Range of problem to be handled with
+Range of problem to be handled with
constexpr would become extended. For example, user defined type
(e.g. Complex type) could be placed in ROM area. But with current
specification, a function defined with constexpr cannot be called
@@ -4359,96 +3885,71 @@
cannot be implemented to repeat anything without recursion.
Although it could be implemented without recursion like func0,
func1, func2 in an example below, it is not elegant
-solution.
+solution.
 
-constexpr double func0(double x) { /*
-... */}
-constexpr double func1(double x) { /*
-call for func0 */ }
-constexpr double func2(double x) { /*
-call for func1 */ }
-/* ... */
- 
-- Compile-time and runtime
-As constexpr can be also evaluated both
+constexpr double func0(double x) { /*
+... */}
+constexpr double func1(double x) { /*
+call for func0 */ }
+constexpr double func2(double x) { /*
+call for func1 */ }
+/* ... */
+ 
+- Compile-time and runtime
+As constexpr can be also evaluated both
in compile-time and runtime, we need to discuss about both
-cases.
+cases.
 
-Runtime evaluation is just to execute
+Runtime evaluation is just to execute
it. If you eliminate constexpr keyword, it is executable as of now.
-Any modern compiler may optimize tail recursion easily.
+Any modern compiler may optimize tail recursion easily.
 
-Compile-time evaluation is the same
+Compile-time evaluation is the same
thing as template recursion. It is necessary to support floating
point operation, but it is already possible to calculate it in
-compile-time, so it’s ok.
+compile-time, so it’s ok.
+ 
+- Sample
+Here is an example to calculate a square
+root using constexpr recursively.
+ 
+/*constexpr*/ double SqrtHelper(double
+x, double a, int n)
+{
+return n == 0 ? a : SqrtHelper(x, (x / a
++ a) / 2.0, n - 1);
+}
+ 
+/*constexpr*/ double Sqrt(double
+x)
+{
+return SqrtHelper(x, x, 20);
+}
 
-- Sample
-Here is an example to calculate a square
-root using constexpr recursively.
- 
-/*constexpr*/ double SqrtHelper(double
-x, double a, int n)
-{
-return n == 0 ? a : SqrtHelper(x, (x / a
-+ a) / 2.0, n - 1);
-}
- 
-/*constexpr*/ double Sqrt(double
-x)
-{
-return SqrtHelper(x, x, 20);
-}
- 
-/*constexpr*/ double root2 = Sqrt(2.0); //
-1.41421...
+/*constexpr*/ double root2 = Sqrt(2.0); //
+1.41421...
 
<td>
-Allow constexpr recursion.
+Allow constexpr recursion.
 
<td>
 
<tr valign="top">
<td>
-US 37
+US 37
<td>
-7.1.6.1
+7.1.6.1
<td>
-1
+1
<td>
-ed
+ed
<td>
-There is a "Note: 3.9.3 describes how
+There is a "Note: 3.9.3 describes how
cv-qualifiers affect object and function types." So far as I can
see, 3.9.3 CV-qualifiers only describes cv-qualifiers for objects,
cv-qualifiers for (member) functions being described in 8.3.5
-Functions.
+Functions.
 
<td>
 
@@ -4456,18 +3957,16 @@
 
<tr valign="top">
<td>
-UK 
-89
+UK 
+89
<td>
-7.1.6.1
+7.1.6.1
<td>
-2
+2
<td>
-Te
+Te
<td>
-The two normative sentences in this paragraph
+The two normative sentences in this paragraph
appear to duplicate text elsewhere - but they aren't exact
duplicates, which introduces uncertainty. 1. "An object declared in
namespace scope with a const-qualified type has internal linkage
@@ -4486,53 +3985,49 @@
initialized with constant expressions". The latter does not allow
for lvalues of enumeration type (neither scoped not unscoped
enumerations are integral types - 3.9.1/7, and note 44). This seems
-to be a flaw in 5.19/2.
+to be a flaw in 5.19/2.
 
<td>
-Make the
+Make the
normative text in this section into one or more notes, with cross
-references, and correct the referenced text if necessary.
+references, and correct the referenced text if necessary.
<td>
 
<tr valign="top">
<td>
-UK 
-90
+UK 
+90
<td>
-7.1.6.2
+7.1.6.2
<td>
-para 1 and
-table 9
+para 1 and
+table 9
<td>
-Ed
+Ed
<td>
-The grammar in paragraph one makes
+The grammar in paragraph one makes
"nested-name-specifier template simple-template-id" a
simple-type-specifier, but unlike all the others it is omitted from
-table 9.
+table 9.
 
<td>
-Add a row to
+Add a row to
table 9 mentioning simple-template-id and punting to clause 14 (cf
-decltype(expression)).
+decltype(expression)).
<td>
 
<tr valign="top">
<td>
-UK 
-91
+UK 
+91
<td>
-7.1.6.2
+7.1.6.2
<td>
-4
+4
<td>
-Te
+Te
<td>
-5.1/5 says "[A] parenthesized expression can be
+5.1/5 says "[A] parenthesized expression can be
used in exactly the same contexts as those where the enclosed
expression can be used, and with the same meaning, except as
otherwise indicated." When the first bullet point of this
@@ -4543,102 +4038,94 @@
caught by the third bullet and treated as an lvalue expression, so
decltype((e)) should be a reference to the type of e. Conversely,
the second bullet point says "(parentheses around e are ignored)",
-which is redundant because of 5.1/5.
+which is redundant because of 5.1/5.
 
<td>
-Insert
+Insert
"unparenthised" in the first bullet point - "if e is an
*unparenthised* id-expression ...". In the second bullet point,
-move "(parentheses around e are ignored)" into a note.
+move "(parentheses around e are ignored)" into a note.
<td>
 
<tr valign="top">
<td>
-UK 
-92
+UK 
+92
<td>
-7.1.6.3
+7.1.6.3
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-The note correctly indicates that, if T is a
+The note correctly indicates that, if T is a
template type parameter, then "friend class T;" is ill-formed. It
might be worth pointing out at the same time that the alternative
-"friend T;" is now allowed - see 11.4/3.
+"friend T;" is now allowed - see 11.4/3.
 
<td>
-Either strike
+Either strike
the note or add reference to 11.4/3 and/or mention of "friend
-T;".
+T;".
<td>
 
<tr valign="top">
<td>
-UK 
-93
+UK 
+93
<td>
-7.1.6.3
+7.1.6.3
<td>
-Grammar
-before para 1
+Grammar
+before para 1
<td>
-Ed
+Ed
<td>
-In the third production, "enum ::opt
+In the third production, "enum ::opt
nested-name-specifieropt identifier", enum should not be in
-italics; its referring to the enum keyword.
+italics; its referring to the enum keyword.
 
<td>
-Change to
-keyword font
+Change to
+keyword font
<td>
 
<tr valign="top">
<td>
-UK 
-94
+UK 
+94
<td>
-7.1.6.4
+7.1.6.4
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-The auto
+The auto
type-specifier signifies that the type of an object being declared
shall be deduced from its initializer or specified explicitly at
the end of a function declarator. A function declarator does not
-declare an object.
+declare an object.
<td>
-The auto type-specifier signifies that the type of
+The auto type-specifier signifies that the type of
an object being declared shall be deduced from its initializer or
that the return type of a function is specified explicitly at the
-end of a function declarator.
+end of a function declarator.
 
<td>
 
<tr valign="top">
<td>
-UK 
-95
+UK 
+95
<td>
-7.1.6.4
+7.1.6.4
<td>
-4
+4
<td>
-Te
+Te
<td>
-(See also c++std-core-13583) This paragraph allows
+(See also c++std-core-13583) This paragraph allows
auto "in the type-specifier-seq in a new-type-id (5.3.4)" (and
nowhere else not listed). Specifically, it isn't allowed in a
type-id in a new-expression. That allows "new auto (42)", but not
@@ -4646,64 +4133,52 @@
allowed "If the auto type-specifier appears in the
type-specifier-seq of a new-type-id or type-id of a new-expression
...". The inconsistency should be resolved, ideally in favour of
-allowing both forms.
+allowing both forms.
 
<td>
-Change "in a
+Change "in a
new-type-id" to "in a new-type-id or type-id in a
-new-expression".
+new-expression".
<td>
 
<tr valign="top">
<td>
-FR 24
+FR 24
<td>
-7.1.6.4 [auto
-specifier]
+7.1.6.4 [auto
+specifier]
<td>
 
<td>
-te
+te
<td>
-Now that 'auto' is finally used in its
+Now that 'auto' is finally used in its
most obvious sense to state `deduce the type of this variable from
initializer', it should also be allowed in template parameter
-declarations, as in
+declarations, as in
 
-template<auto n> struct X { /*
-… */ };
+template<auto n> struct X { /*
+… */ };
 
-X<903> x;
+X<903> x;
 
-X<&Widget::callback> y;
+X<&Widget::callback> y;
 
-instead of the current, often verbose and
-cumbersome
+instead of the current, often verbose and
+cumbersome
 
-template<typename T, T n> struct X { /*
-… */ };
+… */ };
 
-X<int,903> x;
-X<void
-(Widget::*)(),&Widget::callback> y;
+X<int,903> x;
+X<void
+(Widget::*)(),&Widget::callback> y;
 
-We understand that 'auto' is used in
+We understand that 'auto' is used in
14.1/18 in a different way (for constrained template), but that
usable appears very strange syntax, unnatural and does not fit well
-with the usage in this section.
+with the usage in this section.
 
<td>
 
@@ -4711,21 +4186,16 @@
 
<tr valign="top">
<td>
-US 38
+US 38
<td>
-7.2
+7.2
<td>
-1
+1
<td>
-ed
+ed
<td>
-The discussion of attribute specifiers
-should be a separate paragraph.
+The discussion of attribute specifiers
+should be a separate paragraph.
 
<td>
 
@@ -4733,304 +4203,270 @@
 
<tr valign="top">
<td>
-US 39
+US 39
<td>
-7.2
+7.2
<td>
-2
+2
<td>
-te
+te
<td>
-The paragraph says in part "An
+The paragraph says in part "An
opaque-enum-declaration declaring an unscoped enumeration shall not
omit the enum-base." This statement implies that the base may be
omitted for scoped enumerations, which is somewhat inconsistent
-with paragraph 3 and somewhat consistent with paragraph 5.
+with paragraph 3 and somewhat consistent with paragraph 5.
 
<td>
-As this implication leaves no representation, it
+As this implication leaves no representation, it
should be either affirmed here or the statement should be expanded.
-Perhaps a note is warranted.
+Perhaps a note is warranted.
<td>
 
<tr valign="top">
<td>
-JP 13
+JP 13
<td>
-7.2
+7.2
<td>
-paragraph 3
+paragraph 3
<td>
-ed
+ed
<td>
-In the description for an unscoped
+In the description for an unscoped
enumeration, enum-base in redeclaration must be the same underlying
type as in the 1st declaration, but it is not described explicitly,
while it is referred that all enum-bases in redeclarations must
-specify the same underlying type.
+specify the same underlying type.
 
<td>
-Replace the description,
+Replace the description,
"same underlying type", with "same as underlying type of (previous)
-declaration."
+declaration."
<td>
 
<tr valign="top">
<td>
-UK 
-96
+UK 
+96
<td>
-7.2
+7.2
<td>
-7
+7
<td>
-Te
+Te
<td>
-enum E { }; What are the values of E? It has
+enum E { }; What are the values of E? It has
neither a smallest nor largest enumerator, so paragraph 7 doesn't
help. (Paragraph 6 indicates that the underlying type is as if E
had a single enumerator with value 0, but that does not define the
-values of E.)
+values of E.)
 
<td>
-Add a second
+Add a second
sentence to paragraph 7 (before "Otherwise"): "If the
enumerator-list is empty, 0 is the only value of the
-enumeration."
+enumeration."
<td>
 
<tr valign="top">
<td>
-UK 
-97
+UK 
+97
<td>
-7.2
+7.2
<td>
-9
+9
<td>
-Ed
+Ed
<td>
-Missing punctuation after "blue" in: "The possible
+Missing punctuation after "blue" in: "The possible
values of an object of type color are red, yellow, green, blue
-these values can be converted ..."
+these values can be converted ..."
 
<td>
-Add a
+Add a
semicolon: "The possible values of an object of type color are red,
-yellow, green, blue; these values can be converted ..."
+yellow, green, blue; these values can be converted ..."
<td>
 
<tr valign="top">
<td>
-UK 
-98
+UK 
+98
<td>
-7.2
+7.2
<td>
-5
+5
<td>
-Te
+Te
<td>
-It would be useful to be able to determine the
+It would be useful to be able to determine the
underlying type of an arbitrary enumeration type. This would allow
safe casting to an integral type (especially needed for scoped
enums, which do not promote), and would allow use of
numeric_limits. In general it makes generic programming with
-enumerations easier.
+enumerations easier.
 
<td>
-Add a
+Add a
TransformationTrait to 20.5.6 that returns the underlying type of
-an enumeration type.
+an enumeration type.
<td>
 
<tr valign="top">
<td>
-UK 
-99
+UK 
+99
<td>
-7.2
+7.2
<td>
-3
+3
<td>
-Te
+Te
<td>
-It is unclear whether an enumeration type is
+It is unclear whether an enumeration type is
complete after an opaque-enum-declaration. This paragraph only says
so in a note, and the general rule in 3.9/5 ("Incompletely-defined
object types ... are incomplete types") is unclear in this
-situation.
+situation.
 
<td>
-Move "an
+Move "an
enumeration declared by an opaque-enum-declaration ... is a
-complete type" from the note to normative text.
+complete type" from the note to normative text.
<td>
 
<tr valign="top">
<td>
-JP 14
+JP 14
<td>
-7.3.1
+7.3.1
<td>
 
<td>
-te
+te
<td>

-The description of the
+The description of the
behavior when a member that was defined with same name in other
-namespace was referred.
+namespace was referred.

-- It seems that the behavior
+- It seems that the behavior
of the following case is not defined. So we think that it is
-necessary to define that.
+necessary to define that.
namespace Q {
+"margin-left: 0.67in; margin-bottom: 0in">namespace Q {
inline namespace V {
+"margin-left: 0.67in; margin-bottom: 0in">inline namespace V {
int g;
+"margin-left: 0.67in; margin-bottom: 0in">int g;
}
+"margin-left: 0.67in; margin-bottom: 0in">}
int g;
+"margin-left: 0.67in; margin-bottom: 0in">int g;
}
+"margin-left: 0.67in; margin-bottom: 0in">}
Q::g =1;// ill-fromed, Q::V::g =1;, or Q::g =
-1;?
+"margin-left: 0.67in; margin-bottom: 0in">Q::g =1;// ill-fromed, Q::V::g =1;, or Q::g =
+1;?

-- Add that the following case
-is ill-formed to more easily to understand.
+- Add that the following case
+is ill-formed to more easily to understand.
namespace Q {
+"margin-left: 0.5in; margin-bottom: 0in">namespace Q {
inline namespace V1{
+"margin-left: 0.5in; margin-bottom: 0in">inline namespace V1{
int g;
+"margin-left: 0.5in; margin-bottom: 0in">int g;
}
+"margin-left: 0.5in; margin-bottom: 0in">}
inline namespace V2{
+"margin-left: 0.5in; margin-bottom: 0in">inline namespace V2{
int g;
+"margin-left: 0.5in; margin-bottom: 0in">int g;
}
+"margin-left: 0.5in; margin-bottom: 0in">}
}
+"margin-left: 0.5in; margin-bottom: 0in">}
Q::g =1;//ill-formed
+"text-indent: 0.44in; margin-bottom: 0in">Q::g =1;//ill-formed
 
<td>

-Add the description of the
+Add the description of the
behavior when a member that was defined with same name in other
-namespace was referred.
+namespace was referred.
 
<td>
 
<tr valign="top">
<td>
-UK 
-100
+UK 
+100
<td>
-7.3.3
+7.3.3
<td>
-10 and
-13
+10 and
+13
<td>
-Ed
+Ed
<td>
-Para 10 says "A using-declaration is a declaration
+Para 10 says "A using-declaration is a declaration
and can therefore be used repeatedly where (and only where)
multiple declarations are allowed." Para 13 says "Since a
using-declaration is a declaration, the restrictions on
declarations of the same name in the same declarative region (3.3)
also apply to using-declarations." These appear to be saying
-exactly the same thing.
+exactly the same thing.
 
<td>
-Delete para
-10, moving its example into para 13.
+Delete para
+10, moving its example into para 13.
<td>
 
<tr valign="top">
<td>
-UK 
-101
+UK 
+101
<td>
-7.3.3
+7.3.3
<td>
-20
+20
<td>
-Te
+Te
<td>
-If a using-declaration uses the keyword typename
+If a using-declaration uses the keyword typename
and specifies a dependent name (14.6.2), the name introduced by the
using-declaration is treated as a typedef-name (7.1.3). That
doesn't specify at all what the effect of using typename with a
non-dependent name is. Is it allowed? What about outside any
template? What if the name isn't a type? (14.6/4 doesn't cover
-this, I think.)
+this, I think.)
 
<td>
-Allow
-typename for non-dependent names iff they refer to a type.
+Allow
+typename for non-dependent names iff they refer to a type.
<td>
 
<tr valign="top">
<td>
-DE-12
+DE-12
<td>
-7.3.3
+7.3.3
<td>
-p15
+p15
<td>
-te
+te
<td>

-DE-12 Overriding and hiding
+DE-12 Overriding and hiding
of member functions named in using-declarations should consider
-ref-qualifiers, because they are part of the function type.
+ref-qualifiers, because they are part of the function type.
 
<td>
 
@@ -5038,127 +4474,103 @@
 
<tr valign="top">
<td>
-FR 25
+FR 25
<td>
-7.3.3 [The using
-declaration]
+7.3.3 [The using
+declaration]
<td>
-Paragraph 21
+Paragraph 21
<td>
-te
+te
<td>
-The syntax for concept map alias is
-unnecessarily both confused and verbose.
+The syntax for concept map alias is
+unnecessarily both confused and verbose.
<td>
-We strongly suggest simplifications,
-e.g.
-using N1::C<int>;
-that fits well with existing constructs.
+We strongly suggest simplifications,
+e.g.
+using N1::C<int>;
+that fits well with existing constructs.
The syntactic complexity is too high for a new feature presumably
-designed to support sound programming.
+designed to support sound programming.
 
<td>
 
<tr valign="top">
<td>
-UK 
-102
+UK 
+102
<td>
-7.3.4
+7.3.4
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-This paragraph says "If name lookup finds a
+This paragraph says "If name lookup finds a
declaration for a name in two different namespaces, and the
declarations do not declare the same entity and do not declare
functions, the use of the name is ill-formed." But the example uses
declaration of functions, so is not covered by this
-paragraph.
+paragraph.
 
<td>
-Move the
+Move the
example to paragraph 7, and/or replace it with an appropriate
-example.
+example.
<td>
 
<tr valign="top">
<td>
-US 40
+US 40
<td>
-7.6
+7.6
<td>
 
<td>
-te
+te
<td>
-The list of attributes is missing an attribute to
-indicate that a function with a <code>throw()</code>
-(throws nothing) clause need
-not have the <code>unexpected()</code> catch clause generated. This attribute was a
+The list of attributes is missing an attribute to
+indicate that a function with a <code>throw()</code> (throws nothing) clause need
+not have the <code>unexpected()</code> catch clause generated. This attribute was a
motivating example for the attribute syntax, and its omission is
-surprising.
+surprising.
 
<td>
-Add the attribute.
+Add the attribute.
<td>
 
<tr valign="top">
<td>
-US 41
+US 41
<td>
-7.6
+7.6
<td>
 
<td>
-te
+te
<td>
-A common problem is unintentionally
+A common problem is unintentionally
declaring a new virtual member function instead of overriding a
-base virtual member function.
+base virtual member function.
 
<td>
-An attribute stating intent to override would
-enable better diagnostics.
+An attribute stating intent to override would
+enable better diagnostics.
<td>
 
<tr valign="top">
<td>
-FR 26
+FR 26
<td>
-7.6 [Attributes]
+7.6 [Attributes]
<td>
 
<td>
-ed
+ed
<td>
-Are they part of object types or not? The
-section does not appear to indicate that clearly.
+Are they part of object types or not? The
+section does not appear to indicate that clearly.
 
<td>
 
@@ -5166,47 +4578,42 @@
 
<tr valign="top">
<td>
-FI 1
+FI 1
<td>
-7.6
+7.6
<td>
 
<td>
-te
+te
<td>
-Add override-attribute for
+Add override-attribute for
functions in order to avoid mistakes when overriding
-functions.
+functions.
<td>
-See
-override-attribute.doc, override-attribute.ppt
+See
+override-attribute.doc, override-attribute.ppt
<td>
 
<tr valign="top">
<td>
-FR 27
+FR 27
<td>
-7.6.1
+7.6.1
<td>
 
<td>
-te
+te
<td>
-This section specifies that no name lookup
+This section specifies that no name lookup
is performed on any identifier contained in an attribute-token.
This in particular implies that, for example, it is impossible to
define a template class parameterized by its alignment. That
-restriction is unacceptable.
-The original alignment proposal made that
-useful construct possible.
-Furthermore paragraph 7.6.1/2 appears
+restriction is unacceptable.
+The original alignment proposal made that
+useful construct possible.
+Furthermore paragraph 7.6.1/2 appears
contradictory with the rest of that section -- since no name lookup
-is performed, how a 'type-id'is determined?
+is performed, how a 'type-id'is determined?
 
<td>
 
@@ -5214,110 +4621,103 @@
 
<tr valign="top">
<td>
-UK 
-103
+UK 
+103
<td>
-7.6.1
+7.6.1
<td>
 
<td>
-Te
+Te
<td>
-Attributes
+Attributes
should support pack expansion. For example, this would be extremely
useful with the align attribute, directly supporting the (removed)
functionality of aligned_union. NOte that aligned_union was removed
as varaiant-unions were considered a complete replacement - however
this is not true for variadic templates. Adding this support to
attributes would remove the remaining need, and support similar
-attributes in the future.
+attributes in the future.
<td>
-Add:
+Add:
attribute... to the grammar for attribute-list Add to list in
14.5.3p4: "In an attribute-list(7.6.1); the pattern is an
-attribute."
+attribute."
<td>
 
<tr valign="top">
<td>
-UK 
-104
+UK 
+104
<td>
-7.6.1
+7.6.1
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-It is helpful for each subclause to contain a
+It is helpful for each subclause to contain a
short paragraph introducing its intent an purpose. 7.6 has such a
paragraph, but it is nested under a more specific
-subsection.
+subsection.
 
<td>
-7.6.1p1
+7.6.1p1
should move up one level to become 7.6p1. There grammar should
-remain under 7.6.1
+remain under 7.6.1
<td>
 
<tr valign="top">
<td>
-UK 
-105
+UK 
+105
<td>
-7.6.1
+7.6.1
<td>
-1
+1
<td>
-Te
+Te
<td>
-Allowing only
+Allowing only
one level of namespaces in attributes seems unnecessarily
-limiting.
+limiting.
<td>
-To:
+To:
attribute-scoped-token: attribute-namespace :: identifier add
-attribute-namespace :: attribute-scoped-token
+attribute-namespace :: attribute-scoped-token
<td>
 
<tr valign="top">
<td>
-UK 
-106
+UK 
+106
<td>
-7.6.2
+7.6.2
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-Extensive use of alignment and related terms
-without cross reference.
+Extensive use of alignment and related terms
+without cross reference.
 
<td>
-Add
-cross-reference to 3.11.
+Add
+cross-reference to 3.11.
<td>
 
<tr valign="top">
<td>
-JP 15
+JP 15
<td>
-7.6.2
+7.6.2
<td>
 
<td>
-ed
+ed
<td>

-An abbreviation of 7.6.2
+An abbreviation of 7.6.2
should be “[decl.attr.align]” instead of
“[dcl.align]”. 
Section name “[dcl.align]” is not consistent with
@@ -5326,115 +4726,96 @@
been changed from “[dcl.align]” to
“[dcl.attr.align]”, but in N2800 it was reverted to
“[dcl.align]” along with a change of section number,
-7.1.7 to 7.6.2.
+7.1.7 to 7.6.2.
 
<td>
-Change "[dcl.align]" of
-7.6.2 to "[decl.attr.align]".
+Change "[dcl.align]" of
+7.6.2 to "[decl.attr.align]".
<td>
 
<tr valign="top">
<td>
-UK 
-107
+UK 
+107
<td>
-7.6.3
+7.6.3
<td>
 
<td>
-Ed
+Ed
<td>
-While undefined behaviour might be the best we can
+While undefined behaviour might be the best we can
guarantee, it would be helpful to encourage implementations to
-diagnose function definitions that might execute a return.
+diagnose function definitions that might execute a return.
 
<td>
-Adda a [Note
+Adda a [Note
: implementations are encouraged to issue a diagnostic where the
definition of a function marked [[noreturn]] might execute a return
-statement -- end note]
+statement -- end note]
<td>
 
<tr valign="top">
<td>
-UK 
-108
+UK 
+108
<td>
-7.6.4
+7.6.4
<td>
-2
+2
<td>
-Te
+Te
<td>
-It is unclear why no diagnostic is required for an
+It is unclear why no diagnostic is required for an
easily detectable violation. It is even more surprising that the
associated footnote mandates behaviour for an ill-formed
-program.
+program.
 
<td>
-Strike "no
-diagnostic required" and the associated footnote.
+Strike "no
+diagnostic required" and the associated footnote.
<td>
 
<tr valign="top">
<td>
-US 42
+US 42
<td>
-7.6.4
+7.6.4
<td>
 
<td>
-te
+te
<td>
-The meaning of the <code>[[final]]</code> attribute applied to classes is inconsistent with
-other languages and not desirable in its own right.
+The meaning of the <code>[[final]]</code> attribute applied to classes is inconsistent with
+other languages and not desirable in its own right.
 
<td>
-Modify the semantics of <code>[[final]]</code> applied to classes. See the attached paper "Issues
-with the C++ Standard" under Chapter 7 "Meaning of
-<code>[[final]]</code> attribute applied to classes".
+Modify the semantics of <code>[[final]]</code> applied to classes. See the attached paper "Issues
+with the C++ Standard" under Chapter 7 "Meaning of
+<code>[[final]]</code> attribute applied to classes".
 
<td>
 
<tr valign="top">
<td>
-UK 
-109
+UK 
+109
<td>
-7.6.5
+7.6.5
<td>
-4
+4
<td>
-Ed
+Ed
<td>
-The example code refers in comments to
+The example code refers in comments to
"Compilation unit" A and B. The term should be "Translation unit"
-(2/1)
+(2/1)
 
<td>
-Replace
-"Compilation" with "Translation" in two places
+Replace
+"Compilation" with "Translation" in two places
<td>
 
<tr valign="top">
@@ -5454,290 +4835,223 @@
 
<tr valign="top">
<td>
-UK 
-110
+UK 
+110
<td>
-7.6.5
+7.6.5
<td>
-4
+4
<td>
-Te
+Te
<td>
-The code in the example (compilation unit A) has:
+The code in the example (compilation unit A) has:
"foo_head[i].load(memory_order_consume)". foo_head[i] is of type
-foo *, so it does not have a load member.
+foo *, so it does not have a load member.
 
<td>
-Change the
-type of foo_head to atomic<foo *>[].
+Change the
+type of foo_head to atomic<foo *>[].
<td>
 
<tr valign="top">
<td>
-US 43
+US 43
<td>
-8
+8
<td>
 
<td>
-te
+te
<td>
-With the introduction of late-specified return
+With the introduction of late-specified return
types for functions and lambda expressions, we now have three
-different syntaxes for declaring functions. The
-<code>-></code> late declaration is used in two. The
-<code>auto</code> keyword is used in one, but also used differently
-in variable definitions.
+different syntaxes for declaring functions. The 
+<code>-></code> late declaration is used in two. The
+<code>auto</code> keyword is used in one, but also used differently
+in variable definitions.
 
<td>
-Some simplification is needed.
+Some simplification is needed.
<td>
 
<tr valign="top">
<td>
-UK 
-111
+UK 
+111
<td>
-8.3.5
+8.3.5
<td>
-13
+13
<td>
-Ed
+Ed
<td>
-Example missing closing bracket in
-template<typename... T> void f(T (* ...t)(int, int);
+Example missing closing bracket in
+template<typename... T> void f(T (* ...t)(int, int);
 
<td>
-Add closing
+Add closing
bracket like this: template<typename... T> void f(T (*
-...t)(int, int));
+...t)(int, int));
<td>
 
<tr valign="top">
<td>
-US 44
+US 44
<td>
-8.3.5
+8.3.5
<td>
-13
+13
<td>
-ed
+ed
<td>
-In the Example, "template void f(T (*
-...t)(int, int);" is missing a close parenthesis.
+In the Example, "template void f(T (*
+...t)(int, int);" is missing a close parenthesis.
 
<td>
-It presumably should read: "template void f(T (*
-...t))(int, int);".
+It presumably should read: "template void f(T (*
+...t))(int, int);".
<td>
 
<tr valign="top">
<td>
-US 45
+US 45
<td>
-8.3.5
+8.3.5
<td>
-13
+13
<td>
-te
+te
<td>
-At present, function
+At present, function
parameter packs can only occur at the end of a
parameter-declaration-list. This restriction unnecessarily
prohibits uses of function parameter packs in cases where template
-argument deduction isn’t needed, e.g.,
+argument deduction isn’t needed, e.g.,
 
-template<class...
-T> struct X { };
-template<class... T1,
-class... T2>
-struct X<pair<T1,
-T2>...> {
-void f(T1...,
-T2...);
-};
+template<class...
+T> struct X { };
+template<class... T1,
+class... T2>
+struct X<pair<T1,
+T2>...> {
+void f(T1...,
+T2...);
+};
 
-More importantly, this
+More importantly, this
restriction is inconsistent with the way pack expansions are
handled. For example, this template is well-formed (but X<T...,
-int> is a non-deduced context):
+int> is a non-deduced context):
 
-template<class...
-T> void f(X<T..., int>);
+template<class...
+T> void f(X<T..., int>);
 
-Therefore, the restriction that limits function
+Therefore, the restriction that limits function
parameter packs to the end of the parameter-declaration-list should
be removed. Instead, function parameter packs not at the end of the
parameter-declaration-list should be considered non-deduced
-contexts.
+contexts.
<td>
-In 8.3.5p13, remove the sentence
-“A function parameter pack, if
+In 8.3.5p13, remove the sentence
+“A function parameter pack, if
present, shall occur at the end of the
-parameter-declaration-list.”
+parameter-declaration-list.”
 
-In 14.8.2.1p1, replace the phrase
+In 14.8.2.1p1, replace the phrase
“For a function parameter pack” with “For a
-function parameter pack that occurs at the end of a
-parameter-declaration-list”.
+function parameter pack that occurs at the end of a parameter-declaration-list”.
 
-Replace the note text “A
+Replace the note text “A
function parameter pack can only occur at the end of a
-parameter-declaration-list (8.3.5).” with
+parameter-declaration-list (8.3.5).” with
“A function parameter pack that does not occur at the end of
a parameter-declaration-list is a non-deduced
-context.”
+context.”
 
-In 14.8.2.5p5, add a new
+In 14.8.2.5p5, add a new
bullet: “A function parameter pack that does not occur at the
-end of its parameter-declaration-list.”
+end of its parameter-declaration-list.”
 
-In 14.8.2.5p10, replace
-“If the
+In 14.8.2.5p10, replace
+“If the
parameter-declaration corresponding to Pi is a function parameter
-pack” with “If the parameter-declaration corresponding to Pi
+pack” with “If the parameter-declaration corresponding to Pi
is a function parameter pack and Pi occurs at the end of the
parameter-declaration-list”.
 
-Replace the note
+Replace the note
text “A function parameter pack can only occur at the end of
-a parameter-declaration-list (8.3.5).” with
+a parameter-declaration-list (8.3.5).” with
“A function parameter pack that does not occur at the end of
a parameter-declaration-list is a non-deduced
-context.”
+context.”
 
<td>
 
<tr valign="top">
<td>
-DE-13
+DE-13
<td>
-8.4
+8.4
<td>
-p2
+p2
<td>
-te
+te
<td>
-DE-13 The second
+DE-13 The second
paragraph, quoting the grammar for the declarator of a function
declaration, is not considering late-specified return types and
-attributes.
+attributes.
<td>
-Properly quote the grammar
-from 8.3.5.
+Properly quote the grammar
+from 8.3.5.
<td>
 
<tr valign="top">
<td>
-JP 16
+JP 16
<td>
-8.5
+8.5
<td>
-15th paragraph, 1st line
+15th paragraph, 1st line
 
<td>
-ed
+ed
<td>
-Typo, duplicated "in"
-"The initialization that occurs in in the
-forms"
+Typo, duplicated "in"
+"The initialization that occurs in in the
+forms"
<td>
-Remove one.
+Remove one.
<td>
 
<tr valign="top">
<td>
-US 46
+US 46
<td>
-8.5.3
+8.5.3
<td>
 
<td>
-te
+te
<td>
-The ability for an rvalue
+The ability for an rvalue
reference to bind to an lvalue opens a type-safety hole that
becomes very dangerous with concepts. For example, consider
-vector’s push_back operation:
-requires
-MoveConstructible<T> void push_back(T&&);
-requires
-CopyConstructible<T> void push_back(const T&);
+vector’s push_back operation:
+requires
+MoveConstructible<T> void push_back(T&&);
+requires
+CopyConstructible<T> void push_back(const T&);
 
-For a copy-constructible
+For a copy-constructible
T (which is also move-constructible), push_back does the right
thing. However, if T is something that is move-constructible (e.g.,
unique_ptr<int>), the second overload is removed from
@@ -5745,227 +5059,183 @@
first overload remains. Therefore, one could accidentally call
push_back with an lvalue of type T, and push_back would silently
move from the lvalue. The same problem occurs without concepts
-(albeit less frequently).
+(albeit less frequently).
 
 
<td>
-Prohibit rvalue
-references from binding to lvalues.
+Prohibit rvalue
+references from binding to lvalues.
 
-Unfortunately this change
+Unfortunately this change
will break some current use cases of rvalue reference including the
use of rvalue streams, and of the forward function itself. To
resolve this we may want to consider three types of
-references:
+references:
 
<ol>
<li>
-The current
-reference.
+The current
+reference.
<li>
-A non-const reference
-that only binds to rvalues.
+A non-const reference
+that only binds to rvalues.
<li>
-A non-const reference
-that will bind to both lvalues and rvalues.</ol>
+A non-const reference
+that will bind to both lvalues and rvalues.</ol>
 
-Still another solution would be to adopt the
+Still another solution would be to adopt the
“deleted function” solution for all functions. This
solution is described in comment for 12.1, 12.4, 12.8, but
restricted to special functions in that comment. (See US
-NN).
+NN).
<td>
 
<tr valign="top">
<td>
-US 49
+US 49
<td>
-8.5.4
+8.5.4
<td>
-6
+6
<td>
-ed
+ed
<td>
-In the Example, the comments could be
-improved.
+In the Example, the comments could be
+improved.
<td>
-See the attached paper "Issues with the
-C++ Standard" under "Editorial Issues" and "8.5.4/6".
+See the attached paper "Issues with the
+C++ Standard" under "Editorial Issues" and "8.5.4/6".
 
<td>
 
<tr valign="top">
<td>
-UK 
-112
+UK 
+112
<td>
-9
+9
<td>
-4-9
+4-9
<td>
-Ge
+Ge
<td>
-We now have concepts that should (or should not?)
+We now have concepts that should (or should not?)
map to the terms described in Clause 9 - these should be at least
-referenced.
+referenced.
 
<td>
-Add
-appropriate forward references to 14.9.4
+Add
+appropriate forward references to 14.9.4
<td>
 
<tr valign="top">
<td>
-UK 
-113
+UK 
+113
<td>
-9.4.2
+9.4.2
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-Mis-applied
-edit from the paper n2756
+Mis-applied
+edit from the paper n2756
<td>
-The term
+The term
'constant-initializer' should have been struck out when replaced by
brace-or-equal-initializer. There are two occurrences in this
-paragraph
+paragraph
<td>
 
<tr valign="top">
<td>
-US 50
+US 50
<td>
-12.1, 12.4, 12.8
+12.1, 12.4, 12.8
<td>
 
<td>
-te
+te
<td>
-Implicitly-declared
+Implicitly-declared
default constructors, destructors, copy constructors, and copy
assignment operators are deleted when their definitions would be
ill-formed. However, unlike with overloading and template argument
deduction, access control is performed as part of the check for
making one of these special function deleted. This inconsistency
-should be removed.
+should be removed.
 
-This change would
+This change would
sacrifice some backward compatibility in favor of consistency. With
the current wording, checking that the following class
‘A’ is CopyConstructible would proceed without error
-(it is not CopyConstructible):
-class A { A(const
-A&); };
-With the proposed change,
+(it is not CopyConstructible):
+class A { A(const
+A&); };
+With the proposed change,
testing whether A is CopyConstructible would produce a diagnostic.
To fix the problem, the user would have to use a deleted
-function:
-class A { A(const A&)
-= delete; };
+function:
+class A { A(const A&)
+= delete; };
 
<td>
-In 12.1p5, remove the phrase
-“or inaccessible from the
-implicitly-declared default constructor”.
+In 12.1p5, remove the phrase
+“or inaccessible from the
+implicitly-declared default constructor”.
 
-In 12.4p3, remove the phrase
-“or a destructor that is
+In 12.4p3, remove the phrase
+“or a destructor that is
inaccessible from the implicitly-declared destructor,” and
the phrase “or a destructor that is inaccessible from
-the implicitly-declared
-destructor”.
+the implicitly-declared
+destructor”.
 
-In 12.8p5, remove the phrase
-“or inaccessible from the
+In 12.8p5, remove the phrase
+“or inaccessible from the
implicitly-declared copy constructor” from the two places it
-occurs.
+occurs.
 
-In 12.8p10, remove the phrase
-“or inaccessible from the
+In 12.8p10, remove the phrase
+“or inaccessible from the
implicitly-declared copy assignment operator” from the two
-places it occurs.
+places it occurs.
 
<td>
 
<tr valign="top">
<td>
-FR 28
+FR 28
<td>
-12.6.1 [Explicit initialization]
+12.6.1 [Explicit initialization]
 
<td>
 
<td>
-te
+te
<td>
-This section, in particular the example with
+This section, in particular the example with
`g' appears contradictory with the syntax for uniform
-initialization.
+initialization.
<td>
 
<td>
 
<tr valign="top">
<td>
-US 51
+US 51
<td>
-12.6.2
+12.6.2
<td>
-2
+2
<td>
-ed
+ed
<td>
-The discussion of delegating
-constructors should be in its own paragraph.
+The discussion of delegating
+constructors should be in its own paragraph.
 
<td>
 
@@ -5973,27 +5243,25 @@
 
<tr valign="top">
<td>
-UK 
-114
+UK 
+114
<td>
-12.6.2
+12.6.2
<td>
-1
+1
<td>
-Te
+Te
<td>
-Despite all
+Despite all
the attempts to unify initialization syntax, it is still not
possible to copy-initialize base classes or non-static data
members, which means the explicit keyword cannot have a bearing
during evaluation of a constructor. A minimal addition to the
grammar, allowing an optional = between the mem-initializer-id and
braced-init-list would allow the user to choose between copy and
-direct initialization
+direct initialization
<td>
-Ammend the grammar for mem-initializer:
+Ammend the grammar for mem-initializer:
mem-initializer-id =OPT braced-init-list Extend p3 to allow for
Copy Initialization if the optional = is present: 3 The
expression-list or braced-init-list in a mem-initializer is used to
@@ -6001,41 +5269,39 @@
denoted by the mem-initializer-id according to the initialization
rules of 8.5 for direct-initialization, OR COPY-INITIALIZATION IF
THE OPTIONAL = IS PRESENT BETWEEN THE MEM-INITIALIZER-ID and the
-BRACED-INIT-LIST. [Example:...
+BRACED-INIT-LIST. [Example:...
 
<td>
 
<tr valign="top">
<td>
-US 52
+US 52
<td>
-13.5.8
+13.5.8
<td>
-¶ 5
+¶ 5
<td>
-ed
+ed
<td>
-A word is
-misspelled.
+A word is
+misspelled.
<td>
-Change “shal”
-to “shall”.
+Change “shal”
+to “shall”.
<td>
 
<tr valign="top">
<td>
-UK 
-115
+UK 
+115
<td>
-14
+14
<td>
-6-11
+6-11
<td>
-Ge
+Ge
<td>
-Exported templates were a great idea that is
+Exported templates were a great idea that is
generally understood to have failed. In the decade since the
standard was adopted, only one implementation has appeared. No
current vendors appear interested in creating another. We
@@ -6044,297 +5310,255 @@
exported constrained templates become an important compile-time
optimization, as the constraints would be checked once in the
exported definition and not in each translation unit consuming the
-exported declarations.
+exported declarations.
 
<td>
-Consider
+Consider
deprecating exported templates, but no action yet. Examine
interaction with constrained templates, and see if other more
appropriate mechanism will support compile-time
-optimization.
+optimization.
<td>
 
<tr valign="top">
<td>
-UK 
-116
+UK 
+116
<td>
-14
+14
<td>
-6-11
+6-11
<td>
-Te
+Te
<td>
-Is it possible to export a concept map template?
+Is it possible to export a concept map template?
The current wording suggests it is possible, but it is not entirely
-clear what it would mean.
+clear what it would mean.
 
<td>
-Either
+Either
prohibit exporting concept map templates, or more directly address
-what it means to export a concept map.
+what it means to export a concept map.
<td>
 
<tr valign="top">
<td>
-UK 
-117
+UK 
+117
<td>
-14
+14
<td>
-2
+2
<td>
-Ge
+Ge
<td>
-It would be nice to allow template alias within a
+It would be nice to allow template alias within a
function scope, and possibly a scoped concept map. As these affect
name lookup and resolution, rather than defining new callable code,
they are not seen to present the same problems that prevented class
-and function templates in the past.
+and function templates in the past.
 
<td>
-Allow
+Allow
template aliases to be declared inside a function scope, and
-consider scoped concept maps.
+consider scoped concept maps.
<td>
 
<tr valign="top">
<td>
-UK 
-118
+UK 
+118
<td>
-14
+14
<td>
-6-11
+6-11
<td>
-Ed
+Ed
<td>
-Exported templates are a complicated feature with
+Exported templates are a complicated feature with
surprisingly little text. To make this important text more visible,
-split it off into its own subclause [temp.export]
+split it off into its own subclause [temp.export]
 
<td>
-Create a new
+Create a new
subclause [temp.export] containing 14p6-11. Move 14p12 ahead of
-this subclause.
+this subclause.
<td>
 
<tr valign="top">
<td>
-UK 
-119
+UK 
+119
<td>
-14
+14
<td>
-4
+4
<td>
-Te
+Te
<td>
-Does a concept map have linkage? Reading this
+Does a concept map have linkage? Reading this
paragraph and 3.5 suggests a concept map template has external
linkage, but not a 'regular' concept map. Believe this is an
oversight that the linkage words were not updated to provide an
-exception, rather than linkage of concept maps is intended.
+exception, rather than linkage of concept maps is intended.
 
<td>
-Add an
+Add an
exception that concept map templates have no linkage, or add
-concept maps to the list of entities with linkage in 3.5
+concept maps to the list of entities with linkage in 3.5
<td>
 
<tr valign="top">
<td>
-UK 
-120
+UK 
+120
<td>
-14.1
+14.1
<td>
-9
+9
<td>
-Ed
+Ed
<td>
-As this is the first time the phrase
+As this is the first time the phrase
“parameter pack” appears in Ch 14 I would like to see
-the section 8.3.5 referenced here (as well as in 14.1p17).
+the section 8.3.5 referenced here (as well as in 14.1p17).
 
<td>
-Insert
-“(8.3.5)” after “parameter pack”
+Insert
+“(8.3.5)” after “parameter pack”
<td>
 
<tr valign="top">
<td>
-UK 
-121
+UK 
+121
<td>
-14.1
+14.1
<td>
-18
+18
<td>
-Ed
+Ed
<td>
-The example (that follows the normative text) has
-no begin example marker
+The example (that follows the normative text) has
+no begin example marker
 
<td>
-Prefix the
-example code with "[ Example:"
+Prefix the
+example code with "[ Example:"
<td>
 
<tr valign="top">
<td>
-FR 29
+FR 29
<td>
-14.3 [Template arguments]
+14.3 [Template arguments]
 
<td>
 
<td>
-te
+te
<td>
-Constant expressions of any literal type should
-be allowed as template arguments.
+Constant expressions of any literal type should
+be allowed as template arguments.
<td>
 
<td>
 
<tr valign="top">
<td>
-US 53
+US 53
<td>
-14.5.1
+14.5.1
<td>
-5
+5
<td>
-te
+te
<td>
-If the requirements of a constrained member
+If the requirements of a constrained member
that is a copy constructor, copy assignment operator, or destructor
are not satisfied, then that user-declared special function will
not exist. It appears that, in this case, the special function will
-then be implicitly defined, which is likely
+then be implicitly defined, which is likely
to either (a) fail to compile or (b) produce a function with the
wrong semantics. For example:
-template<ObjectType
-T> class vector {
-T* first, last,
-end;
-public:
-requires
-CopyConstructible<T> vector(const vector&);
-};
+template<ObjectType
+T> class vector {
+T* first, last,
+end;
+public:
+requires
+CopyConstructible<T> vector(const vector&);
+};
 
-If instantiated with a type that is not
+If instantiated with a type that is not
CopyConstructible, vector will get an implicitly-defined copy
-constructor that performs a copy of the pointers.
+constructor that performs a copy of the pointers.
<td>
-Add to 14.5.1p5:
-If the constrained member is a copy constructor
+Add to 14.5.1p5:
+If the constrained member is a copy constructor
(12.8), destructor (12.4), or copy assignment operator and its
template requirements are not satisfied, then a copy constructor,
destructor, or copy assignment operator, respectively, with the
same signature as the constrained member (after substituting the
class template’s template arguments for its template
-parameters) will be declared as a deleted function (8.4).
+parameters) will be declared as a deleted function (8.4).
<td>
 
<tr valign="top">
<td>
-UK 
-122
+UK 
+122
<td>
-14.5.3
+14.5.3
<td>
-4
+4
<td>
-Te
+Te
<td>
-Variadic templates should be supported in axioms.
+Variadic templates should be supported in axioms.
There are axioms in the library that rely on this feature, such as
the FrontEmplacement axiom in FrontEmplacementContainer
-(23.1.6.1p10)
+(23.1.6.1p10)
 
<td>
-Add
+Add
clarification in p2 that function parameter packs can be used to
declare axioms, much like p1 clarifies they can be used to declare
-concepts as well as templates.
+concepts as well as templates.
<td>
 
<tr valign="top">
<td>
-FR 30
+FR 30
<td>
-14.5.7 [Template aliases]
+14.5.7 [Template aliases]
<td>
 
<td>
-te
+te
<td>
-When are two template alias names
-equivalent?
+When are two template alias names
+equivalent?
 
-E.g. given
-template<template<class>
-class> struct X { };
+E.g. given
+template<template<class>
+class> struct X { };
 
-template<typename,typename> struct Y
-{ };
+template<typename,typename> struct Y
+{ };
 
-template<typename T>
-using Z1 = Y<int,T>;
+template<typename T>
+using Z1 = Y<int,T>;
 
-template<typename T>
-using Z2 = Y<int,T>;
+template<typename T>
+using Z2 = Y<int,T>;
 
-Are the types X<Z1> and X<Z2>
-equivalent?
-We would suggest yes (since Z1<T>
+Are the types X<Z1> and X<Z2>
+equivalent?
+We would suggest yes (since Z1<T>
and Z2<T> are the same for all T), but we do not see any
-wording to that effect.
+wording to that effect.
 
<td>
 
@@ -6342,237 +5566,202 @@
 
<tr valign="top">
<td>
-JP 17
+JP 17
<td>
-14.7.2
+14.7.2
<td>
-2nd paragraph, 15th line
+2nd paragraph, 15th line
<td>
-ed
+ed
<td>
-Typo.
-if that namespace is inline, any
-namespace from its enclosing namespace set.
+Typo.
+if that namespace is inline, any
+namespace from its enclosing namespace set.
 
-should be
+should be
 
-if that namespace is inline, any namespace
-forming its
-enclosing namespace set.
+if that namespace is inline, any namespace 
+forming its
+enclosing namespace set.
 
<td>
-Replace "from" with
-"forming"
+Replace "from" with
+"forming"
<td>
 
<tr valign="top">
<td>
-DE-14
+DE-14
<td>
-14.7.3
+14.7.3
<td>
-p1
+p1
<td>
-te
+te
<td>
-DE-14 The bulleted list
+DE-14 The bulleted list
neither addresses "member function template of a class" nor "member
-class template of a class".
+class template of a class".
<td>
-Add the respective
-bullets.
+Add the respective
+bullets.
<td>
 
<tr valign="top">
<td>
-JP 18
+JP 18
<td>
-14.7.3
+14.7.3
<td>
-2nd paragraph, 2nd line
+2nd paragraph, 2nd line
<td>
-ed
+ed
<td>
-Typo,
-any namespace from its enclosing
-namespace set
+Typo,
+any namespace from its enclosing
+namespace set
 
-should be
+should be
 
-any namespace forming its enclosing namespace set
+any namespace forming its enclosing namespace set
 
<td>
-Replace "from" with
-"forming"
+Replace "from" with
+"forming"
<td>
 
<tr valign="top">
<td>
-JP 19
+JP 19
<td>
-14.8.2
+14.8.2
<td>
-6th paragraph, 1st line
+6th paragraph, 1st line
<td>
-ed
+ed
<td>
-Typo, duplicated "is"
+Typo, duplicated "is"
"At certain points in the template argument
-deduction process it is is necessary"
+"margin-top: 0.04in; margin-bottom: 0.04in">"At certain points in the template argument
+deduction process it is is necessary"
 
<td>
-Remove one
+Remove one
<td>
 
<tr valign="top">
<td>
-US 54
+US 54
<td>

-14.9 [concept],
-14.10
-[temp.constrained]
+14.9 [concept],
+14.10
+[temp.constrained]
<td>
 
<td>
-ge
+ge
<td>
-Concepts is of course the
+Concepts is of course the
largest new feature in C++0x (in terms of new text inserted into
the wording), and already we have found some significant defects
with it. So far nothing devastating has been found, but more time
-is needed to shake more bugs out.
+is needed to shake more bugs out.
<td>
-I propose no specific
-change here.
+I propose no specific
+change here.
<td>
 
<tr valign="top">
<td>
-US 55
+US 55
<td>
-14.9.1
+14.9.1
<td>
-¶ 6
+¶ 6
<td>
-ed
+ed
<td>
-The paragraph number is in
+The paragraph number is in
the wrong place, causing a grammar rule to be indented more than
-its fellows.
+its fellows.
<td>
-Move the paragraph number
+Move the paragraph number
so as to follow the grammar rules, thus numbering the single
-sentence, “The body of a concept … .”
+sentence, “The body of a concept … .”
<td>
 
<tr valign="top">
<td>
-US 56
+US 56
<td>
-14.9.1
+14.9.1
<td>
-¶ 6
+¶ 6
<td>
-ed
+ed
<td>
-The sentence contains two
-references to 14.9.1.3 [concept.req].
+The sentence contains two
+references to 14.9.1.3 [concept.req].
<td>
-Change the second such
+Change the second such
reference (at the end of the sentence) to 14.9.1.4
-[concept.axiom].
+[concept.axiom].
<td>
 
<tr valign="top">
<td>
-US 57
+US 57
<td>
-14.9.1.4
+14.9.1.4
<td>
-¶ 3
+¶ 3
<td>
-ed
+ed
<td>
-A word is misplaced,
-changing the intended meaning.
+A word is misplaced,
+changing the intended meaning.
<td>
-Change “only find
-… if” to “find … only if”.
+Change “only find
+… if” to “find … only if”.
<td>
 
<tr valign="top">
<td>
-US 58
+US 58
<td>
-14.9.1.4
+14.9.1.4
<td>
-¶ 3
+¶ 3
<td>
-ed
+ed
<td>
-The listed phrases are not
-grammatically parallel.
+The listed phrases are not
+grammatically parallel.
<td>
-Insert “in”
+Insert “in”
before “one” so as to obtain “... in the concept,
in one of its less refined concepts, or in an associated
-requirement.”
+requirement.”
<td>
 
<tr valign="top">
<td>
-US 59
+US 59
<td>
-14.9.1.4
+14.9.1.4
<td>
 
<td>
-te
+te
<td>
-Axioms are under-specified and provide little
+Axioms are under-specified and provide little
benefit to programmers, so they should be removed from the working
paper. The optimizations permitted by axioms (see 14.9.1.4p4-5) are
not compulsory (and, therefore, programmers cannot rely on them)
@@ -6582,89 +5771,70 @@
Regular?” starting with c++std-lib-22717). Given the level of
confusion and the inability to verify the correctness of axioms, it
is likely that many axioms written by programmers (including those
-specified in the candidate draft) will be incorrect.
+specified in the candidate draft) will be incorrect.
<td>
-Remove clause 14.9.1.4
-[concept.axiom]
-In 2.11p1, remove
-“axiom” from the list of keywords.
+Remove clause 14.9.1.4
+[concept.axiom]
+In 2.11p1, remove
+“axiom” from the list of keywords.
 
-In 14.5.8p7, remove
+In 14.5.8p7, remove
“, or if the resulting concept map fails to satisfy the
-axioms of the corresponding concept”
+axioms of the corresponding concept”
 
-In 14.9.1p6, remove
+In 14.9.1p6, remove
axiom-definition from the list of grammar productions for
concept-member-specifier. Remove “, and axioms” from
the final sentence, and instead “and” prior to
-“associated requirements” in the final sentence.
+“associated requirements” in the final sentence.
 
 
-Remove paragraph 14 of
-clause 14.9.2.
+Remove paragraph 14 of
+clause 14.9.2.
 
-In 14.10.1p6, remove the sentence, “When
+In 14.10.1p6, remove the sentence, “When
the concept-instance-alias-def appears in the optional
requires-clause of an axiom-definition (14.9.1.4), the potential
scope of the identifier begins at its point of declaration and
terminates at the end of the
-axiom-deﬁnition.”
+axiom-deﬁnition.”
 
-In clauses 20.2.5, 20.2.8, 23.1.6.1, 23.1.6.2,
+In clauses 20.2.5, 20.2.8, 23.1.6.1, 23.1.6.2,
and 24.1.4, remove the axiom-definitions and replace them with
paragraphs (denoted Requires, Postconditions, or Effects, as
appropriate) that express the intended semantics of the concepts
-from which the axiom-definitions were removed.
+from which the axiom-definitions were removed.
 
-In 24.1.4p2, replace the
-word “axiom” with “condition.”
+In 24.1.4p2, replace the
+word “axiom” with “condition.”
 
<td>
 
<tr valign="top">
<td>
-FR 31
+FR 31
<td>
-14.9.1.4 [Axioms]
+14.9.1.4 [Axioms]
<td>
 
<td>
-te
+te
<td>
-This section states that an
+This section states that an
axiom-definition defines a new semantics axiom but is unusually
-vague as to what those semantics might be.
+vague as to what those semantics might be.
 
-The use of the '==' and '!=' with
+The use of the '==' and '!=' with
completely new semantics, unrelated to anything we have seen before
in C++ is both unwise and confusing, especially if the types
involved in the expressions happen to have operator== and
-operator!= defined.
-We strongly suggest use
-of different tokens, e.g. , and opposed to
-this obscure usage/overload.
-The description is very vague. How many
+operator!= defined.
+We strongly suggest use
+of different tokens, e.g. , and opposed to
+this obscure usage/overload.
+The description is very vague. How many
times is an implementation permitted to replace one expression by
-another one when they have side effects?
+another one when they have side effects?
 
<td>
 
@@ -6672,245 +5842,222 @@
 
<tr valign="top">
<td>
-DE-15
+DE-15
<td>
-14.9.1.4
+14.9.1.4
<td>
 
<td>
-te
+te
<td>
-DE-15 There is no
+DE-15 There is no
implementation experience for axioms. Use of axioms is an area of
active scientific research. It is likely that syntax changes will
become necessary to make good use of axioms; having the syntax
space already crowded is unhelpful. Axioms ought to be useful in
concepts applicable to floating-point types (such as
EqualityComparable), but IEEE floating-point types have special
-values such as NaN violating the axioms.
+values such as NaN violating the axioms.
<td>
-Remove section 14.9.1.4
+Remove section 14.9.1.4
and any reference to axioms in the rest of the proposed standard
-other than the keyword reservation in section 2.11.
+other than the keyword reservation in section 2.11.
<td>
 
<tr valign="top">
<td>
-UK 
-123
+UK 
+123
<td>
-14.9.1.4
+14.9.1.4
<td>
 
<td>
-Te
+Te
<td>
-auto concepts and axioms are incompatible. An
+auto concepts and axioms are incompatible. An
axiom defines the semantics of an operaton or set of operations
that describes the run time behaviour. A concept describes purely
syntactic requirements at compile time. Where an auto concept will
match anything that meets the syntax requirements, there is no way
to know if the axioms will be met or not, and no way to opt out via
-some kind of negative concept map.
+some kind of negative concept map.
 
<td>
-Add a
-paragraph making axioms ill-formed inside an auto concept.
+Add a
+paragraph making axioms ill-formed inside an auto concept.
<td>
 
<tr valign="top">
<td>
UK 
-124
+"margin-right: -0.18in; margin-bottom: 0in">UK 
+124
 
<td>
-14.9.1.4
+14.9.1.4
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-Spelling
-mistake, double-e in were.
+Spelling
+mistake, double-e in were.
<td>
-weere ->
-were
+weere ->
+were
<td>
 
<tr valign="top">
<td>
-UK 
-125
+UK 
+125
<td>
-14.9.1.4
+14.9.1.4
<td>
-2
+2
<td>
-Te
+Te
<td>
-The implicit equality comparison operator
+The implicit equality comparison operator
available to axioms has no semantic. It is not clear what
expressing the condition if( a == b ) { conditional-axiom } would
mean if a and b are not truly EqualityComparable. We suspect the
intent of the 'implicit defefinition' is to support declaring the
equivalence of statements, a context where the operator will not
-actually be evaluated.
+actually be evaluated.
 
<td>
-Define the
+Define the
semantics of the implicitly declared comparison operators, or
restrict their usage to declaring equivalence between
-statements.
+statements.
<td>
 
<tr valign="top">
<td>
-UK 
-126
+UK 
+126
<td>
-14.9.4
+14.9.4
<td>
-41
+41
<td>
-Ed
+Ed
<td>
-This paragraph contains the only definition of the
-underlying_type member - but it's a note, so not normative.
+This paragraph contains the only definition of the
+underlying_type member - but it's a note, so not normative.
 
<td>
-Move the
-second sentence to the Requires clause in paragraph 42.
+Move the
+second sentence to the Requires clause in paragraph 42.
<td>
 
<tr valign="top">
<td>
-UK 
-127
+UK 
+127
<td>
-14.9.4
+14.9.4
<td>
 
<td>
-Ed
+Ed
<td>
-Provide a diagram clearly showing refinement
+Provide a diagram clearly showing refinement
relationship between the different support concepts. Several were
created during development of this clause and they were very
-helpful.
+helpful.
 
<td>
-Provide the
-diagram.
+Provide the
+diagram.
<td>
 
<tr valign="top">
<td>
-UK 
-128
+UK 
+128
<td>
-14.9.4
+14.9.4
<td>
-4
+4
<td>
-Ed
+Ed
<td>
-It is
+It is
surprising for many people that non-copyable move-only types can be
used with a return statement, and so Returnable does not always
-imply CopyConstructible.
+imply CopyConstructible.
<td>
-A non-normative note: [Note: 'move only' types
+A non-normative note: [Note: 'move only' types
that are constructible from rvalue references may be Returnable,
-but not CopyConstructible(20.1.8) - end note]
+but not CopyConstructible(20.1.8) - end note]
 
<td>
 
<tr valign="top">
<td>
-JP 20
+JP 20
<td>
-14.9.4
+14.9.4
<td>
-2nd paragraph
+2nd paragraph
<td>
-te
+te
<td>

-Trivially copyable type was
+Trivially copyable type was
added in “3.9 Types”, so we think that it is necessary
to add concept to trivially copyable type like
-“TriviallyCopyableType”.
+“TriviallyCopyableType”.
 
<td>
-Add TriviallyCopyableType that is
-trivially copyable type as concept.
+Add TriviallyCopyableType that is
+trivially copyable type as concept.
<td>
 
<tr valign="top">
<td>
-UK 
-129
+UK 
+129
<td>
-14.10.1,
-20.1.2
+14.10.1,
+20.1.2
<td>
 
<td>
-Te
+Te
<td>
-It should be possible to support boolean constant
+It should be possible to support boolean constant
expressions as requirements without resorting to defining the True
concept in the library. Boolean expressions are very likely to be
constraints when deadline with non-type template parameters and
variadic templates, and constraints in these cases should feel just
-as natural as constraints on the type system.
+as natural as constraints on the type system.
 
<td>
-Remove the
+Remove the
True concept and library subclause 20.1.2. Provide support in
14.10.1 for boolean constant expressions as constraints. This may
involve overloading the true keyword to disambiguate but ideally
-would not.
+would not.
<td>
 
<tr valign="top">
<td>
-US 60
+US 60
<td>
-14.10.1
+14.10.1
<td>
-1
+1
<td>
-te
+te
<td>
-The use of && as the separator for a
+The use of && as the separator for a
list of requirements has shown itself to be a serious teachability
problem. The mental model behind ‘&&’ treats
concepts as simple predicates, which ignores the role of concepts
@@ -6918,476 +6065,423 @@
‘&&’ (and especially try to fake || with
&& and !), the harder it is for them to understand the role
of concept maps. Simply changing the separator to ‘,’
-would eliminate a significant source of confusion.
+would eliminate a significant source of confusion.
<td>
-Replace
-requirement-list:
-requirement-list ...
-[opt] && requirement
-requirement ...
-[opt]
- 
-with
- 
-requirement-list
-requirement-list ...[opt]
-, requirement
-requirement ...
-[opt]
- 
-In 14.5.4p6, replace the
-first sentence with:
-The instantiation of an
+Replace
+requirement-list:
+requirement-list ...
+[opt] && requirement
+requirement ...
+[opt]
+ 
+with
+ 
+requirement-list
+requirement-list ...[opt]
+, requirement
+requirement ...
+[opt]
+ 
+In 14.5.4p6, replace the
+first sentence with:
+The instantiation of an
expansion produces a comma-separated list E1, E2, ..., EN, where N
-is the number of elements in the pack expansion parameters.
+is the number of elements in the pack expansion parameters.
 
<td>
 
<tr valign="top">
<td>
-UK 
-130
+UK 
+130
<td>
-15.1
+15.1
<td>
-4
+4
<td>
-Te
+Te
<td>
-With the new crrent_exception API it is possible
+With the new crrent_exception API it is possible
to capture a reference to an exception that will outlive its last
active handler. That is in conflict with the sentance "When the
last remaining active handler for the exception exits by any means
other than throw; the temporary object is destroyed and the
implementation may deallocate the memory for the temporary
-object;"
+object;"
 
<td>
-Update
+Update
sentence to allow for exceptions held in excpetion_ptr
-objects.
+objects.
<td>
 
<tr valign="top">
<td>
-UK 
-131
+UK 
+131
<td>
-15.3
+15.3
<td>
-3
+3
<td>
-Te
+Te
<td>
-A handler catching its parameter by
+A handler catching its parameter by
rvalue-reference is syntactically valid, but will never be
-activated.
+activated.
 
<td>
-Disallow
-handlers catching by rvalue-reference.
+Disallow
+handlers catching by rvalue-reference.
<td>
 
<tr valign="top">
<td>
-UK 
-132
+UK 
+132
<td>
-15.3
+15.3
<td>
-16
+16
<td>
-Te
+Te
<td>
-There are obscure cases whrere a copy constructor
+There are obscure cases whrere a copy constructor
is not usually the best match to copy-initialize an object, e.g. A
converting constructor template taking arguments by non-const
reference. A footnote explaining such cases would be helpful, or
the sentance could be rewritten using copy-initialization instead
-of directly calling a copy constructor.
+of directly calling a copy constructor.
 
<td>
-Rewite using
+Rewite using
copy-initialization rather than directly invoking the copy
-constructor
+constructor
<td>
 
<tr valign="top">
<td>
-UK 
-133
+UK 
+133
<td>
-15.4
+15.4
<td>
-2
+2
<td>
-Te
+Te
<td>
-Template aliases have the same semantics as a
-typedef so should also be disallowed
+Template aliases have the same semantics as a
+typedef so should also be disallowed
 
<td>
-add "or
+add "or
alias-declaration" after "shall not appear in a typedef
-declaration".
+declaration".
<td>
 
<tr valign="top">
<td>
-UK 
-134
+UK 
+134
<td>
-15.4
+15.4
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-The sentance "An exception-specification can also
+The sentance "An exception-specification can also
include the class std::bad_exception (18.7.2.1)." is
-redundant.
+redundant.
 
<td>
-Either strike
+Either strike
the quoted sentance, or add a note explaining why it is worth
-calling special attention to this class.
+calling special attention to this class.
<td>
 
<tr valign="top">
<td>
-UK 
-135
+UK 
+135
<td>
-15.4
+15.4
<td>
-8
+8
<td>
-Te
+Te
<td>
-Unclear if
+Unclear if
std::unexpected is called before or after the function arguments
-have been destroyed
+have been destroyed
<td>
-Clarify the
+Clarify the
sequence of calling unexpected with respect to interesting objects,
such as function arguments or partially constructed bases and
-members when called from a constructor or destructor
+members when called from a constructor or destructor
<td>
 
<tr valign="top">
<td>
-UK 
-136
+UK 
+136
<td>
-15.4
+15.4
<td>
 
<td>
-Ge
+Ge
<td>
-Exception
+Exception
specifications have proven close to worthless in practice, while
adding a measurable overhead to programs. The feature should be
deprecated. The one exception to the rule is the empty throw
specification which could serve a legitimate optimizing role if the
requirement to call the runtime unexpected mechanism was relaxed in
-this case.
+this case.
<td>
-Move 15.4 and
+Move 15.4 and
the parts of 15.5 that refer to it to Appendix D. Replace 15.4 with
a simpler specification for empty throw specifications, where the
std::unexpected call is conditionally supported allowing vendors to
choose between optimizing and providing runtime checks. Ideally
require vendors to provide a mode where the runtime checks are
-always disabled.
+always disabled.
<td>
 
<tr valign="top">
<td>
-UK 
-137
+UK 
+137
<td>
-15.5
+15.5
<td>
 
<td>
-Ed
+Ed
<td>
-There is no mention of the current_exception API
+There is no mention of the current_exception API
which can extend the lifetime of an exception object. There should
-at least be a forward reference to the library clause 18.7.5
+at least be a forward reference to the library clause 18.7.5
 
<td>
-Add another
+Add another
paragraph outlining 18.7.5 and the ability of an exception_ptr to
-extend the lifetime of an exception object
+extend the lifetime of an exception object
<td>
 
<tr valign="top">
<td>
-UK 
-138
+UK 
+138
<td>
-15.5.1
+15.5.1
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-The third bullet is redundant with the first, as
-it is a subset of the same conditions.
+The third bullet is redundant with the first, as
+it is a subset of the same conditions.
 
<td>
-Merge the
-third bullet into the first bullet as a note or example.
+Merge the
+third bullet into the first bullet as a note or example.
<td>
 
<tr valign="top">
<td>
-UK 
-139
+UK 
+139
<td>
-15.5.1
+15.5.1
<td>
-1
+1
<td>
-Te
+Te
<td>
-According to the first bullet it is perfectly
+According to the first bullet it is perfectly
alright for a library function to exit by throwing an exception
-during stack unwinding, This is clearly not true.
+during stack unwinding, This is clearly not true.
 
<td>
-Strike the
-word 'user' from the first bullet point.
+Strike the
+word 'user' from the first bullet point.
<td>
 
<tr valign="top">
<td>
-UK 
-140
+UK 
+140
<td>
-15.5.2
+15.5.2
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-The detailed specification can fool people into
+The detailed specification can fool people into
thinking an exception will automatically be translated into
bad_exception, where the default behaviour of std::unexcepted is to
-immediately call std::terminate();
+immediately call std::terminate();
 
<td>
-Add a note
+Add a note
highlighting the default behaviour of std::unexpected if the user
-does not supply a hander-function
+does not supply a hander-function
<td>
 
<tr valign="top">
<td>
-UK 
-141
+UK 
+141
<td>
-15.6
+15.6
<td>
 
<td>
-Ed
+Ed
<td>
-This whole subclause is redundant due to 15.1p5
-and 15.3p17
+This whole subclause is redundant due to 15.1p5
+and 15.3p17
 
<td>
-Strike
-15.6
+Strike
+15.6
<td>
 
<tr valign="top">
<td>
-UK 
-142
+UK 
+142
<td>
-16.3.5
+16.3.5
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-This paragraph opens with "[ Note" but has no
-corresponding "end note ]"
+This paragraph opens with "[ Note" but has no
+corresponding "end note ]"
 
<td>
-Add "end note
-]"
+Add "end note
+]"
<td>
 
<tr valign="top">
<td>
-UK 
-143
+UK 
+143
<td>
-16.3.5
+16.3.5
<td>
-7
+7
<td>
-Ed
+Ed
<td>
-Example uses
-#define t(x,y.z) x ## y ## z
+Example uses
+#define t(x,y.z) x ## y ## z
<td>
-Change
-"x,y.z" to "x,y,z"
+Change
+"x,y.z" to "x,y,z"
<td>
 
<tr valign="top">
<td>
-US 2
+US 2
<td>
-17-30
+17-30
<td>
 
<td>
-ge/te
+ge/te
<td>
-The active issues identified in WG21
+The active issues identified in WG21
N2806, C++ Standard Library Active Issues, must be addressed and
-appropriate action taken.
+appropriate action taken.
 

-<a href=
-"http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">http://www.open-std.org/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/jtc1/sc22/wg21/docs/lwg-active.html>
 
<td>
-Appropriate action would include making changes to
+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.
+or deferring the issue to a later point in time.
<td>
 
<tr valign="top">
<td>
-FR 2
+FR 2
<td>
-General Comment
+General Comment
<td>
-Library
+Library
<td>
-ge
+ge
<td>
-The adoption of the library `constexpr'
+The adoption of the library `constexpr'
proposal was not reflected in the draft, despite formal WG21
-committee vote.
+committee vote.
<td>
-FR 2
+FR 2
<td>
-General Comment
+General Comment
<tr valign="top">
<td>
-US 61
+US 61
<td>
-17 onward
+17 onward
<td>
 
<td>
-te
+te
<td>
-The concepts core language
+The concepts core language
feature is applied to only some of the Standard Library clauses,
-and even then not always consistently.
+and even then not always consistently.
<td>

-Review all clauses of the
+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.
+N2781 exemplifies the necessary level of detail.
 
<td>
 
<tr valign="top">
<td>
-CA-2
+CA-2
<td>
-17 Library
+17 Library
<td>
 
<td>
-Ge
+Ge
<td>

-“Concepts” are a
+“Concepts” are a
significant new addition to the language, but are not exploited
-uniformly in the library as documented in CD 14882.
+uniformly in the library as documented in CD 14882.
<td>
-Fix the standard library so that
+Fix the standard library so that
“Concepts” are used appropriately in the
-library.
+library.
<td>
 
<tr valign="top">
<td>
-US 62
+US 62
<td>
-17-30
+17-30
<td>
 
<td>
-ge
+ge
<td>
-Provide concepts and
-requirements clauses for all standard library templates
+Provide concepts and
+requirements clauses for all standard library templates
 
<td>
 
@@ -7395,857 +6489,809 @@
 
<tr valign="top">
<td>
-US 63
+US 63
<td>
-17-30
+17-30
 
<td>
 
<td>
-te
+te
<td>
-The behavior of the
+The behavior of the
library in the presence of threads is incompletely
-specified.
-For example, if thread 1
+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?
-Another example: 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?
+the same non-const string really introduce a data race?
<td>
 
<td>
 
<tr valign="top">
<td>
-DE-2
+DE-2
<td>
-17 through 30
+17 through 30
<td>
 
<td>
-te
+te
<td>
-DE-2 Marking a constructor
+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".
+non-single-parameter constructors as "explicit".
<td>
-Consider marking
+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.
+that do not have an initializer-list constructor.
<td>
 
<tr valign="top">
<td>
-JP 21
+JP 21
<td>
 
-17 Library
-21.2, 21.4,
-27.2, 27.6, 27.7, 27.8.1, 28.4
+17 Library
+21.2, 21.4,
+27.2, 27.6, 27.7, 27.8.1, 28.4
<td>
 
<td>
-te
+te
<td>
-Support of char16_t/char32_t is
+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.
-Functions such as stoi, to_string in
+char16_t/char32_t.
+Functions such as stoi, to_string in
‘21.4 Numeric Conversion’ does not support
-char16_t/char32_t types.
+char16_t/char32_t types.
<td>
Add commented lines corresponding to char16_t,
-char32_t.
+"margin-top: 0.04in; margin-bottom: 0.04in">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);
+ int stoi(const
+u16string& str, size_t *idx = 0, int base = 10);

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

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

- long long stoll(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 long
+ unsigned long long
stoull(const u16string& str, size_t *idx = 0, int base =
-10);
+10);

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

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

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

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

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

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

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

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

- long long stoll(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 long
+ unsigned long long
stoull(const u32string& str, size_t *idx = 0, int base =
-10);
+10);

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

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

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

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

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

- u32string
-to_u32string(long double val);
-}
+ u32string
+to_u32string(long double val);
+}
 
-27.2
+27.2
 
-namespace std {
+namespace std {

- ...
+ ...

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

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

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

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

- ...
+ ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- ...
+ ...

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

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

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

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

- typedef
+ typedef
fpos<char_traits<char32_t>::state_type>
-u32streampos;
-}
+u32streampos;
+}
 
-27.6
+27.6
 
-namespace std {
+namespace std {

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

- class
-basic_istream;
+ class
+basic_istream;

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

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

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

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

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

- class
-basic_iostream;
+ class
+basic_iostream;

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

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

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

- typedef
-basic_iostream<char32_t> u32iostream;
-}
+ typedef
+basic_iostream<char32_t> u32iostream;
+}
 
-namespace std {
+namespace std {

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

- class
-basic_ostream;
+ class
+basic_ostream;

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

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

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

- typedef
-basic_ostream<char32_t> u32ostream;
-}
+ typedef
+basic_ostream<char32_t> u32ostream;
+}
 
-27.7 paragraph 1
+27.7 paragraph 1
 
-namespace std {
+namespace std {

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

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

- class
-basic_stringbuf;
+ class
+basic_stringbuf;
 

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

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

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

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

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

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

- class
-basic_istringstream;
+ class
+basic_istringstream;
 

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

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

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

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

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

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

- class
-basic_ostringstream;
+ class
+basic_ostringstream;
 

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

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

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

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

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

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

- class
-basic_stringstream;
+ class
+basic_stringstream;
 

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

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

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

- typedef
-basic_stringstream<char32_t> u32stringstream;
-}
+ typedef
+basic_stringstream<char32_t> u32stringstream;
+}
 
-27.8.1 paragraph 1
+27.8.1 paragraph 1
 
-namespace std {
+namespace std {

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

- class
-basic_filebuf;
+ class
+basic_filebuf;

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

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

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

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

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

- class
-basic_ifstream;
+ class
+basic_ifstream;

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

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

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

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

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

- class
-basic_ofstream;
+ class
+basic_ofstream;

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

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

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

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

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

- class
-basic_fstream;
+ class
+basic_fstream;

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

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

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

- typedef
-basic_fstream<char32_t> u32fstream;
-}
+ typedef
+basic_fstream<char32_t> u32fstream;
+}
 
-28.4
+28.4
 
-namespace std {
+namespace std {

- ...
+ ...

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

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

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

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

- ...
+ ...

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

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

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

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

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

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

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

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

- ...
+ ...

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

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

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

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

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

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

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

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

- ...
+ ...

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

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

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

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

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

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

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

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

- ...
+ ...

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

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

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

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

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

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

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

- typedef
-regex_token_iterator<u32string::const_iterator>　u32sregex_token_iterator;
-}
+ typedef
+regex_token_iterator<u32string::const_iterator>　u32sregex_token_iterator;
+}
 
<td>
 
<tr valign="top">
<td>
-UK 
-144
+UK 
+144
<td>
-17.1
+17.1
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-List of
-contents of library should be extened to cover new clauses
+List of
+contents of library should be extened to cover new clauses
<td>
-Add "regular
-expressions, atomic operations and threads"
+Add "regular
+expressions, atomic operations and threads"
<td>
 
<tr valign="top">
<td>
-UK 
-145
+UK 
+145
<td>
-17.1
+17.1
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-Summary of numeric
-facilities should mention random numbers
+Summary of numeric
+facilities should mention random numbers
 
<td>
-Add random
-number framework to the list of library facilities
+Add random
+number framework to the list of library facilities
<td>
 
<tr valign="top">
<td>
-UK 
-146
+UK 
+146
<td>
-17.1
+17.1
<td>
 
<td>
-Ed
+Ed
<td>
-Add a summary
-paragraph for regular expressions
+Add a summary
+paragraph for regular expressions
<td>
-Add a summary
-paragraph for regular expressions
+Add a summary
+paragraph for regular expressions
<td>
 
<tr valign="top">
<td>
-UK 
-147
+UK 
+147
<td>
-17.1
+17.1
<td>
 
<td>
-Ed
+Ed
<td>
-Add a summary
-paragraph for threads
+Add a summary
+paragraph for threads
<td>
-Add a summary
-paragraph for threads
+Add a summary
+paragraph for threads
<td>
 
<tr valign="top">
<td>
-UK 
-148
+UK 
+148
<td>
-17.2
+17.2
<td>
-Table
-12
+Table
+12
<td>
-Ed
+Ed
<td>
-Table 12 is mentioned in and relates to section
+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.
+reader.
 
<td>
-Make sure
-tables are rendered in the section to which they relate.
+Make sure
+tables are rendered in the section to which they relate.
<td>
 
<tr valign="top">
<td>
-UK 
-149
+UK 
+149
<td>
-17.3
+17.3
<td>
 
<td>
-Ed
+Ed
<td>
-For consistency with narrow-oriented and
+For consistency with narrow-oriented and
wide-oriented streams, we should add terms for streams of Unicode
-character sequences
+character sequences
 
<td>
-Define
+Define
Utf16-oriented stream classes and Uft32-oriented stream classes for
-streams of char16_t/char32_t values.
+streams of char16_t/char32_t values.
<td>
 
<tr valign="top">
<td>
-UK 
-150
+UK 
+150
<td>
-17.3
+17.3
<td>
 
<td>
-Ed
+Ed
<td>
-The addition
+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'.
+object is in a singular state'.
<td>
-Define 'singular state' such that an object with a
+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
@@ -8253,1062 +7299,947 @@
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.
+iterator value with a singular state.
 
<td>
 
<tr valign="top">
<td>
-UK 
-151
+UK 
+151
<td>
-17.3.1
+17.3.1
<td>
 
<td>
-Ed
+Ed
<td>
-Missing crossreference to 17.3.17
-[defns.repositional.stream]
+Missing crossreference to 17.3.17
+[defns.repositional.stream]
 
<td>
-Add
-cross-reference in the existing empty brackets
+Add
+cross-reference in the existing empty brackets
<td>
 
<tr valign="top">
<td>
-UK 
-152
+UK 
+152
<td>
-17.3.12
+17.3.12
<td>
 
<td>
-Te
+Te
<td>
-Object state is using a definition of object
+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
+'region of storage' definiton in 1.8p1
 
<td>
-Clarify terms
-and usage
+Clarify terms
+and usage
<td>
 
<tr valign="top">
<td>
-UK 
-153
+UK 
+153
<td>
-17.3.17
+17.3.17
<td>
 
<td>
-Te
+Te
<td>
-If a repositional stream can only seek to a
+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
+cross-referenced in 17.3.17
 
<td>
-Strike the
-word 'only'. A note might be added to reinforce the intent
+Strike the
+word 'only'. A note might be added to reinforce the intent
<td>
 
<tr valign="top">
<td>
UK 
-154
+"margin-right: -0.18in; margin-bottom: 0in">UK 
+154
 
<td>
-17.3.20
+17.3.20
<td>
 
<td>
-Ed
+Ed
<td>
-Missing
-definition of a stable partition algorithm
+Missing
+definition of a stable partition algorithm
<td>
-Add
-definition from 25.2.12p7
+Add
+definition from 25.2.12p7
<td>
 
<tr valign="top">
<td>
-UK 
-155
+UK 
+155
<td>
-17.3.3
+17.3.3
<td>
 
<td>
-Ed
+Ed
<td>
-Add clause 28
-to list that use this definition of character
+Add clause 28
+to list that use this definition of character
<td>
-Add clause 28
-to list that use this definition of character
+Add clause 28
+to list that use this definition of character
<td>
 
<tr valign="top">
<td>
-UK 
-156
+UK 
+156
<td>
-17.3.4
+17.3.4
<td>
 
<td>
-Ed
+Ed
<td>
-Add regular expressions to set of templates using
-character container type
+Add regular expressions to set of templates using
+character container type
 
<td>
-Add regular
+Add regular
expressions to set of templates using character container
-type
+type
<td>
 
<tr valign="top">
<td>
-UK 
-157
+UK 
+157
<td>
-17.5.2.2
+17.5.2.2
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-Add concepts to the ordered list of
-presentation
+Add concepts to the ordered list of
+presentation
 
 
<td>
-Add concepts
-into the sequence
+Add concepts
+into the sequence
<td>
 
<tr valign="top">
<td>
-UK 
-158
+UK 
+158
<td>
-17.5.2.2
+17.5.2.2
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-templates are
-neither classes nor functions
+templates are
+neither classes nor functions
<td>
-Replace 'classes' and 'functions' with 'classes
-and class templates' and 'functions and function templates'
+Replace 'classes' and 'functions' with 'classes
+and class templates' and 'functions and function templates'
 
<td>
 
<tr valign="top">
<td>
-UK 
-159
+UK 
+159
<td>
-17.5.2.4
+17.5.2.4
<td>
-Footnote
-152
+Footnote
+152
<td>
-Ed
+Ed
<td>
-This informative footnote was relevant in 1998,
+This informative footnote was relevant in 1998,
not 2008. The term 'existing vendors' may imply something different
-now
+now
 
<td>
-Strike the
-footnote, or replace 'existing' with 'original' or similar
+Strike the
+footnote, or replace 'existing' with 'original' or similar
<td>
 
<tr valign="top">
<td>
-UK 
-160
+UK 
+160
<td>
-17.5.2.4
+17.5.2.4
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-requires is now a keyword with a specific meaning
+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.
+convention.
 
<td>
-Replace
-'Requires' with 'Preconditions'
+Replace
+'Requires' with 'Preconditions'
<td>
 
<tr valign="top">
<td>
-UK 
-161
+UK 
+161
<td>
-17.5.2.4
+17.5.2.4
<td>
-4
+4
<td>
-Ed
+Ed
<td>
-This paragraph is redundant as the definition of
+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?
+'controlling' definition?
 
<td>
-Strike
-17.5.2.4p4
+Strike
+17.5.2.4p4
<td>
 
<tr valign="top">
<td>
-UK 
-162
+UK 
+162
<td>
-17.5.2.4
+17.5.2.4
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-Clause 30 makes use of a 'Synchronization'
+Clause 30 makes use of a 'Synchronization'
semantic element, that frequently appears either between Effects:
-and Postconditions:, or between Returns: and Throws:
+and Postconditions:, or between Returns: and Throws:
 
<td>
-Add
+Add
'Synchronization' to the list either between Effects: and
-Postconditions:, or between Returns: and Throws:.
+Postconditions:, or between Returns: and Throws:.
<td>
 
<tr valign="top">
<td>
-UK 
-163
+UK 
+163
<td>
-17.5.2.4
+17.5.2.4
<td>
-3
+3
<td>
-Te
+Te
<td>
-Many functions are defined as "Effects: Equivalent
+Many functions are defined as "Effects: Equivalent
to a...", which seems to also define the preconditions, effects,
-etc. But this is not made clear.
+etc. But this is not made clear.
 
<td>
-Introduce an
+Introduce an
explicit "Equivalent to", which defines all of the properties of
-the function.
+the function.
<td>
 
<tr valign="top">
<td>
-UK 
-164
+UK 
+164
<td>
-17.5.3.2.1
+17.5.3.2.1
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-This phrasing
+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
+with appropriate examples
<td>
-Use better names for the examples. Ideally totally
+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.
+CopyConstructible is mis-spelled.
 
<td>
 
<tr valign="top">
<td>
-UK 
-165
+UK 
+165
<td>
-17.5.3.2.2, 17.5.3.2.3
+17.5.3.2.2, 17.5.3.2.3
<td>
 
<td>
-Te
+Te
<td>
-constraints on bitmask and enumation types were
+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
+constexpr feature - see paper n2235 for deails
 
<td>
-Adopt wording
-in line with the motivation described in N2235
+Adopt wording
+in line with the motivation described in N2235
<td>
 
<tr valign="top">
<td>
-UK 
-166
+UK 
+166
<td>
-17.5.3.2.4.1, 17.5.3.3
+17.5.3.2.4.1, 17.5.3.3
 
<td>
 
<td>
-Ed
+Ed
<td>
-List of
-library clauses should go up to 30, not 27
+List of
+library clauses should go up to 30, not 27
<td>
-Replace
-initial refernce to ch27 with ch30
+Replace
+initial refernce to ch27 with ch30
<td>
 
<tr valign="top">
<td>
-UK 
-167
+UK 
+167
<td>
-17.5.3.4
-Private members
+17.5.3.4
+Private members
<td>
 
<td>
-Ed
+Ed
<td>
-Comment
-marker in wrong place.
+Comment
+marker in wrong place.
<td>
-Change: // streambuf* sb; exposition only to
-streambuf* sb; // exposition only To reflect actual usage.
+Change: // streambuf* sb; exposition only to
+streambuf* sb; // exposition only To reflect actual usage.
 
<td>
 
<tr valign="top">
<td>
-UK 
-168
+UK 
+168
<td>
-17.6.2.2
+17.6.2.2
<td>
-2
+2
<td>
-Te
+Te
<td>
-We should make it clear (either by note or
+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.)
+that.)
 
<td>
-Replace
+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"
+std"
<td>
 
<tr valign="top">
<td>
-UK 
-169
+UK 
+169
<td>
-17.6.2.2
+17.6.2.2
<td>
 
<td>
-Te
+Te
<td>
-This phrasing contradicts later freedom to
+This phrasing contradicts later freedom to
implement the C standard library portions in the global namespace
-as well as std. (17.6.2.3p4)
+as well as std. (17.6.2.3p4)
 
<td>
-Resolve
-conflict in either place
+Resolve
+conflict in either place
<td>
 
<tr valign="top">
<td>
-UK 
-170
+UK 
+170
<td>
-17.6.2.3
+17.6.2.3
<td>
 
<td>
-Te
+Te
<td>
-One of goals of C++0x is to make language easier
+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.
+the whole library through a single include statement.
 
<td>
-Add a new
+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.
+<std> but no definitions.
<td>
 
<tr valign="top">
<td>
-UK 
-171
+UK 
+171
<td>
-17.6.2.4
+17.6.2.4
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-Does freestanding implementation require a full
+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?
+empty versions of everything but <cstdlib> conforming?
 
<td>
-Either strike
+Either strike
the references to abort, at_exit and exit, or clarify which headers
-only require partial support.
+only require partial support.
<td>
 
<tr valign="top">
<td>
-UK 
-172
+UK 
+172
<td>
-17.6.2.4
+17.6.2.4
<td>
-3
+3
<td>
-Te
+Te
<td>
-No reference to new functions quick_exit and
-at_quick_exit
+No reference to new functions quick_exit and
+at_quick_exit
 
<td>
-Add reference
-to quick_exit and at_quick_exit
+Add reference
+to quick_exit and at_quick_exit
<td>
 
<tr valign="top">
<td>
-UK 
-173
+UK 
+173
<td>
-17.6.2.4
+17.6.2.4
<td>
-table
-15
+table
+15
<td>
-Te
+Te
<td>
-<initializer_list> is missing from headers
-required in freestanding implementations.
+<initializer_list> is missing from headers
+required in freestanding implementations.
 
<td>
-Add 18.8,
+Add 18.8,
initializer lists, <initializer_list>, to the end of the
-table.
+table.
<td>
 
<tr valign="top">
<td>
-JP 23
+JP 23
<td>
-17.6.2.4
+17.6.2.4
<td>
-2nd paragraph, Table 15
+2nd paragraph, Table 15
<td>
-te
+te
<td>
There is a freestanding implementation including
+"margin-top: 0.04in; margin-bottom: 0.04in">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.
+shall include at least.
 
<td>
-Add <type_traits>, <array>,
-<ration> to Table 15.
+Add <type_traits>, <array>,
+<ration> to Table 15.
<td>
 
<tr valign="top">
<td>
-UK 
-174
+UK 
+174
<td>
-17.6.3.2
+17.6.3.2
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-The phrasing is mildly ambiguous when using the
+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.
+surrounding clause.
 
<td>
-Replace 'the
+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'
+entities that header declares in the translation unit'
<td>
 
<tr valign="top">
<td>
-UK 
-175
+UK 
+175
<td>
-17.6.4.2.1
+17.6.4.2.1
<td>
-2
+2
<td>
-Te
+Te
<td>
-Local types can now be used to instantiate
-templates, but don't have external linkage
+Local types can now be used to instantiate
+templates, but don't have external linkage
 
<td>
-Remove the
-reference to external linkage
+Remove the
+reference to external linkage
<td>
 
<tr valign="top">
<td>
-UK 
-176
+UK 
+176
<td>
-17.6.4.3.3
+17.6.4.3.3
<td>
-Footnote 175
+Footnote 175
 
<td>
-Ed
+Ed
<td>
-Reference to
-namespace ::std should be 17.6.4.2
+Reference to
+namespace ::std should be 17.6.4.2
<td>
-Change
-referfence from 17.6.4.3 to 17.6.4.2
+Change
+referfence from 17.6.4.3 to 17.6.4.2
<td>
 
<tr valign="top">
<td>
-UK 
-177
+UK 
+177
<td>
-17.6.4.3.4
+17.6.4.3.4
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-Sentence is redundant as double underscores are
-reserved in all contexts by 17.6.4.3.3
+Sentence is redundant as double underscores are
+reserved in all contexts by 17.6.4.3.3
 
<td>
-Strike the
-sentence
+Strike the
+sentence
<td>
 
<tr valign="top">
<td>
-UK 
-178
+UK 
+178
<td>
-17.6.4.8
+17.6.4.8
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-The last
+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.
+redundant as behaviour is already undefined.
<td>
-Strike the
-sentence
+Strike the
+sentence
<td>
 
<tr valign="top">
<td>
-UK 
-179
+UK 
+179
<td>
-17.6.4.8
+17.6.4.8
<td>
-2
+2
<td>
-Te
+Te
<td>
-According to the 4th bullet there is a problem if
+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.
+exceptions so long as they are caught within the function.
 
<td>
-Replace the
-word 'throws' with 'propogates'
+Replace the
+word 'throws' with 'propogates'
<td>
 
<tr valign="top">
<td>
-JP 22
+JP 22
<td>
-17.6.5.7
+17.6.5.7
<td>
-4th paragraph, 1st line
+4th paragraph, 1st line
<td>
-ed
+ed
<td>
-The statement below describes relation
+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 ]
-In such case, “among” is
-preferred instead of “between”.
-<td>
-Change "between threads" to "among
-threads".
-There are same cases in 17.6.1 paragraph
+explicitly share objects between threads. —end note ]
+In such case, “among” is
+preferred instead of “between”.
+<td>
+Change "between threads" to "among
+threads".
+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.
+also.
<td>
 
<tr valign="top">
<td>
-UK 
-180
+UK 
+180
<td>
-17.6.5.10
+17.6.5.10
<td>
-1,
-4
+1,
+4
<td>
-Te
+Te
<td>
-It should not be possible to strengthen the
+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.
+possible to strengthen.
 
<td>
-Add
+Add
restriction that exception specification of virtual functions
-cannot be tightened.
+cannot be tightened.
<td>
 
<tr valign="top">
<td>
-UK 
-181
+UK 
+181
<td>
-17.6.5.10
+17.6.5.10
<td>
-Footnote
-186
+Footnote
+186
<td>
-Te
+Te
<td>
-This footnote is wrong. C library functions do not
+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
+had an empty throw specification
 
<td>
-Clarify that
+Clarify that
this note does not mean the functions are genuinely declared with
-the specification, but are treated as-if.
+the specification, but are treated as-if.
<td>
 
<tr valign="top">
<td>
-UK 
-182
+UK 
+182
<td>
-17.6.5.10
+17.6.5.10
<td>
-Footnote
-188
+Footnote
+188
<td>
-Te
+Te
<td>
-It is very helpful to assume all exceptions thrown
+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.
+'encouragement' of this note should be made normative.
 
<td>
-Make this
-footnote normative
+Make this
+footnote normative
<td>
 
<tr valign="top">
<td>
-UK 
-184
+UK 
+184
<td>
-18 ->
-30
+18 ->
+30
<td>
 
<td>
-Ed
+Ed
<td>
-The new alias-declaration syntax is generally
+The new alias-declaration syntax is generally
easier to read than a typedef declaration. This is especially true
-for complex types like function pointers.
+for complex types like function pointers.
 
<td>
-Replace all
+Replace all
typedef declarations in the standard library with
-alias-declarations, except in the standard C library.
+alias-declarations, except in the standard C library.
<td>
 
<tr valign="top">
<td>
-JP 24
+JP 24
<td>
-18
+18
<td>
-2nd paragraph, Table 16
+2nd paragraph, Table 16
<td>
-ed
+ed
<td>
-Subclauses are listed in Table 16
-as:
+Subclauses are listed in Table 16
+as:
"18.6 Type identification …"
+"text-indent: 0.06in; margin-bottom: 0in">"18.6 Type identification …"
"18.8 Initializer lists …"
+"text-indent: 0.06in; margin-bottom: 0in">"18.8 Initializer lists …"
"18.7 Exception handling …".
+"text-indent: 0.06in; margin-top: 0.04in">"18.7 Exception handling …".
<td>

-Sort them in the increasing
+Sort them in the increasing
order 
-"18.6 Type identification …"
+"18.6 Type identification …"
"18.7 Exception handling …".
+"text-indent: 0.06in; margin-bottom: 0in">"18.7 Exception handling …".

-"18.8 Initializer lists
-…"
+"18.8 Initializer lists
+…"
 
<td>
 
<tr valign="top">
<td>
-JP 25
+JP 25
<td>
-18.1
+18.1
<td>
-6th paragraph , last line, SEE ALSO
+6th paragraph , last line, SEE ALSO
 
<td>
-ed
+ed
<td>
-max_align_t is described in 18.1, so add
-3.11 Alignment as the reference.
+max_align_t is described in 18.1, so add
+3.11 Alignment as the reference.
<td>
-Add "3.11, Alignment" to SEE ALSO.
+Add "3.11, Alignment" to SEE ALSO.
<td>
 
<tr valign="top">
<td>
-FR 32
+FR 32
<td>
-18.2.1 [Numeric limits]
+18.2.1 [Numeric limits]
<td>
 
<td>
-te
+te
<td>
-The definition of numeric_limits<>
+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.
+theory.
 
<td>
-We suggest that a more pragmatic approach, in
+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.
+necessarily semantics assertions on the carrier type.
<td>
 
<tr valign="top">
<td>
-DE-16
+DE-16
<td>
-18.2.1
+18.2.1
<td>
 
<td>
-te
+te
<td>

-DE-16 The class template
-numeric_limits should not
-specify the Regular concept
+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
+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>
-Specify a concept
-requirement with fewer constraints as appropriate, for example
-SemiRegular.
+Specify a concept
+requirement with fewer constraints as appropriate, for example SemiRegular.
<td>
 
<tr valign="top">
<td>
-JP 26
+JP 26
<td>
-18.2.1.1
+18.2.1.1
<td>
 
<td>
-te
+te
<td>
-numeric_limits does not use
-concept.
+numeric_limits does not use
+concept.
<td>
-Correct as follows.
+Correct as follows.
 
-template<class T> class
-numeric_limits<const T>;
-template<class T> class
-numeric_limits<volatile T>;
-template<class T> class
-numeric_limits<const volatile T>;
+template<class T> class
+numeric_limits<const T>;
+template<class T> class
+numeric_limits<volatile T>;
+template<class T> class
+numeric_limits<const volatile T>;
 
-should be
+should be
 
-template<Regular T> class
-numeric_limits<const T>;
-template<Regular T> class
-numeric_limits<volatile T>;
-template<Regular T> class
-numeric_limits<const volatile T>;
+template<Regular T> class
+numeric_limits<const T>;
+template<Regular T> class
+numeric_limits<volatile T>;
+template<Regular T> class
+numeric_limits<const volatile T>;
 
<td>
 
<tr valign="top">
<td>
-DE-17
+DE-17
<td>
-18.2.6
+18.2.6
<td>
 
<td>
-te
+te
<td>

-DE-17 The class type_index should be removed; it
+DE-17 The class type_index should be removed; it
provides no additional functionality beyond providing appropriate
-concept maps.
+concept maps.
 
<td>
-Specify concept maps for
+Specify concept maps for
"const type_info *" as required by the ordered and unordered
-containers and remove the class type_index.
+containers and remove the class type_index.
<td>
 
<tr valign="top">
<td>
-UK 
-185
+UK 
+185
<td>
-18.3.1
+18.3.1
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-There is no header <stdint>, it should
-either be <stdint.h> or <cstdint>
+There is no header <stdint>, it should
+either be <stdint.h> or <cstdint>
 
<td>
-Replace
-<stdint> with <cstdint>
+Replace
+<stdint> with <cstdint>
<td>
 
<tr valign="top">
<td>
-DE-18
+DE-18
<td>
-18.4
+18.4
<td>
 
<td>
-te
+te
<td>

-DE-18 The proposed C++
+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
@@ -9322,567 +8253,497 @@
garbage collection support, turning potentially undefined programs
into well-defined ones. 
Note: This issue is contributing significantly to Germany's
-overall “no” vote.
+overall “no” vote.
 
<td>
-Consider applying the
+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>
 
<tr valign="top">
<td>
-UK 
-186
+UK 
+186
<td>
-18.4
+18.4
<td>
-Footnote
-221
+Footnote
+221
<td>
-Ed
+Ed
<td>
-What is the purpose of this comment? The standard
+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.
+be responsible for flushing buffers at the stated time.
 
<td>
-Remove the
-footnote
+Remove the
+footnote
<td>
 
<tr valign="top">
<td>
-UK 
-187
+UK 
+187
<td>
-18.4
+18.4
<td>
-9
+9
<td>
-Te
+Te
<td>
-The term "thread safe" is not defined nor used in
-this context anywhere else in the standard.
+The term "thread safe" is not defined nor used in
+this context anywhere else in the standard.
 
<td>
-Clarify the
-intended meaing of "thread safe"
+Clarify the
+intended meaing of "thread safe"
<td>
 
<tr valign="top">
<td>
-UK 
-188
+UK 
+188
<td>
-18.4
+18.4
<td>
-12
+12
<td>
-Te
+Te
<td>
-The function _Exit does not appear to be defined
+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?
+included-by-reference to the C standard?
 
<td>
-Depends on
-where _Exit comes from
+Depends on
+where _Exit comes from
<td>
 
<tr valign="top">
<td>
-UK 
-189
+UK 
+189
<td>
-18.4,
-18.7
+18.4,
+18.7
<td>
 
<td>
-Te
+Te
<td>
-The addition
+The addition
of the [[noreturn]] attribute to the language will be an important
-aid for static analysis tools.
+aid for static analysis tools.
<td>
-The following functions should be declared in C++
+The following functions should be declared in C++
with the [[noreturn]] attribute: abort exit quick_exit terminate
-unexpected rethrow_exception throw_with_nested
+unexpected rethrow_exception throw_with_nested
 
<td>
 
<tr valign="top">
<td>
-JP 27
+JP 27
<td>
-18.4, 18.9, 18.7.2.2, 18.7.3.1
+18.4, 18.9, 18.7.2.2, 18.7.3.1
<td>
 
<td>
-te
+te
<td>
-There are Standard library functions
+There are Standard library functions
that never return to the caller. They are explained so in the
-Standard but not declared explicitly.
+Standard but not declared explicitly.
<td>
-Consider to add the attribute
-[[noreturn]] to such functions,
+Consider to add the attribute
+[[noreturn]] to such functions,
 
-15.5.2 unexpected 
+15.5.2 unexpected 
18.4: abort(), exit(), quick_exit, 
18.7.2.2: unexpected_handler, 
-18.7.3.1: terminate_handler,
-18.7.6 rethrow_nested
-18.7.6 throw_with_nested 
-18.9: longjmp.
+18.7.3.1: terminate_handler,
+18.7.6 rethrow_nested
+18.7.6 throw_with_nested 
+18.9: longjmp.
 
<td>
 
<tr valign="top">
<td>
-UK 
-190
+UK 
+190
<td>
-18.5.1
+18.5.1
<td>
-various
+various
<td>
-Te
+Te
<td>
-It is not
+It is not
entirely clear how the current specification acts in the presence
-of a garbage collected implementation.
+of a garbage collected implementation.
<td>
-All deallocation functions taking a pointer
+All deallocation functions taking a pointer
parameter should have a Precondition : ptr is a safely-derived
-pointer value.
+pointer value.
 
<td>
 
<tr valign="top">
<td>
-UK 
-191
+UK 
+191
<td>
-18.5.1.1
+18.5.1.1
<td>
-4
+4
<td>
-Ed
+Ed
<td>
-According to
+According to
the second bullet, behaviour becomes undefined (for lack of a
specification) if the user has not yet called
-set_new_handler.
+set_new_handler.
<td>
-Rephrase the second bullet in terms of a new
+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.
+defined.
 
<td>
 
<tr valign="top">
<td>
-UK 
-192
+UK 
+192
<td>
-18.5.1.2
+18.5.1.2
<td>
 
<td>
-Te
+Te
<td>
-The declared signature is not compatible with the
+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.
+something derived from std::bad_alloc.
 
<td>
-Fix 5.3.4p7
-by required std::bad_alloc rather than std::length_error
+Fix 5.3.4p7
+by required std::bad_alloc rather than std::length_error
<td>
 
<tr valign="top">
<td>
-UK 
-193
+UK 
+193
<td>
-18.5.2.2
+18.5.2.2
<td>
-2
+2
<td>
-Te
+Te
<td>
-quick_exit has been added as a new valid way to
-terminate a program in a well defined way
+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();
+Change 3rd
+bullet: call either abort(), exit() or quick_exit();
<td>
 
<tr valign="top">
<td>
-UK 
-194
+UK 
+194
<td>
-18.6
+18.6
<td>
 
<td>
-Te
+Te
<td>
-The inclusion of type_index and
+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.
+freestanding C++ in 17.6.2.4.
 
<td>
-Move
+Move
type_index and hash<type_index> out of <typeinfo> and
-into a new header, <typeindex>.
+into a new header, <typeindex>.
<td>
 
<tr valign="top">
<td>
-JP 28
+JP 28
<td>
-18.6, 18.7, 19.1
+18.6, 18.7, 19.1
<td>
 
<td>
-te
+te
<td>
-Errors reported by Exception classes are
+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.
+be used.
 
<td>
-Consider other types.
+Consider other types.
<td>
 
<tr valign="top">
<td>
-JP 29
+JP 29
<td>
-18.7.6
+18.7.6
<td>
 
<td>
-te
+te
<td>
-throw_with_nested does not use
-concept.
+throw_with_nested does not use
+concept.
<td>
-Correct as follows.
-template<class T> void
-throw_with_nested(T&& t); // [[noreturn]]
+Correct as follows.
+template<class T> void
+throw_with_nested(T&& t); // [[noreturn]]
 
should be
+"text-indent: 0.06in; margin-bottom: 0in">should be
 
-template<CopyConstructible T> void
-throw_with_nested(T&& t); // [[noreturn]]
+template<CopyConstructible T> void
+throw_with_nested(T&& t); // [[noreturn]]
 
<td>
 
<tr valign="top">
<td>
-JP 30
+JP 30
<td>
-18.7.6
+18.7.6
<td>
 
<td>
-te
+te
<td>
-To handle nested exceptions strictly,
+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.
+insufficient as error handling.
<td>
-Consider nested_exception to support
-tree structure.
+Consider nested_exception to support
+tree structure.
<td>
 
<tr valign="top">
<td>
-JP 31
+JP 31
<td>
-18.7.6
+18.7.6
<td>
 
<td>
-te
+te
<td>
-It is difficult to understand in which
-case nested_exception is applied.
+It is difficult to understand in which
+case nested_exception is applied.
<td>
Consider to add a sample program which rethrows
-exception.
+"margin-top: 0.04in; margin-bottom: 0.04in">Consider to add a sample program which rethrows
+exception.
 
<td>
 
<tr valign="top">
<td>
-UK 
-195
+UK 
+195
<td>
-18.8
+18.8
<td>
 
<td>
-Te
+Te
<td>
-The class definition of std::initializer_list
+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.
+implementation.
 
<td>
-Delete the
-two concept maps from std::initializer_list.
+Delete the
+two concept maps from std::initializer_list.
<td>
 
<tr valign="top">
<td>
-UK 
-196
+UK 
+196
<td>
-18.8.3
+18.8.3
<td>
 
<td>
-Te
+Te
<td>
-Concept maps
+Concept maps
for initializer_list to Range should not be in language support
-headers, but instead in iterator concepts.
+headers, but instead in iterator concepts.
<td>
-Remove section 18.8.3 and put it in 24.1.8.1
+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>.
+<initializer_list>.
 
<td>
 
<tr valign="top">
<td>
-UK 
-197
+UK 
+197
<td>
-19
+19
<td>
 
<td>
-Te
+Te
<td>
-All the
+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.
+well.
<td>
-Provide a constructor for every exception class in
+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.
+semantics that the passed string may be moved.
 
<td>
 
<tr valign="top">
<td>
-JP 32
+JP 32
<td>
-19.1
+19.1
<td>
 
<td>
-te
+te
<td>
-Messages returned by the member function
+Messages returned by the member function
what() of standard exception classes seem difficult to
-judge.
-For example, following messages are
+judge.
+For example, following messages are
returned by what() of std::bad_alloc of existing
-implementations:
+implementations:
 
-Compiler: Message returned by
-what()
----------------------------------------------
-Borland C++ 5.6.4: no named exception
-thrown
-Visual C++ 8.0: bad allocation
-Code Warrior 8.0: exception
-g++ 3.4.4: St9exception
- 
-It is difficult to recognize what exception was
-thrown when using those compilers except Visual C++.
+Compiler: Message returned by
+what()
+---------------------------------------------
+Borland C++ 5.6.4: no named exception
+thrown
+Visual C++ 8.0: bad allocation
+Code Warrior 8.0: exception
+g++ 3.4.4: St9exception
+ 
+It is difficult to recognize what exception was
+thrown when using those compilers except Visual C++.
 
<td>
-Consider to add footnote that recommends
+Consider to add footnote that recommends
what() returns message easy to recognize what exception was
-thrown.
+thrown.
<td>
 
<tr valign="top">
<td>
-US 64
+US 64
<td>
-19.3
+19.3
<td>
-1
+1
<td>
-Ge
+Ge
<td>
-“ See also: ISO C 7.1.4, 7.2, Amendment 1
-4.3.“ 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>

-Delete this cross reference.
+Delete this cross reference.
If necessary, expand the main text to include the relevant
-referenced text
+referenced text
 
<td>
 
<tr valign="top">
<td>
-US 65
+US 65
<td>
-20
+20
<td>
 
<td>
-te
+te
<td>
-Scoped allocators and allocator propagation traits
+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.
+tuple.
<td>
-Sketch of proposed resolution: Eliminate
+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.
-Components that I propose eliminating
-include 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 ?</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>.
+?</a>.
 
<td>
 
<tr valign="top">
<td>
-UK 
-198
+UK 
+198
<td>
-20
+20
<td>
 
<td>
-Ed
+Ed
<td>
-The
+The
organization of clause 20 could be improved to better group related
-items, making the standard easier to navigate.
+items, making the standard easier to navigate.
<td>
-20.6.7, 20.6.8, 20.6.9 and 20.6.10 should be
+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
@@ -9906,403 +8767,356 @@
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
+- see more general comment on this
 
<td>
 
<tr valign="top">
<td>
-UK 
-199
+UK 
+199
<td>
-20.1.1,
-20.1.2
+20.1.1,
+20.1.2
<td>
-2
+2
<td>
-Te
+Te
<td>
-The requirement that programs do not supply
+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.
+differently to user written code.
 
<td>
-Replace the
-term 'program' with 'user'.
+Replace the
+term 'program' with 'user'.
<td>
 
<tr valign="top">
<td>
-UK 
-200
+UK 
+200
<td>
-20.1.4
+20.1.4
<td>
 
<td>
-Te
+Te
<td>
-All standard
+All standard
library use expects Predicates to be CopyConstructible, and this
should be recognised easily without reatedly stating on every
-use-case.
+use-case.
<td>
-Either require CopyConstructible<F> as part
+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.
+Callable. Consider making (Std)Predicate SemiRegular.
 
<td>
 
<tr valign="top">
<td>
-UK 
-201
+UK 
+201
<td>
-20.1.5
+20.1.5
<td>
 
<td>
-Te
+Te
<td>
-The
-Consistency axiom for LessThanComparable will not compile.
+The
+Consistency axiom for LessThanComparable will not compile.
<td>
-Add a requires clause to the Consistency axiomL
+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.
+<=/>= requirement.
 
<td>
 
<tr valign="top">
<td>
-JP 33
+JP 33
<td>
-20.1.5
+20.1.5
<td>
 
<td>
-te
+te
<td>
-LessThanComparable and
-EqualityComparable don't correspond to NaN.
+LessThanComparable and
+EqualityComparable don't correspond to NaN.
<td>
Apply concept_map to these concepts at
-FloatingPointType
+"margin-top: 0.04in; margin-bottom: 0.04in">Apply concept_map to these concepts at
+FloatingPointType
 
<td>
 
<tr valign="top">
<td>
-US 66
+US 66
<td>
-20.1.10
+20.1.10
<td>
 
<td>
-te
+te
<td>
-Application of the
+Application of the
"Regular" concept to floating-point types appears to be
-controversial (see long discussion on std-lib reflector).
+controversial (see long discussion on std-lib reflector).
<td>
-State that the
+State that the
“Regular” concept does not apply to floating-point
-types.
+types.
<td>
 
<tr valign="top">
<td>
-JP 34
+JP 34
<td>
-20.2
+20.2
<td>
-1st paragraph, 4th line
+1st paragraph, 4th line
 
<td>
-ed
+ed
<td>
-Though N2672 pointed at adding
-"#include<initializer_list>", it isn't reflected.
+Though N2672 pointed at adding
+"#include<initializer_list>", it isn't reflected.
<td>
-add followings
-#include <initializer_list> // for
-concept_map
+add followings
+#include <initializer_list> // for
+concept_map
<td>
 
<tr valign="top">
<td>
-US 67
+US 67
<td>
-20.2.1
+20.2.1
<td>
-¶ 5 first
-sent.
+¶ 5 first
+sent.
<td>
-ed
+ed
<td>
-Some connective words are
-missing.
+Some connective words are
+missing.
<td>
-Insert
+Insert
“corresponding to” before “an lvalue reference
-type.”
+type.”
<td>
 
<tr valign="top">
<td>
-JP 35
+JP 35
<td>
-20.2.3
+20.2.3
<td>
-6th paragraph, 1st line
+6th paragraph, 1st line
 
<td>
-ed
+ed
<td>
-Typo,
-"stdforward" should be "std::forward"
+Typo,
+"stdforward" should be "std::forward"
<td>
-Correct typo.
+Correct typo.
<td>
 
<tr valign="top">
<td>
-UK 
-202
+UK 
+202
<td>
-20.2.4
+20.2.4
<td>
 
<td>
-Ed
+Ed
<td>
-The references to pair in the tuple-like access to
+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.
+a namespace std block.
 
<td>
-Remove the
-std:: qualification from these references to pair.
+Remove the
+std:: qualification from these references to pair.
<td>
 
<tr valign="top">
<td>
-US 68
+US 68
<td>
-20.2.12
+20.2.12
<td>
-IntegralLike
+IntegralLike
<td>
-te/ed
+te/ed
<td>
-The code defining the
-context is syntactically incorrect.
+The code defining the
+context is syntactically incorrect.
<td>
-Insert a comma in two
+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.
+of the fourth line of refinements.
<td>
 
<tr valign="top">
<td>
-UK 
-203
+UK 
+203
<td>
-20.3.2
+20.3.2
<td>
-1-4
+1-4
<td>
-Ed
+Ed
<td>
-The ratio_xyz types have a misplaced '}'. For
+The ratio_xyz types have a misplaced '}'. For
example: template <class R1, class R2> struct ratio_add {
-typedef see below} type; ;
+typedef see below} type; ;
 
<td>
-Move the '}'
+Move the '}'
to after the typedef: template <class R1, class R2> struct
-ratio_add { typedef see below type; };
+ratio_add { typedef see below type; };
<td>
 
<tr valign="top">
<td>
-JP 36
+JP 36
<td>
-20.4.2.1
+20.4.2.1
<td>
-19th paragraph, 6th line
+19th paragraph, 6th line
 
<td>
-ed
+ed
<td>
-Typo.
-"it it" should be "it is"
+Typo.
+"it it" should be "it is"
<td>
-Correct typo.
+Correct typo.
<td>
 
<tr valign="top">
<td>
-UK 
-204
+UK 
+204
<td>
-20.5
+20.5
<td>
-Table
-41
+Table
+41
<td>
-Te
+Te
<td>
-It is not possible to create a variant union based
+It is not possible to create a variant union based
on a parameter pack expansion, e.g. to implement a classic
-discriminated union template.
+discriminated union template.
 
<td>
-Restore
-aligned_union template that was removed by LWG issue 856.
+Restore
+aligned_union template that was removed by LWG issue 856.
<td>
 
<tr valign="top">
<td>
-US 69
+US 69
<td>
-20.5
+20.5
<td>
 
<td>
-ed
+ed
<td>
-This section, dealing with
+This section, dealing with
tuple<>, should be in the same section as the similar utility
-pair<>.
+pair<>.
<td>
-Restructure Clause 20 so
-as to bring these similar components together.
+Restructure Clause 20 so
+as to bring these similar components together.
<td>
 
<tr valign="top">
<td>
-UK 
-205
+UK 
+205
<td>
-20.5.3
+20.5.3
<td>
 
<td>
-Te
+Te
<td>
-integral_constant objects should be usable in
+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.
+this possible.
 
<td>
-Add a
+Add a
constexpr conversion operator to class tempalate integral_constant:
-constexpr operator value_type() { return value; }
+constexpr operator value_type() { return value; }
<td>
 
<tr valign="top">
<td>
-UK 
-206
+UK 
+206
<td>
-20.5.5
+20.5.5
<td>
-para
-4
+para
+4
<td>
-Te
+Te
<td>
-Currently the std says: "In order to instantiate
+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.
+on whether the template can be instantiated.
 
<td>
-Change: "In
+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:"
+formed:"
<td>
 
<tr valign="top">
<td>
-UK 
-207
+UK 
+207
<td>
-20.5.6.1
+20.5.6.1
<td>
-Table
-36
+Table
+36
<td>
-Ed
+Ed
<td>
-suffix
-"::type" is missing from the some of the examples.
+suffix
+"::type" is missing from the some of the examples.
<td>
-Change: Example:remove_const<const volatile
+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
@@ -10318,110 +9132,100 @@
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
+int*>::type is const volatile int*. —end example
 
<td>
 
<tr valign="top">
<td>
-JP 37
+JP 37
<td>
-20.5.7
+20.5.7
<td>
-Table 41
+Table 41
<td>
-ed
+ed
<td>
-Typo.
+Typo.
There isn't a period at the end of enable_if's
-comments.
+"text-indent: 0.19in; margin-bottom: 0in">There isn't a period at the end of enable_if's
+comments.
 
-If B is true, the member typedef type
+If B is true, the member typedef type
shall equal T; otherwise, there shall be no member typedef
-type
+type
 
-should be
+should be
 
-If B is true, the member typedef type
+If B is true, the member typedef type
shall equal T; otherwise, there shall be no member typedef
-type.
+type.
 
<td>
-Add ”.”
+Add ”.”
<td>
 
<tr valign="top">
<td>
-US 70
+US 70
<td>
-20.6
+20.6
<td>
 
<td>
-te
+te
<td>
-Specifications now
+Specifications now
expressed via narrative text are more accurately and clearly
-expressed via executable code.
+expressed via executable code.
<td>

-Wherever concepts are
+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.
+two nearly-identical notions.
 
<td>
 
<tr valign="top">
<td>
-US 71
+US 71
<td>
-20.6.7
+20.6.7
<td>
-Table 51, last row, column
-3
+Table 51, last row, column
+3
<td>
-ed
+ed
<td>
-The grammar is
-incorrect.
+The grammar is
+incorrect.
<td>
-Change “conversion
-are” to “conversion is”.
+Change “conversion
+are” to “conversion is”.
<td>
 
<tr valign="top">
<td>
-JP 38
+JP 38
<td>
-20.6.12.1.3
+20.6.12.1.3
<td>
 
<td>
-te
+te
<td>

-add the move requirement for
-bind's return type. 
+add the move requirement for
+bind's return type. 

-For example, assume following
-th1 and th2,
- 
+For example, assume following
+th1 and th2,
+ 
void f(vector<int> v) { } 
 
vector<int> v{ ... }; 
@@ -10432,408 +9236,330 @@
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.
+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
+Add the following requirements. 
+"it
has a public move constructor that performs a member-wise
-move."
-Add the MoveConstructible.
+move."
+Add the MoveConstructible.
<td>
 
<tr valign="top">
<td>
-JP 39
+JP 39
<td>
-20.6.16.2
+20.6.16.2
<td>
 
<td>
-te
+te
<td>
-There are no requires corresponding to F
-of std::function.
+There are no requires corresponding to F
+of std::function.
<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&&);
+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&&);
 
should be
+"text-indent: 0.06in; margin-bottom: 0in">should be
 
-template<class F, Allocator
-A>
-requires CopyConstructible<F>
-&& Callable<F, ArgTypes...>
-&& Convertible<Callable<F,
-ArgTypes...>::result_type, R>
-function(allocator_arg_t, const A&,
-F);
-template<class F, Allocator
-A>
-requires CopyConstructible<F>
-&& Callable<F, ArgTypes...>
-&& Convertible<Callable<F,
-ArgTypes...>::result_type, R>
-function(allocator_arg_t, const A&,
-F&&);
+template<class F, Allocator
+A>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+function(allocator_arg_t, const A&,
+F);
+template<class F, Allocator
+A>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+function(allocator_arg_t, const A&,
+F&&);
 
<td>
 
<tr valign="top">
<td>
-JP 40
+JP 40
<td>
-20.6.16.2
+20.6.16.2
<td>
 
<td>
-ed
+ed
<td>
-Thougn it's "Allocator Aloc" at other
+Thougn it's "Allocator Aloc" at other
places, it's "Allocator A" only std::function constructor template
-parameter.
+parameter.
<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&&);
+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&&);
 
should be
+"text-indent: 0.06in; margin-bottom: 0in">should be
 
-template<class F, Allocator
+template<class F, Allocator
Alloc> function(allocator_arg_t, const Alloc
-&, F);
+&, F);
template<class F, Allocator Alloc>
+"margin-top: 0.04in; margin-bottom: 0.04in">template<class F, Allocator Alloc>
function(allocator_arg_t, const Alloc &,
-F&&);
+F&&);
 
<td>
 
<tr valign="top">
<td>
-JP 41
+JP 41
<td>
-20.6.16.2
+20.6.16.2
<td>
 
<td>
-te
+te
<td>
-There are no requires corresponding to R
-and Args of UsesAllocator.
+There are no requires corresponding to R
+and Args of UsesAllocator.
<td>
-Correct as follows.
-template <class R, class...
-Args>
-concept_map
-UsesAllocator<function<R(Args...)>, Alloc> {
-typedef Alloc allocator_type;
-}
+Correct as follows.
+template <class R, class...
+Args>
+concept_map
+UsesAllocator<function<R(Args...)>, Alloc> {
+typedef Alloc allocator_type;
+}
 
should be
+"text-indent: 0.06in; margin-bottom: 0in">should be
 
-template <Returnable R,
-CopyConstructible... Args>
-concept_map
-UsesAllocator<function<R(Args...)>, Alloc> {
-typedef Alloc allocator_type;
-}
+template <Returnable R,
+CopyConstructible... Args>
+concept_map
+UsesAllocator<function<R(Args...)>, Alloc> {
+typedef Alloc allocator_type;
+}
<td>
 
<tr valign="top">
<td>
-JP 42
+JP 42
<td>
-20.6.16.2
+20.6.16.2
<td>
 
<td>
-ed
+ed
<td>
The requires are wrong.
-R require Returnable, and ArgTypes
+"margin-top: 0.04in; margin-bottom: 0.04in">The requires are wrong.
+R require Returnable, and ArgTypes
requires CopyConstructible by a definition of function, then it's a
-mistake to designate followings by MoveConstructible.
+mistake to designate followings by MoveConstructible.
<td>
-Correct as follows.
+Correct as follows.
 
-template <MoveConstructible R,
-MoveConstructible... ArgTypes>
-bool operator==(const
-function<R(ArgTypes...)>&, nullptr_t);
-template <MoveConstructible R,
-MoveConstructible... ArgTypes>
-bool operator==(nullptr_t, const
-function<R(ArgTypes...)>&);
-template <MoveConstructible R,
-MoveConstructible... ArgTypes>
-bool operator!=(const
-function<R(ArgTypes...)>&, nullptr_t);
-template <MoveConstructible R,
-MoveConstructible... ArgTypes>
-bool operator!=(nullptr_t, const
-function<R(ArgTypes...)>&);
-template <MoveConstructible R,
-MoveConstructible... ArgTypes>
-void
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+bool operator==(const
+function<R(ArgTypes...)>&, nullptr_t);
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+bool operator==(nullptr_t, const
+function<R(ArgTypes...)>&);
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+bool operator!=(const
+function<R(ArgTypes...)>&, nullptr_t);
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+bool operator!=(nullptr_t, const
+function<R(ArgTypes...)>&);
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+void
swap(function<R(ArgTypes...)>&,
-function<R(ArgTypes...)>&);
+function<R(ArgTypes...)>&);
 
should be
+"text-indent: 0.06in; margin-bottom: 0in">should be
 
-template <Returnable R,
-CopyConstructible... ArgTypes>
-bool operator==(const
-function<R(ArgTypes...)>&, nullptr_t);
-template <Returnable R,
-CopyConstructible... ArgTypes>
-bool operator==(nullptr_t, const
-function<R(ArgTypes...)>&);
-template <Returnable R,
-CopyConstructible... ArgTypes>
-bool operator!=(const
-function<R(ArgTypes...)>&, nullptr_t);
-template <Returnable R,
-CopyConstructible... ArgTypes>
-bool operator!=(nullptr_t, const
-function<R(ArgTypes...)>&);
-template <Returnable R,
-CopyConstructible... ArgTypes>
-void swap(function<R(ArgTypes...)>&,
-function<R(ArgTypes...)>&);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+bool operator==(const
+function<R(ArgTypes...)>&, nullptr_t);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+bool operator==(nullptr_t, const
+function<R(ArgTypes...)>&);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+bool operator!=(const
+function<R(ArgTypes...)>&, nullptr_t);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+bool operator!=(nullptr_t, const
+function<R(ArgTypes...)>&);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+void swap(function<R(ArgTypes...)>&,
+function<R(ArgTypes...)>&);
 
<td>
 
<tr valign="top">
<td>
-UK 
-208
+UK 
+208
<td>
-20.6.17
+20.6.17
<td>
-1
+1
<td>
-Te
+Te
<td>
-std::hash should be implemented for much more of
+std::hash should be implemented for much more of
the standard library. In particular for pair, tuple and all the
-standard containers.
+standard containers.
 
<td>
-.
+.
<td>
 
<tr valign="top">
<td>
-UK 
-209
+UK 
+209
<td>
-20.7
+20.7
<td>
 
<td>
-Te
+Te
<td>
-Smart
-pointers cannot be used in constrained templates
+Smart
+pointers cannot be used in constrained templates
<td>
-Provide constraints for smart pointers
+Provide constraints for smart pointers
 
 
<td>
 
<tr valign="top">
<td>
-UK 
-213
+UK 
+213
<td>
-20.7.6
+20.7.6
<td>
 
<td>
-Te
+Te
<td>
-std::allocator should be constrained to simplify
+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.
+the requirements of this template.
 
<td>
-The primary
+The primary
allocator template should be constrained to require
ObjectType<T> and FreeStoreAllocatable<T>. Further
-operations to be constrained as required.
+operations to be constrained as required.
<td>
 
<tr valign="top">
<td>
-UK 
-214
+UK 
+214
<td>
-20.7.8
+20.7.8
<td>
 
<td>
-Te
+Te
<td>
-raw_storage_iterator needs constraining as an
-iterator adaptor to be safely used in constrained templates
+raw_storage_iterator needs constraining as an
+iterator adaptor to be safely used in constrained templates
 
<td>
-Constrain the
-raw_storage_iterator template
+Constrain the
+raw_storage_iterator template
<td>
 
<tr valign="top">
<td>
-UK 
-210
+UK 
+210
<td>
-20.7.11
+20.7.11
<td>
 
<td>
-Te
+Te
<td>
-Specialized
+Specialized
algorithms for memory managenment need requirements to be easily
-usable in constrained templates
+usable in constrained templates
<td>
-Provide constraints for all algorithms in
-20.7.11
+Provide constraints for all algorithms in
+20.7.11
 
 
<td>
 
<tr valign="top">
<td>
-DE-20
+DE-20
<td>
-20.7.12
+20.7.12
<td>
 
<td>
-ed
+ed
<td>
-DE-20 The section heading
+DE-20 The section heading
and the first sentence use the term "template function", which is
-undefined.
+undefined.
<td>

-Replace "template function"
-by "function template".
+Replace "template function"
+by "function template".
 
<td>
 
<tr valign="top">
<td>
-US 72
+US 72
<td>
-20.7.12
+20.7.12
<td>
 
<td>
-te
+te
<td>
-bind should support move-only functors
-and bound arguments.
+bind should support move-only functors
+and bound arguments.
 
<td>
 
@@ -10841,158 +9567,141 @@
 
<tr valign="top">
<td>
-DE-21
+DE-21
<td>
-20.7.12.1.3
+20.7.12.1.3
<td>
 
<td>
-te
+te
<td>
-DE-21 The specification
+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.
+such specification appears to exist.
<td>
-Add the missing
+Add the missing
specification in the same section, or add a cross-reference
-indicating the section where the specification appears.
+indicating the section where the specification appears.
<td>
 
<tr valign="top">
<td>
-UK 
-211
+UK 
+211
<td>
-20.7.12.2.3
+20.7.12.2.3
<td>
-11
+11
<td>
-Te
+Te
<td>
-The nullptr_t type was introduced to resolve the
+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.
+library.
 
<td>
-Change
+Change
signature here and in the synopsis to: unique_ptr&
operator=(nullptr_t); Strike the sentance an note before the
-Effects clause.
+Effects clause.
<td>
 
<tr valign="top">
<td>
-UK 
-212
+UK 
+212
<td>
-20.7.13.7
+20.7.13.7
<td>
 
<td>
-Te
+Te
<td>
-The pointer-safety API is nothing to do with smart
+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.
+memory management.
 
<td>
-Move this
+Move this
specification to 18.5. Move the declarations into the header
-<new>.
+<new>.
<td>
 
<tr valign="top">
<td>
-DE-22
+DE-22
<td>
-20.7.16.2
+20.7.16.2
<td>
 
<td>
-te
+te
<td>
-DE-22 The conditions for
+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.
+std::vector<T1>, because it (arguably) "contains" T1.
<td>
-Consider stating the
+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".
+"if and only if" instead of "iff".
<td>
 
<tr valign="top">
<td>
-US 73
+US 73
<td>
-20.7.18
+20.7.18
<td>
 
<td>
-te
+te
<td>
-The
+The
std::reference_closure template is redundant with std::function and
-should be removed.
+should be removed.
 
-std::reference_closure is
+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:
+std::reference_closure was flawed in several ways:
<ol start="3">
<li>
-it failed to enable a
+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
+instances, and
<li>
-it failed to account for
+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>
+realistic application.</ol>
 
<td>
-Remove 20.7.18
-[func.referenceclosure].
+Remove 20.7.18
+[func.referenceclosure].
 
-Remove 5.1.1 paragraph 12.
+Remove 5.1.1 paragraph 12.
<td>
 
<tr valign="top">
<td>
-US 74
+US 74
<td>
-20.8
+20.8
<td>
 
<td>
-te
+te
<td>
-Scoped allocators
+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
@@ -11004,170 +9713,144 @@
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.
+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
+Remove support for scoped
allocators from the working paper. This includes at least the
-following changes:
+following changes:
 
-Remove 20.8.3
-[allocator.element.concepts]
+Remove 20.8.3
+[allocator.element.concepts]
 
-Remove 20.8.7
-[allocator.adaptor]
+Remove 20.8.7
+[allocator.adaptor]
 
-Remove 20.8.10
-[construct.element]
+Remove 20.8.10
+[construct.element]
 
-In Clause 23: replace
+In Clause 23: replace
requirements naming the AllocatableElement concept with
requirements naming CopyConstructible, MoveConstructible,
-DefaultConstructible, or Constructible, as appropriate.
+DefaultConstructible, or Constructible, as appropriate.
 
<td>
 
<tr valign="top">
<td>
-US 74
+US 74
<td>
-20.8.2.2
+20.8.2.2
<td>
-(a) synopsis (b) after
-¶ 14
+(a) synopsis (b) after
+¶ 14
<td>
-te/ed
+te/ed
<td>
-A concept name is twice
-misspelled.
+A concept name is twice
+misspelled.
<td>
-Change
+Change
“Hasconstructor” to “HasConstructor”
-(twice).
+(twice).
<td>
 
<tr valign="top">
<td>
-US 75
+US 75
<td>
-20.8.2.2
+20.8.2.2
<td>
 
<td>
-te
+te
<td>
-Allocator concepts are
-incomplete
+Allocator concepts are
+incomplete
<td>

-See paper:
-http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf>
+See paper:
+http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf
 
<td>
 
<tr valign="top">
<td>
-JP 43
+JP 43
<td>
-20.8.3
+20.8.3
<td>
 
<td>
-ed
+ed
<td>
-Typo.
-"alloc" should be "Alloc"
+Typo.
+"alloc" should be "Alloc"
<td>
-Correct as follows.
+Correct as follows.
 
-auto concept UsesAllocator<typename
-T, typename Alloc> {
-requires Allocator<alloc>;
-typename allocator_type =
-T::allocator_type;
+auto concept UsesAllocator<typename
+T, typename Alloc> {
+requires Allocator<alloc>;
+typename allocator_type =
+T::allocator_type;
 
-should be
+should be
 
-auto concept UsesAllocator<typename
-T, typename Alloc> {
-requires
-Allocator<Alloc>;
-typename allocator_type =
-T::allocator_type;
+auto concept UsesAllocator<typename
+T, typename Alloc> {
+requires
+Allocator<Alloc>;
+typename allocator_type =
+T::allocator_type;
 
<td>
 
<tr valign="top">
<td>
-UK 
-215
+UK 
+215
<td>
-20.8.3.3
+20.8.3.3
<td>
-6,8
+6,8
<td>
-Ed
+Ed
<td>
-Extra pair of {}, presumably some formatting code
-gone awry : duration& operator-{-}();
+Extra pair of {}, presumably some formatting code
+gone awry : duration& operator-{-}();
 
<td>
-Remove the {}
-or fix formatting
+Remove the {}
+or fix formatting
<td>
 
<tr valign="top">
<td>
-US 77
+US 77
<td>
-20.8.4
+20.8.4
<td>
 
<td>
-te
+te
<td>
-Allocator-specific move
+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
+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
@@ -11175,81 +9858,59 @@
(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.
+a tiny fraction of the C++ community.
 
<td>
-Remove 20.8.4.
+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>
 
<tr valign="top">
<td>
-US 78
+US 78
<td>
-20.8.12, 20.8.13.2
+20.8.12, 20.8.13.2
<td>
 
<td>
-te
+te
<td>
-There is
-presently no way to convert directly from a
-<code>shared_ptr</code> to a <code>unique_ptr</code>.
+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
+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>
+"Conversion from <code>shared_ptr</code> to <code>unique_ptr".</code>
 
<td>
 
<tr valign="top">
<td>
-US 79
+US 79
<td>
-20.8.12.2.1
+20.8.12.2.1
<td>
 
<td>
-te
+te
<td>
-[unique.ptr.single.ctor]/5 no longer
+[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:
+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>
 
@@ -11257,1315 +9918,950 @@
 
<tr valign="top">
<td>
-JP 44
+JP 44
<td>
-20.8.13.6
+20.8.13.6
<td>
 
<td>
-te
+te
<td>
-The 1st parameter p and 2nd parameter v
-is now shared_ptr<T> *.
-It should be shared_ptr<T>&,
+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.
+null pointer" at the requires.
<td>
-Change shared_ptr<T>& or add
-the "p shall not be a null pionter" at the requires.
+Change shared_ptr<T>& or add
+the "p shall not be a null pionter" at the requires.
<td>
 
<tr valign="top">
<td>
-JP 45
+JP 45
<td>
-20.9
+20.9
<td>
 
<td>
-te
+te
<td>
-Rep, Period, Clock and Duration don't
-correspond to concept.
-template <class Rep, class Period =
-ratio<1>> class duration;
+Rep, Period, Clock and Duration don't
+correspond to concept.
+template <class Rep, class Period =
+ratio<1>> class duration;
template <class Clock, class Duration =
-typename Clock::duration> class time_point;
+"margin-top: 0.04in; margin-bottom: 0.04in">template <class Clock, class Duration =
+typename Clock::duration> class time_point;
 
<td>
-Make concept for Rep, Period, Clock and
+Make concept for Rep, Period, Clock and
Duration, and fix 20.9 and wait_until and wait_for's template
-parameter at 30.
+parameter at 30.
<td>
 
<tr valign="top">
<td>
-US 80
+US 80
<td>
-20.9.2.1
+20.9.2.1
<td>
-Heading
+Heading
<td>
-ed
+ed
<td>
-The section heading does
-not describe the contents.
+The section heading does
+not describe the contents.
<td>

-Change the heading
+Change the heading
“is_floating_point” to
“treat_as_floating_point”.
-Optionally adjust the section’s label similarly.
+Optionally adjust the section’s label similarly.
 
<td>
 
<tr valign="top">
<td>
-US 81
+US 81
<td>
-20.9.3
+20.9.3
<td>
 
<td>
-te
+te
<td>
-chrono::duration is missing the modulous
+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.
+correct units of the operation.
 
-Ex:
+Ex:
 
-milliseconds ms(...);
-microseconds us(...);
- 
-ms % us; // microseconds
-us % ms; // microseconds
-ms % 5; // milliseconds
-5 % ms; // does not compile
- 
-<td>
-Add:
- 
-template <class Rep, class Period =
-ratio<1>>
-class duration {
-public:
-...
-duration&
-operator%(const rep&);
-duration&
-operator%(const duration&);
-..
-};
- 
-template <class Rep1,
-class Period,
-class Rep2>
-duration<typename
-common_type<
-Rep1, Rep2>::type,
-Period>
-operator%(const
-duration<Rep1, Period>& d, const Rep2& s);
- 
-template <class Rep1,
-class Period1,
-class Rep2, class
-Period2>
-typename
+milliseconds ms(...);
+microseconds us(...);
+ 
+ms % us; // microseconds
+us % ms; // microseconds
+ms % 5; // milliseconds
+5 % ms; // does not compile
+ 
+<td>
+Add:
+ 
+template <class Rep, class Period =
+ratio<1>>
+class duration {
+public:
+...
+duration&
+operator%(const rep&);
+duration&
+operator%(const duration&);
+..
+};
+ 
+template <class Rep1,
+class Period,
+class Rep2>
+duration<typename
+common_type<
+Rep1, Rep2>::type,
+Period>
+operator%(const
+duration<Rep1, Period>& d, const Rep2& s);
+ 
+template <class Rep1,
+class Period1,
+class Rep2, class
+Period2>
+typename
common_type<duration<Rep1, Period1>, duration<Rep2,
-Period2>>::type
-operator%(const
+Period2>>::type
+operator%(const
duration<Rep1, Period1>& lhs, const duration<Rep2,
-Period2>& rhs);
+Period2>& rhs);
 
<td>
 
<tr valign="top">
<td>
-US 82
+US 82
<td>
-20.9.5.3
+20.9.5.3
<td>
-after ¶ 1
+after ¶ 1
<td>
-ed
+ed
<td>
-The code synopsis has a
-minor alignment error.
+The code synopsis has a
+minor alignment error.
<td>
-Align “rep”
-with the other symbols defined in this synopsis.
+Align “rep”
+with the other symbols defined in this synopsis.
<td>
 
<tr valign="top">
<td>
-UK 
-216
+UK 
+216
<td>
-21
+21
<td>
 
<td>
-Te
+Te
<td>
-All the
+All the
containers use concepts for their iterator usage, exect for
-basic_string. This needs fixing.
+basic_string. This needs fixing.
<td>
-Use concepts
-for iterator template parameters throughout the chapter.
+Use concepts
+for iterator template parameters throughout the chapter.
<td>
 
<tr valign="top">
<td>
-JP 46
-<td>
-21.2, 21.3
-<td>
- 
-<td>
-te
-<td>
-The basic_string does not use
-concept.
-<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>,
-Allocator Alloc =
-allocator<charT> >
-class basic_string;
- 
-template<class charT, class traits,
-Allocator Alloc>
-basic_string<charT,traits,Alloc>
-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>&&
-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>&&
-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>&&
-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>
-operator+(const charT* lhs,
-const
-basic_string<charT,traits,Alloc>& rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-basic_string<charT,traits,Alloc>&&
-operator+(const charT* lhs,
-basic_string<charT,traits,Alloc>&&
-rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-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>&&
-operator+(charT lhs,
+JP 46
+<td>
+21.2, 21.3
+<td>
+ 
+<td>
+te
+<td>
+The basic_string does not use
+concept.
+<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>,
+Allocator Alloc =
+allocator<charT> >
+class basic_string;
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>
+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>&&
+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>&&
+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>&&
+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>
+operator+(const charT* lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(const charT* lhs,
+basic_string<charT,traits,Alloc>&&
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+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>&&
+operator+(charT lhs,
basic_string<charT,traits,Alloc>&&
-rhs);
+rhs);
 
-template<class charT, class traits,
-Allocator Alloc>
-basic_string<charT,traits,Alloc>
-operator+(const
-basic_string<charT,traits,Alloc>& lhs,
-const charT* rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-basic_string<charT,traits,Alloc>&&
-operator+(basic_string<charT,traits,Alloc>&&
-lhs,
-const charT* rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-basic_string<charT,traits,Alloc>
-operator+(const
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>
+operator+(const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(basic_string<charT,traits,Alloc>&&
+lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>
+operator+(const
basic_string<charT,traits,Alloc>& lhs, charT
-rhs);
+rhs);
 
-template<class charT, class traits,
-Allocator Alloc>
-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,
-const
-basic_string<charT,traits,Alloc>& rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-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,
-const charT* rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-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,
-const
-basic_string<charT,traits,Alloc>& rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-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,
-const
-basic_string<charT,traits,Alloc>& rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-bool operator< (const
-basic_string<charT,traits,Alloc>& lhs,
-const charT* rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-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,
-const
-basic_string<charT,traits,Alloc>& rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-bool operator> (const
-basic_string<charT,traits,Alloc>& lhs,
-const charT* rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-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,
-const
-basic_string<charT,traits,Alloc>& rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-bool operator<=(const
-basic_string<charT,traits,Alloc>& lhs,
-const charT* rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-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,
-const
-basic_string<charT,traits,Alloc>& rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-bool operator>=(const
-basic_string<charT,traits,Alloc>& lhs,
-const charT* rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-bool operator>=(const charT*
-lhs,
-const
-basic_string<charT,traits,Alloc>& rhs);
- 
-// 21.3.8.8: swap
-template<class charT, class traits,
-Allocator Alloc>
-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,
-basic_string<charT,traits,Alloc>&
-rhs);
- 
-template<class charT, class traits,
-Allocator Alloc>
-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>
-basic_istream<charT,traits>&
-operator>>(basic_istream<charT,traits>&&
-is,
-basic_string<charT,traits,Alloc>&
-str);
- 
-template<class charT, class traits,
-Allocator Alloc>
-basic_ostream<charT,
-traits>&
-operator<<(basic_ostream<charT,
-traits>&& os,
-const
-basic_string<charT,traits,Alloc>& str);
- 
-template<class charT, class traits,
-Allocator Alloc>
-basic_istream<charT,traits>&
-getline(basic_istream<charT,traits>&&
-is,
-basic_string<charT,traits,Alloc>&
-str,
-charT delim);
- 
-template<class charT, class traits,
-Allocator Alloc>
-basic_istream<charT,traits>&
-getline(basic_istream<charT,traits>&&
-is,
-basic_string<charT,traits,Alloc>&
-str);
- 
- 
-// 21.3 Class template
-basic_string
-namespace std {
-template<class charT, class traits =
-char_traits<charT>,
-Allocator Alloc =
-allocator<charT> >
-class basic_string {
-public:
-// types:
-typedef traits traits_type;
-typedef typename traits::char_type
-value_type;
-typedef Alloc
-allocator_type;
-typedef typename Alloc::size_type
-size_type;
-typedef typename
-Alloc::difference_type difference_type;
-typedef typename Alloc::reference
-reference;
-typedef typename
-Alloc::const_reference const_reference;
-typedef typename Alloc::pointer
-pointer;
-typedef typename
-Alloc::const_pointer const_pointer;
-typedef implementation-defined iterator;
-// See 23.1
-typedef implementation-defined
-const_iterator; // See 23.1
-typedef
-std::reverse_iterator<iterator> reverse_iterator;
-typedef
+template<class charT, class traits,
+Allocator Alloc>
+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,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+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,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+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,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+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,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator< (const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+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,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator> (const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+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,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator<=(const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+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,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator>=(const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator>=(const charT*
+lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+// 21.3.8.8: swap
+template<class charT, class traits,
+Allocator Alloc>
+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,
+basic_string<charT,traits,Alloc>&
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+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>
+basic_istream<charT,traits>&
+operator>>(basic_istream<charT,traits>&&
+is,
+basic_string<charT,traits,Alloc>&
+str);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_ostream<charT,
+traits>&
+operator<<(basic_ostream<charT,
+traits>&& os,
+const
+basic_string<charT,traits,Alloc>& str);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_istream<charT,traits>&
+getline(basic_istream<charT,traits>&&
+is,
+basic_string<charT,traits,Alloc>&
+str,
+charT delim);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_istream<charT,traits>&
+getline(basic_istream<charT,traits>&&
+is,
+basic_string<charT,traits,Alloc>&
+str);
+ 
+ 
+// 21.3 Class template
+basic_string
+namespace std {
+template<class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_string {
+public:
+// types:
+typedef traits traits_type;
+typedef typename traits::char_type
+value_type;
+typedef Alloc
+allocator_type;
+typedef typename Alloc::size_type
+size_type;
+typedef typename
+Alloc::difference_type difference_type;
+typedef typename Alloc::reference
+reference;
+typedef typename
+Alloc::const_reference const_reference;
+typedef typename Alloc::pointer
+pointer;
+typedef typename
+Alloc::const_pointer const_pointer;
+typedef implementation-defined iterator;
+// See 23.1
+typedef implementation-defined
+const_iterator; // See 23.1
+typedef
+std::reverse_iterator<iterator> reverse_iterator;
+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());
-basic_string(const basic_string&
-str);
-basic_string(basic_string&&
-str);
-basic_string(const basic_string&
-str, size_type pos, size_type n = npos,
-const Alloc& a =
-Alloc());
-basic_string(const charT* s,
-size_type n, const Alloc& a =
-Alloc());
-basic_string(const charT* s, const
-Alloc& a = Alloc());
-basic_string(size_type n, charT c, const
-Alloc& a = Alloc());
-template<InputIterator
-Iter>
-basic_string(Iter begin,
-Iter end,
-const Alloc& a =
-Alloc());
-basic_string(initializer_list<charT>, const
-Alloc& = Alloc());
-basic_string(const basic_string&,
-const Alloc&);
-basic_string(basic_string&&,
-const Alloc&);
-~basic_string();
-basic_string& operator=(const
-basic_string& str);
-basic_string&
-operator=(basic_string&& str);
-basic_string& operator=(const charT*
-s);
-basic_string& operator=(charT
-c);
-basic_string&
-operator=(initializer_list<charT>);
- 
-// 21.3.3 iterators:
-...
- 
-// 21.3.4 capacity:
-...
- 
-// 21.3.5 element access:
-...
- 
-// 21.3.6 modifiers:
-...
- 
-basic_string& append(const
-basic_string& str);
-basic_string& append(const
-basic_string& str, size_type pos,
-size_type n);
-basic_string& append(const charT* s,
-size_type n);
-basic_string& append(const charT*
-s);
-basic_string& append(size_type n,
-charT c);
-template<InputIterator
-Iter>
-basic_string& append(Iter
-first, Iter last);
-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, size_type pos,
-size_type n);
-basic_string& assign(const charT* s,
-size_type n);
-basic_string& assign(const charT*
-s);
-basic_string& assign(size_type n,
-charT c);
-template<InputIterator
-Iter>
-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,
-size_type pos2, size_type n);
-basic_string& insert(size_type pos,
-const charT* s, size_type n);
-basic_string& insert(size_type pos,
-const charT* s);
-basic_string& insert(size_type pos,
-size_type n, charT c);
-iterator insert(const_iterator p, charT
-c);
-void insert(const_iterator p, size_type
-n, charT c);
-template<InputIterator
-Iter>
-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,
-const basic_string& str,
-size_type pos2, size_type n2);
-basic_string& replace(size_type pos,
-size_type n1, const charT* s,
-size_type n2);
-basic_string& replace(size_type pos,
-size_type n1, const charT* s);
-basic_string& replace(size_type pos,
-size_type n1, size_type n2,
-charT c);
-basic_string& replace(iterator i1,
-iterator i2,
-const basic_string& str);
-basic_string& replace(iterator i1,
-iterator i2, const charT* s,
-size_type n);
-basic_string& replace(iterator i1,
-iterator i2, const charT* s);
-basic_string& replace(iterator i1,
-iterator i2,
-size_type n, charT c);
-template<InputIterator
-Iter>
-basic_string& replace(iterator i1,
-iterator i2,
-Iter j1, Iter j2);
-basic_string& replace(iterator,
-iterator, initializer_list<charT>);
- 
-...
- 
-// 21.3.7 string operations:
-...
- 
-template <class charT, class traits,
-Allocator Alloc>
-struct
-constructible_with_allocator_suffix<
-basic_string<charT, traits, Alloc>
-> : true_type { };
+const_reverse_iterator;
+static const size_type npos = -1;
+ 
+// 21.3.2 construct/copy/destroy:
+explicit basic_string(const
+Alloc& a = Alloc());
+basic_string(const basic_string&
+str);
+basic_string(basic_string&&
+str);
+basic_string(const basic_string&
+str, size_type pos, size_type n = npos,
+const Alloc& a =
+Alloc());
+basic_string(const charT* s,
+size_type n, const Alloc& a =
+Alloc());
+basic_string(const charT* s, const
+Alloc& a = Alloc());
+basic_string(size_type n, charT c, const
+Alloc& a = Alloc());
+template<InputIterator
+Iter>
+basic_string(Iter begin,
+Iter end,
+const Alloc& a =
+Alloc());
+basic_string(initializer_list<charT>, const
+Alloc& = Alloc());
+basic_string(const basic_string&,
+const Alloc&);
+basic_string(basic_string&&,
+const Alloc&);
+~basic_string();
+basic_string& operator=(const
+basic_string& str);
+basic_string&
+operator=(basic_string&& str);
+basic_string& operator=(const charT*
+s);
+basic_string& operator=(charT
+c);
+basic_string&
+operator=(initializer_list<charT>);
+ 
+// 21.3.3 iterators:
+...
+ 
+// 21.3.4 capacity:
+...
+ 
+// 21.3.5 element access:
+...
+ 
+// 21.3.6 modifiers:
+...
+ 
+basic_string& append(const
+basic_string& str);
+basic_string& append(const
+basic_string& str, size_type pos,
+size_type n);
+basic_string& append(const charT* s,
+size_type n);
+basic_string& append(const charT*
+s);
+basic_string& append(size_type n,
+charT c);
+template<InputIterator
+Iter>
+basic_string& append(Iter
+first, Iter last);
+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, size_type pos,
+size_type n);
+basic_string& assign(const charT* s,
+size_type n);
+basic_string& assign(const charT*
+s);
+basic_string& assign(size_type n,
+charT c);
+template<InputIterator
+Iter>
+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,
+size_type pos2, size_type n);
+basic_string& insert(size_type pos,
+const charT* s, size_type n);
+basic_string& insert(size_type pos,
+const charT* s);
+basic_string& insert(size_type pos,
+size_type n, charT c);
+iterator insert(const_iterator p, charT
+c);
+void insert(const_iterator p, size_type
+n, charT c);
+template<InputIterator
+Iter>
+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,
+const basic_string& str,
+size_type pos2, size_type n2);
+basic_string& replace(size_type pos,
+size_type n1, const charT* s,
+size_type n2);
+basic_string& replace(size_type pos,
+size_type n1, const charT* s);
+basic_string& replace(size_type pos,
+size_type n1, size_type n2,
+charT c);
+basic_string& replace(iterator i1,
+iterator i2,
+const basic_string& str);
+basic_string& replace(iterator i1,
+iterator i2, const charT* s,
+size_type n);
+basic_string& replace(iterator i1,
+iterator i2, const charT* s);
+basic_string& replace(iterator i1,
+iterator i2,
+size_type n, charT c);
+template<InputIterator
+Iter>
+basic_string& replace(iterator i1,
+iterator i2,
+Iter j1, Iter j2);
+basic_string& replace(iterator,
+iterator, initializer_list<charT>);
+ 
+...
+ 
+// 21.3.7 string operations:
+...
+ 
+template <class charT, class traits,
+Allocator Alloc>
+struct
+constructible_with_allocator_suffix<
+basic_string<charT, traits, Alloc>
+> : true_type { };
 
<td>
 
<tr valign="top">
<td>
-JP 47
+JP 47
<td>
-21.3
+21.3
<td>
 
<td>
-ed
+ed
<td>
-Typo. Missing ”>”
-template <class charT, class traits,
-Allocator Alloc
+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.
+Correct typo.
<td>
 
<tr valign="top">
<td>
-JP 48
+JP 48
<td>
-21.3
+21.3
<td>
 
<td>
-te
+te
<td>
-char_traits does not use concept.
-For example, create CharTraits concept
-and change as follows:
+char_traits does not use concept.
+For example, create CharTraits concept
+and change as follows:
 
-template<class charT,
-CharTraits traits = char_traits<charT>,
-class Allocator = allocator<charT>
->
+template<class charT,
+CharTraits traits = char_traits<charT>,
+class Allocator = allocator<charT>
+>
class basic_string {
+"margin-top: 0.04in; margin-bottom: 0.04in">class basic_string {
 
<td>
-Add a concept for char_traits.
+Add a concept for char_traits.
<td>
 
<tr valign="top">
<td>
-UK 
-217
+UK 
+217
<td>
-21.3
+21.3
<td>
 
<td>
-Ed
+Ed
<td>
-basic_string
+basic_string
refers to constructible_with_allocator_suffix, which I thought was
-removed?
+removed?
<td>
-Remove the lines: template <class charT, class
+Remove the lines: template <class charT, class
traits, class Alloc struct constructible_with_allocator_suffix<
basic_string<charT, traits, Alloc> > : true_type {
-};
+};
 
<td>
 
<tr valign="top">
<td>
-UK 
-218
+UK 
+218
<td>
-21.3.1
+21.3.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-The identity "&*(s.begin() + n) ==
+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.
+because it is in a different chapter.
 
<td>
-See my
-recommendations for "23.2.1, 23.2.6".
+See my
+recommendations for "23.2.1, 23.2.6".
<td>
 
<tr valign="top">
<td>
-UK 
-219
+UK 
+219
<td>
-21.3.6.6
-[string.replace]
+21.3.6.6
+[string.replace]
<td>
-11
+11
<td>
-Ed
+Ed
<td>
-Effects
+Effects
refers to "whose first begin() - i1 elements" However i1 is greater
-than begin()...
+than begin()...
<td>
-Effects
-refers to "whose first i1 - begin() elements"
+Effects
+refers to "whose first i1 - begin() elements"
<td>
 
<tr valign="top">
<td>
-UK 
-220
+UK 
+220
<td>
-21.3.8.9
+21.3.8.9
<td>
 
<td>
-Te
+Te
<td>
-The operator<< for basic_string takes the
+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)
+(20.7.13.2.8), complex (26.3.6) and sub_match (28.4)
 
<td>
-Use the same
+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.
+TR1, and new classes, did not receive an 'R-value' update.
<td>
 
<tr valign="top">
<td>
-FR 33
+FR 33
<td>
-22.1.1 [locale]
+22.1.1 [locale]
<td>
-3
+3
<td>
-ed
+ed
<td>
-ios_base::iostate err = 0;
+ios_base::iostate err = 0;
 
-iostate is a bitmask type and so could be
-an enumeration. Probably using
-goodbit is the solution.
+iostate is a bitmask type and so could be
+an enumeration. Probably using
+goodbit is the solution.
<td>
 
<td>
 
<tr valign="top">
<td>
-JP 49
+JP 49
<td>
-22.1.3.2.2
+22.1.3.2.2
<td>
 
<td>
-te
+te
<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 {
+codecvt does not use concept. For
+example, create CodeConvert concept and change as follows.
+template<CodeConvert Codecvt,
+class Elem = wchar_t> class wstring_convert {
<td>
-Add a concept for codecvt.
+Add a concept for codecvt.
<td>
 
<tr valign="top">
<td>
-JP 50
+JP 50
<td>
-22.1.3.2.2
+22.1.3.2.2
<td>
 
<td>
-te
+te
<td>
-Add custom allocator parameter to
+Add custom allocator parameter to
wstring_convert, since we cannot allocate memory for strings from a
-custom allocator.
+custom allocator.
<td>
-Correct as follows.
-template<class Codecvt, class Elem =
-wchar_t> class wstring_convert {
-public:
-typedef std::basic_string<char>
-byte_string;
-typedef std::basic_string<Elem>
-wide_string;
- 
-should be
- 
-template<class Codecvt, class Elem =
-wchar_t,
-Allocator WideAllocator =
-allocator<Elem>,
-Allocator ByteAllocator =
-allocator<char>>
-class wstring_convert {
-public:
-typedef std::basic_string<char,
+Correct as follows.
+template<class Codecvt, class Elem =
+wchar_t> class wstring_convert {
+public:
+typedef std::basic_string<char>
+byte_string;
+typedef std::basic_string<Elem>
+wide_string;
+ 
+should be
+ 
+template<class Codecvt, class Elem =
+wchar_t,
+Allocator WideAllocator =
+allocator<Elem>,
+Allocator ByteAllocator =
+allocator<char>>
+class wstring_convert {
+public:
+typedef std::basic_string<char,
char_traits<char>, ByteAllocator>
-byte_string;
+byte_string;
typedef std::basic_string<Elem,
+"margin-top: 0.04in; margin-bottom: 0.04in">typedef std::basic_string<Elem,
char_traits<Elem>, WideAllocator>
-wide_string;
+wide_string;
 
<td>
 
<tr valign="top">
<td>
-FI 4
+FI 4
<td>

-22.2.1.4.1
-22.2.1.4.2
+22.2.1.4.1
+22.2.1.4.2
<td>
 
<td>
-ed
+ed
<td>
-<tt>to_end and to_limit are both used. Only one is
-needed.</tt>
+<tt>to_end and to_limit are both used. Only one is
+needed.</tt>
<td>
-Change to_limit to
-to_end.
+Change to_limit to
+to_end.
<td>
 
<tr valign="top">
<td>
-FI 5
+FI 5
<td>
-<tt>22.2.1.4.2</tt>
+<tt>22.2.1.4.2</tt>
<td>
-#3
+#3
<td>
-ed
+ed
<td>

-<tt>[ Note: As a result of operations on state, it
+<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> 
+—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>Reasoning: When reading one element of
+<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>
+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>
+<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>
 
<tr valign="top">
<td>
-FI 6
+FI 6
<td>

-22.2.1.5
-See also 22.2.1.4
-(1,2,3)
+22.2.1.5
+See also 22.2.1.4
+(1,2,3)
<td>
 
<td>
-te
+te
<td>

-<tt>codecvt_byname is only specified to work with
+<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
@@ -12575,365 +10871,272 @@
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>
+known.</tt>
 
<td>
-<tt>There should be a built-in means to find a
-codecvt with a pair of character set names.</tt>
+<tt>There should be a built-in means to find a
+codecvt with a pair of character set names.</tt>
<td>
 
<tr valign="top">
<td>
-FI 7
+FI 7
<td>
-22.2.1.4
+22.2.1.4
<td>
-1,2,3
+1,2,3
<td>
-ed
+ed
<td>

-The word "codeset" is used,
+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).
+be used (or always both together).
 
<td>
-Change "codeset" to
-"character set."
+Change "codeset" to
+"character set."
<td>
 
<tr valign="top">
<td>
-JP 51
+JP 51
<td>
-22.2.5.1.1
+22.2.5.1.1
<td>
-7th paragraph, 1st line
+7th paragraph, 1st line
<td>
-ed
+ed
<td>
-A parameter `end’ should be
+A parameter `end’ should be
`fmtend’. 
-get() function had two `end’ parameters at N2321.
-iter_type get (iter_type s, iter_type
+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;
+char_type* fmt, const char_type *end) const;
The function prototype of get() has been corrected
+"margin-top: 0.04in; margin-bottom: 0.04in">The function prototype of get() has been corrected
at N2800, but a Requires statement still refers `end’
-parameter.
+parameter.
 
<td>
-Correct as follows.
-Requires: [fmt,end) shall be a valid
-range.
+Correct as follows.
+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>
 
<tr valign="top">
<td>
-JP 52
+JP 52
<td>
-22.2.5.1, 22.2.5.2, 22.2.6.1
+22.2.5.1, 22.2.5.2, 22.2.6.1
<td>
 
<td>
-te
+te
<td>
-InputIterator does not use
-concept.
+InputIterator does not use
+concept.
<td>
-Correct as follows.
+Correct as follows.
 
-22.2.5.1
+22.2.5.1
 
-template <class charT, class
-InputIterator = istreambuf_iterator<charT> >
-class time_get : public locale::facet,
-public time_base {
-public:
-typedef charT char_type;
-typedef InputIterator iter_type;
+template <class charT, class
+InputIterator = istreambuf_iterator<charT> >
+class time_get : public locale::facet,
+public time_base {
+public:
+typedef charT char_type;
+typedef InputIterator iter_type;
 
-should be
+should be
 
-template <class charT,
+template <class charT,
InputIterator InputIter = istreambuf_iterator<charT>
->
-class time_get : public locale::facet,
-public time_base {
-public:
-typedef charT char_type;
-typedef InputIter
-iter_type;
- 
- 
-22.2.5.2
- 
-template <class charT, class
-InputIterator = istreambuf_iterator<charT> >
-class time_get_byname : public
-time_get<charT, InputIterator> {
-public:
-typedef time_base::dateorder
-dateorder;
-typedef InputIterator iter_type;
+>
+class time_get : public locale::facet,
+public time_base {
+public:
+typedef charT char_type;
+typedef InputIter
+iter_type;
+ 
+ 
+22.2.5.2
+ 
+template <class charT, class
+InputIterator = istreambuf_iterator<charT> >
+class time_get_byname : public
+time_get<charT, InputIterator> {
+public:
+typedef time_base::dateorder
+dateorder;
+typedef InputIterator iter_type;
 
-should be
+should be
 
-template <class charT,
+template <class charT,
InputIterator InputIter = istreambuf_iterator<charT>
->
-class time_get_byname : public
-time_get<charT, InputIter> {
-public:
-typedef time_base::dateorder
-dateorder;
-typedef InputIter
-iter_type;
- 
- 
-22.2.6.1
- 
-template <class charT,
-class InputIterator =
-istreambuf_iterator<charT> >
-class money_get : public locale::facet
-{
-public:
-typedef charT char_type;
-typedef InputIterator iter_type;
- 
-should be
- 
-template <class charT,
-InputIterator InputIter =
-istreambuf_iterator<charT> >
-class money_get : public locale::facet
-{
-public:
-typedef charT char_type;
-typedef InputIter
-iter_type;
+>
+class time_get_byname : public
+time_get<charT, InputIter> {
+public:
+typedef time_base::dateorder
+dateorder;
+typedef InputIter
+iter_type;
+ 
+ 
+22.2.6.1
+ 
+template <class charT,
+class InputIterator =
+istreambuf_iterator<charT> >
+class money_get : public locale::facet
+{
+public:
+typedef charT char_type;
+typedef InputIterator iter_type;
+ 
+should be
+ 
+template <class charT,
+InputIterator InputIter =
+istreambuf_iterator<charT> >
+class money_get : public locale::facet
+{
+public:
+typedef charT char_type;
+typedef InputIter
+iter_type;
 
<td>
 
<tr valign="top">
<td>
-JP 53
-<td>
-22.2.5.3 , 22.2.5.4
-<td>
- 
-<td>
-te
-<td>
-OutputIterator does not use
-concept.
-<td>
-Correct as follows.
- 
-22.2.5.3
- 
-template <class charT, class
-OutputIterator = ostreambuf_iterator<charT> >
-class time_put : public locale::facet
-{
-public:
-typedef charT char_type;
-typedef OutputIterator iter_type;
- 
-　should be
+JP 53
+<td>
+22.2.5.3 , 22.2.5.4
+<td>
+ 
+<td>
+te
+<td>
+OutputIterator does not use
+concept.
+<td>
+Correct as follows.
+ 
+22.2.5.3
+ 
+template <class charT, class
+OutputIterator = ostreambuf_iterator<charT> >
+class time_put : public locale::facet
+{
+public:
+typedef charT char_type;
+typedef OutputIterator iter_type;
 
-template <class charT,
+　should be
+ 
+template <class charT,
OutputIterator OutputIter = ostreambuf_iterator<charT>
->
-class time_put : public locale::facet
-{
-public:
-typedef charT char_type;
-typedef OutputIter
-iter_type;
- 
- 
-22.2.5.4
- 
-template <class charT, class
-OutputIterator = ostreambuf_iterator<charT> >
-class time_put_byname : public
-time_put<charT, OutputIterator>
-{
-public:
-typedef charT char_type;
-typedef OutputIterator iter_type;
+>
+class time_put : public locale::facet
+{
+public:
+typedef charT char_type;
+typedef OutputIter
+iter_type;
+ 
+ 
+22.2.5.4
+ 
+template <class charT, class
+OutputIterator = ostreambuf_iterator<charT> >
+class time_put_byname : public
+time_put<charT, OutputIterator>
+{
+public:
+typedef charT char_type;
+typedef OutputIterator iter_type;
 
-should be
+should be
 
-template <class charT,
+template <class charT,
OutputIterator OutputIter = ostreambuf_iterator<charT>
->
-class time_put_byname : public
-time_put<charT, OutputIter>
-{
-public:
-typedef charT char_type;
-typedef OutputIter iter_type;
+>
+class time_put_byname : public
+time_put<charT, OutputIter>
+{
+public:
+typedef charT char_type;
+typedef OutputIter iter_type;
<td>
 
<tr valign="top">
<td>
-JP 54
+JP 54
<td>
-23
+23
<td>
-2nd paragraph, Table 79
+2nd paragraph, Table 79
 
<td>
-ed
+ed
<td>
-There is not <forward_list> in
-Table 79.
+There is not <forward_list> in
+Table 79.
<td>
-Add <forward_list> between
-<deque> and <list>.
+Add <forward_list> between
+<deque> and <list>.
<td>
 
<tr valign="top">
<td>
-UK 
-221
+UK 
+221
<td>
-23
+23
<td>
-Table
-79
+Table
+79
<td>
-Ed
+Ed
<td>
-The table is
-missing the new <forward_list> header.
+The table is
+missing the new <forward_list> header.
<td>
-Add <forward_list> to the table for sequence
+Add <forward_list> to the table for sequence
containers. Alternative (technical) solution might be to merge
-<forward_list> into <list>.
+<forward_list> into <list>.
 
<td>
 
<tr valign="top">
<td>
-UK 
-222
+UK 
+222
<td>
-23
+23
<td>
 
<td>
-Te
+Te
<td>
-It is not clear what purpose the Requirement
+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
@@ -12943,10 +11146,10 @@
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?
+design decision?
 
<td>
-Clarify all
+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
@@ -12954,404 +11157,356 @@
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.
+efficiently.
<td>
 
<tr valign="top">
<td>
-JP 55
+JP 55
<td>
-23.1.1
+23.1.1
<td>
-3rd paragraph, 4th line
+3rd paragraph, 4th line
 
<td>
-ed
+ed
<td>
-It seems that “the
+It seems that “the
MinimalAllocator concep” is the typo of “the
-MinimalAllocator concept”.
+MinimalAllocator concept”.
<td>
-Change to … models the MinimalAllocator
-concept.
+Change to … models the MinimalAllocator
+concept.
<td>
 
<tr valign="top">
<td>
-UK 
-223
+UK 
+223
<td>
-23.1.1
+23.1.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-The library does not define the MinimalAllocator
+The library does not define the MinimalAllocator
or ScopedAllocator concepts, these were part of an earlier
-Allocators proposal that was rejected.
+Allocators proposal that was rejected.
 
<td>
-Remove the
+Remove the
references to MinimalAllocator and ScopedAllocator, or add
-definitions for these concepts to clause 20.7.
+definitions for these concepts to clause 20.7.
<td>
 
<tr valign="top">
<td>
-UK 
-224
+UK 
+224
<td>
-23.1.1
+23.1.1
<td>
-8
+8
<td>
-Te
+Te
<td>
-This
+This
paragraph implicitly requires all containers in clause 23 to
-support allocators, which std::array does not.
+support allocators, which std::array does not.
<td>
-Add an 'unless otherwise specified' rider
+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.
+tuple.
 
<td>
 
<tr valign="top">
<td>
-UK 
-225
+UK 
+225
<td>
-23.1.1
+23.1.1
<td>
-Table
-81
+Table
+81
<td>
-Ed
+Ed
<td>
-Inconsistent words used to say the same thing.
+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
+confusion
 
<td>
-Change return
+Change return
types for X::(const)_reverse_iterator to say "iterator type whose
-value type is (const) T".
+value type is (const) T".
<td>
 
<tr valign="top">
<td>
-UK 
-226
+UK 
+226
<td>
-23.1.1
+23.1.1
<td>
-10
+10
<td>
-Te
+Te
<td>
-<array> must be added to this list. In
+<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.
+swap() function throws an exception.
 
<td>
-If
+If
<array> remains a container, this will have to also reference
array, which will then have to say which of these points it
-satisfies.
+satisfies.
<td>
 
<tr valign="top">
<td>
-UK 
-227
+UK 
+227
<td>
-23.1.1
+23.1.1
<td>
-Table
-80
+Table
+80
<td>
-Ed
+Ed
<td>
-The
+The
post-condition for a = rv uses the word “construction”
-when it means “assignment”
+when it means “assignment”
<td>
-Replace the word “construction” with
-the word “assignment”
+Replace the word “construction” with
+the word “assignment”
 
<td>
 
<tr valign="top">
<td>
-UK 
-228
+UK 
+228
<td>
-23.1.1
+23.1.1
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-Line 4 contains a spelling mistake in the fragment
-"MinimalAllocator concep."
+Line 4 contains a spelling mistake in the fragment
+"MinimalAllocator concep."
 
<td>
-Replace
-"concep" with "concept"
+Replace
+"concep" with "concept"
<td>
 
<tr valign="top">
<td>
-UK 
-229
+UK 
+229
<td>
-23.1.1
+23.1.1
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-The fragment
+The fragment
"A container may directly call constructors" is not technically
-correct as constructors are not callable.
+correct as constructors are not callable.
<td>
-Replace "A container may directly call
+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"
+and call destructors for its stored objects"
 
<td>
 
<tr valign="top">
<td>
-UK 
-230
+UK 
+230
<td>
-23.1.2
+23.1.2
<td>
-1
+1
<td>
-Te
+Te
<td>
-“implementations shall consider the following
+“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?
+or not?
 
<td>
-Clarify what
+Clarify what
is meant and what requirements an implementation must
-satisfy.
+satisfy.
<td>
 
<tr valign="top">
<td>
-JP 56
+JP 56
<td>
-23.1.3
+23.1.3
<td>
-12th paragraph, Table 84
+12th paragraph, Table 84
<td>
-ed
+ed
<td>
-`array’ is unstated in Table 84 -
-Optional sequence container operations.
+`array’ is unstated in Table 84 -
+Optional sequence container operations.
<td>
-Add `array’ to Container field for
-the following Expression.
+Add `array’ to Container field for
+the following Expression.
a.front()
+"text-indent: 0.15in; margin-bottom: 0in">a.front()
a.back()
+"text-indent: 0.15in; margin-bottom: 0in">a.back()
a[n]
+"text-indent: 0.15in; margin-bottom: 0in">a[n]
a.at(n)
+"text-indent: 0.15in; margin-top: 0.04in">a.at(n)
<td>
 
<tr valign="top">
<td>
-UK 
-231
+UK 
+231
<td>
-23.1.3
+23.1.3
<td>
-9-11
+9-11
<td>
-Te
+Te
<td>
-These paragraphs are redundant now that Concepts
+These paragraphs are redundant now that Concepts
define what it means to be an Iterator and guide overload
-resolution accordingly.
+resolution accordingly.
 
<td>
-Strike
+Strike
23.1.3p9-11. Make sure std::basic_string has constraints similar to
-std::vector to meet this old guarantee.
+std::vector to meet this old guarantee.
<td>
 
<tr valign="top">
<td>
-UK 
-232
+UK 
+232
<td>
-23.1.3
+23.1.3
<td>
-Table
-84
+Table
+84
<td>
-Te
+Te
<td>
-match_results may follow the requirements but is
-not listed a general purpose library container.
+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
+Remove
+reference to match_results against a[n] operation
<td>
 
<tr valign="top">
<td>
-UK 
-233
+UK 
+233
<td>
-23.1.3
+23.1.3
<td>
-Table
-84
+Table
+84
<td>
-Te
+Te
<td>
-Add
-references to the new containers.
+Add
+references to the new containers.
<td>
-Add reference to array to the rows for: a.front(),
+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).
+the row for: a.at(n).
 
<td>
 
<tr valign="top">
<td>
-UK 
-234
+UK 
+234
<td>
-23.1.3
+23.1.3
<td>
-Table
-84
+Table
+84
<td>
-Te
+Te
<td>
-Ther reference to iterator in semantics for back
+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.
+standard.
 
<td>
-Replace
+Replace
iterator with auto in semantics for back: { auto tmp = a.end();
---tmp; return *tmp; }
+--tmp; return *tmp; }
<td>
 
<tr valign="top">
<td>
-UK 
-235
+UK 
+235
<td>
-23.1.3
+23.1.3
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-“The
+“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
+of array and forward_list
<td>
-Change the text to read: “The library
+Change the text to read: “The library
provides five basic kinds of sequence containers: array, deque,
-forward_list, list and vector”.
+forward_list, list and vector”.
 
<td>
 
<tr valign="top">
<td>
-UK 
-236
+UK 
+236
<td>
-23.1.3
+23.1.3
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-[ I've moved (1) into a separate comment because I
+[ 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
@@ -13361,110 +11516,102 @@
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
+containers and should not be normative text
 
<td>
-Remove this
-paragraph
+Remove this
+paragraph
<td>
 
<tr valign="top">
<td>
-UK 
-237
+UK 
+237
<td>
-23.1.3
+23.1.3
<td>
-2
+2
<td>
-Ed
+Ed
<td>
-vector, list,
+vector, list,
and deque offer the programmer different complexity trade-offs and
should be used accordingly - this ignores array and
-forward_list
+forward_list
<td>
-Modify the text to read: "array, deque,
+Modify the text to read: "array, deque,
forward_list, list and vector offer the programmer different
-complexity trade-offs and should be used accordingly"
+complexity trade-offs and should be used accordingly"
 
<td>
 
<tr valign="top">
<td>
-UK 
-238
+UK 
+238
<td>
-23.1.4
+23.1.4
<td>
-6
+6
<td>
-Te
+Te
<td>
-Leaving it unspecified whether or not iterator and
+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.
+const_iterator, add a note to that effect.
 
<td>
-Change
+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]
+note]
<td>
 
<tr valign="top">
<td>
-UK 
-239
+UK 
+239
<td>
-23.1.4
+23.1.4
<td>
-85
+85
<td>
-Te
+Te
<td>
-It is not
+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.
+containers.
<td>
-Add below a.erase(q), a.extract(q), with the
+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().
+exists,returns a.end().
 
<td>
 
<tr valign="top">
<td>
-UK 
-240
+UK 
+240
<td>
-23.1.6.1
+23.1.6.1
<td>
-12
+12
<td>
-Te
+Te
<td>
-The axiom EmplacePushEquivalence should be
+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
@@ -13472,165 +11619,147 @@
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,
+rather than push_front/push_back,
 
<td>
-Remove the *
+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...)); }
+args...) == insert(c, position, value_type(args...)); }
<td>
 
<tr valign="top">
<td>
-JP 57
+JP 57
<td>
-23.1.6.3
+23.1.6.3
<td>
-1st paragraph, 4th line
+1st paragraph, 4th line
 
<td>
-ed
+ed
<td>
-Typo, duplicated "to"
-"to to model insertion container
-concepts."
+Typo, duplicated "to"
+"to to model insertion container
+concepts."
<td>
-Remove one.
+Remove one.
<td>
 
<tr valign="top">
<td>
-UK 
-241
+UK 
+241
<td>
-23.2.1
+23.2.1
<td>
 
<td>
-Te
+Te
<td>
-std::array does not have an allocator, so need to
-document an exception to the requirements of 23.1.1p3
+std::array does not have an allocator, so need to
+document an exception to the requirements of 23.1.1p3
 
<td>
-add exception
-to 23.1.1p3
+add exception
+to 23.1.1p3
<td>
 
<tr valign="top">
<td>
-UK 
-242
+UK 
+242
<td>
-23.2.1
+23.2.1
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-std::
-qualification no longer needed for reverse_iterator.
+std::
+qualification no longer needed for reverse_iterator.
<td>
-remove std:: qualification from
+remove std:: qualification from
std::reverse_iterator<iterator> and
-std::reverse_iterator<const_iterator>
+std::reverse_iterator<const_iterator>
 
<td>
 
<tr valign="top">
<td>
-UK 
-243
+UK 
+243
<td>
-23.2.1
+23.2.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-Most containers, and types in general have 3
+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&).
+T&&) But array only has swap(T&, T&).
 
<td>
-add the other
-two swaps.
+add the other
+two swaps.
<td>
 
<tr valign="top">
<td>
-UK 
-244
+UK 
+244
<td>
-23.2.1,
-23.2.6
+23.2.1,
+23.2.6
<td>
-1
+1
<td>
-Te
+Te
<td>
-The validity of the expression &a[n] ==
+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).
+file a separate comment there and cross-reference).
 
<td>
-Define a
+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)); } };
+begin(c)); } };
<td>
 
<tr valign="top">
<td>
-UK 
-245
+UK 
+245
<td>
-23.2.3
+23.2.3
<td>
-2
+2
<td>
-Te
+Te
<td>
-The predicate
+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.
+would render this one redundant.
<td>
-Add CopyConstructible requirement to the following
+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
@@ -13640,97 +11769,74 @@
CopyConstructible<Compare> void
merge(forward_list<T,Alloc>&& x, Compare comp);
template <StrictWeakOrder<auto, T> Compare> requires
-CopyConstructible<Compare> void sort(Compare comp);
+CopyConstructible<Compare> void sort(Compare comp);
 
 
<td>
 
<tr valign="top">
<td>
-JP 58
+JP 58
<td>
-23.2.3.2
+23.2.3.2
<td>
-1st line before 1st paragraph
+1st line before 1st paragraph
 
<td>
-ed
+ed
<td>
-Unnecessary "{" exists before a word
-iterator like "{iterator before_begin()".
+Unnecessary "{" exists before a word
+iterator like "{iterator before_begin()".
<td>
-Remove "{"
+Remove "{"
<td>
 
<tr valign="top">
<td>
-JP 59
+JP 59
<td>
-23.2.4.4
+23.2.4.4
<td>
 
<td>
-ed
+ed
<td>
-Types of the third and forth parameter
+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)
+N2350)
<td>
-Correct as follows.
-void splice(const_iterator position,
-list<T,Allocator>&& x, iterator i);
-void splice(const_iterator position,
-list<T,Allocator>&& x,
-iterator first, iterator last);
- 
-should be
- 
-void splice(const_iterator position,
-list<T,Allocator>&& x, const_iterator i);
-void splice(const_iterator position,
-list<T,Allocator>&& x,
+Correct as follows.
+void splice(const_iterator position,
+list<T,Allocator>&& x, iterator i);
+void splice(const_iterator position,
+list<T,Allocator>&& x,
+iterator first, iterator last);
+ 
+should be
+ 
+void splice(const_iterator position,
+list<T,Allocator>&& x, const_iterator i);
+void splice(const_iterator position,
+list<T,Allocator>&& x,
const_iterator first, const_iterator last);
+"margin-top: 0.04in; margin-bottom: 0.04in">const_iterator first, const_iterator last);
 
<td>
 
<tr valign="top">
<td>
-US 83
+US 83
<td>
-23.2.6.2
+23.2.6.2
<td>
-7
+7
<td>
-ed
+ed
<td>
-"shrink_to_fint" should be
-"shrink_to_fit".
+"shrink_to_fint" should be
+"shrink_to_fit".
 
 
<td>
@@ -13739,770 +11845,672 @@
 
<tr valign="top">
<td>
-UK 
-246
+UK 
+246
<td>
-23.3.2.2
+23.3.2.2
<td>
 
<td>
-Ed
+Ed
<td>
-The content of this sub-clause is purely trying to
+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.
+23.1.4.
 
<td>
-Strike
+Strike
23.3.2.2 entirely. (but do NOT strike these signatures from the
-class template definition!)
+class template definition!)
<td>
 
<tr valign="top">
<td>
-UK 
-247
+UK 
+247
<td>
-24.1
+24.1
<td>
 
<td>
-Ge
+Ge
<td>
-Iterator concepts are not extensive enough to
+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>.
+<iterator_concepts>.
 
<td>
-Move the
+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.
+Clause 20 though.
<td>
 
<tr valign="top">
<td>
-UK 
-248
+UK 
+248
<td>
-24.1
+24.1
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-The text "so for any iterator type there is an
+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.
+term than 'container' should be used.
 
<td>
-Replace the
-reference to container with a more appropriate concept
+Replace the
+reference to container with a more appropriate concept
<td>
 
<tr valign="top">
<td>
-UK 
-250
+UK 
+250
<td>
-24.1.1
+24.1.1
<td>
 
<td>
-Te
+Te
<td>
-A default
+A default
implementation should be supplied for the post-increment operator
-to simplify implementation of iterators by users.
+to simplify implementation of iterators by users.
<td>
-Copy the
+Copy the
Effects clause into the concept description as the default
implementation. Assumes a default value for
-postincrement_result
+postincrement_result
<td>
 
<tr valign="top">
<td>
-UK 
-251
+UK 
+251
<td>
-24.1.1
+24.1.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-The post-increment operator is dangerous for a
+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.
+for the post-increment operator in this case either.
 
<td>
-Move
+Move
declaration of postincrement operator and postincrement_result type
-from Interator concept to the ForwardIterator concept
+from Interator concept to the ForwardIterator concept
<td>
 
<tr valign="top">
<td>
UK 
-252
+"margin-right: -0.18in; margin-bottom: 0in">UK 
+252
 
<td>
-24.1.2
+24.1.2
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-istream_iterator is not a class, but a class
-template
+istream_iterator is not a class, but a class
+template
<td>
-Change
-'class' to 'class template' in the note.
+Change
+'class' to 'class template' in the note.
<td>
 
<tr valign="top">
<td>
-UK 
-253
+UK 
+253
<td>
-24.1.3
+24.1.3
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-First sentance does not make gramatical sense,
+First sentance does not make gramatical sense,
Seems to be missing the words 'if it' by comparison with similar
-sentance in other subsections
+sentance in other subsections
 
<td>
-Add the words
+Add the words
'if it' : "X satisfies the requirements of an output iterator IF IT
-meets the syntactic and semantic requirements"
+meets the syntactic and semantic requirements"
<td>
 
<tr valign="top">
<td>
-UK 
-254
+UK 
+254
<td>
-24.1.3
+24.1.3
<td>
-5
+5
<td>
-Te
+Te
<td>
-This postcondition for pre-increment operator
-should be written as an axiom
+This postcondition for pre-increment operator
+should be written as an axiom
 
<td>
-Move the
-postcondition into the concept definition as an axiom
+Move the
+postcondition into the concept definition as an axiom
<td>
 
<tr valign="top">
<td>
-UK 
-255
+UK 
+255
<td>
-24.1.4
+24.1.4
<td>
-4
+4
<td>
-Te
+Te
<td>
-This postcondition for pre-increment operator
-should be written as an axiom
+This postcondition for pre-increment operator
+should be written as an axiom
 
<td>
-Move the
-postcondition into the concept definition as an axiom
+Move the
+postcondition into the concept definition as an axiom
<td>
 
<tr valign="top">
<td>
-UK 
-256
+UK 
+256
<td>
-24.1.5
+24.1.5
<td>
-3, 4,
-5
+3, 4,
+5
<td>
-Te
+Te
<td>
-The
+The
relationship between pre- and post- decrement should be expressed
-as an axiom.
+as an axiom.
<td>
-Move the text specification of pre/post-conditions
+Move the text specification of pre/post-conditions
and behaviour into an axiom within the BidirectionalIterator
-concept
+concept
 
<td>
 
<tr valign="top">
<td>
-UK 
-257
+UK 
+257
<td>
-24.1.5
+24.1.5
<td>
 
<td>
-Te
+Te
<td>
-There is a reasonable default for
+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
+implentations
 
<td>
-Add the
-default : typename postincrement_result = X;
+Add the
+default : typename postincrement_result = X;
<td>
 
<tr valign="top">
<td>
-UK 
-258
+UK 
+258
<td>
-24.1.5
+24.1.5
<td>
 
<td>
-Te
+Te
<td>
-A default implementation should be supplied for
+A default implementation should be supplied for
the post-decrement operator to simplify implementation of iterators
-by users.
+by users.
 
<td>
-Copy the
+Copy the
Effects clause into the concept description as the default
implementation. Assumes a default value for
-postincrement_result
+postincrement_result
<td>
 
<tr valign="top">
<td>
-UK 
-259
+UK 
+259
<td>
-24.1.5
+24.1.5
<td>
 
<td>
-Te
+Te
<td>
-postdecrement_result is effectively returning a
+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
+feature may want a little more work
 
<td>
-Add the
+Add the
requirement: requires Iterator< postdecrement_result
->;
+>;
<td>
 
<tr valign="top">
<td>
-UK 
-260
+UK 
+260
<td>
-24.1.5
+24.1.5
<td>
-6
+6
<td>
-Te
+Te
<td>
-The effects
+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.
+use of it.
<td>
-Move the Effects clause into the
+Move the Effects clause into the
BidirectionalIterator concept definition as an axiom, and as the
-default implementation for the operation.
+default implementation for the operation.
 
<td>
 
<tr valign="top">
<td>
-UK 
-249
+UK 
+249
<td>
-24.1.6
+24.1.6
<td>
-2
+2
<td>
-Te
+Te
<td>
-The semantic for operator+= should also be
+The semantic for operator+= should also be
provided as a default implementation to simplify implementation of
-user-defined iterators
+user-defined iterators
 
<td>
-Copy the text
+Copy the text
from the effects clause into the RandomAccessIterator concept as
-the default implementaiton.
+the default implementaiton.
<td>
 
<tr valign="top">
<td>
-UK 
-261
+UK 
+261
<td>
-24.1.6
+24.1.6
<td>
 
<td>
-Te
+Te
<td>
-To simplify user defined random access iterator
+To simplify user defined random access iterator
types, the subscript_reference type should default to
-reference
+reference
 
<td>
-typename
-subscript_reference = reference;
+typename
+subscript_reference = reference;
<td>
 
<tr valign="top">
<td>
-UK 
-262
+UK 
+262
<td>
-24.1.6
+24.1.6
<td>
-3,
-4
+3,
+4
<td>
-Te
+Te
<td>
-Effects and
+Effects and
post-conditions for operator+ are more useful if expressed as
-axioms, and supplied as default implementations.
+axioms, and supplied as default implementations.
<td>
-Move the effects and Postcondition definitions
+Move the effects and Postcondition definitions
into the RandomAccessIterator concept and copy the code in the
specification as the default implementation of these
-operations.
+operations.
 
<td>
 
<tr valign="top">
<td>
-UK 
-263
+UK 
+263
<td>
-24.1.6
+24.1.6
<td>
-5
+5
<td>
-Te
+Te
<td>
-This
+This
requirement on operator-= would be better expressed as a default
-implementation in the concept, with a matching axiom
+implementation in the concept, with a matching axiom
<td>
-Move the specification for operator-= from the
+Move the specification for operator-= from the
returns clause into an axiom and default implementation within the
-RandomAccessIterator concept
+RandomAccessIterator concept
 
<td>
 
<tr valign="top">
<td>
-UK 
-264
+UK 
+264
<td>
-24.1.6
+24.1.6
<td>
-6
+6
<td>
-Te
+Te
<td>
-Effects
-clauses are better expressed as axioms where possible.
+Effects
+clauses are better expressed as axioms where possible.
<td>
-Move code in operator- effects clause into
+Move code in operator- effects clause into
RandomAccessIterator concept as both a default implementation and
-an axiom
+an axiom
 
<td>
 
<tr valign="top">
<td>
-UK 
-265
+UK 
+265
<td>
-24.1.6
+24.1.6
<td>
-8
+8
<td>
-Te
+Te
<td>
-This effects clause is nonesense. It looks more
+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
+reference
 
<td>
-Strike the
-Effects clause
+Strike the
+Effects clause
<td>
 
<tr valign="top">
<td>
-UK 
-266
+UK 
+266
<td>
-24.1.6
+24.1.6
<td>
-9
+9
<td>
-Te
+Te
<td>
-This sentance
+This sentance
should be provided as a default definition, along with a matching
-axiom
+axiom
<td>
-Move the Returns clause into the spefication for
+Move the Returns clause into the spefication for
RandomAccessIterator operator- as a default implementation. Move
-the Effects clause as the matching axiom.
+the Effects clause as the matching axiom.
 
<td>
 
<tr valign="top">
<td>
-UK 
-267
+UK 
+267
<td>
-24.1.6
+24.1.6
<td>
-24.1.6
+24.1.6
<td>
-Te
+Te
<td>
-The code in the Requires clause for
+The code in the Requires clause for
RandomAccessIterator operator[] would be better expressed as an
-axiom.
+axiom.
 
<td>
-Rewrite the
+Rewrite the
Requires clause as an axiom in the RandomAccessIterator
-concept
+concept
<td>
 
<tr valign="top">
<td>
-UK 
-268
+UK 
+268
<td>
-24.1.6
+24.1.6
<td>
-12
+12
<td>
-Ed
+Ed
<td>
-This note is potentialy confusing as __far enters
+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.
+attributes in the current wording.
 
<td>
-Clean up the
+Clean up the
note to either avoid using language extension, or spell out this is
-a constraint to support extensions.
+a constraint to support extensions.
<td>
 
<tr valign="top">
<td>
-JP 60
+JP 60
<td>
-24.1.8
+24.1.8
<td>
-1st paragraph
+1st paragraph
<td>
-te
+te
<td>
-Capability of an iterator is too much
-restricted by concept.
+Capability of an iterator is too much
+restricted by concept.
 
-Concept of std::Range is defined
-as:
+Concept of std::Range is defined
+as:
 
-concept Range<typename T> {
-InputIterator iterator;
-iterator begin(T&);
-iterator end(T&);
-}
+concept Range<typename T> {
+InputIterator iterator;
+iterator begin(T&);
+iterator end(T&);
+}
 
-So the following code generates an
-error.
+So the following code generates an
+error.
 
-template <std::Range Rng>
-void sort(Rng& r)
-{
+template <std::Range Rng>
+void sort(Rng& r)
+{

-// error! Rng::iterator does
-not satisfy requirements of a random
+// error! Rng::iterator does
+not satisfy requirements of a random

-// access iterator.
-std::sort(begin(r), end(r));
-}
- 
-std::vector<int> v; //
-vector::iterator is a random access iterator.
-sort(v);
+// access iterator.
+std::sort(begin(r), end(r));
+}
+ 
+std::vector<int> v; //
+vector::iterator is a random access iterator.
+sort(v);
 
-This is because the concept of an
+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.
+parameter.
+ 
+To be able to work the above code, we
+need to write as follows:
+ 
+template <std::Range T>
+requires
+std::RandomAccessIterator<T::iterator> &&
+std::ShuffleIterator<T::iterator>
+&&
+std::LessThanComparable<T::iterator::value_type>
+void sort(T& r)
+{
+sort(begin(r), end(r));
+}
 
-To be able to work the above code, we
-need to write as follows:
- 
-template <std::Range T>
-requires
-std::RandomAccessIterator<T::iterator> &&
-std::ShuffleIterator<T::iterator>
-&&
-std::LessThanComparable<T::iterator::value_type>
-void sort(T& r)
-{
-sort(begin(r), end(r));
-}
- 
-std::vector<int> v;
-sort(v);
+std::vector<int> v;
+sort(v);
 
-It needs quiet a few amount of codes
+It needs quiet a few amount of codes
like this only to recover random access capability from
-InputIterator concept.
+InputIterator concept.
 
-We can write the following valid code
+We can write the following valid code
with Boost.Range, which is implemented with using C++03
-SFINAE.
+SFINAE.
 
-template <class Range>
-void sort(Range& r)
-{
-std::sort(boost::begin(r),
-boost::end(r));
-}
- 
-std::vector<int> v;
-sort(v); // OK
+template <class Range>
+void sort(Range& r)
+{
+std::sort(boost::begin(r),
+boost::end(r));
+}
+ 
+std::vector<int> v;
+sort(v); // OK
 
One of the motivation to introduce concepts are
+"margin-top: 0.04in; margin-bottom: 0.04in">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.
+amount of codes without using SFAINAE.
 
<td>
-Add InputRange, OutputRange,
-ForwardRange, BidirectionalRange and RandomAccessRange.
+Add InputRange, OutputRange,
+ForwardRange, BidirectionalRange and RandomAccessRange.
<td>
 
<tr valign="top">
<td>
-UK 
-269
+UK 
+269
<td>
-24.3
+24.3
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-'decrements for negative n' seems to imply a
-negative number of decrement operations, which is odd.
+'decrements for negative n' seems to imply a
+negative number of decrement operations, which is odd.
 
<td>
-Need simple,
-clearer wording
+Need simple,
+clearer wording
<td>
 
<tr valign="top">
<td>
-UK 
-270
+UK 
+270
<td>
-24.3
+24.3
<td>
-4
+4
<td>
-Te
+Te
<td>
-The reachability constraint in p5 means that a
+The reachability constraint in p5 means that a
negavite result, implying decrements operations in p4, is not
-possible
+possible
 
<td>
-Split the two
+Split the two
overloads into separate descriptions, where reachability is
-permitted to be in either direction for RandomAccessIterator
+permitted to be in either direction for RandomAccessIterator
<td>
 
<tr valign="top">
<td>
-UK 
-271
+UK 
+271
<td>
-24.3
+24.3
<td>
-6,7
+6,7
<td>
-Te
+Te
<td>
-next/prev return an incremented iterator without
+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.
+guarantee the 'multipass' property.
 
<td>
-Replace
+Replace
InputIterator constraint with FOrwardIterator in next and prev
-function templates.
+function templates.
<td>
 
<tr valign="top">
<td>
-UK 
-272
+UK 
+272
<td>
-24.4
+24.4
<td>
 
<td>
-Te
+Te
<td>
-reverse_iterator and move_iterator use different
+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.
@@ -14514,496 +12522,452 @@
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.
+requirements, even if the syntax is met.
 
<td>
-Rephrase the
+Rephrase the
reverse_iterator comparison operations using only operators <
-and ==, as per the move_iterator specification.
+and ==, as per the move_iterator specification.
<td>
 
<tr valign="top">
<td>
-UK 
-274
+UK 
+274
<td>
-24.4,
-24.5
+24.4,
+24.5
<td>
 
<td>
-Ed
+Ed
<td>
-The subclauses for standard iterator adaptors
+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
+iterators
 
<td>
-Promote
+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.
+iterators.
<td>
 
<tr valign="top">
<td>
-UK 
-275
+UK 
+275
<td>
-24.4.1.1
+24.4.1.1
<td>
 
<td>
-Te
+Te
<td>
-The constructor template taking a single Iterator
+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.
+by Direct Initialization.
 
<td>
-The
+The
reverse_iterator template constructor taking a single Iterator
-argument should be explicit.
+argument should be explicit.
<td>
 
<tr valign="top">
<td>
-UK 
-276
+UK 
+276
<td>
-24.4.1.1
+24.4.1.1
<td>
 
<td>
-Ed
+Ed
<td>
-It is odd to have a mix of declaration stlyes for
+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.
+all are 'free' functions.
 
<td>
-Make the
+Make the
member operators taking a difference_type argument non-member
-operators
+operators
<td>
 
<tr valign="top">
<td>
-UK 
-277
+UK 
+277
<td>
-24.4.1.2.1
+24.4.1.2.1
<td>
-1
+1
<td>
-Te
+Te
<td>
-The default constructor default-initializes
+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.
+definition of a singular iterator.
 
<td>
-i/ Specify
+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.
+the singular nature of a value-initialized reserve iterator.
<td>
 
<tr valign="top">
<td>
-UK 
-278
+UK 
+278
<td>
-24.4.1.2.1
+24.4.1.2.1
<td>
-3
+3
<td>
-Te
+Te
<td>
-There is an inconsistency between the constructor
+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.
+efficient moving when copy elision fails to kick in.
 
<td>
-Change the
+Change the
const reverse_iterator & parameter to
-pass-by-value
+pass-by-value
<td>
 
<tr valign="top">
<td>
-UK 
-279
+UK 
+279
<td>
-24.4.1.2.12, 24.4.3.2.12
+24.4.1.2.12, 24.4.3.2.12
<td>
 
<td>
-Te
+Te
<td>
-The reason the return type became unspecified is
+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.
+facilities added since the previous standard.
 
<td>
-Specify the
-return type using either decltype or the Iter concept map
+Specify the
+return type using either decltype or the Iter concept map
<td>
 
<tr valign="top">
<td>
-UK 
-280
+UK 
+280
<td>
-24.4.1.2.4
+24.4.1.2.4
<td>
 
<td>
-Ed
+Ed
<td>
-The presence of the second iterator value is
+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.
+required by the semantic will reduce confusion.
 
<td>
-Add
+Add
reverse_iterator expsoition only member tmp as a comment to class
-declaration, as a private member
+declaration, as a private member
<td>
 
<tr valign="top">
<td>
-UK 
-281
+UK 
+281
<td>
-24.4.1.2.5
+24.4.1.2.5
<td>
 
<td>
-Te
+Te
<td>
-The current specification for return value will
+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'
+pointer'
 
<td>
-Replace the
+Replace the
existing returns specification with a copy of the operator*
-specification that returns this->tmp.operator->
+specification that returns this->tmp.operator->
<td>
 
<tr valign="top">
<td>
-UK 
-282
+UK 
+282
<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
+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>
-n/a
+n/a
<td>
-Te
+Te
<td>
-Insert
-iterators of move-only types will move from lvalues
+Insert
+iterators of move-only types will move from lvalues
<td>
-Add an
+Add an
additional constrained overload for operator= that requires
!CopyConstructible<Cont::value_type> and mark it
-=delete.
+=delete.
<td>
 
<tr valign="top">
<td>
-UK 
-283
+UK 
+283
<td>
-24.4.2.5,
-24.4.2.6.4
+24.4.2.5,
+24.4.2.6.4
<td>
 
<td>
-Te
+Te
<td>
-postincrement
+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
+return-by-value
<td>
-change
+change
operator++(int) overload to return by value, not reference. Affects
-both class summary and operator definition in p
+both class summary and operator definition in p
<td>
 
<tr valign="top">
<td>
-JP 61
+JP 61
<td>
-24.4.3.2.1
+24.4.3.2.1
<td>
-2nd paragraph, 1st line
+2nd paragraph, 1st line
<td>
-ed
+ed
<td>
-Typo.
-"intializing" should be
-"initializing"
+Typo.
+"intializing" should be
+"initializing"
<td>
-Add "i"
+Add "i"
<td>
 
<tr valign="top">
<td>
-UK 
-284
+UK 
+284
<td>
-24.5
+24.5
<td>
 
<td>
-Te
+Te
<td>
-The stream iterators need constraining with
-concepts/requrires clauses.
+The stream iterators need constraining with
+concepts/requrires clauses.
 
<td>
-Provide
-constraints
+Provide
+constraints
<td>
 
<tr valign="top">
<td>
-UK 
-285
+UK 
+285
<td>
-24.5.1
+24.5.1
<td>
-1,2
+1,2
<td>
-Ed
+Ed
<td>
-Much of the content of p1 and the whole of p2 is a
+Much of the content of p1 and the whole of p2 is a
redundant redefinition of InputIterator. It should be
-simplified
+simplified
 
<td>
-Strike p2.
+Strike p2.
Simplify p1 and add a cross-reference to the definition of
-InputIterator concept.
+InputIterator concept.
<td>
 
<tr valign="top">
<td>
-UK 
-286
+UK 
+286
<td>
-24.5.1
+24.5.1
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-To the casual reader it is not clear if it is
+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.
+copy-assign operator is confusing.
 
<td>
-Either
+Either
provide a similar definition to the copy-assign operator as for the
-copy constructor, or strike the copy constructor
+copy constructor, or strike the copy constructor
<td>
 
<tr valign="top">
<td>
-UK 
-287
+UK 
+287
<td>
-24.5.1.1
+24.5.1.1
<td>
-2
+2
<td>
-Te
+Te
<td>
-It is not clear what the intial state of an
+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?
+dereferencable?
 
<td>
-Specify
+Specify
_value_ is initialized by reading the stream, or the iterator takes
-on the end-of-stream value if the stream is empty
+on the end-of-stream value if the stream is empty
<td>
 
<tr valign="top">
<td>
-UK 
-288
+UK 
+288
<td>
-24.5.1.1
+24.5.1.1
<td>
-3
+3
<td>
-Ed
+Ed
<td>
-The provided
-specification is vacuous, offering no useful information.
+The provided
+specification is vacuous, offering no useful information.
<td>
-Either strike the specification of the copy
+Either strike the specification of the copy
constructor, or simply replace it with an = default
-definition.
+definition.
 
<td>
 
<tr valign="top">
<td>
-UK 
-289
+UK 
+289
<td>
-24.5.1.2
+24.5.1.2
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-It is very hard to pick up the correct
+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.
+dangerous misreading.
 
<td>
-Merge
+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.
+istream_iterator.
<td>
 
<tr valign="top">
<td>
-UK 
-290
+UK 
+290
<td>
-24.5.2
+24.5.2
<td>
-1
+1
<td>
-Te
+Te
<td>
-The character type of a string delimiter for an
+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.
+not char *, a narrow character string.
 
<td>
-Replace char
-* with const charT *
+Replace char
+* with const charT *
<td>
 
<tr valign="top">
<td>
-UK 
-291
+UK 
+291
<td>
-24.5.2.2
+24.5.2.2
<td>
-2
+2
<td>
-Te
+Te
<td>
-ostream_iterator postincrement operator returns by
+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.
+return-by-value.
 
<td>
-ostream_iterator operator++(int);
+ostream_iterator operator++(int);
<td>
 
<tr valign="top">
<td>
-FR 34
+FR 34
<td>
-24.5.3 [istreambuf.iterator]
+24.5.3 [istreambuf.iterator]
<td>
 
<td>
-ed
+ed
<td>
-There are two public sections, and the
+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.
+don't it should be.
 
<td>
 
@@ -15011,241 +12975,221 @@
 
<tr valign="top">
<td>
-UK 
-292
+UK 
+292
<td>
-24.5.3
+24.5.3
<td>
-1
+1
<td>
-Ed
+Ed
<td>
-Prefer the use of the new nullptr constant to the
-zero literal when using a null pointer in text.
+Prefer the use of the new nullptr constant to the
+zero literal when using a null pointer in text.
 
<td>
-Change
-istreambuf_iterator(0) to istreambuf_iterator(nullptr)
+Change
+istreambuf_iterator(0) to istreambuf_iterator(nullptr)
<td>
 
<tr valign="top">
<td>
-UK 
-293
+UK 
+293
<td>
-24.5.3
+24.5.3
<td>
-2,3,4
+2,3,4
<td>
-Ed
+Ed
<td>
-The listed
+The listed
paragraphs redundantly redefine an input iterator, and redundancy
can be a dangerous thing in a specification. Suggest a simpler
-phrasing below.
+phrasing below.
<td>
-2. The result of operator*() on an end of stream
+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.
+an input iterator.
 
<td>
 
<tr valign="top">
<td>
-UK 
-294
+UK 
+294
<td>
-24.5.3.2
+24.5.3.2
<td>
-2
+2
<td>
-Te
+Te
<td>
-Implicit
+Implicit
converting constructors can be invoked at surprising times, so
-there should always be a good reason for declaring one.
+there should always be a good reason for declaring one.
<td>
-Mark the two single-argument constructors take a
+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();
+throw();
 
<td>
 
<tr valign="top">
<td>
-UK 
-295
+UK 
+295
<td>
-25
+25
<td>
 
<td>
-Te
+Te
<td>
-THere is a level of redundancy in the library
+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.
+reduces the risk of inttroducing accidental inconsistencies.
 
<td>
-Adopt n2743,
-or an update of that paper.
+Adopt n2743,
+or an update of that paper.
<td>
 
<tr valign="top">
<td>
-JP 62
+JP 62
<td>
-25, 25.3.1.5, 26.3.6.5
+25, 25.3.1.5, 26.3.6.5
<td>
 
<td>
-te
+te
<td>

-The return types of
+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.
+iterator.

-So we think that it is
-reasonable to change those two functions.
+So we think that it is
+reasonable to change those two functions.
 
<td>
-Change "is_sorted_until" to
-"sorted_bound"
-Change "is_heap" to "heap_bound"
+Change "is_sorted_until" to
+"sorted_bound"
+Change "is_heap" to "heap_bound"
<td>
 
<tr valign="top">
<td>
-UK 
-296
+UK 
+296
<td>
-25.1.8
+25.1.8
<td>
-1
+1
<td>
-Te
+Te
<td>
-The 'Returns' of adjacent_find requires only
+The 'Returns' of adjacent_find requires only
HasEqualTo, or a Predicate. Requiring EqualityComparable or
-EquivalenceRelation seems too strong and not useful.
+EquivalenceRelation seems too strong and not useful.
 
<td>
-Change
+Change
EqualityComparable to HasEqualTo and EquivalnceRelation to
-Predicate
+Predicate
<td>
 
<tr valign="top">
<td>
-UK 
-297
+UK 
+297
<td>
-25.2.11
+25.2.11
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-The definition of rotate_copy is very complicated.
+The definition of rotate_copy is very complicated.
It is equivalent to: return copy(first, middle, copy(middle, last,
-result));
+result));
 
<td>
-Change
+Change
'effects' to, returns, requires, complexity to: effects: equivalent
-to: return copy(first, middle, copy(middle, last, result));
+to: return copy(first, middle, copy(middle, last, result));
<td>
 
<tr valign="top">
<td>
-UK 
-298
+UK 
+298
<td>
-25.2.13
+25.2.13
<td>
-13
+13
<td>
-Te
+Te
<td>
-partition_point requires a partitioned
-array
+partition_point requires a partitioned
+array
<td>
-requires:
-is_partitioned(first, last, pred) != false;
+requires:
+is_partitioned(first, last, pred) != false;
<td>
 
<tr valign="top">
<td>
-UK 
-299
+UK 
+299
<td>
-25.2.2
+25.2.2
<td>
 
<td>
-Ed
+Ed
<td>
-Should be
+Should be
consistent in style use of concepts in template parameter lists.
The auto-OutputIterator sytle used in std::copy is probably
-preferred.
+preferred.
<td>
-Change way
+Change way
signature is declared: template<InputIterator InIter,
OutputIterator<auto, RvalueOf<InIter::reference>::type>
OutIter> OutIter move(InIter first, InIter last, OutIter
-result);
+result);
<td>
 
<tr valign="top">
<td>
-UK 
-300
+UK 
+300
<td>
-25.2.3
+25.2.3
<td>
 
<td>
-Te
+Te
<td>
-Since publishing the original standard, we have
+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
@@ -15254,146 +13198,133 @@
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.
+does not create a new dependency.
 
<td>
-Move primary
+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.
+for finding swap.
<td>
 
<tr valign="top">
<td>
-UK 
-301
+UK 
+301
<td>
-25.2.5
+25.2.5
<td>
 
<td>
-Te
+Te
<td>
-replace and replace_if have the requirement:
+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&>
+OutputIterator<Iter, const T&>
 
<td>
-Remove
+Remove
OutputIterator<Iter, Iter::reference> from replace and
-replace_if
+replace_if
<td>
 
<tr valign="top">
<td>
-UK 
-302
+UK 
+302
<td>
-25.3
+25.3
<td>
-4
+4
<td>
-Ed
+Ed
<td>
-the concept StrictWeakOrder covers the definition
-of a strict weak ordering, described in paragraph 4.
+the concept StrictWeakOrder covers the definition
+of a strict weak ordering, described in paragraph 4.
 
<td>
-Remove 4, and
-mention StrictWeakOrder in paragraph 1.
+Remove 4, and
+mention StrictWeakOrder in paragraph 1.
<td>
 
<tr valign="top">
<td>
-UK 
-303
+UK 
+303
<td>
-25.3
+25.3
<td>
-6
+6
<td>
-Ed
+Ed
<td>
-This
-paragraph just describes is_partitioned
+This
+paragraph just describes is_partitioned
<td>
-6 A sequence [start,finish) is partitioned with
+6 A sequence [start,finish) is partitioned with
respect to an expression f(e) if is_partitioned(start, finish, e)
-!= false
+!= false
 
<td>
 
<tr valign="top">
<td>
-UK 
-304
+UK 
+304
<td>
-25.3.6
+25.3.6
<td>
 
<td>
-Ed
+Ed
<td>
-The requires clauses of push_heap, pop_heap and
+The requires clauses of push_heap, pop_heap and
make_heap are inconsistently formatted, dispite being
-identical
+identical
 
<td>
-Format them
-identically.
+Format them
+identically.
<td>
 
<tr valign="top">
<td>
-UK 
-305
+UK 
+305
<td>
-25.3.7
+25.3.7
<td>
-1, 9,
-17
+1, 9,
+17
<td>
-Te
+Te
<td>
-The negative
+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.
+necessary.
<td>
-Strike the
+Strike the
!IsSameType<T, Compare> constraint on min/max/minmax
-algorithms
+algorithms
<td>
 
<tr valign="top">
<td>
-US 84
+US 84
<td>
-26
+26
<td>
 
<td>
-ge
+ge
<td>
-Parts of the numerics chapter are not
-concept enabled.
+Parts of the numerics chapter are not
+concept enabled.
 
<td>
 
@@ -15401,20 +13332,17 @@
 
<tr valign="top">
<td>
-FR 35
+FR 35
<td>
-26.3 [Complex numbers]
+26.3 [Complex numbers]
<td>
 
<td>
-te
+te
<td>
-Instantiations of the class template
+Instantiations of the class template
complex<> have to be allowed for integral types, to reflect
-existing practice and ISO standards (LIA-III).
+existing practice and ISO standards (LIA-III).
 
<td>
 
@@ -15422,126 +13350,106 @@
 
<tr valign="top">
<td>
-UK 
-306
+UK 
+306
<td>
-26.4
+26.4
<td>
 
<td>
-Te
+Te
<td>
-Random number library component cannot be used in
-constrained templates
+Random number library component cannot be used in
+constrained templates
 
<td>
-Provide
-constraints for the random number library
+Provide
+constraints for the random number library
<td>
 
<tr valign="top">
<td>
-JP 63
+JP 63
<td>
-26.4.8.5.1
+26.4.8.5.1
<td>
 
<td>
-te
+te
<td>
-No constructor of discrete_distribution
-that accepts initializer_list.
-discrete_distribution initialize
+No constructor of discrete_distribution
+that accepts initializer_list.
+discrete_distribution initialize
distribution by a given range (iterators), but temporary variable
-of a container or an array is needed in the following case.
+of a container or an array is needed in the following case.
 
-int ar[] = {1, 2, 3};
-discrete_distribution<> dist(ar,
-ar+3);
+int ar[] = {1, 2, 3};
+discrete_distribution<> dist(ar,
+ar+3);
 
Other libraries also accept initializer_list, so
+"margin-top: 0.04in; margin-bottom: 0.04in">Other libraries also accept initializer_list, so
change discrete_distribution library to accept initializer_list
-too.
+too.
 
<td>
-Add the following constructer.
-discrete_distribution(initializer_list<result_type>);
+Add the following constructer.
+discrete_distribution(initializer_list<result_type>);
<td>
 
<tr valign="top">
<td>
-JP 64
+JP 64
<td>
-26.5.2
+26.5.2
<td>
 
<td>
-te
+te
<td>
“valarray<T>& operator+=
-(initializer_list<T>);” is not defined.
+"margin-top: 0.04in; margin-bottom: 0.04in">“valarray<T>& operator+=
+(initializer_list<T>);” is not defined.
 
<td>
-Add valarray<T>& operator+=
-(initializer_list<T>);
+Add valarray<T>& operator+=
+(initializer_list<T>);
<td>
 
<tr valign="top">
<td>
-UK 
-307
+UK 
+307
<td>
-26.7
+26.7
<td>
-Footnote
-288
+Footnote
+288
<td>
-Ed
+Ed
<td>
-The footnote refers to TR1, which is not a defined
+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.
+is no longer relevant.
 
<td>
-Drop the
-reference to TR1.
+Drop the
+reference to TR1.
<td>
 
<tr valign="top">
<td>
-US 85
+US 85
<td>
-27
+27
<td>
 
<td>
-ge
+ge
<td>
-The input/output chapter is not concept
-enabled.
+The input/output chapter is not concept
+enabled.
 
<td>
 
@@ -15549,102 +13457,82 @@
 
<tr valign="top">
<td>
-UK 
-308
+UK 
+308
<td>
-27
+27
<td>
 
<td>
-Te
+Te
<td>
-iostreams library
-cannot be used from constrained templates
+iostreams library
+cannot be used from constrained templates
 
<td>
-Provide
-constraints for the iostreams library, clause 27
+Provide
+constraints for the iostreams library, clause 27
<td>
 
<tr valign="top">
<td>
-JP 65
+JP 65
<td>
-27.4.4
+27.4.4
<td>
 
<td>
-te
+te
<td>
Switch from “unspecified-bool-type”
-to　“explicit operator bool() const”.
+"margin-top: 0.04in; margin-bottom: 0.04in">Switch from “unspecified-bool-type”
+to　“explicit operator bool() const”.
 
<td>
-Replace "operator
+Replace "operator
unspecified-bool-type() const;" with "explicit operator
-bool() const;"
+bool() const;"
<td>
 
<tr valign="top">
<td>
-JP 66
+JP 66
<td>
-27.4.4.3
+27.4.4.3
<td>
-1st paragraph
+1st paragraph
<td>
-te
+te
<td>
Switch from “unspecified-bool-type”
-to　“explicit operator bool() const”
+"margin-top: 0.04in; margin-bottom: 0.04in">Switch from “unspecified-bool-type”
+to　“explicit operator bool() const”
 
<td>
-Replace "operator
+Replace "operator
unspecified-bool-type() const;" with "explicit operator
-bool() const;"
+bool() const;"
<td>
 
<tr valign="top">
<td>
-FR 36
+FR 36
<td>
-27.6.1.2.2
-[istream.formatted.arithmetic]
+27.6.1.2.2
+[istream.formatted.arithmetic]
<td>
-1, 2, and 3
+1, 2, and 3
<td>
-ed
+ed
<td>
-iostate err = 0;
+iostate err = 0;
 
-iostate is a bitmask type and so could be
-an enumeration. Probably using
-goodbit is the solution.
+iostate is a bitmask type and so could be
+an enumeration. Probably using
+goodbit is the solution.
 
<td>
 
@@ -15652,26 +13540,21 @@
 
<tr valign="top">
<td>
-FR 37
+FR 37
<td>
-27.6.1.2.2
-[istream.formatted.arithmetic]
+27.6.1.2.2
+[istream.formatted.arithmetic]
<td>
-3
+3
<td>
-ed
+ed
<td>
-else if (lval <
-numeric_limits<int>::min()
-|| numeric_limits<int>::max() <
-lval))
+else if (lval <
+numeric_limits<int>::min()
+|| numeric_limits<int>::max() <
+lval))
 
-The parentheses aren't balanced.
+The parentheses aren't balanced.
 
<td>
 
@@ -15679,595 +13562,407 @@
 
<tr valign="top">
<td>
-JP 67
-<td>
-27.7.1
-<td>
- 
-<td>
-te
-<td>
-basic_stringbuf dose not use
-concept.
-<td>
-Replace “class Allocator” to
-“Allocator Alloc”.
- 
-Correct as follows.
- 
-namespace std {
-template <class charT, class traits =
-char_traits<charT>,
-Allocator Alloc =
-allocator<charT> >
-class basic_stringbuf : public
-basic_streambuf<charT,traits> {
-public:
-...
- 
-// 27.7.1.1 Constructors:
-explicit
-basic_stringbuf(ios_base::openmode which
-= ios_base::in | ios_base::out);
-explicit basic_stringbuf
-(const
-basic_string<charT,traits,Alloc>& str,
-ios_base::openmode which = ios_base::in
-| ios_base::out);
-basic_stringbuf(basic_stringbuf&&
-rhs);
- 
-...
- 
- 
-// 27.7.1.3 Get and set:
-basic_string<charT,traits,Alloc>
-str() const;
-void str(const
-basic_string<charT,traits,Alloc>& s);
- 
-...
-};
- 
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_stringbuf<charT,
-traits, Alloc>& x,
-basic_stringbuf<charT, traits,
-Alloc>& y);
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_stringbuf<charT,
-traits, Alloc>&& x,
-basic_stringbuf<charT, traits,
-Alloc>& y);
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_stringbuf<charT,
-traits, Alloc>& x,
-basic_stringbuf<charT, traits,
-Alloc>&& y);
+JP 67
+<td>
+27.7.1
+<td>
+ 
+<td>
+te
+<td>
+basic_stringbuf dose not use
+concept.
+<td>
+Replace “class Allocator” to
+“Allocator Alloc”.
+  Correct as follows.
+ 
+namespace std {
+template <class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_stringbuf : public
+basic_streambuf<charT,traits> {
+public:
+...
+ 
+// 27.7.1.1 Constructors:
+explicit
+basic_stringbuf(ios_base::openmode which
+= ios_base::in | ios_base::out);
+explicit basic_stringbuf
+(const
+basic_string<charT,traits,Alloc>& str,
+ios_base::openmode which = ios_base::in
+| ios_base::out);
+basic_stringbuf(basic_stringbuf&&
+rhs);
+ 
+...
+ 
+ 
+// 27.7.1.3 Get and set:
+basic_string<charT,traits,Alloc>
+str() const;
+void str(const
+basic_string<charT,traits,Alloc>& s);
+ 
+...
+};
+ 
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringbuf<charT,
+traits, Alloc>& x,
+basic_stringbuf<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringbuf<charT,
+traits, Alloc>&& x,
+basic_stringbuf<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringbuf<charT,
+traits, Alloc>& x,
+basic_stringbuf<charT, traits,
+Alloc>&& y);
}
+"margin-top: 0.04in; margin-bottom: 0.04in">}
 
<td>
 
<tr valign="top">
<td>
-JP 68
+JP 68
<td>
-27.7.2
+27.7.2
<td>
 
<td>
-te
+te
<td>
-basic_istringstream dose not use
-concept.
-<td>
-Replace “class Allocator” to
-“Allocator Alloc”.
- 
-Correct as follows.
- 
-namespace std {
-template <class charT, class traits =
-char_traits<charT>,
-Allocator Alloc =
-allocator<charT> >
-class basic_istringstream : public
-basic_istream<charT,traits> {
-public:
-typedef charT char_type;
-typedef typename traits::int_type
-int_type;
-typedef typename traits::pos_type
-pos_type;
-typedef typename traits::off_type
-off_type;
-typedef traits traits_type;
-typedef Alloc
-allocator_type;
- 
-// 27.7.2.1 Constructors:
-explicit
+basic_istringstream dose not use
+concept.
+<td>
+Replace “class Allocator” to
+“Allocator Alloc”.
+  Correct as follows.
+ 
+namespace std {
+template <class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_istringstream : public
+basic_istream<charT,traits> {
+public:
+typedef charT char_type;
+typedef typename traits::int_type
+int_type;
+typedef typename traits::pos_type
+pos_type;
+typedef typename traits::off_type
+off_type;
+typedef traits traits_type;
+typedef Alloc
+allocator_type;
+ 
+// 27.7.2.1 Constructors:
+explicit
basic_istringstream(ios_base::openmode which =
-ios_base::in);
-explicit basic_istringstream(
-const
-basic_string<charT,traits,Alloc>& str,
-ios_base::openmode which =
-ios_base::in);
-basic_istringstream(basic_istringstream&&
-rhs);
- 
-// 27.7.2.2 Assign and swap:
-basic_istringstream&
-operator=(basic_istringstream&& rhs);
-void swap(basic_istringstream&&
-rhs);
- 
-// 27.7.2.3 Members:
-basic_stringbuf<charT,traits,Alloc>*
-rdbuf() const;
- 
-basic_string<charT,traits,Alloc>
-str() const;
-void str(const
-basic_string<charT,traits,Alloc>& s);
- 
-private:
-//
+ios_base::in);
+explicit basic_istringstream(
+const
+basic_string<charT,traits,Alloc>& str,
+ios_base::openmode which =
+ios_base::in);
+basic_istringstream(basic_istringstream&&
+rhs);
+ 
+// 27.7.2.2 Assign and swap:
+basic_istringstream&
+operator=(basic_istringstream&& rhs);
+void swap(basic_istringstream&&
+rhs);
+ 
+// 27.7.2.3 Members:
+basic_stringbuf<charT,traits,Alloc>*
+rdbuf() const;
+ 
+basic_string<charT,traits,Alloc>
+str() const;
+void str(const
+basic_string<charT,traits,Alloc>& s);
+ 
+private:
+//
basic_stringbuf<charT,traits,Alloc> sb; exposition
-only
-};
- 
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_istringstream<charT,
-traits, Alloc>& x,
-basic_istringstream<charT, traits,
-Alloc>& y);
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_istringstream<charT,
-traits, Alloc>&& x,
-basic_istringstream<charT, traits,
-Alloc>& y);
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_istringstream<charT,
-traits, Alloc>& x,
-basic_istringstream<charT, traits,
-Alloc>&& y);
-}
+only
+};
+ 
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_istringstream<charT,
+traits, Alloc>& x,
+basic_istringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_istringstream<charT,
+traits, Alloc>&& x,
+basic_istringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_istringstream<charT,
+traits, Alloc>& x,
+basic_istringstream<charT, traits,
+Alloc>&& y);
+}
 
<td>
 
<tr valign="top">
<td>
-JP 69
-<td>
-27.7.3
-<td>
- 
-<td>
-te
-<td>
-basic_ostringstream dose not use
-concept.
-<td>
-Replace “class Allocator” to
-“Allocator Alloc”.
- 
-Correct as follows.
- 
-namespace std {
-template <class charT, class traits =
-char_traits<charT>,
-Allocator Alloc =
-allocator<charT> >
-class basic_ostringstream : public
-basic_ostream<charT,traits> {
-public:
-// types:
-typedef charT char_type;
-typedef typename traits::int_type
-int_type;
-typedef typename traits::pos_type
-pos_type;
-typedef typename traits::off_type
-off_type;
-typedef traits traits_type;
-typedef Alloc
-allocator_type;
- 
-// 27.7.3.1
-Constructors/destructor:
-explicit
+JP 69
+<td>
+27.7.3
+<td>
+ 
+<td>
+te
+<td>
+basic_ostringstream dose not use
+concept.
+<td>
+Replace “class Allocator” to
+“Allocator Alloc”.
+  Correct as follows.
+ 
+namespace std {
+template <class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_ostringstream : public
+basic_ostream<charT,traits> {
+public:
+// types:
+typedef charT char_type;
+typedef typename traits::int_type
+int_type;
+typedef typename traits::pos_type
+pos_type;
+typedef typename traits::off_type
+off_type;
+typedef traits traits_type;
+typedef Alloc
+allocator_type;
+ 
+// 27.7.3.1
+Constructors/destructor:
+explicit
basic_ostringstream(ios_base::openmode which =
-ios_base::out);
-explicit basic_ostringstream(
-const
-basic_string<charT,traits,Alloc>& str,
-ios_base::openmode which =
-ios_base::out);
-basic_ostringstream(basic_ostringstream&&
-rhs);
- 
-// 27.7.3.2 Assign/swap:
-basic_ostringstream&
-operator=(basic_ostringstream&& rhs);
-void swap(basic_ostringstream&&
-rhs);
- 
-// 27.7.3.3 Members:
-basic_stringbuf<charT,traits,Alloc>*
-rdbuf() const;
-basic_string<charT,traits,Alloc>
-str() const;
-void str(const
-basic_string<charT,traits,Alloc>& s);
-private:
-//
+ios_base::out);
+explicit basic_ostringstream(
+const
+basic_string<charT,traits,Alloc>& str,
+ios_base::openmode which =
+ios_base::out);
+basic_ostringstream(basic_ostringstream&&
+rhs);
+ 
+// 27.7.3.2 Assign/swap:
+basic_ostringstream&
+operator=(basic_ostringstream&& rhs);
+void swap(basic_ostringstream&&
+rhs);
+ 
+// 27.7.3.3 Members:
+basic_stringbuf<charT,traits,Alloc>*
+rdbuf() const;
+basic_string<charT,traits,Alloc>
+str() const;
+void str(const
+basic_string<charT,traits,Alloc>& s);
+private:
+//
basic_stringbuf<charT,traits,Alloc> sb; exposition
-only
-};
- 
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_ostringstream<charT,
-traits, Alloc>& x,
-basic_ostringstream<charT, traits,
-Alloc>& y);
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_ostringstream<charT,
-traits, Alloc>&& x,
-basic_ostringstream<charT, traits,
-Alloc>& y);
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_ostringstream<charT,
-traits, Alloc>& x,
-basic_ostringstream<charT, traits,
-Alloc>&& y);
+only
+};
+ 
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_ostringstream<charT,
+traits, Alloc>& x,
+basic_ostringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_ostringstream<charT,
+traits, Alloc>&& x,
+basic_ostringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_ostringstream<charT,
+traits, Alloc>& x,
+basic_ostringstream<charT, traits,
+Alloc>&& y);
}
+"margin-top: 0.04in; margin-bottom: 0.04in">}
 
<td>
 
<tr valign="top">
<td>
-JP 71
+JP 71
<td>
-27.7.3
+27.7.3
<td>
 
<td>
-ed
+ed
<td>
-Typo.
-"template" is missing in "class
-basic_ostringstream" of the title of the chapter.
-<td>
-Correct as follows.
-27.7.3 Class basic_ostringstream
- 
-should be
- 
-27.7.3 Class template
-basic_ostringstream
-<td>
- 
-<tr valign="top">
-<td>
-JP 72
-<td>
-27.7.4
-<td>
- 
-<td>
-te
-<td>
-basic_stringstream dose not use
-concept.
-<td>
-Replace "class Allocator" to "Allocator
-Alloc".
- 
-Correct as follows.
- 
-namespace std {
-template <class charT, class traits =
-char_traits<charT>,
-Allocator Alloc =
-allocator<charT> >
-class basic_stringstream
-: public
-basic_iostream<charT,traits> {
-public:
-// types:
-typedef charT char_type;
-typedef typename traits::int_type
-int_type;
-typedef typename traits::pos_type
-pos_type;
-typedef typename traits::off_type
-off_type;
-typedef traits traits_type;
-typedef Alloc
-allocator_type;
- 
-// constructors/destructor
-explicit basic_stringstream(
-ios_base::openmode which =
-ios_base::out|ios_base::in);
-explicit basic_stringstream(
-const
-basic_string<charT,traits,Alloc>& str,
-ios_base::openmode which =
-ios_base::out|ios_base::in);
-basic_stringstream(basic_stringstream&&
-rhs);
- 
-// 27.7.5.1 Assign/swap:
-void swap(basic_stringstream&&
-rhs);
- 
-// Members:
-basic_stringbuf<charT,traits,Alloc>*
-rdbuf() const;
-basic_string<charT,traits,Alloc>
-str() const;
-void str(const
-basic_string<charT,traits,Alloc>& str);
-private:
-// basic_stringbuf<charT, traits>
-sb; exposition only
-};
- 
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_stringstream<charT,
-traits, Alloc>& x,
-basic_stringstream<charT, traits,
-Alloc>& y);
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_stringstream<charT,
-traits, Alloc>&& x,
-basic_stringstream<charT, traits,
-Alloc>& y);
-template <class charT, class traits,
-Allocator Alloc>
-void swap(basic_stringstream<charT,
-traits, Alloc>& x,
-basic_stringstream<charT, traits,
-Alloc>&& y);
-}
-<td>
- 
-<tr valign="top">
-<td>
-JP 73
-<td>
-27.8.1.14
+Typo.
+"template" is missing in "class
+basic_ostringstream" of the title of the chapter.
+<td>
+Correct as follows.
+27.7.3 Class basic_ostringstream
+ 
+should be
+ 
+27.7.3 Class template
+basic_ostringstream
<td>
 
+<tr valign="top">
+<td>
+JP 72
+<td>
+27.7.4
+<td>
+ 
+<td>
+te
+<td>
+basic_stringstream dose not use
+concept.
+<td>
+Replace "class Allocator" to "Allocator
+Alloc".
+  Correct as follows.
+ 
+namespace std {
+template <class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_stringstream
+: public
+basic_iostream<charT,traits> {
+public:
+// types:
+typedef charT char_type;
+typedef typename traits::int_type
+int_type;
+typedef typename traits::pos_type
+pos_type;
+typedef typename traits::off_type
+off_type;
+typedef traits traits_type;
+typedef Alloc
+allocator_type;
+ 
+// constructors/destructor
+explicit basic_stringstream(
+ios_base::openmode which =
+ios_base::out|ios_base::in);
+explicit basic_stringstream(
+const
+basic_string<charT,traits,Alloc>& str,
+ios_base::openmode which =
+ios_base::out|ios_base::in);
+basic_stringstream(basic_stringstream&&
+rhs);
+ 
+// 27.7.5.1 Assign/swap:
+void swap(basic_stringstream&&
+rhs);
+ 
+// Members:
+basic_stringbuf<charT,traits,Alloc>*
+rdbuf() const;
+basic_string<charT,traits,Alloc>
+str() const;
+void str(const
+basic_string<charT,traits,Alloc>& str);
+private:
+// basic_stringbuf<charT, traits>
+sb; exposition only
+};
+ 
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringstream<charT,
+traits, Alloc>& x,
+basic_stringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringstream<charT,
+traits, Alloc>&& x,
+basic_stringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringstream<charT,
+traits, Alloc>& x,
+basic_stringstream<charT, traits,
+Alloc>&& y);
+}
+<td>
+ 
+<tr valign="top">
<td>
-te
+JP 73
+<td>
+27.8.1.14
+<td>
+ 
+<td>
+te
<td>
It is a problem from C++98, fstream cannot appoint
+"margin-top: 0.04in; margin-bottom: 0.04in">It is a problem from C++98, fstream cannot appoint
a filename of wide character string(const wchar_t and const
-wstring&).
+wstring&).
 
<td>
-Add interface corresponding to wchar_t,
-char16_t and char32_t.
+Add interface corresponding to wchar_t,
+char16_t and char32_t.
<td>
 
<tr valign="top">
<td>
-US 86
+US 86
<td>
-28
+28
<td>
 
<td>
-ge
+ge
<td>
-The regular expressions chapter is not
-concept enabled.
+The regular expressions chapter is not
+concept enabled.
 
<td>
 
@@ -16275,195 +13970,181 @@
 
<tr valign="top">
<td>
-UK 
-309
+UK 
+309
<td>
-28
+28
<td>
 
<td>
-Te
+Te
<td>
-Regular expressions cannot be used in constrained
-templates
+Regular expressions cannot be used in constrained
+templates
 
<td>
-Provide
-constraints for the regular expression library, clause 28
+Provide
+constraints for the regular expression library, clause 28
<td>
 
<tr valign="top">
<td>
-UK 
-310
+UK 
+310
<td>
-28
+28
<td>
 
<td>
-Te
+Te
<td>
-The regex
+The regex
chapter uses iterators in the old pre-concept style, it should be
-changed to use concepts instead.
+changed to use concepts instead.
<td>
-Use concepts
-for iterator template arguments throughout.
+Use concepts
+for iterator template arguments throughout.
<td>
 
<tr valign="top">
<td>
-UK 
-314
+UK 
+314
<td>
-28.4
+28.4
<td>
 
<td>
-Te
+Te
<td>
-The swap overloads for regex classes are only
+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.
+respectively.
 
<td>
-Add the
+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
+proposes a single overload with two r-value references
<td>
 
<tr valign="top">
<td>
-UK 
-315
+UK 
+315
<td>
-28.4
+28.4
<td>
-p6
+p6
<td>
-Te
+Te
<td>
-6 Effects: string_type str(first, last); return
+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() ?
+legal to dereference str.end() ?
 
<td>
-Reword to
-effect clause to use legal iterator dereferences
+Reword to
+effect clause to use legal iterator dereferences
<td>
 
<tr valign="top">
<td>
-UK 
-316
+UK 
+316
<td>
-28.4
-ff
+28.4
+ff
<td>
 
<td>
-Te
+Te
<td>
-The constructors for regex classes do not have an
-r-value overload.
+The constructors for regex classes do not have an
+r-value overload.
 
<td>
-Add the
-missing r-value constructors to regex classes.
+Add the
+missing r-value constructors to regex classes.
<td>
 
<tr valign="top">
<td>
-UK 
-317
+UK 
+317
<td>
-28.8
+28.8
<td>
 
<td>
-Te
+Te
<td>
-basic_string
+basic_string
has both a constructor and an assignment operator that accepts an
-initializer list, basic_regex should have the same.
+initializer list, basic_regex should have the same.
<td>
-In the basic_regex synopsis, after:
+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());
+Effects: returns assign(il.begin(), il.end());
 
<td>
 
<tr valign="top">
<td>
-JP 74
+JP 74
<td>
-28.8
+28.8
<td>
 
<td>
-te
+te
<td>
“basic_regx & operator=
-(initializer_list<T>);” is not defined.
+"margin-top: 0.04in; margin-bottom: 0.04in">“basic_regx & operator=
+(initializer_list<T>);” is not defined.
 
<td>
-Add basic_regx & operator=
-(initializer_list<T>);
+Add basic_regx & operator=
+(initializer_list<T>);
<td>
 
<tr valign="top">
<td>
-UK 
-318
+UK 
+318
<td>
-28.8.2
+28.8.2
<td>
-para
-22
+para
+22
<td>
-Ed
+Ed
<td>
-Constructor definition should appear with the
-other constructors not after assignment ops.
+Constructor definition should appear with the
+other constructors not after assignment ops.
 
<td>
-Move para 22
-to just after para 17.
+Move para 22
+to just after para 17.
<td>
 
<tr valign="top">
<td>
-UK 
-319
+UK 
+319
<td>
-28.12.2
+28.12.2
<td>
 
<td>
-Te
+Te
<td>
-It was always
+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
@@ -16472,10 +14153,9 @@
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.
+we should use them to remove this particular wart.
<td>
-To the synopsis for regex_token_iterator, after
+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],
@@ -16491,26 +14171,22 @@
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()).
+submatches.end()).
 
<td>
 
<tr valign="top">
<td>
-US 87
+US 87
<td>
-29
+29
<td>
 
<td>
-ge
+ge
<td>
-The atomics chapter is not concept
-enabled. The adopted paper, N2427, did have those concepts.
+The atomics chapter is not concept
+enabled. The adopted paper, N2427, did have those concepts.
 
<td>
 
@@ -16518,446 +14194,320 @@
 
<tr valign="top">
<td>
-UK 
-311
+UK 
+311
<td>
-29
+29
<td>
 
<td>
-Te
+Te
<td>
-Atomic types cannot be used generically in a
-constrained template
+Atomic types cannot be used generically in a
+constrained template
 
<td>
-Provide
-constraints for the atomics library, clause 29
+Provide
+constraints for the atomics library, clause 29
<td>
 
<tr valign="top">
<td>
-UK 
-312
+UK 
+312
<td>
-29
+29
<td>
 
<td>
-Te
+Te
<td>
-The contents
+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.
+should not use them now.
<td>
-Remove
+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.
+with a TR.
<td>
 
<tr valign="top">
<td>
-JP 75
+JP 75
<td>
-29
-<td>
- 
-<td>
-ed
-<td>
-A definition of enum or struct is the
-style of C using typedef.
-<td>
-Change to a style of C++.
-Correct as follows.
- 
-29.1
- 
-namespace std {
-typedef enum memory_order
-{
-memory_order_relaxed,
-memory_order_consume, memory_order_acquire,
-memory_order_release,
-memory_order_acq_rel, memory_order_seq_cst
-} memory_order;
-}
- 
-should be
- 
-namespace std {
-enum memory_order {
-memory_order_relaxed,
-memory_order_consume, memory_order_acquire,
-memory_order_release,
-memory_order_acq_rel, memory_order_seq_cst
-};
-}
- 
-29.3.1
- 
-namespace std {
-typedef struct atomic_bool
-{
-...
-} atomic_bool;
-}
- 
-should be
- 
-namespace std {
-struct atomic_bool {
-...
-};
-}
- 
-namespace std {
-typedef struct
-atomic_itype {
-...
-} atomic_itype;
-}
- 
-should be
- 
-namespace std {
-struct atomic_itype {
-...
-};
-}
- 
-29.3.2
- 
-namespace std {
-typedef struct atomic_address
-{
-...
-} atomic_address;
-}
- 
-should be
- 
-namespace std {
-struct atomic_address {
-...
-};
-}
- 
-29.5
- 
-namespace std {
-typedef struct atomic_flag
-{
-...
-} atomic_flag;
-}
- 
-should be
- 
-namespace std {
-struct atomic_flag {
-...
-};
-}
-<td>
- 
-<tr valign="top">
-<td>
-UK 
-313
+29
<td>
-29.1
+ 
+<td>
+ed
+<td>
+A definition of enum or struct is the
+style of C using typedef.
+<td>
+Change to a style of C++.
+Correct as follows.
+ 
+29.1
+ 
+namespace std {
+typedef enum memory_order
+{
+memory_order_relaxed,
+memory_order_consume, memory_order_acquire,
+memory_order_release,
+memory_order_acq_rel, memory_order_seq_cst
+} memory_order;
+}
+ 
+should be
+ 
+namespace std {
+enum memory_order {
+memory_order_relaxed,
+memory_order_consume, memory_order_acquire,
+memory_order_release,
+memory_order_acq_rel, memory_order_seq_cst
+};
+}
+ 
+29.3.1
+ 
+namespace std {
+typedef struct atomic_bool
+{
+...
+} atomic_bool;
+}
+ 
+should be
+ 
+namespace std {
+struct atomic_bool {
+...
+};
+}
+ 
+namespace std {
+typedef struct
+atomic_itype {
+...
+} atomic_itype;
+}
+ 
+should be
+ 
+namespace std {
+struct atomic_itype {
+...
+};
+}
+ 
+29.3.2
+ 
+namespace std {
+typedef struct atomic_address
+{
+...
+} atomic_address;
+}
+ 
+should be
+ 
+namespace std {
+struct atomic_address {
+...
+};
+}
+ 
+29.5
+ 
+namespace std {
+typedef struct atomic_flag
+{
+...
+} atomic_flag;
+}
+ 
+should be
+ 
+namespace std {
+struct atomic_flag {
+...
+};
+}
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+313
+<td>
+29.1
<td>
 
<td>
-Te
+Te
<td>
-seq_cst
+seq_cst
fences don't necessarily guarantee ordering
-http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926>
+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
+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.
+modifiction order of M.
 
<td>
 
<tr valign="top">
<td>
-US 88
+US 88
<td>
-29.2
+29.2
<td>
 
<td>
-te
+te
<td>
-The "lockfree" facilities do not tell the
-programmer enough.
+The "lockfree" facilities do not tell the
+programmer enough.
<td>
-Expand the "lockfree" facilities. See
+Expand the "lockfree" facilities. See
the attached paper "Issues with the C++ Standard" under Chapter 29,
-"atomics.lockfree doesn't tell the programmer enough"
+"atomics.lockfree doesn't tell the programmer enough"
 
<td>
 
<tr valign="top">
<td>
-US 89
+US 89
<td>
-29.3.1
+29.3.1
<td>
-Table 122
+Table 122
<td>
-te
+te
<td>
-The types in the table "Atomics for
+The types in the table "Atomics for
standard typedef types" should be typedefs, not classes. These
-semantics are necessary for compatibility with C.
+semantics are necessary for compatibility with C.
 
<td>
-Change the classes to typedefs.
+Change the classes to typedefs.
<td>
-Google
+Google
<tr valign="top">
<td>
-US 90
+US 90
<td>
-29.4
+29.4
<td>
 
<td>
-te
+te
<td>
-Are atomic functions allowed to have non-volatile
-overloads?
+Are atomic functions allowed to have non-volatile
+overloads?
<td>
-Allow non-volatile overloads. See the
+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?"
+overloads?"
 
<td>
 
<tr valign="top">
<td>
-US 91
+US 91
<td>
-29.4
+29.4
<td>
 
<td>
-te
+te
<td>
-Whether or not a failed compare_exchange is a RMW
-operation (as used in 1.10 [intro.multithread]) is unclear.
+Whether or not a failed compare_exchange is a RMW
+operation (as used in 1.10 [intro.multithread]) is unclear.
<td>
-Make failing compare_exchange operations
-not
-be RMW. See the attached
+Make failing compare_exchange operations 
+not be RMW. See the attached
paper under "atomic RMW status of failed
-compare_exchange"
+compare_exchange"
 
<td>
 
<tr valign="top">
<td>
-US 92
+US 92
<td>
-29.4
+29.4
<td>
 
<td>
-te
+te
<td>
-The effect of memory_order_consume with atomic RMW
-operations is unclear.
+The effect of memory_order_consume with atomic RMW
+operations is unclear.
<td>
-Follow the lead of fences
+Follow the lead of fences
[atomics.fences], and promote memory_order_consume to
-memory_order_acquire with RMW operations.
+memory_order_acquire with RMW operations.
 
<td>
 
<tr valign="top">
<td>
-JP 76
+JP 76
<td>
-30
+30
<td>
 
<td>
-ed
-<td>
-A description for "Throws:
-Nothing." are not unified.
-At the part without throw,
-"Throws: Nothing." should be described.
-<td>
-Add "Throws: Nothing." to the
-following.
-30.2.1.6 , 1st paragraph
-30.3.3.1 , 4th paragraph
-30.3.3.2.1 , 6th paragraph
-30.4.1 , 7th and 8th paragraph
-30.4.2 ,
-6th, 7th,19th,21th and 25th paragraph
+ed
+<td>
+A description for "Throws:
+Nothing." are not unified.
+At the part without throw,
+"Throws: Nothing." should be described.
+<td>
+Add "Throws: Nothing." to the
+following.
+30.2.1.6 , 1st paragraph
+30.3.3.1 , 4th paragraph
+30.3.3.2.1 , 6th paragraph
+30.4.1 , 7th and 8th paragraph
+30.4.2 ,
+6th, 7th,19th,21th and 25th paragraph
 
<td>
 
<tr valign="top">
<td>
-US 93
+US 93
<td>
-30
+30
<td>
 
<td>
-ge
+ge
<td>
-The thread chapter is not concept
-enabled.
+The thread chapter is not concept
+enabled.
 
<td>
 
@@ -16966,37 +14516,35 @@
<tr valign="top">
<td>
UK 
-320
+"margin-right: -0.18in; margin-bottom: 0in">UK 
+320
 
<td>
-30
+30
<td>
 
<td>
-Te
+Te
<td>
-Threads
-library cannot be used in constrained templates
+Threads
+library cannot be used in constrained templates
<td>
-Provide
-constraints for the threads library, clause 30
+Provide
+constraints for the threads library, clause 30
<td>
 
<tr valign="top">
<td>
-UK 
-321
+UK 
+321
<td>
-30
+30
<td>
 
<td>
-Ed
+Ed
<td>
-Throughout this clause, the term Requires: is used
+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
@@ -17004,161 +14552,150 @@
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.
+clause 17 for more details.
 
<td>
-Decument
+Decument
Preconditions: paragraphs in 17.5.2.4, and use consistently through
-rest of the library.
+rest of the library.
<td>
 
<tr valign="top">
<td>
-US 94
+US 94
<td>
-30.1.2
+30.1.2
<td>
-1
+1
<td>
-te
+te
<td>
-The first sentence of para
+The first sentence of para
1 suggests that no other library function is permitted to call
-operating system or low level APIs.
+operating system or low level APIs.
<td>

-Rewrite para 1 as: “
+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.”
+from returning a meaningful value.”
 
<td>
 
<tr valign="top">
<td>
-US 95
+US 95
<td>
-30.1.3
+30.1.3
<td>
-1
+1
<td>
-te
+te
<td>
-“native_handle_type” is a typedef, not a
-class member.
+“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
-presence of this member and its
+"margin-top: 0.04in; margin-bottom: 0.04in">Several classes described in this Clause have a
+member native_handle (of type native_handle_type) . The
+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>
 
<tr valign="top">
<td>
-US 96
+US 96
<td>
-30.1.4
+30.1.4
<td>
-2
+2
<td>
-te
+te
<td>
-There is no definition
-here for monotonic clock.
+There is no definition
+here for monotonic clock.
<td>
Implementations should use a monotonic
+"margin-top: 0.04in; margin-bottom: 0.04in">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.
+negative clock jumps.
 
<td>
 
<tr valign="top">
<td>
-UK 
-322
+UK 
+322
<td>
-30.1.4
+30.1.4
<td>
-2
+2
<td>
-Te
+Te
<td>
-Not all systms can provide a monotonic clock. How
-are they expected to treat a _for function?
+Not all systms can provide a monotonic clock. How
+are they expected to treat a _for function?
 
<td>
-Add at least
+Add at least
a note explaining the intent for systems that do not support a
-monotonic clock.
+monotonic clock.
<td>
 
<tr valign="top">
<td>
-UK 
-323
+UK 
+323
<td>
-30.2.1
+30.2.1
<td>
-1
+1
<td>
-Te
+Te
<td>
-The presence of a non-explicit variadic template
+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.
+supplied func is an lvalue.
 
<td>
-Mark
+Mark
constructor template <class F, class ...Args>
thread(F&& f, Args&&... args); as explicit and
-remove the single-argument constructor.
+remove the single-argument constructor.
<td>
 
<tr valign="top">
<td>
-UK 
-324
+UK 
+324
<td>
-30.2.1.1
+30.2.1.1
<td>
 
<td>
-Te
+Te
<td>
-thread::id objects should be as useable in hashing
-containers as they are in ordered associative containers.
+thread::id objects should be as useable in hashing
+containers as they are in ordered associative containers.
 
<td>
-Add thread::id support for std::hash
+Add thread::id support for std::hash
 
 
 
@@ -17166,139 +14703,120 @@
 
<tr valign="top">
<td>
-JP 77
+JP 77
<td>
-30.2.1.2
+30.2.1.2
<td>
 
<td>
-te
+te
<td>
"CopyConstructible" and "MoveConstructible" in
+"margin-top: 0.04in; margin-bottom: 0.04in">"CopyConstructible" and "MoveConstructible" in
"Requires: F and each Ti in Args shall be CopyConstructible
if an lvalue and otherwise MoveConstructible." are reflected by
-interface.
+interface.
 
<td>
-Add a concept for constructor of
-thread.
+Add a concept for constructor of
+thread.
<td>
 
<tr valign="top">
<td>
-JP 78
+JP 78
<td>
-30.2.1.2
+30.2.1.2
<td>
-4th paragraph, 1st line
+4th paragraph, 1st line
 
<td>
-ed
+ed
<td>
-In "F and each Ti in Args", 'Ti' is not
-clear.
+In "F and each Ti in Args", 'Ti' is not
+clear.
<td>
-Replace "Ti" with "args"
+Replace "Ti" with "args"
<td>
 
<tr valign="top">
<td>
-US 97
+US 97
<td>
-30.2.1.3
+30.2.1.3
<td>
-1
+1
<td>
-te
+te
<td>
-detach-on-destruction may
+detach-on-destruction may
result in “escaped” threads accessing objects with
-bounded lifetime after the end of their lifetime.
+bounded lifetime after the end of their lifetime.
<td>
-See document WG21
-N2802=08-0312 written by Hans Boehm.
+See document WG21
+N2802=08-0312 written by Hans Boehm.
<td>
 
<tr valign="top">
<td>
-US 98
+US 98
<td>
-30.2.1.3, 30.2.1.4
+30.2.1.3, 30.2.1.4
<td>
 
<td>
 
<td>
-The current defined behavior for the std::thread
+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.
+behavior.
<td>
-Change destruction behavior to undefined
+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".
+"Implicit thread detach is harmful".
 
<td>
 
<tr valign="top">
<td>
-UK 
-325
+UK 
+325
<td>
-30.3.3
+30.3.3
<td>
-2
+2
<td>
-Te
+Te
<td>
-We believe
+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.
+completely.
<td>
-Replace the extern declarations: extern const
+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{};
+try_to_lock{}; constexpr adopt_lock_t adopt_lock{};
 
<td>
 
<tr valign="top">
<td>
-UK 
-326
+UK 
+326
<td>
-30.3.3.2.1
+30.3.3.2.1
<td>
-7
+7
<td>
-Te
+Te
<td>
-The precondition that the mutex is not owned by
+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
@@ -17306,28 +14824,26 @@
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.
+lock.
 
<td>
-Strike
-30.3.3.2.1p7
+Strike
+30.3.3.2.1p7
<td>
 
<tr valign="top">
<td>
-UK 
-327
+UK 
+327
<td>
-30.3.3.2.2
+30.3.3.2.2
<td>
-4, 9, 14,
-19
+4, 9, 14,
+19
<td>
-Te
+Te
<td>
-Not clear what the specification for error
+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
@@ -17338,58 +14854,54 @@
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.
+is boolean and not a integer to count recursive locks.
 
<td>
-Add a
+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.
+by the host OS.
<td>
 
<tr valign="top">
<td>
-UK 
-328
+UK 
+328
<td>
-30.3.3.2.2
+30.3.3.2.2
<td>
-20
+20
<td>
-Te
+Te
<td>
-There is a
+There is a
missing precondition that owns is true, or an if(owns) test is
-missing from the effect clause
+missing from the effect clause
<td>
-Add a precondition that owns == true. Add an error
+Add a precondition that owns == true. Add an error
condition to detect a violation, rather than yield undefined
-behaviour.
+behaviour.
 
<td>
 
<tr valign="top">
<td>
-UK 
-329
+UK 
+329
<td>
-30.5
+30.5
<td>
 
<td>
-Te
+Te
<td>
-future,
+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.
+Advanced thread pools are to be left for TR2.
<td>
-Provide a simple function along the lines of:
+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
@@ -17404,219 +14916,196 @@
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.]
+no free worker threads then the async call should fail.]
 
<td>
 
<tr valign="top">
<td>
-UK 
-330
+UK 
+330
<td>
-30.5.1
+30.5.1
<td>
 
<td>
-Ed
+Ed
<td>
-30.5.1 (and
+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.
+not in the CD, so references to it should be removed.
<td>
-Remove the reference to
+Remove the reference to
constructible_with_allocator_prefix in 30.5.1 Remove paragraph
-30.5.7
+30.5.7
 
<td>
 
<tr valign="top">
<td>
-JP 79
+JP 79
<td>
-30.5.1
+30.5.1
<td>
 
<td>
-te
+te
<td>
-The concept of UsesAllocator and
-Allocator should be used.
+The concept of UsesAllocator and
+Allocator should be used.
<td>
-Correct as follows.
+Correct as follows.
 
-template <class R, class
-Alloc>
-struct
-uses_allocator<promise<R>, Alloc>;
-template <class R>
-struct
+template <class R, class
+Alloc>
+struct
+uses_allocator<promise<R>, Alloc>;
+template <class R>
+struct
constructible_with_allocator_prefix<promise<R>
->;
+>;
 
-should be
+should be
 
-template<class R, Allocator
-Alloc>
-concept_map UsesAllocator<promise<R>,
-Alloc>;
+template<class R, Allocator
+Alloc>
+concept_map UsesAllocator<promise<R>,
+Alloc>;
 
<td>
 
<tr valign="top">
<td>
-UK 
-331
+UK 
+331
<td>
-30.5.3
+30.5.3
<td>
 
<td>
-Te
+Te
<td>
-Not clear what it means for a public constructor
+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.
+public consumption.
 
<td>
-Declare the
+Declare the
constructor as private with a note about intended friendship, or
remove the exposition-only comment and document the
-semantics.
+semantics.
<td>
 
<tr valign="top">
<td>
-UK 
-332
+UK 
+332
<td>
-30.5.4
+30.5.4
<td>
 
<td>
-Ed
+Ed
<td>
-It is not clear without reference to the original
+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.
+it would be most useful in this case.
 
<td>
-Provide a
+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.
+the promise API.
<td>
 
<tr valign="top">
<td>
-UK 
-333
+UK 
+333
<td>
-30.5.4
+30.5.4
<td>
-5
+5
<td>
-Ge
+Ge
<td>
-We expect the
+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.
+application of concepts.
<td>
-Requires
-fully baked concepts for clause 30
+Requires
+fully baked concepts for clause 30
<td>
 
<tr valign="top">
<td>
-UK 
-334
+UK 
+334
<td>
-30.5.4
+30.5.4
<td>
-5
+5
<td>
-Te
+Te
<td>
-Behaviour of get() is undefined if calling get()
+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.
+and will wait for the future to become ready.
 
<td>
-Effects: If
+Effects: If
is_ready() would return false, block on the asynchronous result
-associated with *this.
+associated with *this.
<td>
 
<tr valign="top">
<td>
-UK 
-335
+UK 
+335
<td>
-30.5.4
+30.5.4
<td>
 
<td>
-Te
+Te
<td>
-std::unique_future is MoveConstructible, so you
+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.
+oops, uf has no result to wait for.
 
<td>
-Add a
+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();
+can say: if(uf.waitable()) uf.wait();
<td>
 
<tr valign="top">
<td>
-UK 
-336
+UK 
+336
<td>
-30.5.4
+30.5.4
<td>
 
<td>
-Te
+Te
<td>
-It is possible to transfer ownership of the
+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
@@ -17624,72 +15113,65 @@
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.
+move-assignable for example.
 
<td>
-Add a default
+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.
+which transfers ownership.
<td>
 
<tr valign="top">
<td>
-JP 80
+JP 80
<td>
-30.5.4 , 30.5.5
+30.5.4 , 30.5.5
<td>
 
<td>
-ed
+ed
<td>
-Typo, duplicated ">"
+Typo, duplicated ">"
"class Period>>"
+"margin-top: 0.04in; margin-bottom: 0.04in">"class Period>>"
 
<td>
-Remove one
+Remove one
<td>
 
<tr valign="top">
<td>
-UK 
-337
+UK 
+337
<td>
-30.5.5
+30.5.5
<td>
 
<td>
-Te
+Te
<td>
-shared_future should support an efficient move
+shared_future should support an efficient move
constructor that can avoid unnecessary manipulation of a reference
-count, much like shared_ptr
+count, much like shared_ptr
 
<td>
-Add a move
-constructor
+Add a move
+constructor
<td>
 
<tr valign="top">
<td>
-UK 
-338
+UK 
+338
<td>
-30.5.5
+30.5.5
<td>
 
<td>
-Te
+Te
<td>
-shared_future
+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
@@ -17698,10 +15180,9 @@
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".
+shared_future".
<td>
-Remove "=delete" from the copy-assignment operator
+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).
@@ -17709,364 +15190,316 @@
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.
+that rhs has no associated state.
 
<td>
 
<tr valign="top">
<td>
-UK 
-339
+UK 
+339
<td>
-30.5.6
+30.5.6
<td>
-6,
-7
+6,
+7
<td>
-Te
+Te
<td>
-Move
+Move
assignment is goiing in the wrong direction, assigning from *this
to the passed rvalue, and then returning a reference to an unusable
-*this
+*this
<td>
-Strike 6. 7 Postcondition: associated state of
+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.
+rhs has no associated state.
 
<td>
 
<tr valign="top">
<td>
-UK 
-340
+UK 
+340
<td>
-30.5.6
+30.5.6
<td>
-11, 12,
-13
+11, 12,
+13
<td>
-Te
+Te
<td>
-There is an implied postcondition that the state
+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.
+with no associated state. It should be spelled out.
 
<td>
-Postcondition: *this has no associated
-state.
+Postcondition: *this has no associated
+state.
<td>
 
<tr valign="top">
<td>
-UK 
-341
+UK 
+341
<td>
-30.5.6
+30.5.6
<td>
 
<td>
-Te
+Te
<td>
-promise::swap
+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
+swap functions accept an rvalue reference
<td>
-Change
-promise::swap to take an rvalue reference.
+Change
+promise::swap to take an rvalue reference.
<td>
 
<tr valign="top">
<td>
-UK 
-342
+UK 
+342
<td>
-30.5.6
+30.5.6
<td>
 
<td>
-Te
+Te
<td>
-std::promise is missing a non-member overload of
+std::promise is missing a non-member overload of
swap. This is inconsistent with other types that provide a swap
-member function
+member function
 
<td>
-Add a
+Add a
non-member overload void swap(promise&& x,promise&&
-y){ x.swap(y); }
+y){ x.swap(y); }
<td>
 
<tr valign="top">
<td>
-UK 
-343
+UK 
+343
<td>
-30.5.6
+30.5.6
<td>
-3
+3
<td>
-Te
+Te
<td>
-The move
+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.
+constructor is superfluous.
<td>
-Remove the constructor with the signature template
+Remove the constructor with the signature template
<class Allocator> promise(allocator_arg_t, const
-Allocator& a, promise& rhs);
+Allocator& a, promise& rhs);
 
<td>
 
<tr valign="top">
<td>
-JP 81
+JP 81
+<td>
+30.5.8
+<td>
+ 
+<td>
+ed
<td>
-30.5.8
-<td>
- 
-<td>
-ed
-<td>
-There are not requirements for F and a
-concept of Allocator dose not use.
-<td>
-Correct as follows.
- 
-template <class F>
-explicit packaged_task(F f);
-template <class F, class
-Allocator>
-explicit packaged_task(allocator_arg_t,
-const Allocator& a, F f);
-template <class F>
-explicit packaged_task(F&&
-f);
-template <class F, class
-Allocator>
-explicit packaged_task(allocator_arg_t,
-const Allocator& a, F&& f);
- 
-should be
- 
-template <class F>
-requires CopyConstructible<F>
-&& Callable<F, ArgTypes...>
-&& Convertible<Callable<F,
-ArgTypes...>::result_type, R>
-explicit packaged_task(F f);
- 
-template <class F, Allocator
-Alloc>
-requires CopyConstructible<F>
-&& Callable<F, ArgTypes...>
-&& Convertible<Callable<F,
-ArgTypes...>::result_type, R>
-explicit packaged_task(allocator_arg_t,
-const Alloc& a, F f);
- 
-template <class F>
-requires CopyConstructible<F>
-&& Callable<F, ArgTypes...>
-&& Convertible<Callable<F,
-ArgTypes...>::result_type, R>
-explicit packaged_task(F&&
-f);
- 
-template <class F, Allocator
-Alloc>
-requires CopyConstructible<F>
-&& Callable<F, ArgTypes...>
-&& Convertible<Callable<F,
-ArgTypes...>::result_type, R>
-explicit packaged_task(allocator_arg_t, const
-Alloc& a, F&& f);
+There are not requirements for F and a
+concept of Allocator dose not use.
+<td>
+Correct as follows.
+ 
+template <class F>
+explicit packaged_task(F f);
+template <class F, class
+Allocator>
+explicit packaged_task(allocator_arg_t,
+const Allocator& a, F f);
+template <class F>
+explicit packaged_task(F&&
+f);
+template <class F, class
+Allocator>
+explicit packaged_task(allocator_arg_t,
+const Allocator& a, F&& f);
+ 
+should be
+ 
+template <class F>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+explicit packaged_task(F f);
+ 
+template <class F, Allocator
+Alloc>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+explicit packaged_task(allocator_arg_t,
+const Alloc& a, F f);
+ 
+template <class F>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+explicit packaged_task(F&&
+f);
+ 
+template <class F, Allocator
+Alloc>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+explicit packaged_task(allocator_arg_t, const
+Alloc& a, F&& f);
 
<td>
 
<tr valign="top">
<td>
-DE-23
+DE-23
<td>
-Annex B
+Annex B
<td>
-p2
+p2
<td>
-te
+te
<td>

-DE-23 Recursive use of
+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.
+recursion.
 
<td>
-In Annex B, specify a
-recursion depth of 256 or a larger value.
+In Annex B, specify a
+recursion depth of 256 or a larger value.
<td>
 
<tr valign="top">
<td>
-DE-24
+DE-24
<td>
-Annex B
+Annex B
<td>
-p2
+p2
<td>
-te
+te
<td>

-DE-24 The number of
+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.
+but no minimum is suggested in Annex B.
 
<td>
-Add a miminum of 10
-placeholders to Annex B.
+Add a miminum of 10
+placeholders to Annex B.
<td>
 
<tr valign="top">
<td>
-DE-25
+DE-25
<td>
-Annex B
+Annex B
<td>
-p2
+p2
<td>
-te
+te
<td>

-DE-25 Specifying a minimum of
+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.
+template instantiations" is inapposite.
 
<td>
-Remove the bullet
-"Recursively nested template instantiations [17]".
+Remove the bullet
+"Recursively nested template instantiations [17]".
<td>
 
<tr valign="top">
<td>
-FR 38
+FR 38
<td>
-C.2 [diffs.library]
+C.2 [diffs.library]
<td>
-1
+1
<td>
-ed
+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
-make reference to things which were
-introduced by Amd.1).
+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
+make reference to things which were
+introduced by Amd.1).
 
<td>
-One need probably a reference to the
-document which introduce char16_t and
-char32_t in C (ISO/IEC TR
-19769:2004?).
+One need probably a reference to the
+document which introduce char16_t and
+char32_t in C (ISO/IEC TR
+19769:2004?).
<td>
 
<tr valign="top">
<td>
-UK 
-344
+UK 
+344
<td>
-Appendix
-D
+Appendix
+D
<td>
 
<td>
-Ge
+Ge
<td>
-It is
+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.
+step.
<td>
-Add to the
+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.
+deprecated features are supported.
<td>
 
<tr valign="top">
<td>
-FR 39
+FR 39
<td>
-Index
+Index
<td>
 
<td>
-ed
+ed
<td>
-Some definitions seem not indexed (such as
-/trivially copyable/ or
-/sequenced before/), indexing them would
+Some definitions seem not indexed (such as
+/trivially copyable/ or
+/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).
+also be considered).
 
<td>

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51563 - sandbox/committee/LWG"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51561 - 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