Boost-Commit :

Date view	Thread view	Subject view	Author view

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

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

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

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

Modified: sandbox/committee/LWG/0xCD1_Comments.html
==============================================================================
--- sandbox/committee/LWG/0xCD1_Comments.html (original)
+++ sandbox/committee/LWG/0xCD1_Comments.html 2009-03-03 08:32:44 EST (Tue, 03 Mar 2009)
@@ -25,23 +25,23 @@
 <td width="29">
 MB 

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

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

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

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

- <td width="178">
+ <td width="225">
 
 Disposition
@@ -50,8882 +50,18 @@

 <tr valign="top">
 <td width="29">
- FR 1
-
- <td width="118">
- General 
- Comment
-
- <td width="85">
- 
-
- <td width="62">
- ge
-
- <td width="514">
- 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.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 1
-
- <td width="118">
- 1-16
-
- <td width="85">
- 
-
- <td width="62">
- ge/te
-
- <td width="514">
- The
- active issues identified in WG21 N2803, C++ Standard Core
- Language Active Issues, must be addressed 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>
-
- <td width="536">
- 
- Appropriate action would include making changes to the CD,
- identifying an issue as not requiring a change to the CD,
- or deferring the issue to a later point in time.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- CA-1
-
- <td width="118">
- 
-
- <td width="85">
- 
-
- <td width="62">
- Ge
-
- <td width="514">
- There are quite a number of defects for the current CD
- recorded in SC22/WG21-N2803 and N2806
-
- <td width="536">
- Consider these comments and update ISO/IEC CD 14882
- accordingly
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-1
-
- <td width="118">
- 1 through 16
-
- <td width="85">
- 
-
- <td width="62">
- ge/te
-
- <td width="514">
- DE-1 Consider addressing a significant part of the
- unresolved core language issues presented in WG21 document
- N2791 "C++ Standard Core Language Active Issues, Revision
- 59", available at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
- .
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- CH 2
-
- <td width="118">
- all
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The issues on the issues lists shall be addressed before
- the standard becomes final.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 3
-
- <td width="118">
- all
-
- <td width="85">
- 
-
- <td width="62">
- ed
-
- <td width="514">
- Latin abbreviations are presented incorrectly.
-
- <td width="536">
- Italicize all
- Latin abbreviations, append commas after each occurrence of
- i.e. and e.g., and remove extraneous space
- after each such abbreviation.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 3
-
- <td width="118">
- 1 [intro.scope]
-
- <td width="85">
- 2
-
- <td width="62">
- ed
-
- <td width="514">
- C++ is split at the end of line.
-
- <td width="536">
-  <td width="178">
-  <tr valign="top">
- <td width="29">
- US 4
-
- <td width="118">
- 1.1
-
- <td width="85">
- 2
-
- <td width="62">
- ed
-
- <td width="514">
- There is a bad line break in
- "C++".
-
- <td width="536">
-  <td width="178">
-  <tr valign="top">
- <td width="29">
- UK 1
-
- <td width="118">
- 1.1
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- List of additional facilities over C has
- been extended with this standard, so should be mentioned in
- the introductory material.
-
- <td width="536">
- Add the following to the list in 1.1p2:
- atomic operations concurrency alignment control
- user-defined literals attributes
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 4
-
- <td width="118">
- 1.2 [intro.refs]
-
- <td width="85">
- 1
-
- <td width="62">
- ed
-
- <td width="514">
- Is the lack of reference to ISO/CEI 9899/AC3:2007
- voluntary?
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 2
-
- <td width="118">
- 1.2
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- 
- We recommend taking the latest update to
- each listed standard, yet the C standard is quite
- deliberately held back to the 1990 version without
- comment.+
-
- <td width="536">
- ... not sure ...
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 3
-
- <td width="118">
- 1.3.1
-
- <td width="85">
- 
-
- <td width="62">
- Ed
-
- <td width="514">
- The definition of an argument does not seem
- to cover many assumed use cases, and we believe that is not
- intentional.
-
- <td width="536">
- 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
- agrument, but the value forwarded to operator[]() is ? Does
- not apply to operators as call-points not bounded by
- parenthises ? Similar for copy initialization and
- conversion? what are Deduced 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?
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 4
-
- <td width="118">
- 1.3.3
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- This definition is essentially worthless,
- as it says nothing about what distinguished a diagnostic
- message from other output messages provided by the
- implementation
-
- <td width="536">
- ... add
- something about the diagnostic message being a message
- issues by the implementation when translating a program
- that violates the rules of the standard. ...
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 5
-
- <td width="118">
- 1.3.4 
- [defns. 
- dynamic.type]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- "The dynamic type of an rvalue expression is its static
- type." Is this true with rvalue references?
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 5
-
- <td width="118">
- 1.3.5
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The wording is unclear as to whether it is the input or
- the implementation "that is not a well-formed program".
-
- <td width="536">
- Reword to clarify that it is the input that is here
- considered not well-formed.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 6
-
- <td width="118">
- 1.3.6 
- [defns. 
- impl.defined]
-
- <td width="85">
- 
-
- <td width="62">
- ed
-
- <td width="514">
- There is a page break between the title and the
- paragraph.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 7
-
- <td width="118">
- 1.3.13 
- [defns. 
- undefined]
-
- <td width="85">
- 
-
- <td width="62">
- ed
-
- <td width="514">
- [intro.execution]/5 explicitly allows non causal
- undefined behaviour,
-
- <td width="536">
- Adding it to the note outlying possible undefined
- behaviours.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 6
-
- <td width="118">
- 1.3.14
-
- <td width="85">
- 
-
- <td width="62">
- ge
-
- <td width="514">
- 
- 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?) 
-
- <td width="536">
- Clearly state whether or not
- Unspecified behavior includes undefined behavior.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 8
-
- <td width="118">
- 1.4 
- [intro. 
- compliance]
-
- <td width="85">
- 8
-
- <td width="62">
- ed
-
- <td width="514">
- The paragraph as its stands seems to require that
- violations of the ODR (which make a program ill-formed) are
- required to be diagnosed if the program also uses an
- extension which defines some cases of ODR.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 5
-
- <td width="118">
- 1.5
-
- <td width="85">
- 
-
- <td width="62">
- Ge
-
- <td width="514">
- Missing checklist of implementation defined
- behaviour (see ISO/IEC TR 10176, 4.1.1p6)
-
- <td width="536">
- Provide a new annex with the missing
- checklist
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 6
-
- <td width="118">
- 1.5
-
- <td width="85">
- 
-
- <td width="62">
- Ge
-
- <td width="514">
- Missing annex describing potential
- incompatibility to previous edition of the standard (see
- ISO/IEC TR 10176, 4.1.1p9)
-
- <td width="536">
- Provide a new annex with the missing
- documentation. See n2733(08-0243) for a starting point
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 7
-
- <td width="118">
- 1.5
-
- <td width="85">
- 2
-
- <td width="62">
- ed
-
- <td width="514">
- There is no mention of Clause 17.
-
- <td width="536">
- Include Clause 17 among the list of Clauses that specify
- the Standard Library.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 8
-
- <td width="118">
- 1.5
-
- <td width="85">
- 2
-
- <td width="62">
- te
-
- <td width="514">
- The paragraph
- omits to mention concepts and concept maps among its list
- of entities defined in the Standard Library. 
-
- <td width="536">
- Mention concepts and concept maps among the list of
- entities.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 9
-
- <td width="118">
- 1.6
-
- <td width="85">
- 1
-
- <td width="62">
- ed
-
- <td width="514">
- The
- syntax description does not account for lines that wrap. 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 10
-
- <td width="118">
- 1.7
-
- <td width="85">
- 3
-
- <td width="62">
- ed
-
- <td width="514">
- The term thread is used before
- defined.
-
- <td width="536">
- Reference 1.10 [intro.multithread].
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 11
-
- <td width="118">
- 1.7
-
- <td width="85">
- ¶ 3 last sent.
-
- <td width="62">
- ed
-
- <td width="514">
- The phrase “threads of execution” should be
- accompanied by a reference to [intro.multithread].
-
- <td width="536">
- Insert the recommended reference.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 12
-
- <td width="118">
- 1.7
-
- <td width="85">
- ¶ 3 first sent.
-
- <td width="62">
- te
-
- <td width="514">
- A memory location is not an object as the sentence
- claims.
-
- <td width="536">
- Clarify that a memory location “holds” an
- object rather than that it “is” an object.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 13
-
- <td width="118">
- 1.7
-
- <td width="85">
- ¶ 3 last sent.
-
- <td width="62">
- te
-
- <td width="514">
- It is unclear what is meant by memory locations that are
- "separate": are they distinct? non-overlapping? how much
- "separation" is needed?
-
- <td width="536">
- Provide either a better definition of
- “separate” or reword (this and subsequent
- paragraphs) to avoid this term.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 14
-
- <td width="118">
- 1.7
-
- <td width="85">
- ¶ 4
-
- <td width="62">
- te
-
- <td width="514">
- The phrase "no matter what the sizes of the intervening
- bit-fields happen to be" contradicts the claim of
- separation "by a zero-length bit-field declaration".
-
- <td width="536">
- Delete the “no matter…” phrase, or
- resolve the contradiction in a different way.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 15
-
- <td width="118">
- 1.7
-
- <td width="85">
- ¶ 5
-
- <td width="62">
- te
-
- <td width="514">
- A struct does not “contain” memory
- locations.
-
- <td width="536">
- Reword so that a struct is “held in” one or
- more memory locations.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 16
-
- <td width="118">
- 1.9
-
- <td width="85">
- 
-
- <td width="62">
- 
-
- <td width="514">
- The discussion of observable behavior in 1.9 is not
- consistent with the addition of threads to the language.
- Volatile reads and writes and other observable actions no
- longer occur in a single "sequence”.
-
- <td width="536">
- Remove/replace various occurrences of "sequence" in 1.9.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 8
-
- <td width="118">
- 1.9
-
- <td width="85">
- 5
-
- <td width="62">
- Te
-
- <td width="514">
- With parallel execution there is no longer
- the idea of a single execution sequence for a program.
- Instead, a program may be considered a set of exectution
- sequences.
-
- <td width="536">
- 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 7
-
- <td width="118">
- 1.9
-
- <td width="85">
- 6
-
- <td width="62">
- Te
-
- <td width="514">
- Does the term 'sequence' imply all
- reads/writes through volatile memory much be serialized,
- and cannot occur in parallel on truly parallel hardware?
- 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
-
- <td width="536">
- Replace 'sequence' with 'sequences'.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 9
-
- <td width="118">
- 1.9 
- [intro.execution]
-
- <td width="85">
- 16
-
- <td width="62">
- ed
-
- <td width="514">
- This example use int *v while the other examples seems
- to use notation like int* v.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 17
-
- <td width="118">
- 1.10
-
- <td width="85">
- 1
-
- <td width="62">
- Ge
-
- <td width="514">
- This definition of
- “thread” is poor, and assumes the user already
- knows what multi-threaded means (probably true!). In
- particular, it does not deal adequately with the concept
- that all threads share the same address space.
-
- <td width="536">
- Replace first
- sentence of para 1 as follows:
-
- 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,
- including but not limited to static objects, storage
- obtained via 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 9
-
- <td width="118">
- 2.1
-
- <td width="85">
- 2, 4
-
- <td width="62">
- Te
-
- <td width="514">
- Undefined behaviour is a drastic way to
- silently ignore minor issues. The cases in this paragraph
- could be easily defined. In this case opt for conditionally
- supported behaviour, which mandates a diagnostic if the
- compiler is not prepared to handle the syntax consistently.
-
- <td width="536">
- 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 10
-
- <td width="118">
- 2.1
-
- <td width="85">
- 3
-
- <td width="62">
- Te
-
- <td width="514">
- Implementation
- defined seems unnecessarily burdensome for negligible gain.
- I am yet to see code that depended on whether non-empty
- sequences of whitespace were concatenated. Better left
- unspecified.
-
- <td width="536">
- How the compiler treats non-empty sequences
- of whitespace should be left unspecified, rather than
- implementation-defined.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 10
-
- <td width="118">
- 2.1 [lex.phases]/5 
- and 
- 2.2 [lex.charset]/3
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- [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 of the execution character sets are
- implementation defined, and any additional members are
- locale-specific." 
-
- 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. 
-
- 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.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 11
-
- <td width="118">
- 2.3
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- Trigraphs are a complicated solution to an
- old problem, that cause more problems than they solve in
- the modern environment. Unexpected trigraphs in string
- literals and occasionally in comments can be very confusing
- for the non-expert.
-
- <td width="536">
- Deprecate the whole of 2.3 and move it to
- appendix D.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 12
-
- <td width="118">
- 2.4, 2.8
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- <td width="536">
- Replace undefined behaviour with
- conditionally supported behaviour with implementation
- defined semantics.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 18
-
- <td width="118">
- 2.4
-
- <td width="85">
- ¶ 2
-
- <td width="62">
- ed
-
- <td width="514">
- The paragraph begins with an empty line.
-
- <td width="536">
- Delete the empty line.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 11
-
- <td width="118">
- 2.4 
- [lex.pptokens]
-
- <td width="85">
- 3
-
- <td width="62">
- ed
-
- <td width="514">
- There are spurious empty lines.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 12
-
- <td width="118">
- 2.5 [lex.digraph] 
- and 2.11 
- [lex.key]/2
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The alternative representations are reserved as such
- even in attribute. Is that what is wanted?
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FI 2
-
- <td width="118">
- 2.5
-
- <td width="85">
- Table 2
-
- <td width="62">
- te
-
- <td width="514">
- Add eq, for spelling out == in order to distinguish it
- from the assignment operator.
-
- <td width="536">
- See eq-keyword.doc, eq-keyword.ppt
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 13
-
- <td width="118">
- 2.9
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- This text is confusing in isolation, as it
- implies pp-numbers do not have a value in translation phase
- 4 when evaluating #if preprocessor expressions.
-
- <td width="536">
- Add a note with a cross-refernce to 16.1
- that a pp-number may briefly acquire a value during
- translation phase 4 while evaluating #if expressions.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 14
-
- <td width="118">
- 2.11
-
- <td width="85">
- table 3
-
- <td width="62">
- Ed
-
- <td width="514">
- The table is
- nearly sorted, but not quite. It was sorted in previous
- versions of the standard.
-
- <td width="536">
- Sort the table.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 1
-
- <td width="118">
- 2.11
-
- <td width="85">
- Table 3
-
- <td width="62">
- ed
-
- <td width="514">
- Keywords in the table are listed disorderly. Also, a
- part of a frame of the table is not drawn.
-
- <td width="536">
- Sort it in alphabetical order.
- Complete the table frame.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 19
-
- <td width="118">
- 2.13.1
-
- <td width="85">
- Table 5, 
- rows “l or 
- L” and “ll or
- LL”
-
- <td width="62">
- te
-
- <td width="514">
- The final entry in the last column (“unsigned long
- int”) is incorrect.
-
- <td width="536">
- Replace the incorrect entries by “unsigned long
- long int”.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 20
-
- <td width="118">
- 2.13.1, 
- 2.13.3
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- Long strings of digits in
- literals are a continuing problem in the production and
- maintenance of programs.
-
- <td width="536">
- 
- 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>
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 15
-
- <td width="118">
- 2.13.2
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- Inconsistency between definition of a
- multicharacter literal and a wide character literal
- containing multiple c-chars.
-
- <td width="536">
- Define the term
- multicharacter wide literal for a wchar_t literal
- containing multiple elements, and specify its type is
- integer (or wider)
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 16
-
- <td width="118">
- 2.13.2
-
- <td width="85">
- 3
-
- <td width="62">
- Ed
-
- <td width="514">
- Not immediately clear why the question mark
- needs escaping. A note would help.
-
- <td width="536">
- Add a note
- explaining that the ? character may need escaping to avoid
- accidentally creating a trigraph.<td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 2
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- 
- 1st para, 2nd line
-
- <td width="62">
- ed
-
- <td width="514">
- Typo, R"..." should be
- R"[...]"
-
- <td width="536">
- Correct typo.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 3
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- 2nd para<td width="62">
- te
-
- <td width="514">
- We think that the explanation of d-char-sequence is not
- enough.
-
- <td width="536">
- Add
- the following.
-
- <ol>
- <li>
- Add the
- following to the explanation of d-char-sequence, more
- easily to understand.
- </ol>
-
- ...prefix is a
- raw string literal.
-
- The
- d-char-sequence is used as delimiter.
-
- The terminating
- d-char-sequence of ...
-
- <ol start="2">
- <li>
- Add the
- following note that there are square brackets in
- r-char-sequence.
- </ol>
-
- [Note:
-
- char foo[] =
- R”delimiter[[a-z] specifies a range which
- matches any lowercase letter from "a" to
- "z".]delimiter”;
-
- 
-
- the expression
- statement behaves exactly the same as
-
- 
-
- char foo[]="[a-z]
- specifies a range which matches any lowercase letter from
- \"a\" to \"z\".";
-
- - end note]
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 4
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- 3rd para, 
- 1st line of
- example
-
- <td width="62">
- ed
-
- <td width="514">
- 
- Typo. Lack of a necessary backslash in the first line of
- the example as follows:
-
- 
- 
-
- 
- const char *p = R"[a
-
- b
-
- 
- c]";
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- const char *p = R"[a\
-
- b
-
- c]";
-
- <td width="536">
- Correct typo.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 21
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- ¶ 3
-
- <td width="62">
- ed
-
- <td width="514">
- The paragraph, marked as a Note, contains an embedded
- example not marked as such.
-
- <td width="536">
- Denote the code (and perhaps also its commentary) as an
- Example.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 22
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- ¶ 3
-
- <td width="62">
- te
-
- <td width="514">
- The code does not have the effect predicted by its
- accompanying narrative.
-
- <td width="536">
- Append a backslash to the first line of the code.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 5
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- 
- 11th para, Table 7
-
- <td width="62">
- te
-
- <td width="514">
- It is not explicit how to combine raw-string and
- non-raw-string.
-
- <td width="536">
- Add rules containing raw-string in the table 7.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 13
-
- <td width="118">
- 2.13.4 
- [lex.string]
-
- <td width="85">
- 3
-
- <td width="62">
- ed
-
- <td width="514">
- Shouldn't the assert be
-
- assert(std::strcmp(p, "a\nb\nc") == 0);
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 17
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- 10
-
- <td width="62">
- Te
-
- <td width="514">
- 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 conversion were remove (see other
- comments) then string literals 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.
-
- <td width="536">
- (asssuming deprecated conversion to
- non-const array is removed or can be turned off) Strike the
- sentence on undefined behaviour.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 18
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- 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 error
- message. There is no need to support arbitrary constant
- 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.
-
- <td width="536">
- Define a syntax to support string-ization
- of integral constant expressions in a form eligible for
- string literal concatenation, 2.13.4p6. Suggested syntax:
- 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 19
-
- <td width="118">
- 2.13.4
-
- <td width="85">
- 
-
- <td width="62">
- Ed
-
- <td width="514">
- The grammar for string literal is becoming
- unwieldy and could easily be refactored into the type
- optional specifier and the string contents.
-
- <td width="536">
- 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
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 14
-
- <td width="118">
- 3 [basic]
-
- <td width="85">
- 7
-
- <td width="62">
- ed
-
- <td width="514">
- "In general it is necessary to determine whether a name
- denotes one of these entities before parsing the program
- that contains it."
-
- <td width="536">
- 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 15
-
- <td width="118">
- 3 [basic]
-
- <td width="85">
- 8
-
- <td width="62">
- ed
-
- <td width="514">
- /operator-function-id/,
- /conversion-function-id/, /template-id/ are followed by a
- space and then a "s" while usually such production names
- aren't followed by a space when put in plural (see
- /identifier/).<td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 20
-
- <td width="118">
- 3
-
- <td width="85">
- 
-
- <td width="62">
- Ge
-
- <td width="514">
- 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.
-
- <td width="536">
- Change the title to "Basic definitions".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 21
-
- <td width="118">
- 3
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- Concepts is now the name of a specific
- feature of the language, the term now risks confusion and
- ambiguity when used in the more general sense.
-
- <td width="536">
- Rename the chapter Basic ???. THe note in
- p2 specifically needs similar rewording
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 22
-
- <td width="118">
- 3
-
- <td width="85">
- 6
-
- <td width="62">
- Te
-
- <td width="514">
- References are
- frequently considered variables, but this definition only
- applies to objects.
-
- <td width="536">
- Add "or reference" after both uses of
- "object"
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 23
-
- <td width="118">
- 3.1
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- 
- alias-declarations are not definitions and should be added
- to the list
-
- <td width="536">
- Add alias-declaration after typedef
- declaration.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 24
-
- <td width="118">
- 3.1
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- The current
- words suggest the declaration of a static integral constant
- data member of a class cannot be a definition. Trying to
- 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
-
- <td width="536">
- Add a footnote attached to the static data
- membmer rule: *static data member delcarations of intergral
- type may also be definitions if a constant integral
- expression is provided for an initializer.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 25
-
- <td width="118">
- 3.1
-
- <td width="85">
- 3
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- <td width="536">
- Remove the : s() from the illustrated
- default constructor: struct C { std::string s; C() { }
- C(const C& x): s(x.s) { } C& operator=(const C&
- x) { s = x.s; return *this; } ~C() { } };
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 26
-
- <td width="118">
- 3.2
-
- <td width="85">
- 1
-
- <td width="62">
- Te
-
- <td width="514">
- THe one
- definition rule should cover references, and unless the
- term 'variable' is extended to cover references the list in
- this paragraph is incomplete.<td width="536">
- Either include references in the definition
- of 'variable' (see earlier comment) or add reference to the
- list in this paragraph.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 27
-
- <td width="118">
- 3.2
-
- <td width="85">
- 4
-
- <td width="62">
- Ed
-
- <td width="514">
- A class type
- must be complete when catching exceptions, even by
- reference or pointer. See 15.3.
-
- <td width="536">
- Add "when used in an exception-handler
- (15.3)" to the list.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 16
-
- <td width="118">
- 3.3 
- [Declarative 
- regions and scopes.]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The scope of function
- parameters is defined, but what is the scope of template
- parameters?
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 28
-
- <td width="118">
- 3.3.1
-
- <td width="85">
- 3
-
- <td width="62">
- Te
-
- <td width="514">
- Class templates
- are not classes, so we should include this case.
-
- <td width="536">
- ammend "class" to "class or class template"
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK
-
- 29
-
- <td width="118">
- 3.3.10
-
- <td width="85">
- 3
-
- <td width="62">
- Te
-
- <td width="514">
- operators and conversion functions do not
- have names, yet are susceptible to 'name hiding' within a
- class - indeed we rely on this for the implicitly declared
- copy-assignment operator.
-
- <td width="536">
- Add the
- additional phrase "The declaration of an operator or
- conversion function in a derived class (Clause 10) hides
- the declaration of an operator or conversion function of a
- base class of the same operator or type;"
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 17
-
- <td width="118">
- 3.5 [Program 
- and linkage]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 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?
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 30
-
- <td width="118">
- 3.5
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- This paragraph implies concepts have no
- linkage (do they need it?) and that the entities behind
- names without linkage cannot be used in other scopes. This
- maybe a bigger problem for concept maps?
-
- <td width="536">
- Add a note to clarify that concepts don't
- need linkage.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 31
-
- <td width="118">
- 3.5
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- What is the linkage of names declared
- inside a namespace, in turn declared inside an anonymous
- namespace? It is not clear why such a namespace has no
- linkage, and there is no language suggesting its memmbers
- should lose linkage with it, which we assume is the
- intended consequence.
-
- <td width="536">
- Clarify rules for namespaces inside nested
- namespaces, or remove the restriction.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 23
-
- <td width="118">
- 3.5
-
- <td width="85">
- 6
-
- <td width="62">
- ed
-
- <td width="514">
- Bad
- paragraph break.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 18
-
- <td width="118">
- 3.5 
- [basic.link]
-
- <td width="85">
- 6
-
- <td width="62">
- ed
-
- <td width="514">
- The paragraph number is not aligned with the text.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 19
-
- <td width="118">
- 3.6 [Start 
- and 
- termination]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 32
-
- <td width="118">
- 3.6.1
-
- <td width="85">
- 3
-
- <td width="62">
- Te
-
- <td width="514">
- Do we really want to allow: constexpr int
- main() { return 0; } as a valid program?
-
- <td width="536">
- Add constexpr to
- the list of ill-formed things to annotate main 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 24
-
- <td width="118">
- 3.6.1
-
- <td width="85">
- 4
-
- <td width="62">
- te
-
- <td width="514">
- std::quick_exit is not
- referenced.
-
- <td width="536">
- 
- 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 25
-
- <td width="118">
- 3.6.3
-
- <td width="85">
- ¶ 2 last sent.
-
- <td width="62">
- ed
-
- <td width="514">
- The parenthesized phrase, introduced via
- “i.e.” is in the nature of an example.
-
- <td width="536">
- Change “i.e.” to “e.g.”
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 6
-
- <td width="118">
- 3.7.4.1
-
- <td width="85">
- 4th para, 
- 4th
- line
-
- <td width="62">
- ed
-
- <td width="514">
- 
- 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.
-
- 
- 
-
- [
- 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 ]
-
- 
- 
-
- should be
-
- 
- 
-
- [
- 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 ]
-
- 
-
- <td width="536">
- Correct typo.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-3
-
- <td width="118">
- 3.7.4.3
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- DE-3 It is
- unclear whether the following code has well-defined
- behavior; none of the bullets in the second paragraph seem
- to apply.
-
- int& i =
- *new int(5);
-
- delete &i;
-
- <td width="536">
- Clarify that &i is considered a safely-derived
- pointer value.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 26
-
- <td width="118">
- 3.8
-
- <td width="85">
- 1 and 5
-
- <td width="62">
- te
-
- <td width="514">
- Use of object fields during
- destruction is excessively and erroneously constrained.
-
- <td width="536">
- See
- the attached document "Issues with the C++ Standard" under
- Chapter 3 "Use of objects, especially from other threads,
- during destruction".
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 27
-
- <td width="118">
- 3.9
-
- <td width="85">
- ¶ 9 first sent.
-
- <td width="62">
- ed
-
- <td width="514">
- There is a superfluous/extraneous “and”.
-
- <td width="536">
- Delete “and” from the phrase “and
- std::nullptr_t”.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 20
-
- <td width="118">
- 3.9 [Types]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The phrase 'effective type'
- is defined and used in a way that is incompatible with C99.
- Such a deliberate incompatible choice of terminology is
- 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.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 7
-
- <td width="118">
- 3.9.2
-
- <td width="85">
- 3rd para, 
- 13th
- line
-
- <td width="62">
- ed
-
- <td width="514">
- over-aligned type was added as new notion. So it is
- preferable to add the link after that.
-
- <td width="536">
- 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 functions.
- An implementation may provide other means of obtaining a
- valid pointer value for an over-aligned type(3.11).—end note ]
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 28
-
- <td width="118">
- 3.9.3
-
- <td width="85">
- ¶ 5 first sent.
-
- <td width="62">
- ed
-
- <td width="514">
- The closing
- braces of the first two sets are preceded by extraneous
- space.
-
- <td width="536">
- Delete the extra spaces.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE 4
-
- <td width="118">
- 4.2
-
- <td width="85">
- p2
-
- <td width="62">
- te
-
- <td width="514">
- DE-4 The deprecated conversion from string literals to
- pointer to non-const character types should be limited to
- those conversions and types of string literals that were
- already present in ISO/IEC 14882:2003, or the deprecated
- conversions should be removed entirely.
-
- <td width="536">
- 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- CH 1
-
- <td width="118">
- 4.9 and 5.2.9
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- With respect to the target type, pointer to members
- should behave like normal pointers (least surprise
- principle).
-
- <td width="536">
- 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-5
-
- <td width="118">
- 4.11, 
- 5.3.1, 
- 5.5
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- DE-5 Ref-qualification has not been integrated with
- pointer-to-members.
-
- <td width="536">
- Review implicit
- conversions (4.11), forming pointer-to-members (5.3.1), and
- dereferencing pointer-to-members (5.5) for type-safety
- concerns in the presence of ref-qualifiers on the member.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 33
-
- <td width="118">
- 4.13
-
- <td width="85">
- 1
-
- <td width="62">
- Te
-
- <td width="514">
- We have: "No two signed integer types shall
- have the same rank ..." "the rank of char shall equal the
- rank of signed char" Can we therefore deduce that char may
- not be signed?
-
- <td width="536">
- Replace the
- first sentence with "No two signed integer types shall have
- the same rank, even if they have the same representation,
- except that signed char shall have the same rank as char
- even if char is signed (3.9.1/1)."
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 34
-
- <td width="118">
- 4.13
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- 6th bullet, "the
- rank of char" - first letter should be capitalised for
- consistency with the other bullets
-
- <td width="536">
- The rank of char
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 36
-
- <td width="118">
- 5.1
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- Primary
- expressions are literals, names, names qualified by the
- scope resolution operator ::, and lambda expressions. The
- immediately following grammar flatly contradicts this -
- this and (e) are also lambda expressions.<td width="536">
- Delete this paragraph.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 37
-
- <td width="118">
- 5.1
-
- <td width="85">
- 11
-
- <td width="62">
- Ed
-
- <td width="514">
- Member function
- templates are not member functions, so should also be
- listed in the 3rd bullet
-
- <td width="536">
- Add member function templates to the 3rd
- bullet
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 38
-
- <td width="118">
- 5.1
-
- <td width="85">
- 3
-
- <td width="62">
- Te
-
- <td width="514">
- this might be useful in a few more places
- than it is permitted, specifically in decltype expressions
- within a class. Two examples that would be ill-formed at
- class scope without changes: typedef decltype( *this )
- this_type; decltype( [this]{ return this->memfun(); } )
- my_lambda;
-
- <td width="536">
- ... words to follow ...
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 8
-
- <td width="118">
- 5.1
-
- <td width="85">
- 7th para, Syntax rules
-
- <td width="62">
- te
-
- <td width="514">
- 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 width="536">
- 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 ::
-
- 
- nested-name-specifieropt concept-id ::
-
- decltype (
- expression ) ::
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 9
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- It
- would be preferable that “&&” could be
- specified in a lambda expression to declare move capture.
-
- 
- 
-
- 
- 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 width="536">
- Add
- move capture in a lambda expression.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 10
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 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.
-
- 
- 
-
- 
- template <class F>
-
- 
- void foo(F f)
-
- {
-
- 
- typedef std::result_of<F()>::type result; // error
-
- }
-
- 
- foo([]{});
-
- 
- 
-
- 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.
-
- <td width="536">
- Add
- result_type to the syntax of an unnamed function object
- generated by a lambda expression.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 29
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The
- standard does not state whether or not direct recursion of
- lambdas is possible.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 30
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 
- 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?
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 31
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 
- 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.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 45
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- para 2
-
- <td width="62">
- Te
-
- <td width="514">
- Lambda is a language feature with an
- apparent dependency on <functional>. This increases
- dependency of language on library, and is inconsistent with
- the definition of freestanding in 17.6.2.4.
-
- <td width="536">
- Change the text
- "a closure object behaves as a function object" to "a
- closure object is a built-in object which behaves as a
- function object"; and after "context.", insert " A closure
- object may be used without any need for
- <functional>." This makes clear what may already be
- implied, 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).
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US
- 32
-
- 
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 3
-
- <td width="62">
- ed
-
- <td width="514">
- The
- final italic "this" in the paragraph should be a teletype
- "this".
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 39
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 11
-
- <td width="62">
- Te
-
- <td width="514">
- This paragraph lists all the special member
- functions for the class representing a lambda. But it omits
- the destructor, which is awkward.
-
- <td width="536">
- Add "F has an implicitly-declared
- destructor".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 40
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 12
-
- <td width="62">
- Te
-
- <td width="514">
- If one or more
- names in the effective capture set are preceded by &,
- the effect of invoking a closure object or a copy after the
- innermost block scope of the context of the lambda
- expression has been exited is undefined. That is too
- restrictive. The behaviour should be undefined iff the
- lifetime of any of the 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();
-
- <td width="536">
- If one or more names in the effective
- capture set are preceded by &, the effect of invoking a
- closure object or a copy after the lifetime of any of the
- variables referenced has ended is undefined.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 41
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 12
-
- <td width="62">
- Te
-
- <td width="514">
- For argument dependant lookup (3.4.2) the
- associated namespaces for a class include its bases, and
- associated namespaces of its bases. Requiring the result of
- 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.
-
- <td width="536">
- Replace inheritance with implicit
- conversion.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 42
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- A lambda with an empty capture list has
- identical semantics to a regular function type. By
- requiring this mapping we get an efficient lambda type with
- a known API that is also compatible with existing operating
- system and C library functions.
-
- <td width="536">
- 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
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 43
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 12
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- ... provvide exceptions in the right places
- ...
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 44
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 12
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Extend reference_closure requirement to
- cover [this] lambdas. Consider a simple syntax for creating
- such bound expressions.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 46
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- para 12
-
- <td width="62">
- Te
-
- <td width="514">
- 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++.
-
- <td width="536">
- 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>.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-6
-
- <td width="118">
- 5.1.1, 20.7.18
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- DE-6 Some uses of lambda expressions refer to
- specializations of the unconstrained class template
- std::reference_closure (5.1.1). If the lambda expression
- 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.
-
- <td width="536">
- In 20.7.18, for the class template
- std::reference_closure, require Returnable for R and
- VariableType for each of the ArgTypes.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-7
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- p10
-
- <td width="62">
- ed
-
- <td width="514">
- DE-7 The note at the end of paragraph 10 appears to be
- garbled.
-
- <td width="536">
- Remove "or references" in the note.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-8
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- p10
-
- <td width="62">
- te
-
- <td width="514">
- DE-8 The construction of the function call operator
- signature is missing specifications for the ref-qualifier
- and the attribute-specifier.
-
- <td width="536">
- Add bullets that say that the ref-qualifier and the
- attribute-specifier are absent.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 33
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 11
-
- <td width="62">
- Ge
-
- <td width="514">
- There is no definition of “move constructor”
- or “move operation”
-
- <td width="536">
- Since this is
- the first place the terms are used, a definition should
- either be added here, or a cross reference to one.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-9
-
- <td width="118">
- 5.1.1
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- DE-9 There is not a single example of a
- lambda-expression in the standard. See also core issue 720
- in WG21 document N2791 "C++ Standard Core Language Active
- Issues, Revision 59", available at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
- .
-
- <td width="536">
- Add a few well-chosen examples.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 52
-
- <td width="118">
- 5.2
-
- <td width="85">
- 3
-
- <td width="62">
- Ed
-
- <td width="514">
- This paragraph seens out of place,
- assignment expressions are covered in 5.17
-
- <td width="536">
- Move p3 to subsection 5.17
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 53
-
- <td width="118">
- 5.2.1
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- The definition in p1 makes no allowance for
- overloaded operator[] that treats the expression as a
- simple function call, and does not support the
- interchangability of arguments. Howver p2 relies on this
- definition when describing the use of brace-init-lists
- inside [].
-
- <td width="536">
- Insert a new p2 describing the changed
- semantics for overloaded operator[]. This should be a note
- to avoid introducing normative text that could potentially
- conflict with the later definiton of these semantics.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 59
-
- <td width="118">
- 5.2.2
-
- <td width="85">
- 7
-
- <td width="62">
- Te
-
- <td width="514">
- When there is no parameter for a given
- argument, the argument is passed in such a way that the
- receiving function can obtain the value of the argument by
- invoking va_arg. That shouldn't apply to parameter packs.
- template <class ... Types> void f(Types ... pack);
- f(1, 2, 3);
-
- <td width="536">
- Clarify that this sentence only applies
- where the ellipsis is used.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 60
-
- <td width="118">
- 5.2.5
-
- <td width="85">
- 3
-
- <td width="62">
- Ed
-
- <td width="514">
- In the remainder of 5.2.5, cq represents
- either const or the absence of const vq represents either
- volatile or the absence of volatile.
-
- <td width="536">
- Add "and" before vq
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 61
-
- <td width="118">
- 5.2.5
-
- <td width="85">
- p1
-
- <td width="62">
- Ed
-
- <td width="514">
- Together with footnote 60 there may be
- confusion that the postfix expression is always evaluated -
- even when part of an unevaluated operand. We believe the
- standard does not require this, and a comment in the
- existing note would be a useful clarification.
-
- <td width="536">
- Clarify in footnote 60 that this will not
- happen if the whole expression is an unevaluated operand.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 62
-
- <td width="118">
- 5.2.5
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- In the final bullet, what does 'not an
- lvalue' mean? Does it imply rvalue, or are there other
- possible meanings? Should clauses that trigger on rvalues
- pick up on this?
-
- <td width="536">
- Replace 'not an lvalue' with 'is an
- rvalue'.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-10
-
- <td width="118">
- 5.2.5
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- DE-10 If E1.E2 is referring to a non-static member
- function, the potential ref-qualification on E2 should be
- taken into account.
-
- <td width="536">
- Adjust the presentation of the types involved as
- appropriate.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 63
-
- <td width="118">
- 5.2.6
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- Paragraph 2 is missing its number.
-
- <td width="536">
- Add one.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 64
-
- <td width="118">
- 5.2.7
-
- <td width="85">
- 3
-
- <td width="62">
- Ed
-
- <td width="514">
- A new name R is introduced for use in
- paragraphs 3 and 4. But R is the same as T.
-
- <td width="536">
- Replace R with T
- and replace "the required result type (which, for
- convenience, will be called R in this description)" with
- "T".
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 65
-
- <td width="118">
- 5.2.7
-
- <td width="85">
- 8
-
- <td width="62">
- Te
-
- <td width="514">
- In the first two
- bullets we have "the result is a pointer (an lvalue
- referring) to". But para 2 makes clear that a dynamic_cast
- of an rvalue references produces a rvalue. (Can an lvalue
- refer to anything anyway?)
-
- 
-
- <td width="536">
- Replace "an lvalue referring to" with
- "reference", twice.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 66
-
- <td width="118">
- 5.2.8
-
- <td width="85">
- 1
-
- <td width="62">
- Te
-
- <td width="514">
- typeid may
- return "an implementation-defined class derived from std ::
- type_info". The derivation must be public.
-
- 
-
- <td width="536">
- an implementation-defined class publicly
- derived from std :: type_info
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 67
-
- <td width="118">
- 5.2.9
-
- <td width="85">
- 1, 2, 3
-
- <td width="62">
- Te
-
- <td width="514">
- Paragraph 1 specifies when the result of
- static_cast is an lvalue; repeating it is unnecessary.
-
- <td width="536">
- In para 2,
- delete "It is an lvalue if the type cast to is an lvalue
- reference; otherwise, it is an rvalue." and "The result is
- 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."
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 54
-
- <td width="118">
- 5.2.10
-
- <td width="85">
- 3, 6
-
- <td width="62">
- Te
-
- <td width="514">
- Para 3: "The mapping performed by
- reinterpret_cast is implementation-defined.". Para 6: "...
- the result of such a pointer conversion is unspecified."
- Which is it?
-
- <td width="536">
- In para 6,
- replace unspecified with implementation-defined.
- Alternatively, delete paragraph 3, since individual cases
- are labelled appropriately.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 55
-
- <td width="118">
- 5.2.10
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- dynamic_cast and reinterpret_cast
- crossreference 5.2.11 without creating an extra note. The
- second half of the note is unrelated to the crossrefernce,
- and would serve as well in normative text.
-
- <td width="536">
- 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.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 56
-
- <td width="118">
- 5.2.10
-
- <td width="85">
- 5
-
- <td width="62">
- Ed
-
- <td width="514">
- The notion of
- safely derived pointers means this conversion may not be as
- safe in the revised standard as the original. It would be
- good to call attention to the changed semantics with a
- note.
-
- 
-
- <td width="536">
- Add: [Note: the result of such a conversion
- will not be a safely-derived pointer value (3.7.4.3) -- end
- note]
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 57
-
- <td width="118">
- 5.2.10
-
- <td width="85">
- 8
-
- <td width="62">
- Ed
-
- <td width="514">
- Conditionally supported behaviour gives a
- wide range or permission, so clarify relationship between
- safely-derived object pointers and function pointers in a
- note.
-
- <td width="536">
- Add: [Note: In such cases, the
- implementation shall also define whether a safely-derived
- object pointer cast to a function pointer can be safely
- cast back -- end note]
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 58
-
- <td width="118">
- 5.2.11
-
- <td width="85">
- 9
-
- <td width="62">
- Te
-
- <td width="514">
- Casting from an
- lvalue of type T1 to an lvalue of type T2 using a reference
- cast casts away constness if a cast from an rvalue of type
- “pointer to T1” to the type “pointer to
- T2” casts away constness. That doesn't cover rvalue
- references.
-
- 
-
- <td width="536">
- Replace lvalue with "lvalue or rvalue"
- twice.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US
- 34
-
- 
-
- <td width="118">
- 5.3
-
- <td width="85">
- 1
-
- <td width="62">
- ed
-
- <td width="514">
- The list of unary operator
- should be in teletype font.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 68
-
- <td width="118">
- 5.3.1
-
- <td width="85">
- 2-9
-
- <td width="62">
- Te
-
- <td width="514">
- All the unary operands other than * return
- rvalues - but this is not stated.
-
- <td width="536">
- Add a paragraph
- 1a "The following unary operators all produce results that
- are rvalues."
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 69
-
- <td width="118">
- 5.3.1
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- If we cannot
- bind references/take address of functions in concept_maps,
- does that mean we cannot use generic bind in constrained
- templates? Launch threads with expressions found via
- concept map lookup? Hit problems creating std::function
- objects? Does the problem only occur if we use qualified
- lookup to 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?!
-
- 
-
- <td width="536">
- ... unknown ...
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 70
-
- <td width="118">
- 5.3.3
-
- <td width="85">
- 1
-
- <td width="62">
- Te
-
- <td width="514">
- 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).
-
- 
-
- <td width="536">
- Change "an enumeration type" to "an
- enumeration type whose underlying type is not fixed".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 71
-
- <td width="118">
- 5.3.4
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- The type of an allocated object wih the
- type specifier auto is determined by the rules of copy
- initialization, but the initialization applied will be
- 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.
-
- <td width="536">
- Replace T x = e; with T x(e);
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 72
-
- <td width="118">
- 5.3.4
-
- <td width="85">
- 7
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Throw std::bad_alloc instead of
- std::length_error.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 73
-
- <td width="118">
- 5.3.4
-
- <td width="85">
- 6
-
- <td width="62">
- Ed
-
- <td width="514">
- A class type
- with conversion operator can only be used if the conversion
- type is constexpr and the class is a literal type. Adding
- the single word 'literal' before class type will clarify
- this.
-
- 
-
- <td width="536">
- Add 'literal' before 'class type'
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 74
-
- <td width="118">
- 5.3.4
-
- <td width="85">
- 8
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Change "the allocation function’s
- name is operator new" to "the allocation function is named
- operator new" and similarly for operator delete.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 35
-
- <td width="118">
- 5.3.4
-
- <td width="85">
- 9
-
- <td width="62">
- Ed
-
- <td width="514">
- Missing period in middle of paragraph
- between "in the scope of T" and "If this lookup fails"
-
- <td width="536">
- Add a period
- between "in the scope of T" and "If this lookup fails"
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 75
-
- <td width="118">
- 5.3.5
-
- <td width="85">
- 8
-
- <td width="62">
- Ed
-
- <td width="514">
- A paragraph
- strarting with [Note... is easily skipped when reading,
- missing the normative text at the end.
-
- 
-
- <td width="536">
- Swap order of the note and normative text.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 21
-
- <td width="118">
- 5.3.6 
- [Alignof
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- Should not the type of alignof-expression be of type
- std::max_align_t?
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 35
-
- <td width="118">
- 5.8
-
- <td width="85">
- 2 and 3
-
- <td width="62">
- ed
-
- <td width="514">
- 
- There is curious spacing in the expressions "E1 <<E2"
- and "E1 >>E2". This is a formatting change since
- previous versions of the Standard.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 47
-
- <td width="118">
- 5.14 / 5.15
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Pick one form of wording as 'the best' and
- apply it in both places.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 48
-
- <td width="118">
- 5.18
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Add: [Note: There are no guarantees on the
- order of value computation for an overloaded comma operator
- -- end note]
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 49
-
- <td width="118">
- 5.19
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- Is an implementation permitted to reject
- this? constexpr int f() { return f(); } int a[f()]; AFAICT
- it is well-formed; f() seems to satisfy all the rules to
- make it a constant expression. I would hate compilation to
- become a potentially non-terminating experience.
-
- <td width="536">
- 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.)
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 50
-
- <td width="118">
- 5.19
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- The following should be valid: enum E { foo
- = 4}; const E c = foo; int a[c]; But currently it is not -
- c is not an lvalue of effective integral type (4th bullet).
- (See also 7.1.6.1/2)
-
- <td width="536">
- Change
- "effective integral type" to "effective integral or
- enumeration type" in the 4th bullet, 1st sub-bullet.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 51
-
- <td width="118">
- 5.19
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Strike the words "whose operand is of a
- polymorphic class type" on the bullet for typeid
- expressions.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 76
-
- <td width="118">
- 6.3
-
- <td width="85">
- 
-
- <td width="62">
- Ed
-
- <td width="514">
- Do we really need two different terms that
- say the same thing?
-
- <td width="536">
- Pick either
- 'block' or 'compound statement' as the preferred term and
- use it consistently throughout the standard.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 22
-
- <td width="118">
- 6.4.2 
- [The switch 
- statement]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The constant-expression in
-
- 
-
- case constant-expression
-
- 
-
- 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.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 77
-
- <td width="118">
- 6.5
-
- <td width="85">
- 5
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Profide a cross-reference for the terms:
- i/o operation, synchronize operation and atomic operation
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 11
-
- <td width="118">
- 6.5.4
-
- <td width="85">
- 1st para, 
- 5th
- line
-
- <td width="62">
- ed
-
- <td width="514">
- There is no _RangeT type in the equivalent code to
- “range-base for” statement. It existed in
- N2049.
-
- <td width="536">
- Add
- a typedef for _RangeT in the example as follows:
-
- 
- 
-
- {
-
- 
-     typedef decltype( expression )
- _RangeT;
-
- 
-     auto && __range = ( expression
- );
-
- 
-     for ( auto __begin =
- std::Range<_RangeT>:: begin(__range),
-
- 
-          
-   __end = std::Range<_RangeT>:: end(__range);
-
- 
-          
- __begin != __end;
-
- 
-          
- ++__begin )
-
- 
-     {
-
- 
-        
- for-range-declaration = *__begin;
-
- 
-         statement
-
- 
-     }
-
- }
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 78
-
- <td width="118">
- 6.5.4
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- Including the header
- <iterator_concepts> is far too unwieldy to enable an
- important and (expected to be) frequently used syntax.
-
- <td width="536">
- 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.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 79
-
- <td width="118">
- 6.5.4
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- When expression is an array a of length N
- whose length is known at compile time, expand range-for as
- 'for (... p=a, p!=a+N, p++) ...' without requiring the
- Range concept or <iterator_concepts>. Also, when
- expression is an initializer_list, expand range-for
- similarly without requiring <iterator_concepts>.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-11
-
- <td width="118">
- 6.9
-
- <td width="85">
- p1
-
- <td width="62">
- te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- State that such a late-checked block has the same
- meaning as if the late_check keyword were absent.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 80
-
- <td width="118">
- 7
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- 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
- inaccurate. This may not matter, but I feel the document
- would be 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.
-
- 
-
- <td width="536">
- Strike the first sentence.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 81
-
- <td width="118">
- 7
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- String literal
- concatenation happens in phase 6, before parsing, so it is
- legal and useful to use it for the string literal in a
- static_assert. It would be useful to add a note mentioning
- this.
-
- 
-
- <td width="536">
- Add a note: Multiple adjacent string
- literals may be used instead of a single /string-literal/;
- see [lex.phases].
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 82
-
- <td width="118">
- 7
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- 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."
-
- 
-
- <td width="536">
- Add "scoped enumeration" to the list in the
- second sentence.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 83
-
- <td width="118">
- 7.1
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- The longest
- sequence of decl-specifiers that could possibly be a type
- name is taken as the decl-specifier-seq of a declaration.
- But many sequences of decl-specifiers cannot possibly be a
- type name - eg the sequence "friend int", or "typedef int".
-
- 
-
- <td width="536">
- Not sure. I understand the rule, just not
- how to say it.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 84
-
- <td width="118">
- 7.1
-
- <td width="85">
- 1
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Delete the production (including the
- duplicate in A6)
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FI 3
-
- <td width="118">
- 7.1
-
- <td width="85">
- [dcl. 
- spec. 
- auto]
-
- <td width="62">
- te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- See restricted-auto.ppt
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 85
-
- <td width="118">
- 7.1.1
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- ... 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.").
-
- 
-
- <td width="536">
- Replace "global" with "namespace scope".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 86
-
- <td width="118">
- 7.1.1
-
- <td width="85">
- 2,3
-
- <td width="62">
- Te
-
- <td width="514">
- The register
- keyword serves very little function, offering no more than
- a hint that a note says is typically ignored. It should be
- 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.
-
- 
-
- <td width="536">
- Deprecate current usage of the register
- keyword.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 87
-
- <td width="118">
- 7.1.1
-
- <td width="85">
- 1, 4, 5
-
- <td width="62">
- Te
-
- <td width="514">
- Why require two
- keywords, where one on its own becomes ill-formed?
- thread_local should imply 'static' in this case, and the
- combination of keywords should be banned rather than
- required. This would also eliminate the one of two
- exceptions documented in 7.1.1p1.
-
- 
-
- <td width="536">
- Drop requirement to combine static keyword
- with thread_local at block-scope inside a function
- definition.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 36
-
- <td width="118">
- 7.1.1
-
- <td width="85">
- 4
-
- <td width="62">
- te
-
- <td width="514">
- The
- permission to use thread_local static data members is
- missing.
-
- 
-
- <td width="536">
- Add the static members as a
- permitted use.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 23
-
- <td width="118">
- 7.1.5 
- [constexpr]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 'constexpr' functions should
- be allowed to take const reference parameters, as long as
- their uses are in a context where a constant expression may
- be required. For example, the following should be allowed
-
- 
-
- template<typename T, int
- N>
-
- int size(const T(&)[N]) {
- return N; }
-
- 
-
- int a[] = { 41,42,43,44 };
-
- enum { v = size(a) };
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 12
-
- <td width="118">
- 7.1.5
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- It should be
- allowed to define constexpr recursively.
-
- 
- There is an explanation in N2235, Generalized Constant
- Expressions—Revision 5, as follows.
-
- 
- 
-
- 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.
-
- 
- 
-
- 
- Then, here are the use cases where allowing recursion for
- constexpr is very useful.
-
- 
- 
-
- 
- 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 recursively. As a side effect is not allowed in
- compile-time, it 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.
-
- 
- 
-
- 
- 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.
-
- 
- 
-
- 
- 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.
-
- 
- 
-
- 
- 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.
-
- 
- 
-
- -
- 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...
-
- 
- 
-
- <td width="536">
- 
- Allow constexpr recursion.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 37
-
- <td width="118">
- 7.1.6.1
-
- <td width="85">
- 1
-
- <td width="62">
- ed
-
- <td width="514">
- 
- There is a "Note: 3.9.3 describes how cv-qualifiers affect
- object and function types." So far as I can see, 3.9.3
- CV-qualifiers only describes cv-qualifiers for objects,
- cv-qualifiers for (member) functions being described in
- 8.3.5 Functions.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 89
-
- <td width="118">
- 7.1.6.1
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- 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
- unless it is explicitly declared extern or unless it was
- previously declared to have external linkage.". This nearly
- repeats 7.1.1/7: "Objects declared const and not explicitly
- declared extern have internal linkage." The former seems to
- allow more wiggle room - can an object be "previously
- declared to have external linkage" without having been
- "explicitly declared extern"? 2. "A variable of
- non-volatile const-qualified integral or enumeration type
- initialized by an integral constant expression can be used
- in integral constant expressions (5.19)." This nearly
- duplicates 5.19/2, bullet 4, 1st sub-bullet - "[... an
- integaral constant expression can use] an lvalue of
- effective integral type that refers to a non-volatile const
- variable or static data member 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.
-
- 
-
- <td width="536">
- Make the normative text in this section
- into one or more notes, with cross references, and correct
- the referenced text if necessary.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 90
-
- <td width="118">
- 7.1.6.2
-
- <td width="85">
- para 1 and table 9
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Add a row to table 9 mentioning
- simple-template-id and punting to clause 14 (cf
- decltype(expression)).
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 91
-
- <td width="118">
- 7.1.6.2
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- 5.1/5 says "[A]
- parenthesized expression can be used in exactly the same
- contexts as those where the enclosed expression can be
- used, and with the same meaning, except as otherwise
- indicated." When the first bullet point of this paragraph,
- describing the type denoted by decltype(e), says "if e is
- an id-expression ... decltype(e) is the type of the entity
- named by e", 5.1/5 is not excluded, which would imply that
- decltype((e)) was also the type of e. But the intention
- appears that it should be 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.
-
- 
-
- <td width="536">
- Insert "unparenthised" in the first bullet
- point - "if e is an *unparenthised* id-expression ...". In
- the second bullet point, move "(parentheses around e are
- ignored)" into a note.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 92
-
- <td width="118">
- 7.1.6.3
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Either strike the note or add reference to
- 11.4/3 and/or mention of "friend T;".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 93
-
- <td width="118">
- 7.1.6.3
-
- <td width="85">
- Grammar before para 1
-
- <td width="62">
- Ed
-
- <td width="514">
- In the third
- production, "enum ::opt nested-name-specifieropt
- identifier", enum should not be in italics; its referring
- to the enum keyword.
-
- 
-
- <td width="536">
- Change to keyword font
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 94
-
- <td width="118">
- 7.1.6.4
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- The auto type-specifier signifies that the
- type of an object being declared shall be deduced from its
- initializer or specified explicitly at the end of a
- function declarator. A function declarator does not declare
- an object.
-
- <td width="536">
- 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.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 95
-
- <td width="118">
- 7.1.6.4
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- (See also
- c++std-core-13583) This paragraph allows auto "in the
- type-specifier-seq in a new-type-id (5.3.4)" (and nowhere
- else not listed). Specifically, it isn't allowed in a
- type-id in a new-expression. That allows "new auto (42)",
- but not "new (auto)(42)". However, 5.3.4/2 suggests the
- latter should be 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.
-
- 
-
- <td width="536">
- Change "in a new-type-id" to "in a
- new-type-id or type-id in a new-expression".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 24
-
- <td width="118">
- 7.1.6.4 
- [auto 
- specifier]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- Now that 'auto' is finally
- used in its most obvious sense to state `deduce the type of
- this variable from initializer', it should also be allowed
- in template parameter declarations, as in
-
- 
-
- template<auto n> struct
- X { /* … */ };
-
- 
-
- X<903> x;
-
- 
-
- 
- X<&Widget::callback> y;
-
- 
-
- 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;
-
- 
-
- 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.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 38
-
- <td width="118">
- 7.2
-
- <td width="85">
- 1
-
- <td width="62">
- ed
-
- <td width="514">
- The
- discussion of attribute specifiers should be a separate
- paragraph.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 39
-
- <td width="118">
- 7.2
-
- <td width="85">
- 2
-
- <td width="62">
- te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- As this implication leaves no
- representation, it should be either affirmed here or the
- statement should be expanded. Perhaps a note is warranted.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 13
-
- <td width="118">
- 7.2
-
- <td width="85">
- para 3
-
- <td width="62">
- ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Replace the description, "same underlying type", with
- "same as underlying type of (previous) declaration."
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 96
-
- <td width="118">
- 7.2
-
- <td width="85">
- 7
-
- <td width="62">
- Te
-
- <td width="514">
- enum E { }; What
- are the values of E? It has neither a smallest nor largest
- enumerator, so paragraph 7 doesn't help. (Paragraph 6
- 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.)
-
- 
-
- <td width="536">
- Add a second sentence to paragraph 7
- (before "Otherwise"): "If the enumerator-list is empty, 0
- is the only value of the enumeration."
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 97
-
- <td width="118">
- 7.2
-
- <td width="85">
- 9
-
- <td width="62">
- Ed
-
- <td width="514">
- Missing
- punctuation after "blue" in: "The possible values of an
- object of type color are red, yellow, green, blue these
- values can be converted ..."
-
- 
-
- <td width="536">
- Add a semicolon: "The possible values of an
- object of type color are red, yellow, green, blue; these
- values can be converted ..."
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 98
-
- <td width="118">
- 7.2
-
- <td width="85">
- 5
-
- <td width="62">
- Te
-
- <td width="514">
- It would be
- useful to be able to determine the underlying type of an
- arbitrary enumeration type. This would allow safe casting
- 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.
-
- 
-
- <td width="536">
- Add a TransformationTrait to 20.5.6 that
- returns the underlying type of an enumeration type.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 99
-
- <td width="118">
- 7.2
-
- <td width="85">
- 3
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Move "an enumeration declared by an
- opaque-enum-declaration ... is a complete type" from the
- note to normative text.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 14
-
- <td width="118">
- 7.3.1
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 
- The description of the behavior when a member that was
- defined with same name in other namespace was referred.
-
- 
- - It seems that the behavior of the following case is not
- defined. So we think that it is necessary to define that.
-
- namespace Q {
-
- inline namespace
- V {
-
- int g;
-
- }
-
- int g;
-
- }
-
- 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.
-
- namespace Q {
-
- inline namespace
- V1{
-
- int g;
-
- }
-
- inline namespace
- V2{
-
- int g;
-
- }
-
- }
-
- Q::g
- =1;//ill-formed
-
- 
- 
-
- <td width="536">
- 
- Add the description of the behavior when a member that was
- defined with same name in other namespace was referred.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 100
-
- <td width="118">
- 7.3.3
-
- <td width="85">
- 10 and 13
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Delete para 10, moving its example into
- para 13.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 101
-
- <td width="118">
- 7.3.3
-
- <td width="85">
- 20
-
- <td width="62">
- Te
-
- <td width="514">
- 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.)
-
- 
-
- <td width="536">
- Allow typename for non-dependent names iff
- they refer to a type.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-12
-
- <td width="118">
- 7.3.3
-
- <td width="85">
- p15
-
- <td width="62">
- te
-
- <td width="514">
- DE-12
- Overriding and hiding of member functions named in
- using-declarations should consider ref-qualifiers, because
- they are part of the function type.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 25
-
- <td width="118">
- 7.3.3 
- [The using 
- declaration]
-
- <td width="85">
- Para 21
-
- <td width="62">
- te
-
- <td width="514">
- The syntax for concept map alias is unnecessarily both
- confused and verbose.
-
- <td width="536">
- 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.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 102
-
- <td width="118">
- 7.3.4
-
- <td width="85">
- 6
-
- <td width="62">
- Ed
-
- <td width="514">
- This paragraph
- says "If name lookup finds a declaration for a name in two
- different namespaces, and the declarations do not declare
- 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.
-
- 
-
- <td width="536">
- Move the example to paragraph 7, and/or
- replace it with an appropriate example.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 40
-
- <td width="118">
- 7.6
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Add the attribute.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 41
-
- <td width="118">
- 7.6
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- A
- common problem is unintentionally declaring a new virtual
- member function instead of overriding a base virtual member
- function.
-
- 
-
- <td width="536">
- An attribute stating intent to
- override would enable better diagnostics.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 26
-
- <td width="118">
- 7.6 [Attributes]
-
- <td width="85">
- 
-
- <td width="62">
- ed
-
- <td width="514">
- Are they part of object types
- or not? The section does not appear to indicate that
- clearly.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FI 1
-
- <td width="118">
- 7.6
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- Add override-attribute for functions in order to avoid
- mistakes when overriding functions.
-
- <td width="536">
- See override-attribute.doc, override-attribute.ppt
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 27
-
- <td width="118">
- 7.6.1
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- This section specifies that
- no name lookup is performed on any identifier contained in
- an attribute-token. This in particular implies that, for
- 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 contradictory with the rest of that section --
- since no name lookup is performed, how a 'type-id'is
- determined?
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 103
-
- <td width="118">
- 7.6.1
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- <td width="536">
- Add: attribute... to the grammar for
- attribute-list Add to list in 14.5.3p4: "In an
- attribute-list(7.6.1); the pattern is an attribute."
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 104
-
- <td width="118">
- 7.6.1
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- It is helpful
- for each subclause to contain a short paragraph introducing
- its intent an purpose. 7.6 has such a paragraph, but it is
- nested under a more specific subsection.
-
- 
-
- <td width="536">
- 7.6.1p1 should move up one level to become
- 7.6p1. There grammar should remain under 7.6.1
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 105
-
- <td width="118">
- 7.6.1
-
- <td width="85">
- 1
-
- <td width="62">
- Te
-
- <td width="514">
- Allowing only one level of namespaces in
- attributes seems unnecessarily limiting.
-
- <td width="536">
- To: attribute-scoped-token:
- attribute-namespace :: identifier add attribute-namespace
- :: attribute-scoped-token
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 106
-
- <td width="118">
- 7.6.2
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- Extensive use of
- alignment and related terms without cross reference.
-
- 
-
- <td width="536">
- Add cross-reference to 3.11.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 15
-
- <td width="118">
- 7.6.2
-
- <td width="85">
- 
-
- <td width="62">
- ed
-
- <td width="514">
- An abbreviation
- of 7.6.2 should be “[decl.attr.align]” instead
- of “[dcl.align]”. 
- Section name “[dcl.align]” is not consistent
- with others, because others in 7.6 are the form of
- “dcl.attr.*”. In N2761, the section name of
- 7.1.7 had 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.
-
- 
-
- <td width="536">
- Change "[dcl.align]" of 7.6.2 to "[decl.attr.align]".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 107
-
- <td width="118">
- 7.6.3
-
- <td width="85">
- 
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Adda a [Note : implementations are
- encouraged to issue a diagnostic where the definition of a
- function marked [[noreturn]] might execute a return
- statement -- end note]
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 108
-
- <td width="118">
- 7.6.4
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Strike "no diagnostic required" and the
- associated footnote.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 42
-
- <td width="118">
- 7.6.4
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The
- meaning of the <code>[[final]]</code> attribute applied
- to classes is inconsistent with other languages and not
- desirable in its own right.
-
- 
-
- <td width="536">
- 
- 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 width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 109
-
- <td width="118">
- 7.6.5
-
- <td width="85">
- 4
-
- <td width="62">
- Ed
-
- <td width="514">
- The example code
- refers in comments to "Compilation unit" A and B. The term
- should be "Translation unit" (2/1)
-
- 
-
- <td width="536">
- Replace "Compilation" with "Translation" in
- two places
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- 
-
- <td width="118">
- 
-
- <td width="85">
- 
-
- <td width="62">
- 
-
- <td width="514">
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 110
-
- <td width="118">
- 7.6.5
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Change the type of foo_head to
- atomic<foo *>[].
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 43
-
- <td width="118">
- 8
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 
- 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.
-
- 
-
- <td width="536">
- Some simplification is needed.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 111
-
- <td width="118">
- 8.3.5
-
- <td width="85">
- 13
-
- <td width="62">
- Ed
-
- <td width="514">
- Example missing
- closing bracket in template<typename... T> void f(T
- (* ...t)(int, int);
-
- 
-
- <td width="536">
- Add closing bracket like this:
- template<typename... T> void f(T (* ...t)(int, int));
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 44
-
- <td width="118">
- 8.3.5
-
- <td width="85">
- 13
-
- <td width="62">
- ed
-
- <td width="514">
- In
- the Example, "template void f(T (* ...t)(int, int);" is
- missing a close parenthesis.
-
- 
-
- <td width="536">
- It presumably should read:
- "template void f(T (* ...t))(int, int);".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 45
-
- <td width="118">
- 8.3.5
-
- <td width="85">
- 13
-
- <td width="62">
- te
-
- <td width="514">
- 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.,
-
- 
-
- 
- template<class... T> struct X { };
-
- 
- template<class... T1, class... T2>
-
- struct
- X<pair<T1, T2>...> {
-
- void f(T1...,
- T2...);
-
- };
-
- 
-
- 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):
-
- 
-
- 
- template<class... T> void f(X<T..., int>);
-
- 
-
- 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.
-
- <td width="536">
- In 8.3.5p13,
- remove the sentence “A function
- parameter pack, if present, shall occur at the end of the
- parameter-declaration-list.”
-
- 
-
- 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”.
-
- 
-
- Replace the note text “A function parameter pack
- can only occur at the end of 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.”
-
- 
-
- 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.”
-
- 
-
- 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 is a function
- parameter pack and Pi occurs at the end of the
- parameter-declaration-list”.
-
- 
-
- Replace
- the note text “A function parameter pack can only
- occur at the end of 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.”
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-13
-
- <td width="118">
- 8.4
-
- <td width="85">
- p2
-
- <td width="62">
- te
-
- <td width="514">
- DE-13 The second paragraph, quoting the grammar for the
- declarator of a function declaration, is not considering
- late-specified return types and attributes.
-
- <td width="536">
- Properly quote the grammar from 8.3.5.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 16
-
- <td width="118">
- 8.5
-
- <td width="85">
- 
- 15th para, 1st line
-
- 
-
- <td width="62">
- ed
-
- <td width="514">
- 
- Typo, duplicated "in"
-
- "The initialization that
- occurs in in the forms"
-
- <td width="536">
- Remove one.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 46
-
- <td width="118">
- 8.5.3
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- The ability for
- an rvalue reference to bind to an lvalue opens a
- type-safety hole that becomes very dangerous with concepts.
- For example, consider vector’s push_back operation:
-
- requires
- MoveConstructible<T> void push_back(T&&);
-
- requires
- CopyConstructible<T> void push_back(const T&);
-
- 
-
- 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 considered (it is
- effectively SFINAE’d away), so only the 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).
-
- 
-
- 
-
- <td width="536">
- Prohibit rvalue
- references from binding to lvalues.
-
- 
-
- 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:
-
- 
-
- <ol>
- <li>
- The current
- reference.
-
- <li>
- A non-const
- reference that only binds to rvalues.
-
- <li>
- A non-const
- reference that will bind to both lvalues and rvalues.
- </ol>
-
- 
-
- 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).
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 49
-
- <td width="118">
- 8.5.4
-
- <td width="85">
- 6
-
- <td width="62">
- ed
-
- <td width="514">
- In the Example, the comments
- could be improved.
-
- <td width="536">
- See
- the attached paper "Issues with the C++ Standard" under
- "Editorial Issues" and "8.5.4/6".
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 112
-
- <td width="118">
- 9
-
- <td width="85">
- 4-9
-
- <td width="62">
- Ge
-
- <td width="514">
- We now have
- concepts that should (or should not?) map to the terms
- described in Clause 9 - these should be at least
- referenced.
-
- 
-
- <td width="536">
- Add appropriate forward references to
- 14.9.4
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 113
-
- <td width="118">
- 9.4.2
-
- <td width="85">
- 3
-
- <td width="62">
- Ed
-
- <td width="514">
- Mis-applied edit from the paper n2756
-
- <td width="536">
- The term 'constant-initializer' should have
- been struck out when replaced by
- brace-or-equal-initializer. There are two occurrences in
- this paragraph
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 50
-
- <td width="118">
- 12.1, 
- 12.4, 
- 12.8
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- 
- 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.
-
- 
-
- 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, 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; };
-
- 
-
- <td width="536">
- 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 inaccessible from the implicitly-declared
- destructor,” and the phrase “or a destructor
- that is inaccessible from the implicitly-declared
- destructor”.
-
- 
-
- In 12.8p5,
- remove the phrase “or inaccessible from
- the implicitly-declared copy constructor” from the
- two places it occurs.
-
- 
-
- In 12.8p10,
- remove the phrase “or inaccessible from
- the implicitly-declared copy assignment operator”
- from the two places it occurs.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 28
-
- <td width="118">
- 12.6.1 
- [Explicit 
- initialization]
-
- 
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- This section, in particular the example with `g' appears
- contradictory with the syntax for uniform initialization.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 51
-
- <td width="118">
- 12.6.2
-
- <td width="85">
- 2
-
- <td width="62">
- ed
-
- <td width="514">
- The
- discussion of delegating constructors should be in its own
- paragraph.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 114
-
- <td width="118">
- 12.6.2
-
- <td width="85">
- 1
-
- <td width="62">
- Te
-
- <td width="514">
- Despite all the attempts to unify
- initialization syntax, it is still not possible to
- copy-initialize base classes or non-static data members,
- 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
-
- <td width="536">
- 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 initialize
- the base class or non-static data member subobject 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:...
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 52
-
- <td width="118">
- 13.5.8
-
- <td width="85">
- ¶ 5
-
- <td width="62">
- ed
-
- <td width="514">
- A word is misspelled.
-
- <td width="536">
- Change “shal” to “shall”.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 115
-
- <td width="118">
- 14
-
- <td width="85">
- 6-11
-
- <td width="62">
- Ge
-
- <td width="514">
- 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 tentatively
- suggest this makes the feature ripe for deprecation. Our
- main concern with deprecation is that it might turn out
- that 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.
-
- 
-
- <td width="536">
- Consider deprecating exported templates,
- but no action yet. Examine interaction with constrained
- templates, and see if other more appropriate mechanism will
- support compile-time optimization.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 116
-
- <td width="118">
- 14
-
- <td width="85">
- 6-11
-
- <td width="62">
- Te
-
- <td width="514">
- Is it possible
- to export a concept map template? The current wording
- suggests it is possible, but it is not entirely clear what
- it would mean.
-
- 
-
- <td width="536">
- Either prohibit exporting concept map
- templates, or more directly address what it means to export
- a concept map.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 117
-
- <td width="118">
- 14
-
- <td width="85">
- 2
-
- <td width="62">
- Ge
-
- <td width="514">
- It would be nice
- to allow template alias within a function scope, and
- possibly a scoped concept map. As these affect name lookup
- 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.
-
- 
-
- <td width="536">
- Allow template aliases to be declared
- inside a function scope, and consider scoped concept maps.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 118
-
- <td width="118">
- 14
-
- <td width="85">
- 6-11
-
- <td width="62">
- Ed
-
- <td width="514">
- 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]
-
- 
-
- <td width="536">
- Create a new subclause [temp.export]
- containing 14p6-11. Move 14p12 ahead of this subclause.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 119
-
- <td width="118">
- 14
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- Does a concept
- map have linkage? Reading this paragraph and 3.5 suggests a
- concept map template has external linkage, but not a
- '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.
-
- 
-
- <td width="536">
- Add an exception that concept map templates
- have no linkage, or add concept maps to the list of
- entities with linkage in 3.5
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 120
-
- <td width="118">
- 14.1
-
- <td width="85">
- 9
-
- <td width="62">
- Ed
-
- <td width="514">
- As this is the
- first time the phrase “parameter pack” appears
- in Ch 14 I would like to see the section 8.3.5 referenced
- here (as well as in 14.1p17).
-
- 
-
- <td width="536">
- Insert “(8.3.5)” after
- “parameter pack”
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 121
-
- <td width="118">
- 14.1
-
- <td width="85">
- 18
-
- <td width="62">
- Ed
-
- <td width="514">
- The example
- (that follows the normative text) has no begin example
- marker
-
- 
-
- <td width="536">
- Prefix the example code with "[ Example:"
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 29
-
- <td width="118">
- 14.3 
- [Template 
- arguments]
-
- 
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- Constant expressions of any literal type should be
- allowed as template arguments.
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 53
-
- <td width="118">
- 14.5.1
-
- <td width="85">
- 5
-
- <td width="62">
- te
-
- <td width="514">
- 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 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&);
-
- };
-
- 
-
- If instantiated with a type that is not
- CopyConstructible, vector will get an implicitly-defined
- copy constructor that performs a copy of the pointers.
-
- <td width="536">
- 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).
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 122
-
- <td width="118">
- 14.5.3
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- 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)
-
- 
-
- <td width="536">
- Add clarification in p2 that function
- parameter packs can be used to declare axioms, much like p1
- clarifies they can be used to declare concepts as well as
- templates.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 30
-
- <td width="118">
- 14.5.7 
- [Template 
- aliases]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- When are two template alias
- names equivalent?
-
- 
-
- E.g. given
-
- 
- template<template<class> class> struct X { };
-
- 
-
- 
- template<typename,typename> struct Y { };
-
- 
-
- template<typename T>
-
- using Z1 = 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> and Z2<T> are the same for all T), but we
- do not see any wording to that effect.
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 17
-
- <td width="118">
- 14.7.2
-
- <td width="85">
- 2nd para, 15th
- line
-
- <td width="62">
- ed
-
- <td width="514">
- 
- Typo.
-
- if
- that namespace is inline, any namespace from its enclosing
- namespace set.
-
- 
- 
-
- 
- should be
-
- 
- 
-
- if
- that namespace is inline, any namespace forming its enclosing namespace
- set.
-
- 
-
- <td width="536">
- Replace "from" with "forming"
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-14
-
- <td width="118">
- 14.7.3
-
- <td width="85">
- p1
-
- <td width="62">
- te
-
- <td width="514">
- DE-14 The bulleted list neither addresses "member
- function template of a class" nor "member class template of
- a class".
-
- <td width="536">
- Add the respective bullets.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 18
-
- <td width="118">
- 14.7.3
-
- <td width="85">
- 2nd para, 2nd
- line
-
- <td width="62">
- ed
-
- <td width="514">
- 
- Typo,
-
- any
- namespace from its enclosing namespace set
-
- 
- 
-
- 
- should be
-
- 
- 
-
- any
- namespace forming its
- enclosing namespace set
-
- 
-
- <td width="536">
- Replace "from" with "forming"
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 19
-
- <td width="118">
- 14.8.2
-
- <td width="85">
- 6th para, 1st
- line
-
- <td width="62">
- ed
-
- <td width="514">
- 
- Typo, duplicated "is"
-
- "At certain
- points in the template argument deduction process it is
- is necessary"
-
- 
- 
-
- <td width="536">
- 
- Remove one
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 54
-
- <td width="118">
- 14.9 
- [concept],
-
- 14.10 
- [temp. 
- constrained]
-
- <td width="85">
- 
-
- <td width="62">
- ge
-
- <td width="514">
- Concepts is of course the largest new feature in C++0x
- (in terms of new text inserted into the wording), and
- already we have found some significant defects with it. So
- far nothing devastating has been found, but more time is
- needed to shake more bugs out.
-
- <td width="536">
- I propose no specific change here.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 55
-
- <td width="118">
- 14.9.1
-
- <td width="85">
- ¶ 6
-
- <td width="62">
- ed
-
- <td width="514">
- The paragraph number is in the wrong place, causing a
- grammar rule to be indented more than its fellows.
-
- <td width="536">
- Move the paragraph number so as to follow the grammar
- rules, thus numbering the single sentence, “The body
- of a concept … .”
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 56
-
- <td width="118">
- 14.9.1
-
- <td width="85">
- ¶ 6
-
- <td width="62">
- ed
-
- <td width="514">
- The sentence contains two references to 14.9.1.3
- [concept.req].
-
- <td width="536">
- Change the second such reference (at the end of the
- sentence) to 14.9.1.4 [concept.axiom].
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 57
-
- <td width="118">
- 14.9.1.4
-
- <td width="85">
- ¶ 3
-
- <td width="62">
- ed
-
- <td width="514">
- A word is misplaced, changing the intended meaning.
-
- <td width="536">
- Change “only find … if” to “find
- … only if”.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 58
-
- <td width="118">
- 14.9.1.4
-
- <td width="85">
- ¶ 3
-
- <td width="62">
- ed
-
- <td width="514">
- The listed phrases are not grammatically parallel.
-
- <td width="536">
- Insert “in” before “one” so as
- to obtain “... in the concept, in one of its less
- refined concepts, or in an associated requirement.”
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 59
-
- <td width="118">
- 14.9.1.4
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- Axioms are under-specified and provide
- little benefit to programmers, so they should be removed
- from the working paper. The optimizations permitted by
- axioms (see 14.9.1.4p4-5) are not compulsory (and,
- therefore, programmers cannot rely on them) and the
- semantics expressed by axioms cannot be verified by any
- implementation. The resulting specification has lead to
- great confusion (see the reflector thread “Are
- floating point types 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.
-
- <td width="536">
- Remove clause
- 14.9.1.4 [concept.axiom]
-
- In 2.11p1,
- remove “axiom” from the list of keywords.
-
- 
-
- In 14.5.8p7,
- remove “, or if the resulting concept map fails to
- satisfy the axioms of the corresponding concept”
-
- 
-
- 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.
-
- 
-
- 
-
- Remove paragraph
- 14 of clause 14.9.2.
-
- 
-
- 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.”
-
- 
-
- 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.
-
- 
-
- In 24.1.4p2,
- replace the word “axiom” with
- “condition.”
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- FR 31
-
- <td width="118">
- 14.9.1.4 
- [Axioms]
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- This section states that an
- axiom-definition defines a new semantics axiom but is
- unusually vague as to what those semantics might be.
-
- 
-
- 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 times is an implementation permitted to
- replace one expression by another one when they have side
- effects?
-
- 
-
- <td width="536">
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- DE-15
-
- <td width="118">
- 14.9.1.4
-
- <td width="85">
- 
-
- <td width="62">
- te
-
- <td width="514">
- DE-15 There is no implementation experience for axioms.
- Use of axioms is an area of active scientific research. It
- is likely that syntax changes will become necessary to make
- 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.
-
- <td width="536">
- Remove section 14.9.1.4 and any reference to axioms in
- the rest of the proposed standard other than the keyword
- reservation in section 2.11.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 123
-
- <td width="118">
- 14.9.1.4
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- auto concepts
- and axioms are incompatible. An axiom defines the semantics
- of an operaton or set of operations that describes the run
- 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.
-
- 
-
- <td width="536">
- Add a paragraph making axioms ill-formed
- inside an auto concept.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 124
-
- 
-
- <td width="118">
- 14.9.1.4
-
- <td width="85">
- 6
-
- <td width="62">
- Ed
-
- <td width="514">
- Spelling mistake, double-e in were.
-
- <td width="536">
- weere -> were
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 125
-
- <td width="118">
- 14.9.1.4
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Define the semantics of the implicitly
- declared comparison operators, or restrict their usage to
- declaring equivalence between statements.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 126
-
- <td width="118">
- 14.9.4
-
- <td width="85">
- 41
-
- <td width="62">
- Ed
-
- <td width="514">
- This paragraph
- contains the only definition of the underlying_type member
- - but it's a note, so not normative.
-
- 
-
- <td width="536">
- Move the second sentence to the Requires
- clause in paragraph 42.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 127
-
- <td width="118">
- 14.9.4
-
- <td width="85">
- 
-
- <td width="62">
- Ed
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Provide the diagram.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 128
-
- <td width="118">
- 14.9.4
-
- <td width="85">
- 4
-
- <td width="62">
- Ed
-
- <td width="514">
- It is surprising for many people that
- non-copyable move-only types can be used with a return
- statement, and so Returnable does not always imply
- CopyConstructible.
-
- <td width="536">
- 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]
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- JP 20
-
- <td width="118">
- 14.9.4
-
- <td width="85">
- 2nd para
-
- <td width="62">
- te
-
- <td width="514">
- 
- 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”.
-
- 
- 
-
- <td width="536">
- Add
- TriviallyCopyableType that is trivially copyable type as
- concept.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 129
-
- <td width="118">
- 14.10.1, 
- 20.1.2
-
- <td width="85">
- 
-
- <td width="62">
- Te
-
- <td width="514">
- 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.
-
- 
-
- <td width="536">
- Remove the True concept and library
- subclause 20.1.2. Provide support in 14.10.1 for boolean
- constant expressions as constraints. This may involve
- overloading the true keyword to disambiguate but ideally
- would not.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- US 60
-
- <td width="118">
- 14.10.1
-
- <td width="85">
- 1
-
- <td width="62">
- te
-
- <td width="514">
- The use of && as the separator for
- a list of requirements has shown itself to be a serious
- teachability problem. The mental model behind
- ‘&&’ treats concepts as simple
- predicates, which ignores the role of concepts in
- type-checking templates. The more programmers read into the
- ‘&&’ (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.
-
- <td width="536">
- 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.
-
- 
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 130
-
- <td width="118">
- 15.1
-
- <td width="85">
- 4
-
- <td width="62">
- Te
-
- <td width="514">
- With the new
- crrent_exception API it is possible to capture a reference
- to an exception that will outlive its last active handler.
- 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;"
-
- 
-
- <td width="536">
- Update sentence to allow for exceptions
- held in excpetion_ptr objects.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 131
-
- <td width="118">
- 15.3
-
- <td width="85">
- 3
-
- <td width="62">
- Te
-
- <td width="514">
- A handler
- catching its parameter by rvalue-reference is syntactically
- valid, but will never be activated.
-
- 
-
- <td width="536">
- Disallow handlers catching by
- rvalue-reference.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 132
-
- <td width="118">
- 15.3
-
- <td width="85">
- 16
-
- <td width="62">
- Te
-
- <td width="514">
- There are
- obscure cases whrere a copy constructor is not usually the
- best match to copy-initialize an object, e.g. A converting
- 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.
-
- 
-
- <td width="536">
- Rewite using copy-initialization rather
- than directly invoking the copy constructor
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 133
-
- <td width="118">
- 15.4
-
- <td width="85">
- 2
-
- <td width="62">
- Te
-
- <td width="514">
- Template aliases
- have the same semantics as a typedef so should also be
- disallowed
-
- 
-
- <td width="536">
- add "or alias-declaration" after "shall not
- appear in a typedef declaration".
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 134
-
- <td width="118">
- 15.4
-
- <td width="85">
- 6
-
- <td width="62">
- Ed
-
- <td width="514">
- The sentance "An
- exception-specification can also include the class
- std::bad_exception (18.7.2.1)." is redundant.
-
- 
-
- <td width="536">
- Either strike the quoted sentance, or add a
- note explaining why it is worth calling special attention
- to this class.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 135
-
- <td width="118">
- 15.4
-
- <td width="85">
- 8
-
- <td width="62">
- Te
-
- <td width="514">
- Unclear if std::unexpected is called before
- or after the function arguments have been destroyed
-
- <td width="536">
- Clarify the sequence of calling unexpected
- with respect to interesting objects, such as function
- arguments or partially constructed bases and members when
- called from a constructor or destructor
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 136
-
- <td width="118">
- 15.4
-
- <td width="85">
- 
-
- <td width="62">
- Ge
-
- <td width="514">
- Exception specifications have proven close
- to worthless in practice, while adding a measurable
- overhead to programs. The feature should be deprecated. The
- 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.
-
- <td width="536">
- Move 15.4 and the parts of 15.5 that refer
- to it to Appendix D. Replace 15.4 with a simpler
- specification for empty throw specifications, where the
- 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.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 137
-
- <td width="118">
- 15.5
-
- <td width="85">
- 
-
- <td width="62">
- Ed
-
- <td width="514">
- There is no
- mention of the current_exception API which can extend the
- lifetime of an exception object. There should at least be a
- forward reference to the library clause 18.7.5
-
- 
-
- <td width="536">
- Add another paragraph outlining 18.7.5 and
- the ability of an exception_ptr to extend the lifetime of
- an exception object
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 138
-
- <td width="118">
- 15.5.1
-
- <td width="85">
- 1
-
- <td width="62">
- Ed
-
- <td width="514">
- The third bullet
- is redundant with the first, as it is a subset of the same
- conditions.
-
- 
-
- <td width="536">
- Merge the third bullet into the first
- bullet as a note or example.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 139
-
- <td width="118">
- 15.5.1
-
- <td width="85">
- 1
-
- <td width="62">
- Te
-
- <td width="514">
- According to the
- first bullet it is perfectly alright for a library function
- to exit by throwing an exception during stack unwinding,
- This is clearly not true.
-
- 
-
- <td width="536">
- Strike the word 'user' from the first
- bullet point.
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 140
-
- <td width="118">
- 15.5.2
-
- <td width="85">
- 2
-
- <td width="62">
- Ed
-
- <td width="514">
- 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();
-
- 
-
- <td width="536">
- Add a note highlighting the default
- behaviour of std::unexpected if the user does not supply a
- hander-function
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 141
-
- <td width="118">
- 15.6
-
- <td width="85">
- 
-
- <td width="62">
- Ed
-
- <td width="514">
- This whole
- subclause is redundant due to 15.1p5 and 15.3p17
-
- 
-
- <td width="536">
- Strike 15.6
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 142
-
- <td width="118">
- 16.3.5
-
- <td width="85">
- 3
-
- <td width="62">
- Ed
-
- <td width="514">
- This paragraph
- opens with "[ Note" but has no corresponding "end note ]"
-
- 
-
- <td width="536">
- Add "end note ]"
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 143
-
- <td width="118">
- 16.3.5
-
- <td width="85">
- 7
-
- <td width="62">
- Ed
-
- <td width="514">
- Example uses #define t(x,y.z) x ## y ## z
-
- <td width="536">
- Change "x,y.z" to "x,y,z"
-
- <td width="178">
- 
-
- <tr valign="top">
- <td width="29">
 US 2

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

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

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

- <td width="514">
+ <td width="375">
 The
 active issues identified in WG21 N2806, C++ Standard
 Library Active Issues, must be addressed and appropriate
@@ -8937,60 +73,63 @@
 
 <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>
+ http://www.open-std.org/> 
+ <a href=
+ "http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
+ jtc1/sc22/wg21/docs/lwg-active.html</a>

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

 17 SG: should go to threads group; misclassified in document
@@ -9096,16 +235,16 @@
 <td width="29">
 DE-2

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

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

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

- <td width="514">
+ <td width="375">
 DE-2 Marking a constructor with "explicit" has semantics
 even for a constructor with zero or several parameters:
 Such a constructor cannot be used with list-initialization
@@ -9113,20 +252,20 @@
 standard library apparently has not been reviewed for
 marking non-single-parameter constructors as "explicit".

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

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

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

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

@@ -9141,13 +280,13 @@
 27.8.1, 
 28.4

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

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

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

- <td width="536">
+ <td width="466">
 Add commented
 lines corresponding to char16_t, char32_t.
@@ -9958,7 +1097,7 @@

 

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

 Previously considered; we decided not to do it. We believe it is not too
@@ -9968,24 +1107,24 @@
 UK 
 144

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

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

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

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

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

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

 <tr valign="top">
@@ -9993,27 +1132,27 @@
 UK 
 145

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10021,24 +1160,24 @@
 UK 
 146

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

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

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

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

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

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

 <tr valign="top">
@@ -10046,22 +1185,22 @@
 UK 
 147

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

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

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

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

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

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

 <tr valign="top">
@@ -10069,16 +1208,16 @@
 UK 
 148

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10098,28 +1237,28 @@
 UK 
 149

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10127,16 +1266,16 @@
 UK 
 150

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

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

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

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

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

 

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

 <tr valign="top">
@@ -10169,26 +1308,26 @@
 UK 
 151

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10196,16 +1335,16 @@
 UK 
 152

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

 editorial; sent to Pete Becker<tr valign="top">
@@ -10256,23 +1395,23 @@

 

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

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

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

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

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

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

 <tr valign="top">
@@ -10280,24 +1419,24 @@
 UK 
 155

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

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

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

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

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

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

 <tr valign="top">
@@ -10305,27 +1444,27 @@
 UK 
 156

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10333,16 +1472,16 @@
 UK 
 157

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

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

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

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

@@ -10350,10 +1489,10 @@

 

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

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

 <tr valign="top">
@@ -10361,26 +1500,26 @@
 UK 
 158

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

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

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

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

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

 

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

 <tr valign="top">
@@ -10388,27 +1527,27 @@
 UK 
 159

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10416,16 +1555,16 @@
 UK 
 160

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10448,16 +1587,16 @@
 UK 
 161

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10477,16 +1616,16 @@
 UK 
 162

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10507,16 +1646,16 @@
 UK 
 163

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

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

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

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

 

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

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

 Tom Plum to open LWG issue; we believe this is related to LWG625<tr valign="top">
@@ -10536,22 +1675,22 @@
 UK 
 164

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

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

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

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

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

 

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

 <tr valign="top">
@@ -10568,17 +1707,17 @@
 UK 
 165

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

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

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

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

 

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

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

 Robert Klarer to review<tr valign="top">
@@ -10598,26 +1737,26 @@
 UK 
 166

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

 

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

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

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

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

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

 <tr valign="top">
@@ -10625,28 +1764,28 @@
 UK 
 167

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

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

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

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

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

 

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

 <tr valign="top">
@@ -10654,16 +1793,16 @@
 UK 
 168

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

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

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

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

 

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

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

 Howard will create issue to adopt UK words (some have reservations whether
@@ -10689,16 +1828,16 @@
 UK 
 169

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

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

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

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

 

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

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

 Bill Plaugher to open issue. If the wording is too broad we need to add an
@@ -10718,16 +1857,16 @@
 UK 
 170

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

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

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

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

 

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

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

 Alisdair to open issue. We prefer
@@ -10757,16 +1896,16 @@
 UK 
 171

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10790,26 +1929,26 @@
 UK 
 172

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

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

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

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

 

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

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

 NAD. We do not belive at_exit and at_quick_exit should be required by
@@ -10818,27 +1957,27 @@
 UK 
 173

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

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

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

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

 

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

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

 LWG is interested in N2814, but we're concerned whether CWG will accept
@@ -10846,17 +1985,17 @@
 <td width="29">
 JP 23

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

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

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

- <td width="514">
+ <td width="375">
 There is a
 freestanding implementation including <type_traits>,
@@ -10870,12 +2009,12 @@
 
 

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

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

 LWG is interested in N2814, but we're concerned whether CWG will accept
@@ -10886,16 +2025,16 @@
 UK 
 174

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10918,26 +2057,26 @@
 UK 
 175

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

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

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

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

 

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

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

 we accept the proposed solution. Martin will draft an issue.<tr valign="top">
@@ -10945,25 +2084,25 @@
 UK 
 176

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

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

 

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

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

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

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

 <tr valign="top">
@@ -10971,26 +2110,26 @@
 UK 
 177

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

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

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

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

 

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

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

 <tr valign="top">
@@ -10998,25 +2137,25 @@
 UK 
 178

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

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

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

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

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

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

 <tr valign="top">
@@ -11024,16 +2163,16 @@
 UK 
 179

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

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

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

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

 

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

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

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

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

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

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

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

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

@@ -11085,7 +2224,7 @@
 There are same cases in 17.6.1 paragraph 2, 17.6.5.7
 paragraph 6, 30.1 paragraph 1, 30.3.1 paragraph 1 also.

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

 <tr valign="top">
@@ -11093,16 +2232,16 @@
 UK 
 180

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

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

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

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

 

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

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

 NAD, the standard already has the desired restriction.<tr valign="top">
@@ -11125,16 +2264,16 @@
 UK 
 181

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

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

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

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

 

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

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

 We agree that the footnote is wrong and it will be removed. Pete will handle
@@ -11156,16 +2295,16 @@
 UK 
 182

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

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

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

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

 

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

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

 NAD. We cannot mandate all standard-library functions that might use some
@@ -11185,16 +2324,16 @@
 UK 
 184

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

@@ -11422,23 +2561,23 @@

 

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

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

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

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

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

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

 

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

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

 <tr valign="top">
@@ -11459,42 +2598,42 @@
 UK 
 185

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

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

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

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

 

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

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

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

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

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

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

- <td width="514">
+ <td width="375">
 DE-18 The
 proposed C++ standard makes a considerable number of
@@ -11516,14 +2655,14 @@

 

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

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

 <tr valign="top">
@@ -11531,16 +2670,16 @@
 UK 
 186

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

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

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

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

 

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

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

 <tr valign="top">
@@ -11560,27 +2699,27 @@
 UK 
 187

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

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

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

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

 

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

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

 <tr valign="top">
@@ -11588,16 +2727,16 @@
 UK 
 188

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

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

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

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

 

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

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

 <tr valign="top">
@@ -11616,21 +2755,21 @@
 UK 
 189

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

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

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

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

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

 

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

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

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

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

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

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

- <td width="536">
+ <td width="466">
 
 Consider to add the attribute [[noreturn]] to such
 functions,
@@ -11687,7 +2826,7 @@
 
 

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

 <tr valign="top">
@@ -11695,28 +2834,28 @@
 UK 
 190

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

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

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

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

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

 

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

 <tr valign="top">
@@ -11724,21 +2863,21 @@
 UK 
 191

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

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

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

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

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

 

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

 <tr valign="top">
@@ -11754,16 +2893,16 @@
 UK 
 192

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

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

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

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

 

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

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

 <tr valign="top">
@@ -11785,27 +2924,27 @@
 UK 
 193

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

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

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

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

 

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

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

 <tr valign="top">
@@ -11813,16 +2952,16 @@
 UK 
 194

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

@@ -11911,55 +3050,55 @@

 

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

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

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

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

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

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

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

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

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

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

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

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

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

- <td width="536">
+ <td width="466">
 Consider to add
 a sample program which rethrows exception.
@@ -11967,7 +3106,7 @@
 
 

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

 <tr valign="top">
@@ -11975,16 +3114,16 @@
 UK 
 195

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

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

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

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

 

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

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

 <tr valign="top">
@@ -12006,21 +3145,21 @@
 UK 
 196

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

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

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

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

- <td width="536">
+ <td width="466">
 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
@@ -12030,7 +3169,7 @@

 

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

 <tr valign="top">
@@ -12038,22 +3177,22 @@
 UK 
 197

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

- <td width="536">
+ <td width="466">
 Delete this
 cross reference. If necessary, expand the main text to
@@ -12153,7 +3292,7 @@

 

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

 The statement made in the comment was already aired prior to the last vote.
@@ -12163,16 +3302,16 @@
 <td width="29">
 US 65

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

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

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

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

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

 

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

 <tr valign="top">
@@ -12214,21 +3353,21 @@
 UK 
 198

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

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

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

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

- <td width="536">
+ <td width="466">
 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
@@ -12261,7 +3400,7 @@

 

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

 Agree that this is editorial -- forward to project editor. (effective
@@ -12270,16 +3409,16 @@
 UK 
 199

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

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

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

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

 

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

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

 Agree change 'program' to 'user' in clauses 20.1.1 and 20.1.2<tr valign="top">
@@ -12302,21 +3441,21 @@
 UK 
 200

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

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

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

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

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

 

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

 We agree that adding constraints to predicate is a good idea. Predicate
@@ -12338,20 +3477,20 @@
 UK 
 201

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

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

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

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

- <td width="536">
+ <td width="466">
 Add a requires
 clause to the Consistency axiomL requires
 HasLessEquals<T> &&
@@ -12361,7 +3500,7 @@

 

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

 After consultation with the submitter, we agreed that the suggestion was in
@@ -12369,21 +3508,21 @@
 <td width="29">
 JP 33

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

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

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

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

- <td width="536">
+ <td width="466">
 Apply
 concept_map to these concepts at FloatingPointType
@@ -12391,7 +3530,7 @@
 
 

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

 We believe that no change is necessary, but it should be reviewed by a group
@@ -12401,57 +3540,57 @@
 <td width="29">
 US 66

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

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

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

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

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

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

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

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

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

 

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

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

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

 
 #include <initializer_list> // for concept_map

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

 Agree that the omission of <code>#include
@@ -12465,53 +3604,53 @@
 <td width="29">
 US 67

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

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

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

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

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

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

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

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

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

 

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

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

 "stdforward" should be
 "std::forward"

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

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

 Yes. Forward to project editor.<tr valign="top">
@@ -12519,16 +3658,16 @@
 UK 
 202

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

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

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

- <td width="514">
+ <td width="375">
 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
@@ -12536,36 +3675,36 @@

 

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

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

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

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

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

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

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

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

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

 Editorial. The correct section is 20.1.12, not 20.2.12. Forward to project
@@ -12574,16 +3713,16 @@
 UK 
 203

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

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

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

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

 

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

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

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

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

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

 

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

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

 "it
 it" should be "it is"

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

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

 Yes. Forward to project editor.<tr valign="top">
@@ -12635,16 +3774,16 @@
 UK 
 204

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

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

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

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

 

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

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

 Agree that aligned_union is not completely redundant. We are investigating
@@ -12664,24 +3803,24 @@
 <td width="29">
 US 69

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

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

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

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

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

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

 Editorial (effective duplicate of UK 198). Forward to project editor.<tr valign="top">
@@ -12689,16 +3828,16 @@
 UK 
 205

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

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

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

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

 

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

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

 Agree: Add a constexpr conversion operator to class template
@@ -12721,16 +3860,16 @@
 UK 
 206

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

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

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

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

 

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

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

 Agree with the proposed resolution: Section 20.5.5, Change: "In order to
@@ -12759,20 +3898,20 @@
 UK 
 207

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

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

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

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

- <td width="536">
+ <td width="466">
 Change:
 Example:remove_const<const volatile int>::type
 evaluates to volatile int, whereas remove_const<const
@@ -12796,7 +3935,7 @@

 

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

 We tend to agree. Forward to project editor. Also recommend that the word
@@ -12804,16 +3943,16 @@
 <td width="29">
 JP 37

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

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

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

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

@@ -12843,31 +3982,31 @@

 

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

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

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

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

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

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

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

- <td width="536">
+ <td width="466">
 Wherever
 concepts are available that directly match this
@@ -12879,7 +4018,7 @@

 

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

 (The correct reference is section 20.5, not 20.6) We think that this is a
@@ -12889,23 +4028,23 @@
 <td width="29">
 US 71

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

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

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

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

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

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

 (The correct reference is section 20.5.7, table 41, last row). Agree:
@@ -12913,16 +4052,16 @@
 <td width="29">
 JP 38

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

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

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

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

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

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

 We were not clear about what the submitter really intended. Requiring that
@@ -12979,20 +4118,20 @@
 <td width="29">
 JP 39

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

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

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

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

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

@@ -13043,7 +4182,7 @@

 

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

 Agree with one correction: CopyConstructible?
@@ -13053,22 +4192,22 @@
 <td width="29">
 JP 40

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

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

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

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

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

@@ -13102,28 +4241,28 @@
 
 

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

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

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

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

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

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

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

@@ -13161,7 +4300,7 @@

 }

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

 This change would be redundant because function<> is already sufficiently
@@ -13169,16 +4308,16 @@
 <td width="29">
 JP 42

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

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

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

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

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

@@ -13288,7 +4427,7 @@
 
 

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

 As with JP 41, these constraints are redundant given that function<> is
@@ -13298,26 +4437,26 @@
 UK 
 208

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

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

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

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

 

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

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

 Consensus is that this is an expansion of the scope of C++0X and so we
@@ -13326,20 +4465,20 @@
 UK 
 209

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

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

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

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

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

@@ -13347,7 +4486,7 @@

 

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

 We look forward to a paper on this topic. We recommend no action until a
@@ -13356,16 +4495,16 @@
 UK 
 213

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

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

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

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

 

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

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

 <tr valign="top">
@@ -13391,26 +4530,26 @@
 UK 
 214

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

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

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

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

 

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

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

 We look forward to a paper on this topic. We recommend no action until a
@@ -13419,21 +4558,21 @@
 UK 
 210

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

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

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

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

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

@@ -13441,7 +4580,7 @@

 

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

 We look forward to a paper on this topic. We recommend no action until a
@@ -13449,79 +4588,79 @@
 <td width="29">
 DE-20

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

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

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

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

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

 

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

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

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

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

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

- <td width="514">
+ <td width="375">
 
 bind should support move-only functors and bound arguments.

 

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

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

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

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

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

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

- <td width="514">
+ <td width="375">
 DE-21 The specification for bind claims twice that "the
 values and types for the bound arguments v1, v2, ..., vN
 are determined as specified below". No such specification
 appears to exist.

- <td width="536">
+ <td width="466">
 Add the missing specification in the same section, or
 add a cross-reference indicating the section where the
 specification appears.

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

 <tr valign="top">
@@ -13529,16 +4668,16 @@
 UK 
 211

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

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

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

- <td width="514">
+ <td width="375">
 The nullptr_t
 type was introduced to resolve the null pointer literal
 problem. It should be used for the assignemnt operator, as
@@ -13546,12 +4685,12 @@

 

- <td width="536">
+ <td width="466">
 Change signature here and in the synopsis
 to: unique_ptr& operator=(nullptr_t); Strike the
 sentance an note before the Effects clause.

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

 <tr valign="top">
@@ -13559,16 +4698,16 @@
 UK 
 212

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

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

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

- <td width="514">
+ <td width="375">
 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
@@ -13578,55 +4717,55 @@

 

- <td width="536">
+ <td width="466">
 Move this specification to 18.5. Move the
 declarations into the header <new>.

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

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

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

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

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

- <td width="514">
+ <td width="375">
 DE-22 The conditions for deriving from
 std::unary_function and std::binary_function are unclear:
 The condition would also be satisfied if ArgTypes were
 std::vector<T1>, because it (arguably) "contains" T1.

- <td width="536">
+ <td width="466">
 Consider stating the conditions in normative prose
 instead of in comments in the class definition. Use
 "consists of" instead of "contains". Consider using "if and
 only if" instead of "iff".

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

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

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

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

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

- <td width="514">
+ <td width="375">
 The
 std::reference_closure template is redundant with
 std::function and should be removed.
@@ -13659,7 +4798,7 @@

 

- <td width="536">
+ <td width="466">
 Remove 20.7.18
 [func.referenceclosure].

@@ -13667,23 +4806,23 @@

 Remove 5.1.1 paragraph 12.

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

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

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

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

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

- <td width="514">
+ <td width="375">
 Scoped
 allocators represent a poor trade-off for standardization,
 since (1) scoped-allocator--aware containers can be
@@ -13711,7 +4850,7 @@

 

- <td width="536">
+ <td width="466">
 Remove support
 for scoped allocators from the working paper. This includes
 at least the following changes:
@@ -13741,79 +4880,79 @@

 

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

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

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

- <td width="85">
+ <td width="31">
 (a) synopsis (b) after ¶ 14

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

- <td width="514">
+ <td width="375">
 A concept name is twice misspelled.

- <td width="536">
+ <td width="466">
 Change “Hasconstructor” to
 “HasConstructor” (twice).

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

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

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

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

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

- <td width="514">
+ <td width="375">
 Allocator concepts are incomplete

- <td width="536">
+ <td width="466">
 See paper:
 http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf

 

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

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

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

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

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

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

 
 "alloc" should be "Alloc"

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

@@ -13853,7 +4992,7 @@
 
 

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

 <tr valign="top">
@@ -13861,42 +5000,42 @@
 UK 
 215

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

- <td width="85">
+ <td width="31">
 6,8

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

- <td width="514">
+ <td width="375">
 Extra pair of
 {}, presumably some formatting code gone awry :
 duration& operator-{-}();

 

- <td width="536">
+ <td width="466">
 Remove the {} or fix formatting

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

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

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

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

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

- <td width="514">
+ <td width="375">
 
 Allocator-specific move and copy behavior for containers
 (N2525) complicates a little-used and already-complicated
@@ -13920,7 +5059,7 @@

 

- <td width="536">
+ <td width="466">
 Remove 20.8.4.

 
@@ -13932,30 +5071,30 @@
 Remove all references to the facilities in
 20.8.4 and 20.8.5 from clause 23.

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

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

- <td width="118">
+ <td width="75">
 20.8.12, 
 20.8.13.2

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

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

- <td width="514">
+ <td width="375">
 There is presently no way to
 convert directly from a <code>shared_ptr</code> to a
 <code>unique_ptr</code>.

- <td width="536">
+ <td width="466">
 Add
 an interface that performs the conversion. See the
 attached, Issues with the C++ Standard" paper under Chapter
@@ -13965,23 +5104,23 @@

 

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

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

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

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

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

- <td width="514">
+ <td width="375">
 
 [unique.ptr.single.ctor]/5 no longer requires for D not to
 be a pointer type.  This restriction needs to be put
@@ -14004,26 +5143,26 @@

 

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

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

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

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

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

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

- <td width="514">
+ <td width="375">
 The
 1st parameter p and 2nd parameter v is now
 shared_ptr<T> *.
@@ -14033,28 +5172,28 @@
 shared_ptr<T>* then add the "p shall not be a null
 pointer" at the requires.

- <td width="536">
+ <td width="466">
 
 Change shared_ptr<T>& or add the "p shall not be
 a null pionter" at the requires.

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

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

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

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

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

- <td width="514">
+ <td width="375">
 
 Rep, Period, Clock and Duration don't correspond to
 concept.
@@ -14071,32 +5210,32 @@
 
 

- <td width="536">
+ <td width="466">
 
 Make concept for Rep, Period, Clock and Duration, and fix
 20.9 and wait_until and wait_for's template parameter at
 30.

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

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

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

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

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

- <td width="514">
+ <td width="375">
 The section heading does not describe the contents.

- <td width="536">
+ <td width="466">
 Change the
 heading “

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

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

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

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

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

- <td width="514">
+ <td width="375">
 
 chrono::duration is missing the modulous operator for both
 member and non-member arithmetic. This operator is useful
@@ -14164,7 +5303,7 @@

 

- <td width="536">
+ <td width="466">
 Add:

 
@@ -14224,30 +5363,30 @@

 

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

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

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

- <td width="85">
+ <td width="31">
 after ¶ 1

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

- <td width="514">
+ <td width="375">
 The code synopsis has a minor alignment error.

- <td width="536">
+ <td width="466">
 Align “rep” with the other symbols defined
 in this synopsis.

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

 <tr valign="top">
@@ -14255,24 +5394,24 @@
 UK 
 216

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

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

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

- <td width="514">
+ <td width="375">
 All the containers use concepts for their
 iterator usage, exect for basic_string. This needs fixing.

- <td width="536">
+ <td width="466">
 Use concepts for iterator template
 parameters throughout the chapter.

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

 NB comments to be handled by Dave Abrahams and Howard Hinnant with advice
@@ -14281,20 +5420,20 @@
 <td width="29">
 JP 46

- <td width="118">
+ <td width="75">
 21.2, 21.3

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

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

- <td width="514">
+ <td width="375">
 The
 basic_string does not use concept.

- <td width="536">
+ <td width="466">
 The
 "class Alloc" is changed to "Allocator Alloc".

@@ -15288,23 +6427,23 @@
 
 

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

 See UK 216<tr valign="top">
 <td width="29">
 JP 47

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

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

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

- <td width="514">
+ <td width="375">
 
 Typo. Missing ”>”

@@ -15325,27 +6464,27 @@

 

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

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

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

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

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

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

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

@@ -15369,11 +6508,11 @@
 
 

- <td width="536">
+ <td width="466">
 Add
 a concept for char_traits.

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

 See UK 216<tr valign="top">
@@ -15381,21 +6520,21 @@
 UK 
 217

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

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

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

- <td width="514">
+ <td width="375">
 basic_string refers to
 constructible_with_allocator_suffix, which I thought was
 removed?

- <td width="536">
+ <td width="466">
 Remove the
 lines: template <class charT, class traits, class Alloc
 struct constructible_with_allocator_suffix<
@@ -15404,7 +6543,7 @@

 

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

 <tr valign="top">
@@ -15412,16 +6551,16 @@
 UK 
 218

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

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

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

- <td width="514">
+ <td width="375">
 The identity
 "&*(s.begin() + n) == &*s.begin() + n" relies on
 operator& doing the "right thing", which (AFAICS) there
@@ -15432,11 +6571,11 @@

 

- <td width="536">
+ <td width="466">
 See my recommendations for "23.2.1,
 23.2.6".

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

 NAD, we think. basic_string elements have to be POD and PODs may not have
@@ -15446,26 +6585,26 @@
 UK 
 219

- <td width="118">
+ <td width="75">
 21.3.6.6 
 [string. 
 replace]

- <td width="85">
+ <td width="31">
 11

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 Effects refers to "whose first begin() - i1
 elements" However i1 is greater than begin()...

- <td width="536">
+ <td width="466">
 Effects refers to "whose first i1 - begin()
 elements"

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -15473,16 +6612,16 @@
 UK 
 220

- <td width="118">
+ <td width="75">
 21.3.8.9

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The
 operator<< for basic_string takes the output stream
 by r-value reference. This is different from the same
@@ -15492,13 +6631,13 @@

 

- <td width="536">
+ <td width="466">
 Use the same reference type for the all the
 library types. This should be the r-value reference. There
 are other places in the standard where TR1, and new
 classes, did not receive an 'R-value' update.

- <td width="178">
+ <td width="225">
 

 We did it differently for basic_string because otherwise rvalue strreaming
@@ -15507,17 +6646,17 @@
 <td width="29">
 FR 33

- <td width="118">
+ <td width="75">
 22.1.1 
 [locale]

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 ios_base::iostate err = 0;

 
@@ -15527,26 +6666,26 @@

 goodbit is the solution.

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 49

- <td width="118">
+ <td width="75">
 22.1.3.2.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 codecvt does not use concept. For example, create
 CodeConvert concept and change as follows.
@@ -15555,32 +6694,32 @@
 template<CodeConvert Codecvt, class Elem =
 wchar_t> class wstring_convert {

- <td width="536">
+ <td width="466">
 Add
 a concept for codecvt.

- <td width="178">
+ <td width="225">
 

 to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
 <td width="29">
 JP 50

- <td width="118">
+ <td width="75">
 22.1.3.2.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 Add
 custom allocator parameter to wstring_convert, since we
 cannot allocate memory for strings from a custom allocator.

- <td width="536">
+ <td width="466">
 
 Correct as follows.

@@ -15634,49 +6773,49 @@
 
 

- <td width="178">
+ <td width="225">
 

 to be handled by PJ Plaugher<tr valign="top">
 <td width="29">
 FI 4

- <td width="118">
+ <td width="75">
 22.2.1.4.1

 22.2.1.4.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 <tt>to_end and to_limit are both used. Only one is
 needed.</tt>

- <td width="536">
+ <td width="466">
 Change to_limit to to_end.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 FI 5

- <td width="118">
+ <td width="75">
 <tt>22.2.1.4.2</tt>

- <td width="85">
+ <td width="31">
 #3

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 <tt>[ Note: As
 a result of operations on state, it can return ok or
@@ -15703,21 +6842,21 @@
 from_next is unaltered, to_next is advanced, state is
 altered and return value is partial.</tt>

- <td width="536">
+ <td width="466">
 <tt>[ Note: As a result of operations on state, do_in
 and do_out can return</tt> 
 <tt>ok or partial and set from_next == from and/or to_next
 != to. —end</tt> 
 <tt>note ]</tt>

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 FI 6

- <td width="118">
+ <td width="75">
 22.2.1.5

@@ -15725,13 +6864,13 @@
 22.2.1.4 
 (1,2,3)

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 <tt>codecvt_byname is only specified to work with locale
@@ -15749,11 +6888,11 @@

 

- <td width="536">
+ <td width="466">
 <tt>There should be a built-in means to find a codecvt
 with a pair of character set names.</tt>

- <td width="178">
+ <td width="225">
 

 Martin Sebor interested in solving this problem (also POSIX group), but
@@ -15762,16 +6901,16 @@
 <td width="29">
 FI 7

- <td width="118">
+ <td width="75">
 22.2.1.4

- <td width="85">
+ <td width="31">
 1,2,3

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 The word
 "codeset" is used, whereas the word "character set" is used
@@ -15781,28 +6920,28 @@

 

- <td width="536">
+ <td width="466">
 Change "codeset" to "character set."

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 51

- <td width="118">
+ <td width="75">
 22.2.5.1.1

- <td width="85">
+ <td width="31">
 7th para, 1st
 line

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 A
 parameter `end’ should be `fmtend’. 
 get() function had two `end’ parameters at N2321.
@@ -15820,7 +6959,7 @@
 
 

- <td width="536">
+ <td width="466">
 
 Correct as follows.

@@ -15840,29 +6979,29 @@
 
 Requires: [fmt,fmtend) shall be a valid range.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 52

- <td width="118">
+ <td width="75">
 22.2.5.1, 
 22.2.5.2, 
 22.2.6.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 InputIterator does not use concept.

- <td width="536">
+ <td width="466">
 
 Correct as follows.

@@ -16031,28 +7170,28 @@

 

- <td width="178">
+ <td width="225">
 

 to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
 <td width="29">
 JP 53

- <td width="118">
+ <td width="75">
 22.2.5.3 , 
 22.2.5.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 OutputIterator does not use concept.

- <td width="536">
+ <td width="466">
 
 Correct as follows.

@@ -16165,36 +7304,36 @@
 typedef OutputIter
 iter_type;

- <td width="178">
+ <td width="225">
 

 to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
 <td width="29">
 JP 54

- <td width="118">
+ <td width="75">
 23

- <td width="85">
+ <td width="31">
 
 2nd para, Table 79

 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 There is not <forward_list> in Table 79.

- <td width="536">
+ <td width="466">
 Add
 <forward_list> between <deque> and
 <list>.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16202,20 +7341,20 @@
 UK 
 221

- <td width="118">
+ <td width="75">
 23

- <td width="85">
+ <td width="31">
 Table 79

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The table is missing the new
 <forward_list> header.

- <td width="536">
+ <td width="466">
 Add
 <forward_list> to the table for sequence containers.
 Alternative (technical) solution might be to merge
@@ -16223,7 +7362,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16231,16 +7370,16 @@
 UK 
 222

- <td width="118">
+ <td width="75">
 23

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 It is not clear
 what purpose the Requirement tables serve in the Containers
 clause. Are they the definition of a library Container? Or
@@ -16257,7 +7396,7 @@

 

- <td width="536">
+ <td width="466">
 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
@@ -16268,38 +7407,38 @@
 not provide the required size operation as it cannot be
 implemented efficiently.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 55

- <td width="118">
+ <td width="75">
 23.1.1

- <td width="85">
+ <td width="31">
 
 3rd para, 4th line

 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 It
 seems that “the MinimalAllocator concep” is the
 typo of “the MinimalAllocator concept”.

- <td width="536">
+ <td width="466">
 
 Change to … models the MinimalAllocator
 concept.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16307,16 +7446,16 @@
 UK 
 223

- <td width="118">
+ <td width="75">
 23.1.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The library does
 not define the MinimalAllocator or ScopedAllocator
 concepts, these were part of an earlier Allocators proposal
@@ -16324,12 +7463,12 @@

 

- <td width="536">
+ <td width="466">
 Remove the references to MinimalAllocator
 and ScopedAllocator, or add definitions for these concepts
 to clause 20.7.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16337,21 +7476,21 @@
 UK 
 224

- <td width="118">
+ <td width="75">
 23.1.1

- <td width="85">
+ <td width="31">
 8

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 This paragraph implicitly requires all
 containers in clause 23 to support allocators, which
 std::array does not.

- <td width="536">
+ <td width="466">
 Add an 'unless
 otherwise specified' rider somewhere in p8, or move the
 whole array container from clause 23 [containers] to clause
@@ -16359,7 +7498,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16367,16 +7506,16 @@
 UK 
 225

- <td width="118">
+ <td width="75">
 23.1.1

- <td width="85">
+ <td width="31">
 Table 81

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 Inconsistent
 words used to say the same thing. Table 80 describes
 iterator/const_iterator typedef as returning an "iterator
@@ -16387,12 +7526,12 @@

 

- <td width="536">
+ <td width="466">
 Change return types for
 X::(const)_reverse_iterator to say "iterator type whose
 value type is (const) T".

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16400,16 +7539,16 @@
 UK 
 226

- <td width="118">
+ <td width="75">
 23.1.1

- <td width="85">
+ <td width="31">
 10

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 <array>
 must be added to this list. In particular it doesn't
 satisfy: - no swap() function invalidates any references,
@@ -16419,12 +7558,12 @@

 

- <td width="536">
+ <td width="466">
 If <array> remains a container, this
 will have to also reference array, which will then have to
 say which of these points it satisfies.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16432,28 +7571,28 @@
 UK 
 227

- <td width="118">
+ <td width="75">
 23.1.1

- <td width="85">
+ <td width="31">
 Table 80

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The post-condition for a = rv uses the word
 “construction” when it means
 “assignment”

- <td width="536">
+ <td width="466">
 Replace the word
 “construction” with the word
 “assignment”

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16461,26 +7600,26 @@
 UK 
 228

- <td width="118">
+ <td width="75">
 23.1.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 Line 4 contains
 a spelling mistake in the fragment "MinimalAllocator
 concep."

 

- <td width="536">
+ <td width="466">
 Replace "concep" with "concept"

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16488,21 +7627,21 @@
 UK 
 229

- <td width="118">
+ <td width="75">
 23.1.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The fragment "A container may directly call
 constructors" is not technically correct as constructors
 are not callable.

- <td width="536">
+ <td width="466">
 Replace "A
 container may directly call constructors and destructors
 for its stored objects" with something similar to "A
@@ -16511,7 +7650,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16519,16 +7658,16 @@
 UK 
 230

- <td width="118">
+ <td width="75">
 23.1.2

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 
 “implementations shall consider the following
 functions to be const” - what does this mean? I don't
@@ -16538,33 +7677,33 @@

 

- <td width="536">
+ <td width="466">
 Clarify what is meant and what requirements
 an implementation must satisfy.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 56

- <td width="118">
+ <td width="75">
 23.1.3

- <td width="85">
+ <td width="31">
 12th para, Table 84

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 `array’ is unstated in Table 84 - Optional sequence
 container operations.

- <td width="536">
+ <td width="466">
 Add
 `array’ to Container field for the following
 Expression.
@@ -16581,7 +7720,7 @@
 a.at(n)

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16589,28 +7728,28 @@
 UK 
 231

- <td width="118">
+ <td width="75">
 23.1.3

- <td width="85">
+ <td width="31">
 9-11

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 These paragraphs
 are redundant now that Concepts define what it means to be
 an Iterator and guide overload resolution accordingly.

 

- <td width="536">
+ <td width="466">
 Strike 23.1.3p9-11. Make sure
 std::basic_string has constraints similar to std::vector to
 meet this old guarantee.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16618,27 +7757,27 @@
 UK 
 232

- <td width="118">
+ <td width="75">
 23.1.3

- <td width="85">
+ <td width="31">
 Table 84

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 match_results
 may follow the requirements but is not listed a general
 purpose library container.

 

- <td width="536">
+ <td width="466">
 Remove reference to match_results against
 a[n] operation

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16646,19 +7785,19 @@
 UK 
 233

- <td width="118">
+ <td width="75">
 23.1.3

- <td width="85">
+ <td width="31">
 Table 84

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Add references to the new containers.

- <td width="536">
+ <td width="466">
 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(),
@@ -16668,7 +7807,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16676,16 +7815,16 @@
 UK 
 234

- <td width="118">
+ <td width="75">
 23.1.3

- <td width="85">
+ <td width="31">
 Table 84

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Ther reference
 to iterator in semantics for back should also allow for
 const_iterator when called on a const-qualified container.
@@ -16694,11 +7833,11 @@

 

- <td width="536">
+ <td width="466">
 Replace iterator with auto in semantics for
 back: { auto tmp = a.end(); --tmp; return *tmp; }

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16706,22 +7845,22 @@
 UK 
 235

- <td width="118">
+ <td width="75">
 23.1.3

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 “The library provides three basic
 kinds of sequence containers: vector, list, and
 deque” - text appears to be out of date re addition
 of array and forward_list

- <td width="536">
+ <td width="466">
 Change the text
 to read: “The library provides five basic kinds of
 sequence containers: array, deque, forward_list, list and
@@ -16729,7 +7868,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16737,16 +7876,16 @@
 UK 
 236

- <td width="118">
+ <td width="75">
 23.1.3

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 [ 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
@@ -16763,10 +7902,10 @@

 

- <td width="536">
+ <td width="466">
 Remove this paragraph

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16774,21 +7913,21 @@
 UK 
 237

- <td width="118">
+ <td width="75">
 23.1.3

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 vector, list, and deque offer the
 programmer different complexity trade-offs and should be
 used accordingly - this ignores array and forward_list

- <td width="536">
+ <td width="466">
 Modify the text
 to read: "array, deque, forward_list, list and vector offer
 the programmer different complexity trade-offs and should
@@ -16796,7 +7935,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16804,16 +7943,16 @@
 UK 
 238

- <td width="118">
+ <td width="75">
 23.1.4

- <td width="85">
+ <td width="31">
 6

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Leaving it
 unspecified whether or not iterator and const_iterator are
 the same type is dangerous, as user code may or may not
@@ -16826,7 +7965,7 @@

 

- <td width="536">
+ <td width="466">
 Change 'unspecified' to 'implementation
 defined'. Add "[Note: As itererator and const_iterator have
 identical semantics in this case, and iterator is
@@ -16834,7 +7973,7 @@
 the One Definition Rule by always using const_iterator in
 their function parameter lists -- end note]

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16842,21 +7981,21 @@
 UK 
 239

- <td width="118">
+ <td width="75">
 23.1.4

- <td width="85">
+ <td width="31">
 85

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 It is not possible to take a move-only key
 out of an unordered container, such as (multi)set or
 (multi)map, or the new hashed containers.

- <td width="536">
+ <td width="466">
 Add below
 a.erase(q), a.extract(q), with the following notation:
 a.extract(q), Return type pair<key, iterator>
@@ -16868,7 +8007,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16876,16 +8015,16 @@
 UK 
 240

- <td width="118">
+ <td width="75">
 23.1.6.1

- <td width="85">
+ <td width="31">
 12

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The axiom
 EmplacePushEquivalence should be asserting the stronger
 contract that emplace and insert return the same iterator
@@ -16900,7 +8039,7 @@

 

- <td width="536">
+ <td width="466">
 Remove the * to deference the returned
 iterator either side of the == in the
 EmplacePushEquivalence axiom, rename the axiom
@@ -16911,38 +8050,38 @@
 position, Args... args) { emplace(c, position, args...) ==
 insert(c, position, value_type(args...)); }

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 57

- <td width="118">
+ <td width="75">
 23.1.6.3

- <td width="85">
+ <td width="31">
 
 1st para, 4th line

 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 Typo, duplicated "to"

 
 "to to model insertion container concepts."

- <td width="536">
+ <td width="466">
 
 Remove one.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16950,26 +8089,26 @@
 UK 
 241

- <td width="118">
+ <td width="75">
 23.2.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 std::array does
 not have an allocator, so need to document an exception to
 the requirements of 23.1.1p3

 

- <td width="536">
+ <td width="466">
 add exception to 23.1.1p3

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -16977,27 +8116,27 @@
 UK 
 242

- <td width="118">
+ <td width="75">
 23.2.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 std:: qualification no longer needed for
 reverse_iterator.

- <td width="536">
+ <td width="466">
 remove std::
 qualification from std::reverse_iterator<iterator>
 and std::reverse_iterator<const_iterator>

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17005,16 +8144,16 @@
 UK 
 243

- <td width="118">
+ <td width="75">
 23.2.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Most containers,
 and types in general have 3 swaps: swap(T&, T&)
 swap(T&&, T&) swap(T&, T&&) But
@@ -17022,10 +8161,10 @@

 

- <td width="536">
+ <td width="466">
 add the other two swaps.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17033,17 +8172,17 @@
 UK 
 244

- <td width="118">
+ <td width="75">
 23.2.1, 
 23.2.6

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The validity of
 the expression &a[n] == &a[0] + n is contingent on
 operator& doing the “right thing” (as
@@ -17056,7 +8195,7 @@

 

- <td width="536">
+ <td width="466">
 Define a ContiguousStrorage and apply it to
 vector,array and string. The Concept (supplied by Alisdair
 M) looks like this: Concept< typename C >
@@ -17065,7 +8204,7 @@
 Contiguous { C c; true = equal_ranges( data( c), data(c) +
 size(c), begin(c)); } };

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17073,16 +8212,16 @@
 UK 
 245

- <td width="118">
+ <td width="75">
 23.2.3

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 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
@@ -17091,7 +8230,7 @@
 library specification in general. See earlier comment for
 details, that would render this one redundant.

- <td width="536">
+ <td width="466">
 Add
 CopyConstructible requirement to the following signatures:
 template <Predicate<auto, T> Pred> requires
@@ -17111,59 +8250,59 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 58

- <td width="118">
+ <td width="75">
 23.2.3.2

- <td width="85">
+ <td width="31">
 
 1st line
 before 1st para

 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 Unnecessary "{" exists before a word iterator like
 "{iterator before_begin()".

- <td width="536">
+ <td width="466">
 
 Remove "{"

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 59

- <td width="118">
+ <td width="75">
 23.2.4.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 Types of the third and forth parameter of splice() are
 iterator at 23.2.4.4, though types of them are
 const_iterator at 23.2.4. (They are both const_iterator on
 N2350)

- <td width="536">
+ <td width="466">
 
 Correct as follows.

@@ -17202,23 +8341,23 @@
 
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 US 83

- <td width="118">
+ <td width="75">
 23.2.6.2

- <td width="85">
+ <td width="31">
 7

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 "shrink_to_fint" should be "shrink_to_fit".

@@ -17227,10 +8366,10 @@

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17238,16 +8377,16 @@
 UK 
 246

- <td width="118">
+ <td width="75">
 23.3.2.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The content of
 this sub-clause is purely trying to describe in words the
 effect of the requires clauses on these operations, now
@@ -17258,12 +8397,12 @@

 

- <td width="536">
+ <td width="466">
 Strike 23.3.2.2 entirely. (but do NOT
 strike these signatures from the class template
 definition!)

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17271,16 +8410,16 @@
 UK 
 247

- <td width="118">
+ <td width="75">
 24.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ge

- <td width="514">
+ <td width="375">
 Iterator
 concepts are not extensive enough to merit a whole new
 header, and should be merged into <concpts>. This is
@@ -17292,13 +8431,13 @@

 

- <td width="536">
+ <td width="466">
 Move the concepts of
 <iterator_concepts> into the <concepts> header.
 We take no position on moving the text from Clause 24 to
 Clause 20 though.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17306,16 +8445,16 @@
 UK 
 248

- <td width="118">
+ <td width="75">
 24.1

- <td width="85">
+ <td width="31">
 6

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The text "so for
 any iterator type there is an iterator value that points
 past the last element of a corresponding container" is
@@ -17325,11 +8464,11 @@

 

- <td width="536">
+ <td width="466">
 Replace the reference to container with a
 more appropriate concept

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17337,26 +8476,26 @@
 UK 
 250

- <td width="118">
+ <td width="75">
 24.1.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 A default implementation should be supplied
 for the post-increment operator to simplify implementation
 of iterators by users.

- <td width="536">
+ <td width="466">
 Copy the Effects clause into the concept
 description as the default implementation. Assumes a
 default value for postincrement_result

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17364,16 +8503,16 @@
 UK 
 251

- <td width="118">
+ <td width="75">
 24.1.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The
 post-increment operator is dangerous for a general
 InputIterator. The multi-pass guarantees that make it
@@ -17387,12 +8526,12 @@

 

- <td width="536">
+ <td width="466">
 Move declaration of postincrement operator
 and postincrement_result type from Interator concept to the
 ForwardIterator concept

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17403,24 +8542,24 @@

 

- <td width="118">
+ <td width="75">
 24.1.2

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 istream_iterator is not a class, but a
 class template

- <td width="536">
+ <td width="466">
 Change 'class' to 'class template' in the
 note.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17428,16 +8567,16 @@
 UK 
 253

- <td width="118">
+ <td width="75">
 24.1.3

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 First sentance
 does not make gramatical sense, Seems to be missing the
 words 'if it' by comparison with similar sentance in other
@@ -17445,12 +8584,12 @@

 

- <td width="536">
+ <td width="466">
 Add the words 'if it' : "X satisfies the
 requirements of an output iterator IF IT meets the
 syntactic and semantic requirements"

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17458,27 +8597,27 @@
 UK 
 254

- <td width="118">
+ <td width="75">
 24.1.3

- <td width="85">
+ <td width="31">
 5

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 This
 postcondition for pre-increment operator should be written
 as an axiom

 

- <td width="536">
+ <td width="466">
 Move the postcondition into the concept
 definition as an axiom

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17486,27 +8625,27 @@
 UK 
 255

- <td width="118">
+ <td width="75">
 24.1.4

- <td width="85">
+ <td width="31">
 4

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 This
 postcondition for pre-increment operator should be written
 as an axiom

 

- <td width="536">
+ <td width="466">
 Move the postcondition into the concept
 definition as an axiom

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17514,27 +8653,27 @@
 UK 
 256

- <td width="118">
+ <td width="75">
 24.1.5

- <td width="85">
+ <td width="31">
 3, 4, 5

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The relationship between pre- and post-
 decrement should be expressed as an axiom.

- <td width="536">
+ <td width="466">
 Move the text
 specification of pre/post-conditions and behaviour into an
 axiom within the BidirectionalIterator concept

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17542,16 +8681,16 @@
 UK 
 257

- <td width="118">
+ <td width="75">
 24.1.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 There is a
 reasonable default for postdecrement_result type, which is
 X. X is required to be regular, therefore CopyConstructible
@@ -17560,11 +8699,11 @@

 

- <td width="536">
+ <td width="466">
 Add the default : typename
 postincrement_result = X;

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17572,28 +8711,28 @@
 UK 
 258

- <td width="118">
+ <td width="75">
 24.1.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 A default
 implementation should be supplied for the post-decrement
 operator to simplify implementation of iterators by users.

 

- <td width="536">
+ <td width="466">
 Copy the Effects clause into the concept
 description as the default implementation. Assumes a
 default value for postincrement_result

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17601,16 +8740,16 @@
 UK 
 259

- <td width="118">
+ <td width="75">
 24.1.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 
 postdecrement_result is effectively returning a copy of the
 original iterator value, so should have similar
@@ -17620,11 +8759,11 @@

 

- <td width="536">
+ <td width="466">
 Add the requirement: requires Iterator<
 postdecrement_result >;

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17632,22 +8771,22 @@
 UK 
 260

- <td width="118">
+ <td width="75">
 24.1.5

- <td width="85">
+ <td width="31">
 6

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The effects clause for post-decrement
 iterator should be available as an axiom and a default
 implementation, where the compiler can make better use of
 it.

- <td width="536">
+ <td width="466">
 Move the Effects
 clause into the BidirectionalIterator concept definition as
 an axiom, and as the default implementation for the
@@ -17655,7 +8794,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17663,17 +8802,17 @@
 UK 
 249

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The semantic for
 operator+= should also be provided as a default
 implementation to simplify implementation of user-defined
@@ -17681,12 +8820,12 @@

 

- <td width="536">
+ <td width="466">
 Copy the text from the effects clause into
 the RandomAccessIterator concept as the default
 implementaiton.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17694,26 +8833,26 @@
 UK 
 261

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 To simplify user
 defined random access iterator types, the
 subscript_reference type should default to reference

 

- <td width="536">
+ <td width="466">
 typename subscript_reference = reference;

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17721,21 +8860,21 @@
 UK 
 262

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 3, 4

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Effects and post-conditions for operator+
 are more useful if expressed as axioms, and supplied as
 default implementations.

- <td width="536">
+ <td width="466">
 Move the effects
 and Postcondition definitions into the RandomAccessIterator
 concept and copy the code in the specification as the
@@ -17743,7 +8882,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17751,21 +8890,21 @@
 UK 
 263

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 5

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 This requirement on operator-= would be
 better expressed as a default implementation in the
 concept, with a matching axiom

- <td width="536">
+ <td width="466">
 Move the
 specification for operator-= from the returns clause into
 an axiom and default implementation within the
@@ -17773,7 +8912,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17781,27 +8920,27 @@
 UK 
 264

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 6

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Effects clauses are better expressed as
 axioms where possible.

- <td width="536">
+ <td width="466">
 Move code in
 operator- effects clause into RandomAccessIterator concept
 as both a default implementation and an axiom

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17809,16 +8948,16 @@
 UK 
 265

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 8

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 This effects
 clause is nonesense. It looks more like an axiom stating
 equivalence, and certainly an effects clause cannot change
@@ -17826,10 +8965,10 @@

 

- <td width="536">
+ <td width="466">
 Strike the Effects clause

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17837,20 +8976,20 @@
 UK 
 266

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 9

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 This sentance should be provided as a
 default definition, along with a matching axiom

- <td width="536">
+ <td width="466">
 Move the Returns
 clause into the spefication for RandomAccessIterator
 operator- as a default implementation. Move the Effects
@@ -17858,7 +8997,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17866,27 +9005,27 @@
 UK 
 267

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 24.1.6

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The code in the
 Requires clause for RandomAccessIterator operator[] would
 be better expressed as an axiom.

 

- <td width="536">
+ <td width="466">
 Rewrite the Requires clause as an axiom in
 the RandomAccessIterator concept

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -17894,16 +9033,16 @@
 UK 
 268

- <td width="118">
+ <td width="75">
 24.1.6

- <td width="85">
+ <td width="31">
 12

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 This note is
 potentialy confusing as __far enters the syntax as a clear
 language extension, but the note treats it as a regular
@@ -17912,29 +9051,29 @@

 

- <td width="536">
+ <td width="466">
 Clean up the note to either avoid using
 language extension, or spell out this is a constraint to
 support extensions.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 60

- <td width="118">
+ <td width="75">
 24.1.8

- <td width="85">
+ <td width="31">
 1st para

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 Capability of an iterator is too much restricted by
 concept.
@@ -18106,12 +9245,12 @@
 
 

- <td width="536">
+ <td width="466">
 Add
 InputRange, OutputRange, ForwardRange, BidirectionalRange
 and RandomAccessRange.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18119,26 +9258,26 @@
 UK 
 269

- <td width="118">
+ <td width="75">
 24.3

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 'decrements for
 negative n' seems to imply a negative number of decrement
 operations, which is odd.

 

- <td width="536">
+ <td width="466">
 Need simple, clearer wording

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18146,28 +9285,28 @@
 UK 
 270

- <td width="118">
+ <td width="75">
 24.3

- <td width="85">
+ <td width="31">
 4

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The reachability
 constraint in p5 means that a negavite result, implying
 decrements operations in p4, is not possible

 

- <td width="536">
+ <td width="466">
 Split the two overloads into separate
 descriptions, where reachability is permitted to be in
 either direction for RandomAccessIterator

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18175,16 +9314,16 @@
 UK 
 271

- <td width="118">
+ <td width="75">
 24.3

- <td width="85">
+ <td width="31">
 6,7

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 next/prev return
 an incremented iterator without changing the value of the
 original iterator. However, even this may invalidate an
@@ -18193,11 +9332,11 @@

 

- <td width="536">
+ <td width="466">
 Replace InputIterator constraint with
 FOrwardIterator in next and prev function templates.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18205,16 +9344,16 @@
 UK 
 272

- <td width="118">
+ <td width="75">
 24.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 reverse_iterator
 and move_iterator use different formulations for their
 comparison operations. move_iterator merely requires the
@@ -18233,12 +9372,12 @@

 

- <td width="536">
+ <td width="466">
 Rephrase the reverse_iterator comparison
 operations using only operators < and ==, as per the
 move_iterator specification.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18246,16 +9385,16 @@
 UK 
 274

- <td width="118">
+ <td width="75">
 24.4, 24.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The subclauses
 for standard iterator adaptors could be better organised.
 There are essentially 3 kinds of iterator wrappers
@@ -18268,13 +9407,13 @@

 

- <td width="536">
+ <td width="466">
 Promote 24.4.2 [insert.iterators] up one
 level to 24.6. Emphasize that insert iterators adapt
 containers Retarget 24.4 [predef.iterators] as iterator
 adapters for iterator templates that wrap other iterators.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18282,16 +9421,16 @@
 UK 
 275

- <td width="118">
+ <td width="75">
 24.4.1.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The constructor
 template taking a single Iterator argument will be selected
 for Copy Initialization instead of the non-template
@@ -18300,11 +9439,11 @@

 

- <td width="536">
+ <td width="466">
 The reverse_iterator template constructor
 taking a single Iterator argument should be explicit.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18312,16 +9451,16 @@
 UK 
 276

- <td width="118">
+ <td width="75">
 24.4.1.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 It is odd to
 have a mix of declaration stlyes for operator+ overloads.
 Prefer if either all are member functions, or all are
@@ -18329,11 +9468,11 @@

 

- <td width="536">
+ <td width="466">
 Make the member operators taking a
 difference_type argument non-member operators

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18341,16 +9480,16 @@
 UK 
 277

- <td width="118">
+ <td width="75">
 24.4.1.2.1

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The default
 constructor default-initializes current, rather than
 value-initializes. This means that when Iterator
@@ -18363,7 +9502,7 @@

 

- <td width="536">
+ <td width="466">
 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
@@ -18371,7 +9510,7 @@
 iii/ Add a note to the description emphasizing the singular
 nature of a value-initialized reserve iterator.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18379,16 +9518,16 @@
 UK 
 278

- <td width="118">
+ <td width="75">
 24.4.1.2.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 There is an
 inconsistency between the constructor taking an iterator
 and the constructor template taking a reverse_iterator
@@ -18398,11 +9537,11 @@

 

- <td width="536">
+ <td width="466">
 Change the const reverse_iterator
 & parameter to pass-by-value

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18410,17 +9549,17 @@
 UK 
 279

- <td width="118">
+ <td width="75">
 24.4.1.2.12, 
 24.4.3.2.12

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The reason the
 return type became unspecified is LWG issue 386. This
 reasoning no longer applies as there are at least two ways
@@ -18429,11 +9568,11 @@

 

- <td width="536">
+ <td width="466">
 Specify the return type using either
 decltype or the Iter concept map

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18441,16 +9580,16 @@
 UK 
 280

- <td width="118">
+ <td width="75">
 24.4.1.2.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The presence of
 the second iterator value is surprising for many readers
 who underestimate the size of a reverse_iterator object.
@@ -18459,11 +9598,11 @@

 

- <td width="536">
+ <td width="466">
 Add reverse_iterator expsoition only member
 tmp as a comment to class declaration, as a private member

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18471,16 +9610,16 @@
 UK 
 281

- <td width="118">
+ <td width="75">
 24.4.1.2.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The current
 specification for return value will always be a true
 pointer type, but reverse_iterator supports proxy iterators
@@ -18488,12 +9627,12 @@

 

- <td width="536">
+ <td width="466">
 Replace the existing returns specification
 with a copy of the operator* specification that returns
 this->tmp.operator->

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18501,7 +9640,7 @@
 UK 
 282

- <td width="118">
+ <td width="75">
 24.4.2.1, 
 24.4.2.2.2, 
 24.4.2.3, 
@@ -18509,23 +9648,23 @@
 24.4.2.5, 
 24.4.2.6.2

- <td width="85">
+ <td width="31">
 n/a

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Insert iterators of move-only types will
 move from lvalues

- <td width="536">
+ <td width="466">
 Add an additional constrained overload for
 operator= that requires
 !CopyConstructible<Cont::value_type> and mark it
 =delete.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18533,17 +9672,17 @@
 UK 
 283

- <td width="118">
+ <td width="75">
 24.4.2.5, 
 24.4.2.6.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 postincrement operator overloads
 traditionally return by value - insert_iterator is declared
 as return by reference. The change is harmless in this
@@ -18551,41 +9690,41 @@
 matching change for consistency, or this function should
 return-by-value

- <td width="536">
+ <td width="466">
 change operator++(int) overload to return
 by value, not reference. Affects both class summary and
 operator definition in p

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 61

- <td width="118">
+ <td width="75">
 24.4.3.2.1

- <td width="85">
+ <td width="31">
 2nd para, 1st
 line

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 Typo.

 
 "intializing" should be "initializing"

- <td width="536">
+ <td width="466">
 Add
 "i"

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18593,26 +9732,26 @@
 UK 
 284

- <td width="118">
+ <td width="75">
 24.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The stream
 iterators need constraining with concepts/requrires
 clauses.

 

- <td width="536">
+ <td width="466">
 Provide constraints

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18620,27 +9759,27 @@
 UK 
 285

- <td width="118">
+ <td width="75">
 24.5.1

- <td width="85">
+ <td width="31">
 1,2

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 Much of the
 content of p1 and the whole of p2 is a redundant
 redefinition of InputIterator. It should be simplified

 

- <td width="536">
+ <td width="466">
 Strike p2. Simplify p1 and add a
 cross-reference to the definition of InputIterator concept.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18648,16 +9787,16 @@
 UK 
 286

- <td width="118">
+ <td width="75">
 24.5.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 To the casual
 reader it is not clear if it is intended to be able to
 assign to istream_iterator objects. Specifying the copy
@@ -18666,12 +9805,12 @@

 

- <td width="536">
+ <td width="466">
 Either provide a similar definition to the
 copy-assign operator as for the copy constructor, or strike
 the copy constructor

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18679,16 +9818,16 @@
 UK 
 287

- <td width="118">
+ <td width="75">
 24.5.1.1

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 It is not clear
 what the intial state of an istream_iterator should be. Is
 _value_ initialized by reading the stream, or default/value
@@ -18700,12 +9839,12 @@

 

- <td width="536">
+ <td width="466">
 Specify _value_ is initialized by reading
 the stream, or the iterator takes on the end-of-stream
 value if the stream is empty

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18713,27 +9852,27 @@
 UK 
 288

- <td width="118">
+ <td width="75">
 24.5.1.1

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The provided specification is vacuous,
 offering no useful information.

- <td width="536">
+ <td width="466">
 Either strike
 the specification of the copy constructor, or simply
 replace it with an = default definition.

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18741,16 +9880,16 @@
 UK 
 289

- <td width="118">
+ <td width="75">
 24.5.1.2

- <td width="85">
+ <td width="31">
 6

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 It is very hard
 to pick up the correct specification for
 istream_iterator::operator== as the complete specification
@@ -18762,12 +9901,12 @@

 

- <td width="536">
+ <td width="466">
 Merge 24.5.1p3, equality comparison of
 end-of-stream-iterators, into 24.5.1.2p6, the specification
 of the equality operator for istream_iterator.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18775,16 +9914,16 @@
 UK 
 290

- <td width="118">
+ <td width="75">
 24.5.2

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The character
 type of a string delimiter for an ostream_iterator should
 be const charT *, the type of the elements, not char *, a
@@ -18792,10 +9931,10 @@

 

- <td width="536">
+ <td width="466">
 Replace char * with const charT *

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18803,16 +9942,16 @@
 UK 
 291

- <td width="118">
+ <td width="75">
 24.5.2.2

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 ostream_iterator
 postincrement operator returns by reference rather than by
 value. This may be a small efficiency gain, but it is
@@ -18820,38 +9959,38 @@

 

- <td width="536">
+ <td width="466">
 ostream_iterator operator++(int);

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 FR 34

- <td width="118">
+ <td width="75">
 24.5.3 
 [istreambuf. 
 iterator]

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 There are two public
 sections, and the content of the second one is indented
 with respect to the first. I don't it should be.

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18859,27 +9998,27 @@
 UK 
 292

- <td width="118">
+ <td width="75">
 24.5.3

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 Prefer the use
 of the new nullptr constant to the zero literal when using
 a null pointer in text.

 

- <td width="536">
+ <td width="466">
 Change istreambuf_iterator(0) to
 istreambuf_iterator(nullptr)

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18887,21 +10026,21 @@
 UK 
 293

- <td width="118">
+ <td width="75">
 24.5.3

- <td width="85">
+ <td width="31">
 2,3,4

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The listed paragraphs redundantly redefine
 an input iterator, and redundancy can be a dangerous thing
 in a specification. Suggest a simpler phrasing below.

- <td width="536">
+ <td width="466">
 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
@@ -18914,7 +10053,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18922,21 +10061,21 @@
 UK 
 294

- <td width="118">
+ <td width="75">
 24.5.3.2

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Implicit converting constructors can be
 invoked at surprising times, so there should always be a
 good reason for declaring one.

- <td width="536">
+ <td width="466">
 Mark the two
 single-argument constructors take a stream or stream buffer
 as explicit. The proxy constructor should remain implicit.
@@ -18948,7 +10087,7 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -18956,16 +10095,16 @@
 UK 
 295

- <td width="118">
+ <td width="75">
 25

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 THere is a level
 of redundancy in the library specification for many
 algorithms that can be eliminated with the combination of
@@ -18975,27 +10114,27 @@

 

- <td width="536">
+ <td width="466">
 Adopt n2743, or an update of that paper.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 62

- <td width="118">
+ <td width="75">
 25, 25.3.1.5, 
 26.3.6.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 The return types of is_sorted_until function and
@@ -19011,14 +10150,14 @@
 

- <td width="536">
+ <td width="466">
 
 Change "is_sorted_until" to "sorted_bound"

 
 Change "is_heap" to "heap_bound"

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19026,16 +10165,16 @@
 UK 
 296

- <td width="118">
+ <td width="75">
 25.1.8

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The 'Returns' of
 adjacent_find requires only HasEqualTo, or a Predicate.
 Requiring EqualityComparable or EquivalenceRelation seems
@@ -19043,11 +10182,11 @@

 

- <td width="536">
+ <td width="466">
 Change EqualityComparable to HasEqualTo and
 EquivalnceRelation to Predicate

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19055,28 +10194,28 @@
 UK 
 297

- <td width="118">
+ <td width="75">
 25.2.11

- <td width="85">
+ <td width="31">
 6

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The definition
 of rotate_copy is very complicated. It is equivalent to:
 return copy(first, middle, copy(middle, last, result));

 

- <td width="536">
+ <td width="466">
 Change 'effects' to, returns, requires,
 complexity to: effects: equivalent to: return copy(first,
 middle, copy(middle, last, result));

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19084,24 +10223,24 @@
 UK 
 298

- <td width="118">
+ <td width="75">
 25.2.13

- <td width="85">
+ <td width="31">
 13

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 partition_point requires a partitioned
 array

- <td width="536">
+ <td width="466">
 requires: is_partitioned(first, last, pred)
 != false;

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19109,28 +10248,28 @@
 UK 
 299

- <td width="118">
+ <td width="75">
 25.2.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 Should be consistent in style use of
 concepts in template parameter lists. The
 auto-OutputIterator sytle used in std::copy is probably
 preferred.

- <td width="536">
+ <td width="466">
 Change way signature is declared:
 template<InputIterator InIter, OutputIterator<auto,
 RvalueOf<InIter::reference>::type> OutIter>
 OutIter move(InIter first, InIter last, OutIter result);

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19138,16 +10277,16 @@
 UK 
 300

- <td width="118">
+ <td width="75">
 25.2.3

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Since publishing
 the original standard, we have learned that swap is a
 fundamental operation, and several common idioms rely on it
@@ -19163,14 +10302,14 @@

 

- <td width="536">
+ <td width="466">
 Move primary swap template from
 <algorithm> into <utility>. Move 25.2.3 to
 somewhere under 20.2. Require <algorithm> to #include
 <utility> to access pair and provide legacy support
 for finding swap.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19178,16 +10317,16 @@
 UK 
 301

- <td width="118">
+ <td width="75">
 25.2.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 replace and
 replace_if have the requirement: OutputIterator<Iter,
 Iter::reference> Which implies they need to copy some
@@ -19198,11 +10337,11 @@

 

- <td width="536">
+ <td width="466">
 Remove OutputIterator<Iter,
 Iter::reference> from replace and replace_if

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19210,27 +10349,27 @@
 UK 
 302

- <td width="118">
+ <td width="75">
 25.3

- <td width="85">
+ <td width="31">
 4

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 the concept
 StrictWeakOrder covers the definition of a strict weak
 ordering, described in paragraph 4.

 

- <td width="536">
+ <td width="466">
 Remove 4, and mention StrictWeakOrder in
 paragraph 1.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19238,27 +10377,27 @@
 UK 
 303

- <td width="118">
+ <td width="75">
 25.3

- <td width="85">
+ <td width="31">
 6

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 This paragraph just describes
 is_partitioned

- <td width="536">
+ <td width="466">
 6 A sequence
 [start,finish) is partitioned with respect to an expression
 f(e) if is_partitioned(start, finish, e) != false

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19266,26 +10405,26 @@
 UK 
 304

- <td width="118">
+ <td width="75">
 25.3.6

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The requires
 clauses of push_heap, pop_heap and make_heap are
 inconsistently formatted, dispite being identical

 

- <td width="536">
+ <td width="466">
 Format them identically.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19293,68 +10432,68 @@
 UK 
 305

- <td width="118">
+ <td width="75">
 25.3.7

- <td width="85">
+ <td width="31">
 1, 9, 17

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The negative requirement on IsSameType is a
 hold-over from an earlier draught with a variadic template
 form of min/max algorith. It is no longer necessary.

- <td width="536">
+ <td width="466">
 Strike the !IsSameType<T, Compare>
 constraint on min/max/minmax algorithms

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 US 84

- <td width="118">
+ <td width="75">
 26

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ge

- <td width="514">
+ <td width="375">
 
 Parts of the numerics chapter are not concept enabled.

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 FR 35

- <td width="118">
+ <td width="75">
 26.3 
 [Complex 
 numbers]

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 Instantiations of the class
 template complex<> have to be allowed for integral
 types, to reflect existing practice and ISO standards
@@ -19362,10 +10501,10 @@

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19373,42 +10512,42 @@
 UK 
 306

- <td width="118">
+ <td width="75">
 26.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Random number
 library component cannot be used in constrained templates

 

- <td width="536">
+ <td width="466">
 Provide constraints for the random number
 library

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 63

- <td width="118">
+ <td width="75">
 26.4.8.5.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 No
 constructor of discrete_distribution that accepts
 initializer_list.
@@ -19439,30 +10578,30 @@
 
 

- <td width="536">
+ <td width="466">
 Add
 the following constructer.

 
 discrete_distribution(initializer_list<result_type>);

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 64

- <td width="118">
+ <td width="75">
 26.5.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 “valarray<T>& operator+=
@@ -19471,12 +10610,12 @@
 
 

- <td width="536">
+ <td width="466">
 Add
 valarray<T>& operator+=
 (initializer_list<T>);

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19484,16 +10623,16 @@
 UK 
 307

- <td width="118">
+ <td width="75">
 26.7

- <td width="85">
+ <td width="31">
 Footnote 288

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 The footnote
 refers to TR1, which is not a defined term in this
 standard. Drop the reference to TR1, those templates are a
@@ -19502,35 +10641,35 @@

 

- <td width="536">
+ <td width="466">
 Drop the reference to TR1.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 US 85

- <td width="118">
+ <td width="75">
 27

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ge

- <td width="514">
+ <td width="375">
 The
 input/output chapter is not concept enabled.

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -19538,43 +10677,43 @@
 UK 
 308

- <td width="118">
+ <td width="75">
 27

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 
 iostreams library cannot be used from
 constrained templates

 

- <td width="536">
+ <td width="466">
 Provide constraints for the iostreams
 library, clause 27

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 65

- <td width="118">
+ <td width="75">
 27.4.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 Switch from
 “unspecified-bool-type” to
 

- <td width="536">
+ <td width="466">
 
 Replace "operator unspecified-bool-type() const;"
 with "explicit operator bool() const;"

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 66

- <td width="118">
+ <td width="75">
 27.4.4.3

- <td width="85">
+ <td width="31">
 1st para

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 Switch from
 “unspecified-bool-type” to
 

- <td width="536">
+ <td width="466">
 
 Replace "operator unspecified-bool-type() const;"
 with "explicit operator bool() const;"

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 FR 36

- <td width="118">
+ <td width="75">
 27.6.1.2.2 
 [istream. 
 formatted. 
 arithmetic]

- <td width="85">
+ <td width="31">
 1, 2, and 3

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 iostate err = 0;

 
@@ -19652,29 +10791,29 @@

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 FR 37

- <td width="118">
+ <td width="75">
 27.6.1.2.2 
 [istream. 
 formatted. 
 arithmetic]

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 else if (lval <
 numeric_limits<int>::min()

@@ -19688,30 +10827,30 @@

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 67

- <td width="118">
+ <td width="75">
 27.7.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 basic_stringbuf dose not use concept.

- <td width="536">
+ <td width="466">
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -19837,27 +10976,27 @@
 
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 68

- <td width="118">
+ <td width="75">
 27.7.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 basic_istringstream dose not use concept.

- <td width="536">
+ <td width="466">
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -20014,27 +11153,27 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 69

- <td width="118">
+ <td width="75">
 27.7.3

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 basic_ostringstream dose not use concept.

- <td width="536">
+ <td width="466">
 
 Replace “class Allocator” to “Allocator
 Alloc”.
@@ -20192,30 +11331,30 @@
 
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 71

- <td width="118">
+ <td width="75">
 27.7.3

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 Typo.

 "template" is missing in
 "class basic_ostringstream" of the title of the chapter.

- <td width="536">
+ <td width="466">
 
 Correct as follows.

@@ -20234,27 +11373,27 @@
 27.7.3 Class template
 basic_ostringstream

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 72

- <td width="118">
+ <td width="75">
 27.7.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 basic_stringstream dose not use concept.

- <td width="536">
+ <td width="466">
 
 Replace "class Allocator" to "Allocator Alloc".

@@ -20406,23 +11545,23 @@

 }

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 73

- <td width="118">
+ <td width="75">
 27.8.1.14

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 It is a problem
 from C++98, fstream cannot appoint a filename of wide
@@ -20431,36 +11570,36 @@
 
 

- <td width="536">
+ <td width="466">
 Add
 interface corresponding to wchar_t, char16_t and char32_t.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 US 86

- <td width="118">
+ <td width="75">
 28

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ge

- <td width="514">
+ <td width="375">
 The
 regular expressions chapter is not concept enabled.

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -20468,26 +11607,26 @@
 UK 
 309

- <td width="118">
+ <td width="75">
 28

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Regular
 expressions cannot be used in constrained templates

 

- <td width="536">
+ <td width="466">
 Provide constraints for the regular
 expression library, clause 28

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -20495,25 +11634,25 @@
 UK 
 310

- <td width="118">
+ <td width="75">
 28

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The regex chapter uses iterators in the old
 pre-concept style, it should be changed to use concepts
 instead.

- <td width="536">
+ <td width="466">
 Use concepts for iterator template
 arguments throughout.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -20521,16 +11660,16 @@
 UK 
 314

- <td width="118">
+ <td width="75">
 28.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The swap
 overloads for regex classes are only supplied for l-value
 references. Other sections of the library (eg 21 strings or
@@ -20540,13 +11679,13 @@

 

- <td width="536">
+ <td width="466">
 Add the missing overloads to 28.4 and the
 corresponding later sections in 28 for each swap function.
 We want to accept AMs paper which proposes a single
 overload with two r-value references

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -20554,16 +11693,16 @@
 UK 
 315

- <td width="118">
+ <td width="75">
 28.4

- <td width="85">
+ <td width="31">
 p6

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 6 Effects:
 string_type str(first, last); return
 use_facet<collate<charT> >(
@@ -20572,11 +11711,11 @@

 

- <td width="536">
+ <td width="466">
 Reword to effect clause to use legal
 iterator dereferences

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -20584,26 +11723,26 @@
 UK 
 316

- <td width="118">
+ <td width="75">
 28.4 ff

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The constructors
 for regex classes do not have an r-value overload.

 

- <td width="536">
+ <td width="466">
 Add the missing r-value constructors to
 regex classes.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -20611,21 +11750,21 @@
 UK 
 317

- <td width="118">
+ <td width="75">
 28.8

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 basic_string has both a constructor and an
 assignment operator that accepts an initializer list,
 basic_regex should have the same.

- <td width="536">
+ <td width="466">
 In the
 basic_regex synopsis, after: basic_regex&
 operator=(const charT* ptr); add: basic_regex&
@@ -20636,23 +11775,23 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 JP 74

- <td width="118">
+ <td width="75">
 28.8

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 “basic_regx & operator=
@@ -20661,11 +11800,11 @@
 
 

- <td width="536">
+ <td width="466">
 Add
 basic_regx & operator= (initializer_list<T>);

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -20673,26 +11812,26 @@
 UK 
 318

- <td width="118">
+ <td width="75">
 28.8.2

- <td width="85">
+ <td width="31">
 para 22

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 Constructor
 definition should appear with the other constructors not
 after assignment ops.

 

- <td width="536">
+ <td width="466">
 Move para 22 to just after para 17.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -20700,16 +11839,16 @@
 UK 
 319

- <td width="118">
+ <td width="75">
 28.12.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 It was always expected that
 regex_token_iterator would be constructible from an array
 literal: indeed ideally this is the prefered method of
@@ -20722,7 +11861,7 @@
 initializer_lists we should use them to remove this
 particular wart.

- <td width="536">
+ <td width="466">
 To the synopsis
 for regex_token_iterator, after template <std::size_t
 N> regex_token_iterator(BidirectionalIterator a,
@@ -20745,33 +11884,33 @@

 

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 US 87

- <td width="118">
+ <td width="75">
 29

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ge

- <td width="514">
+ <td width="375">
 The
 atomics chapter is not concept enabled. The adopted paper,
 N2427, did have those concepts.

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 Create an issue for concepts in the atomics chapter. See
 N2427. Needs to also consider issues 923 and 924. 

@@ -20780,26 +11919,26 @@
 UK 
 311

- <td width="118">
+ <td width="75">
 29

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Atomic types
 cannot be used generically in a constrained template

 

- <td width="536">
+ <td width="466">
 Provide constraints for the atomics
 library, clause 29

- <td width="178">
+ <td width="225">
 Duplicate of US 87. 

 <tr valign="top">
@@ -20807,23 +11946,23 @@
 UK 
 312

- <td width="118">
+ <td width="75">
 29

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The contents of the <stdatomic.h>
 header are not listed anywhere, and <cstdatomic> is
 listed as a C99 header in chapter 17. If we intend to use
 these for compatibility with a future C standard, we should
 not use them now.

- <td width="536">
+ <td width="466">
 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
@@ -20832,7 +11971,7 @@
 adds atomic operations to C we can add corresponding
 headers to table 14 with a TR.

- <td width="178">
+ <td width="225">
 Create an issue. Assigned to Lawrence Crowl. May be
 resolvable with a footnote for clarity stating that the header is
 defined where it exists. 
@@ -20841,21 +11980,21 @@
 <td width="29">
 JP 75

- <td width="118">
+ <td width="75">
 29

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 A
 definition of enum or struct is the style of C using
 typedef.

- <td width="536">
+ <td width="466">
 
 Change to a style of C++.

@@ -21083,7 +12222,7 @@

 }

- <td width="178">
+ <td width="225">
 Recommend to reject the comment: We believe the current
 syntax is most appropriate for an interface that is intended to be
 highly compatible with C. 
@@ -21093,21 +12232,21 @@
 UK 
 313

- <td width="118">
+ <td width="75">
 29.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 seq_cst fences don't necessarily guarantee
 ordering
 http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926

- <td width="536">
+ <td width="466">
 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
@@ -21118,27 +12257,27 @@

 

- <td width="178">
+ <td width="225">
 Hans to make proposal. See LWG Issue 926. 

 <tr valign="top">
 <td width="29">
 US 88

- <td width="118">
+ <td width="75">
 29.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 The "lockfree" facilities do
 not tell the programmer enough.

- <td width="536">
+ <td width="466">
 
 Expand the "lockfree" facilities. See the attached paper
 "Issues with the C++ Standard" under Chapter 29,
@@ -21146,7 +12285,7 @@

 

- <td width="178">
+ <td width="225">
 Create an issue, will require more discussion. Assigned
 to Lawrence. Description of issue should be based on what is in the
 additional notes for US 88. 
@@ -21155,16 +12294,16 @@
 <td width="29">
 US 89

- <td width="118">
+ <td width="75">
 29.3.1

- <td width="85">
+ <td width="31">
 Table 122

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 The
 types in the table "Atomics for standard typedef types"
 should be typedefs, not classes. These semantics are
@@ -21172,11 +12311,11 @@

 

- <td width="536">
+ <td width="466">
 Change the classes to
 typedefs.

- <td width="178">
+ <td width="225">
 LWG Issue 937. Direct the editor to turn the types into
 typedefs as proposed in the comment. Paper approved by committee used
 typedefs, this appears to have been introduced as an editorial change.
@@ -21184,20 +12323,20 @@
 <td width="29">
 US 90

- <td width="118">
+ <td width="75">
 29.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 Are atomic functions allowed
 to have non-volatile overloads?

- <td width="536">
+ <td width="466">
 
 Allow non-volatile overloads. See the attached paper
 "Issues with the C++ Standard, under Chapter 29, "Are
@@ -21205,7 +12344,7 @@

 

- <td width="178">
+ <td width="225">
 Create an issue. Assigned to Lawrence Crowl. Should
 explicitly consider the process shared issue. 

@@ -21213,21 +12352,21 @@
 <td width="29">
 US 91

- <td width="118">
+ <td width="75">
 29.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 Whether or not a failed
 compare_exchange is a RMW operation (as used in 1.10
 [intro.multithread]) is unclear.

- <td width="536">
+ <td width="466">
 
 Make failing compare_exchange operations not be RMW. See
@@ -21236,7 +12375,7 @@

 

- <td width="178">
+ <td width="225">
 Create an issue, goes to review. Attention: Howard.
 Group agrees with the resolution as proposed by Anthony Williams in the
 attached note. 
@@ -21245,20 +12384,20 @@
 <td width="29">
 US 92

- <td width="118">
+ <td width="75">
 29.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 The effect of
 memory_order_consume with atomic RMW operations is unclear.

- <td width="536">
+ <td width="466">
 
 Follow the lead of fences [atomics.fences], and promote
 memory_order_consume to memory_order_acquire with RMW
@@ -21266,7 +12405,7 @@

 

- <td width="178">
+ <td width="225">
 Create an issue. Assigned to Lawrence. Resolution
 requires proposed wording. 

@@ -21274,16 +12413,16 @@
 <td width="29">
 JP 76

- <td width="118">
+ <td width="75">
 30

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 A
 description for "Throws: Nothing." are not unified.

@@ -21291,7 +12430,7 @@
 the part without throw, "Throws: Nothing." should be
 described.

- <td width="536">
+ <td width="466">
 Add
 "Throws: Nothing." to the following.

@@ -21320,32 +12459,32 @@
 
 

- <td width="178">
+ <td width="225">
 Pass on to editor. 

 <tr valign="top">
 <td width="29">
 US 93

- <td width="118">
+ <td width="75">
 30

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ge

- <td width="514">
+ <td width="375">
 The
 thread chapter is not concept enabled.

 

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 Create an issue. Need to find volunteers to work on
 this. 

@@ -21357,24 +12496,24 @@

 

- <td width="118">
+ <td width="75">
 30

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Threads library cannot be used in
 constrained templates

- <td width="536">
+ <td width="466">
 Provide constraints for the threads
 library, clause 30

- <td width="178">
+ <td width="225">
 Duplicate of US 93. 

 <tr valign="top">
@@ -21382,16 +12521,16 @@
 UK 
 321

- <td width="118">
+ <td width="75">
 30

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 Throughout this
 clause, the term Requires: is used to introduce compile
 time requirements, which we expect to be replaced with
@@ -21405,32 +12544,32 @@

 

- <td width="536">
+ <td width="466">
 Decument Preconditions: paragraphs in
 17.5.2.4, and use consistently through rest of the library.

- <td width="178">
+ <td width="225">
 Pass on to editor. 

 <tr valign="top">
 <td width="29">
 US 94

- <td width="118">
+ <td width="75">
 30.1.2

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 The first sentence of para 1 suggests that no other
 library function is permitted to call operating system or
 low level APIs.

- <td width="536">
+ <td width="466">
 Rewrite para 1
 as: “ Some functions described
@@ -21444,27 +12583,27 @@

 

- <td width="178">
+ <td width="225">
 

 Reclassify as editorial. Pass on to editor, wording roughly as proposed.<tr valign="top">
 <td width="29">
 US 95

- <td width="118">
+ <td width="75">
 30.1.3

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 “native_handle_type” is a typedef, not a
 class member.

- <td width="536">
+ <td width="466">
 Several classes
 described in this Clause have a member native_handle (of
@@ -21481,7 +12620,7 @@

 

- <td width="178">
+ <td width="225">
 

 Not a defect. native_handle_type is a typedef, but it is also a member of
@@ -21489,19 +12628,19 @@
 <td width="29">
 US 96

- <td width="118">
+ <td width="75">
 30.1.4

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 There is no definition here for monotonic clock.

- <td width="536">
+ <td width="466">
 Implementations
 should use a monotonic clock to measure time for
@@ -21511,7 +12650,7 @@

 

- <td width="178">
+ <td width="225">
 

 Create an issue, together with UK 322. Detlef will write the issue, but not
@@ -21520,27 +12659,27 @@
 UK 
 322

- <td width="118">
+ <td width="75">
 30.1.4

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Not all systms
 can provide a monotonic clock. How are they expected to
 treat a _for function?

 

- <td width="536">
+ <td width="466">
 Add at least a note explaining the intent
 for systems that do not support a monotonic clock.

- <td width="178">
+ <td width="225">
 

 Create an issue, together with UK 96. Note that the specification as is
@@ -21551,16 +12690,16 @@
 UK 
 323

- <td width="118">
+ <td width="75">
 30.2.1

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The presence of
 a non-explicit variadic template constructor alongside an
 explicit single-argument constructor can lead to behaviour
@@ -21573,13 +12712,13 @@

 

- <td width="536">
+ <td width="466">
 Mark constructor template <class F,
 class ...Args> thread(F&& f, Args&&...
 args); as explicit and remove the single-argument
 constructor.

- <td width="178">
+ <td width="225">
 

 Create an issue, goes to review. Attention: Howard. Group agrees with the
@@ -21588,23 +12727,23 @@
 UK 
 324

- <td width="118">
+ <td width="75">
 30.2.1.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 thread::id
 objects should be as useable in hashing containers as they
 are in ordered associative containers.

 

- <td width="536">
+ <td width="466">
 Add thread::id
 support for std::hash

@@ -21614,7 +12753,7 @@

 

- <td width="178">
+ <td width="225">
 

 Not a defect. See [unord.hash], where std::thread:id is already listed as a
@@ -21622,16 +12761,16 @@
 <td width="29">
 JP 77

- <td width="118">
+ <td width="75">
 30.2.1.2

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 
 "CopyConstructible" and "MoveConstructible" in
@@ -21642,86 +12781,86 @@
 
 

- <td width="536">
+ <td width="466">
 Add
 a concept for constructor of thread.

- <td width="178">
+ <td width="225">
 

 Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
 <td width="29">
 JP 78

- <td width="118">
+ <td width="75">
 30.2.1.2

- <td width="85">
+ <td width="31">
 
 4th para, 1st line

 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 In
 "F and each Ti in Args", 'Ti' is not clear.

- <td width="536">
+ <td width="466">
 
 Replace "Ti" with "args"

- <td width="178">
+ <td width="225">
 

 Pass on to editor.<tr valign="top">
 <td width="29">
 US 97

- <td width="118">
+ <td width="75">
 30.2.1.3

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 detach-on-destruction may result in
 “escaped” threads accessing objects with
 bounded lifetime after the end of their lifetime.

- <td width="536">
+ <td width="466">
 See document WG21 N2802=08-0312 written by Hans Boehm.

- <td width="178">
+ <td width="225">
 

 Create an issue. To be discussed in full library group.<tr valign="top">
 <td width="29">
 US 98

- <td width="118">
+ <td width="75">
 30.2.1.3, 
 30.2.1.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 

- <td width="514">
+ <td width="375">
 The current defined behavior
 for the std::thread destructor is to detach the thread.
 Unfortunately, this behavior exposes programmers to tricky,
 hard-to-diagnose, undefined behavior.

- <td width="536">
+ <td width="466">
 
 Change destruction behavior to undefined behavior, with a
 note strongly encouraging termination. See the attached
@@ -21730,7 +12869,7 @@

 

- <td width="178">
+ <td width="225">
 

 Duplicate of US 97.<tr valign="top">
@@ -21738,22 +12877,22 @@
 UK 
 325

- <td width="118">
+ <td width="75">
 30.3.3

- <td width="85">
+ <td width="31">
 2

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 We believe constexpr literal values should
 be a more natural expression of empty tag types than extern
 objects as it should improve the compilers ability to
 optimize the empty object away completely.

- <td width="536">
+ <td width="466">
 Replace the
 extern declarations: extern const defer_lock_t defer_lock;
 extern const try_to_lock_t try_to_lock; extern const
@@ -21763,7 +12902,7 @@

 

- <td width="178">
+ <td width="225">
 

 Create an issue. Move to review, attention: Howard. The current
@@ -21773,16 +12912,16 @@
 UK 
 326

- <td width="118">
+ <td width="75">
 30.3.3.2.1

- <td width="85">
+ <td width="31">
 7

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The precondition
 that the mutex is not owned by this thread offers
 introduces the risk of un-necessary undefined behaviour
@@ -21796,10 +12935,10 @@

 

- <td width="536">
+ <td width="466">
 Strike 30.3.3.2.1p7

- <td width="178">
+ <td width="225">
 

 Create an issue. Move to review, attention: Howard. Proposed resolution is
@@ -21808,16 +12947,16 @@
 UK 
 327

- <td width="118">
+ <td width="75">
 30.3.3.2.2

- <td width="85">
+ <td width="31">
 4, 9, 14, 19

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Not clear what
 the specification for error condition
 resource_deadlock_would_occur means. It is perfectly
@@ -21836,12 +12975,12 @@

 

- <td width="536">
+ <td width="466">
 Add a precondition !owns. Change the 'i.e.'
 in the error condition to be 'e.g.' to allow for this
 condition to propogate deadlock detection by the host OS.

- <td width="178">
+ <td width="225">
 

 Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock
@@ -21852,28 +12991,28 @@
 UK 
 328

- <td width="118">
+ <td width="75">
 30.3.3.2.2

- <td width="85">
+ <td width="31">
 20

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 There is a missing precondition that owns
 is true, or an if(owns) test is missing from the effect
 clause

- <td width="536">
+ <td width="466">
 Add a
 precondition that owns == true. Add an error condition to
 detect a violation, rather than yield undefined behaviour.

 

- <td width="178">
+ <td width="225">
 

 Handle in same issue as UK 327. Also uncertain that the proposed resolution
@@ -21882,23 +13021,23 @@
 UK 
 329

- <td width="118">
+ <td width="75">
 30.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 future, promise and packaged_task provide a
 framework for creating future values, but a simple function
 to tie all three components together is missing. Note that
 we only need a *simple* facility for C++0x. Advanced thread
 pools are to be left for TR2.

- <td width="536">
+ <td width="466">
 Provide a simple
 function along the lines of: template< typename F,
 typename ... Args > requires Callable< F, Args...
@@ -21921,7 +13060,7 @@

 

- <td width="178">
+ <td width="225">
 

 Not a defect. This class of feature has been rejected by the committee as a
@@ -21930,30 +13069,30 @@
 UK 
 330

- <td width="118">
+ <td width="75">
 30.5.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 30.5.1 (and then 30.5.7) refer to a
 specialisation of
 constructible_with_allocator_prefix<> However this
 trait is not in the CD, so references to it should be
 removed.

- <td width="536">
+ <td width="466">
 Remove the
 reference to constructible_with_allocator_prefix in 30.5.1
 Remove paragraph 30.5.7

 

- <td width="178">
+ <td width="225">
 

 Related to JP 79 and therefore subset of US 93. Should be addressed under
@@ -21961,20 +13100,20 @@
 <td width="29">
 JP 79

- <td width="118">
+ <td width="75">
 30.5.1

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 The
 concept of UsesAllocator and Allocator should be used.

- <td width="536">
+ <td width="466">
 
 Correct as follows.

@@ -22014,7 +13153,7 @@
 
 

- <td width="178">
+ <td width="225">
 

 Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
@@ -22022,16 +13161,16 @@
 UK 
 331

- <td width="118">
+ <td width="75">
 30.5.3

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Not clear what
 it means for a public constructor to be 'exposition only'.
 If the intent is purely to support the library calling this
@@ -22041,12 +13180,12 @@

 

- <td width="536">
+ <td width="466">
 Declare the constructor as private with a
 note about intended friendship, or remove the
 exposition-only comment and document the semantics.

- <td width="178">
+ <td width="225">
 

 Create an issue. Assigned to Detlef. Suggested resolution probably makes
@@ -22055,16 +13194,16 @@
 UK 
 332

- <td width="118">
+ <td width="75">
 30.5.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ed

- <td width="514">
+ <td width="375">
 It is not clear
 without reference to the original proposal how to use a
 future. In particular, the only way for the user to
@@ -22075,13 +13214,13 @@

 

- <td width="536">
+ <td width="466">
 Provide a small introductory paragraph,
 docuenting intended purpose of the future class template
 and the way futures can only be created via the promise
 API.

- <td width="178">
+ <td width="225">
 

 Pass on to editor. Detlef has volunteered to provide some wording.<tr valign="top">
@@ -22089,25 +13228,25 @@
 UK 
 333

- <td width="118">
+ <td width="75">
 30.5.4

- <td width="85">
+ <td width="31">
 5

- <td width="62">
+ <td width="38">
 Ge

- <td width="514">
+ <td width="375">
 We expect the complicated 3-signature
 specifcation for future::get() to be simplified to a single
 signature with a requires clause by the application of
 concepts.

- <td width="536">
+ <td width="466">
 Requires fully baked concepts for clause 30

- <td width="178">
+ <td width="225">
 

 Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
@@ -22115,16 +13254,16 @@
 UK 
 334

- <td width="118">
+ <td width="75">
 30.5.4

- <td width="85">
+ <td width="31">
 5

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Behaviour of
 get() is undefined if calling get() while not is_ready().
 The intent is that get() is a blocking call, and will wait
@@ -22132,11 +13271,11 @@

 

- <td width="536">
+ <td width="466">
 Effects: If is_ready() would return false,
 block on the asynchronous result associated with *this.

- <td width="178">
+ <td width="225">
 

 Create an issue. Move to review, attention: Howard. Proposed resolution is
@@ -22145,16 +13284,16 @@
 UK 
 335

- <td width="118">
+ <td width="75">
 30.5.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 
 std::unique_future is MoveConstructible, so you can
 transfer the association with an asynchronous result from
@@ -22168,14 +13307,14 @@

 

- <td width="536">
+ <td width="466">
 Add a "waitable()" function to
 unique_future (and shared_future) akin to
 std::thread::joinable(), which returns true if there is an
 associated result to wait for (whether or not it is ready).
 Then we can say: if(uf.waitable()) uf.wait();

- <td width="178">
+ <td width="225">
 

 Create an issue. Requires input from Howard. Probably NAD.<tr valign="top">
@@ -22183,16 +13322,16 @@
 UK 
 336

- <td width="118">
+ <td width="75">
 30.5.4

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 It is possible
 to transfer ownership of the asynchronous result from one
 unique_future instance to another via the move-constructor.
@@ -22206,30 +13345,30 @@

 

- <td width="536">
+ <td width="466">
 Add a default constructor with the
 semantics that it creates a unique_future with no
 associated asynchronous result. Add a move-assignment
 operator which transfers ownership.

- <td width="178">
+ <td width="225">
 

 Create an issue. Detlef will look into it.<tr valign="top">
 <td width="29">
 JP 80

- <td width="118">
+ <td width="75">
 30.5.4 , 
 30.5.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 Typo, duplicated ">"

@@ -22240,11 +13379,11 @@
 
 

- <td width="536">
+ <td width="466">
 
 Remove one

- <td width="178">
+ <td width="225">
 

 Pass on to editor.<tr valign="top">
@@ -22252,16 +13391,16 @@
 UK 
 337

- <td width="118">
+ <td width="75">
 30.5.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 shared_future
 should support an efficient move constructor that can avoid
 unnecessary manipulation of a reference count, much like
@@ -22269,10 +13408,10 @@

 

- <td width="536">
+ <td width="466">
 Add a move constructor

- <td width="178">
+ <td width="225">
 

 Create an issue. Detlef will look into it.<tr valign="top">
@@ -22280,16 +13419,16 @@
 UK 
 338

- <td width="118">
+ <td width="75">
 30.5.5

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 shared_future is currently
 CopyConstructible, but not CopyAssignable. This is
 inconsistent with shared_ptr, and will surprise users.
@@ -22302,7 +13441,7 @@
 retained by declaring such an instance as "const
 shared_future".

- <td width="536">
+ <td width="466">
 Remove "=delete"
 from the copy-assignment operator of shared_future. Add a
 move-constructor shared_future(shared_future&&
@@ -22317,7 +13456,7 @@

 

- <td width="178">
+ <td width="225">
 

 Create an issue. Detlef will look into it.<tr valign="top">
@@ -22325,21 +13464,21 @@
 UK 
 339

- <td width="118">
+ <td width="75">
 30.5.6

- <td width="85">
+ <td width="31">
 6, 7

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 Move assignment is goiing in the wrong
 direction, assigning from *this to the passed rvalue, and
 then returning a reference to an unusable *this

- <td width="536">
+ <td width="466">
 Strike 6. 7
 Postcondition: associated state of *this is the same as the
 associated state of rhs before the call. rhs has no
@@ -22347,7 +13486,7 @@

 

- <td width="178">
+ <td width="225">
 

 Create an issue. Move to review, attention: Howard. Proposed resolution is
@@ -22356,16 +13495,16 @@
 UK 
 340

- <td width="118">
+ <td width="75">
 30.5.6

- <td width="85">
+ <td width="31">
 11, 12, 13

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 There is an
 implied postcondition that the state of the promise is
 transferred into the future leaving the promise with no
@@ -22373,11 +13512,11 @@

 

- <td width="536">
+ <td width="466">
 Postcondition: *this has no associated
 state.

- <td width="178">
+ <td width="225">
 

 Create an issue. Move to review, attention: Howard. Proposed resolution is
@@ -22386,26 +13525,26 @@
 UK 
 341

- <td width="118">
+ <td width="75">
 30.5.6

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 promise::swap accepts its parameter by
 lvalue reference. This is inconsistent with other types
 that provide a swap member function, where those swap
 functions accept an rvalue reference

- <td width="536">
+ <td width="466">
 Change promise::swap to take an rvalue
 reference.

- <td width="178">
+ <td width="225">
 

 Create an issue. Detlef will look into it. Probably ready as it.<tr valign="top">
@@ -22413,27 +13552,27 @@
 UK 
 342

- <td width="118">
+ <td width="75">
 30.5.6

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 std::promise is
 missing a non-member overload of swap. This is inconsistent
 with other types that provide a swap member function

 

- <td width="536">
+ <td width="466">
 Add a non-member overload void
 swap(promise&& x,promise&& y){ x.swap(y); }

- <td width="178">
+ <td width="225">
 

 Create an issue. Move to review, attention: Howard. Detlef will also look
@@ -22442,22 +13581,22 @@
 UK 
 343

- <td width="118">
+ <td width="75">
 30.5.6

- <td width="85">
+ <td width="31">
 3

- <td width="62">
+ <td width="38">
 Te

- <td width="514">
+ <td width="375">
 The move constructor of a std::promise
 object does not need to allocate any memory, so the
 move-construct-with-allocator overload of the constructor
 is superfluous.

- <td width="536">
+ <td width="466">
 Remove the
 constructor with the signature template <class
 Allocator> promise(allocator_arg_t, const Allocator&
@@ -22465,7 +13604,7 @@

 

- <td width="178">
+ <td width="225">
 

 Create an issue. Detlef will look into it. Will solicit feedback from Pablo.
@@ -22473,21 +13612,21 @@
 <td width="29">
 JP 81

- <td width="118">
+ <td width="75">
 30.5.8

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 
 There are not requirements for F and a concept of Allocator
 dose not use.

- <td width="536">
+ <td width="466">
 
 Correct as follows.

@@ -22597,7 +13736,7 @@
 packaged_task(allocator_arg_t, const Alloc& a,
 F&& f);

- <td width="178">
+ <td width="225">
 

 Subset of US 93. Should be addressed under the issue corresponding to US 93.
@@ -22605,16 +13744,16 @@
 <td width="29">
 DE-23

- <td width="118">
+ <td width="75">
 Annex B

- <td width="85">
+ <td width="31">
 p2

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 DE-23 Recursive
 use of constexpr functions appears to be permitted. Since
@@ -22622,52 +13761,52 @@
 compile-time, Annex B "implementation quantities" should
 specify a maximum depth of recursion.

- <td width="536">
+ <td width="466">
 In Annex B, specify a recursion depth of 256 or a larger
 value.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 DE-24

- <td width="118">
+ <td width="75">
 Annex B

- <td width="85">
+ <td width="31">
 p2

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 DE-24 The
 number of placeholders for "bind" is implementation-defined
 in 20.7.12.1.4, but no minimum is suggested in Annex B. 

- <td width="536">
+ <td width="466">
 Add a miminum of 10 placeholders to Annex B.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 DE-25

- <td width="118">
+ <td width="75">
 Annex B

- <td width="85">
+ <td width="31">
 p2

- <td width="62">
+ <td width="38">
 te

- <td width="514">
+ <td width="375">
 DE-25
 Specifying a minimum of 17 recursively nested template
@@ -22678,28 +13817,28 @@
 . The conclusion is that the metric "number of recursively
 nested template instantiations" is inapposite.

- <td width="536">
+ <td width="466">
 Remove the bullet "Recursively nested template
 instantiations [17]".

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 FR 38

- <td width="118">
+ <td width="75">
 C.2 
 [diffs.library]

- <td width="85">
+ <td width="31">
 1

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 What is ISO/IEC 1990:9899/DAM
 1? My guess is that's a typo for ISO/IEC

@@ -22709,13 +13848,13 @@
 make reference to things
 which were introduced by Amd.1).

- <td width="536">
+ <td width="466">
 One need probably a reference
 to the document which introduce char16_t and

 char32_t in C (ISO/IEC TR 19769:2004?).

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
@@ -22723,45 +13862,45 @@
 UK 
 344

- <td width="118">
+ <td width="75">
 Appendix D

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 Ge

- <td width="514">
+ <td width="375">
 It is desirable to allow some mechanism to
 support phasing out of deprecated features in the future.
 Allowing compilers to implement a mode where deprecated
 features are not available is a good first step.

- <td width="536">
+ <td width="466">
 Add to the definition of deprecated
 features permission for compilers to maintain a
 conditionally supported mode where deprecated features can
 be disabled, so long as they also default to a mode where
 all deprecated features are supported.

- <td width="178">
+ <td width="225">
 

 <tr valign="top">
 <td width="29">
 FR 39

- <td width="118">
+ <td width="75">
 Index

- <td width="85">
+ <td width="31">
 

- <td width="62">
+ <td width="38">
 ed

- <td width="514">
+ <td width="375">
 Some definitions seem not
 indexed (such as /trivially copyable/ or

@@ -22771,10 +13910,10 @@
 increase the usefulness; having a separate index of all
 definitions is something which could also be considered).

- <td width="536">
+ <td width="466">
 

- <td width="178">
+ <td width="225">
 

 </table><hr>
\ No newline at end of file

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51568 - sandbox/committee/LWG"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51566 - 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