Editor’s Report

N857=09-0047, Working Draft, Standard for Programming Language C++, contains the working draft for the standard, with the following changes made since the Committee Draft, N2800:

• N2816, Core issues: 499, 542, 556, 564, 569, 571, 576, 588, 598, 628, 641, 645, 650, 652, 658, 665, 668
• N2841: Consolidated Quasi-editorial Changes for National Body Comments Concerning the Core Language
• N2844: Fixing a Safety Problem with Rvalue References (except 20.2.2 forward/move helpers)
• N2845: Remove std::reference_closure
• N2821, Library issues: 753, 758, 821, 866, 894 (752 is also in the paper, but it makes changes to text that does not exist)
• N2802: A Plea to Reconsider Detach-on-destruction for Thread Objects (Alternative 2)
• N2840: Defects and Proposed Resolutions for Allocator Concepts (Rev. 2)
• N2836: Wording Tweaks for Concept-enabled Random Number Generation in C++0x
• Editor’s Responses to National Body Comments Marked as Editorial (see below)

My thanks to the following people, who pointed out various errors in earlier versions of this draft:

• Alan Talbot
• Alisdair Meredith
• Doug Gregor
• Hans Boehm
• Jens Maurer
• Lawrence Crowl
• Mike Miller
• Pablo Halpern
• Walter Brown

My apologies to anyone whose name didn’t get on this list. Any omissions are entirely accidental.

Editor’s Responses to National Body Comments Marked as Editorial

All the changes for the comments that are marked as "Accepted" or "Accepted with Modifications" have been made in the working draft.

Comments marked as "Technical" are not, in the judgment of the Project Editor or one of the working groups, editorial. They need to be resolved by the appropriate working group.

A few comments, marked "Typesetting", concern typesetting issues that can't reasonably be resolved until the final document is generated. Bad line breaks, bad page breaks, etc. change as the preceding and surrounding text changes, so there's nothing to be gained by fixing them now. Eventually they'll be marked as "Accepted", but for now, treat "Accepted" as "Accepted and in the Working Draft".

Comments marked as "Unresolved" have been postponed, simply for lack of time. This does not reflect any judgment on their merits.

Note that the contents of the comments here are my own notes from the submissions by the Member Bodies; if any of them differs from what the actual comment says, believe the comment.

Table of Contents

DE: 7 20

FI: 4 5 7

FR: 2 3 4 6 7 8 9 11 13 14 15 18 26 33 34 36 37 38 39

JP: 1 2 3 4 6 7 11 13 15 16 17 18 19 22 24 25 34 35 36 37 40 42 43 47 51 54 55 56 57 58 59 61 71 75 76 78 80 81

UK: 1 2 3 5 13 14 16 19 20 21 23 25 27 34 35 36 37 47 48 52 55 56 57 60 61 63 64 73 74 75 76 77 80 85 90 92 93 94 97 100 102 104 106 107 109 111 112 113 118 120 121 124 126 127 128 134 137 138 140 141 142 143 144 145 146 147 148 149 150 151 153 154 155 156 157 158 159 160 161 162 164 166 167 171 174 176 177 178 181 184 185 186 191 198 202 203 207 212 215 217 219 221 225 227 228 229 235 236 237 242 246 248 252 253 268 269 274 276 280 285 286 288 289 290 292 293 297 298 299 302 303 304 307 315 318 321 330 332

US: 3 4 5 7 8 9 10 11 12 18 19 21 22 23 25 27 28 32 34 35 37 38 44 49 51 52 55 56 57 58 64 67 68 69 71 74.1 80 82 83 89 94

Classifications: Accepted (149) Accepted with Modifications (14) Rejected (24) Technical (24) Typesetting (3) Unresolved (26)

Accepted (149)

NB comments that raise editorial issues and have been resolved in the working draft in the way that's suggested in the comment.

Replace "template function" with "function template" in section heading and first sentence

Change to_limit to to_end

in note: As a result of operations on state, it can return ok or partial and set next == from and to_next != to.

"next" should be "from_next".

Change "codeset" to "character set"

This example uses int *v while the other examples seems to use notation like int* v.

There are spurious empty lines

In general it is necessary to determine whether a name denotes one of these entities before parsing the program that contains it.

... before continuing to parse the program that contains it.

... to complete the parsing of the program that contains it.

as some names denotes entities declared after the first occurrence.

/operator-function-id/, /conversion-function-id/, /tempalte-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.

The paragraph number is not aligned with the text.

ios_base::iostate err = 0;

iostate is a bitmask type and so could be an enumeration. probably using goodbit is the solution.

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.

iostate err = 0;

iostate is a bitmask type and so could be an enumeration. Probably using goodbit is the solution.

else if (lval < numeric_limits::min()

|| numeric_limits::max() < lval))

The parentheses aren't balanced.

What is ISO/IEC 1990:9899/DAM 1? My guess is that's a typo for ISO/IEC 9899/Amd.1:1995 which I'd have expected to be referenced here (the tables make reference to things which were introduced by Amd. 1).

One need probably a reference to the document which introduce char16_t and char32_t in C (ISO/IEC TR 19769:2004?).

Keywords in the table are listed disorderly. Also, a part of a frame of the table is not drawn.

Type, R"..." should be R"[...]"

We think that the explanation of d-char-sequence is not enough.

Add text from N2837.

CWG: editorial

Typo. Lack of a necessary backslash in the first line of the example.

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)".

Over-aligned type was added as new notion. So it is preferable to add the link after that.

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.

Replace the description, "same underlying type", with "same as underlying type of (previous) declaration."

Typo, "in in"

"is is"

Sort subclauses in table 16 in numerical order

add "3.11, Alignment" to SEE ALSO

Though N2672 pointed at adding #include , it isn't reflected.

Add

1. include // for concept_map

"stdforward" should be "std::forward"

"it it" should be "it is"

Add period at end of enable_if's comments.

Change "Allocator A" to "Allocator Alloc"

Fix requirements

LWG: change "MoveConstructible" to "class"

Change "alloc" to "Alloc"

Add missing '>' in template argument list

Change "Requires: [fmt,end)" to "Requires: [fmt,fmtend)"

Add to table 79

Change "concep" to "concept"

Add "array" to Container field for a.front(), a.back(), a[n], and a.at(n)

"to to"

Remove '{' before "iterator"

Change iterator to const_iterator, three places

Add 'i' to "intializing"

"template" is missing in "class basic_ostringstream" of the title of the chapter.

In "F and each Ti in Args", "Ti" is not clear.

Replace "Ti" with "args"

duplicated '>' "class Period>>"

The table is nearly sorted, but not quite. It was sorted in previous versions of the standard.

Not immediately clear why the question mark needs escaping. A note would help.

Add a note explaining that the ? character may need escaping to avoid accidentally creating a trigraph.

6th bullet, "the rank of char" - first letter should be capitalised for consistency with the other bullets.

Missing period in middle of paragraph between "in the scope of T" and "If this lookup fails"

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 enought to call attention to it.

Add note: there are no guarantees on the order of value computation for an overloaded comma operator.

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.

Add "and" before vq

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.

Clarify in footnote 60 that this will not happen if the whole expression is an unevaluated operand.

Paragraph 2 is missing its number.

A new name R is introduced for use in paragraphs 3 and 4. But R is the same as T.

Replace R with T and replace "the required result type (which, for convenience, will be called R in this description)" with "T"

A paragraph starting with [Note... is easily skipped when reading, missing the normative text at the end.

Swap order of the note and normative text.

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 cross-referenced.

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.

Add a row to table 9 mentioning simple-template-id and punting to clause 14 (cf decltype(expression)).

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.

Either strike the note or add reference to 11.4/3 and/or mention of "friend T;".

In the third production, "enum ::opt nested-name-specifieropt identifier", enum should not be in italics; its referring to the enum keyword.

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.

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.

Missing punctuation after "blue" in "The possible values of an object of type color are red, yellow, green, blue these values can be converted...".

Add a semicolon after "blue".

Extensive use of alignment and related terms without cross reference.

Add cross reference to 3.11.

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.

Add note: implementations are encouraged to issue a diagnostic where the definition of a function marked [[noreturn]] might execute a return statement.

CWG: editorial

The example code refers to comments to "Compilation unit" A and B. The term should be "Translation unit" (two places)

Example missing closing bracket in template void f(T (*...t)(int,int);

mis-applied edit from N2756: "constant-initializer" should have been struck out when replaced by brace-or-equal-initializer, two places.

Move exported templates (14/6-11) into their own subclause (move p. 12 ahead of this new subclause)

"parameter pack" should have a cross reference

Add example marker at start of example.

"weere"

Move the second sentence to the Requires clause in paragraph 42.

Add note: "move only" types that are constructible from rvalue references may be Returnable, but not CopyConstructible (20.1.8).

The sentence "An exception-specification can also include the class std::bad_exception (18.7.2.1)." is redundant.

Either strike the quoted sentence or add a note explaining why it is worth calling special attention to this class.

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.

Add another paragraph outlining 18.7.5 and the ability of an exception_ptr to extend the lifetime of an exception object.

The detailed specification can fool people into thinking an exception will automatically be translated into bad_exception, where the default behavior of std::unexpected is to immediately call std::terminate().

Add a note highlighting the default behavior of std::unexpected if the user does not supply a handler-function.

This whole subclause is redundant due to 15.1/5 and 15.3/17.

Strike 15.6.

This paragraph opens with "[ Note" but has no corresponding "end note ]".

Example uses #define t(x,y.z).

change to t(x,y,z)

Add "regular expressions, atomic operations and threads"

Summary of numeric facilities should mention random numbers.

Add a summary paragraph for regular expressions.

Add a summary paragraph for threads.

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

Strike the word 'only'. A note might be added to reinforce the intent.

Add clause 28 to list that use this definition of character.

Add regular expressions to set of templates using character container type.

Add concepts to the ordered list of presentation

Replace "classes" and "functions" with "classes and class templates" and "functions and function templates".

Strike the footnote or replace "existing" with "original" or similar.

Add "Synchronization:" either between "Effects:" and "Postconditions:" or between "Returns:" and "Throws:".

List of library clauses should go up to 30, not 27.

Comment marker for "exposition only" in wrong place.

Either strike the references to abort, at_exit and exit, or clarify which headers only require partial support.

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"

Strike redundant sentence.

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

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

Change to

Remove meaningless footnote.

remove std:: qualifiers from references to pair in tuple-like access

Move the '}' to after the typedef for the ratio_xyz types

suffix "::type" is missing from the some of the examples

LWG: replace "is" with "evaluates to" in the same text

Stray {} on operator--

remove mention of constructible_with_allocator_suffix

Change "begin() - i1" to "i1 - begin()"

Add to table 79

Change return types for X::(const)_reverse_iterator to say "iterator type whose value type is (const) T"

Replace "construction" with "assignment" in postcondition for a = rv

Change "concep" to "concept"

Replace "A container may directly call constructors and destructors for its stored objects" with something similar to "A container may directly construct its stored objects and call destructors for its stored objects"

Add array and forward_list to list of sequence containers

Add array and forward_list to list of containers is the complexity discussion

Remove std::qualification from two mentions of reverse_iterator

Replace mention of "container" with more general term; iterators refer to sequences, not just containers.

Change "class" to "class template" in note.

Add "if it" to first sentence.

This note is potentially confusing as __far enters the syntax as a clear language extension, but the note treats it as a regular part of the grammar. It might be better expressed using attributes in the current wording.

Clean up the note to either avoid using language extension, or spell out this is a constraint to support extensions.

"decrements for negative n" seems to imply a negative number of decrement operations, which is odd.

Need simple, clearer wording.

The subclauses for standard iterator adaptors could be better organised. There are essentially 3 kinds of iterator wrappers provided, stream iterators adapt streams and get their own subsection. insert iterators adapt containers, and get their own subsection but it is inserted into the middle of 24.4 Predefined iterators. reverse_iterator and move_iterator adpat [sic] other iterators, but their presentation is split by insert iterators.

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.

The presence of the second iterator value is surprising for many readers who underestimate the size of a reverse_iterator object. Adding the exposition only member that is required by the semantic will reduce confusion.

Add reverse_iterator exposition-only member tmp as a comment to class declaration, as a private member

The character type of a string delimiter for an ostream_iterator should

be const charT*, the type of the elements, not char*, a narrow character string.

Replace char* with const charT*.

The definition of rotate_copy is very complicated. It is equivalent to: return copy(first, middle, copy(middle, last, result)):

Change 'effects' to, returns, requires, complexity to: effects: equivalent to: return copy(first, middle, copy(middle, last, result));

partition_point requires a partitioned array.

Requires: is_partitioned(first, last, pred) != false;

The footnote refers to TR1, which is not a defined term in this standard. Drop the reference to TR1, those templates are a regular part of the standard now and how they were introduced is no longer relevant.

Drop the reference to TR1.

6 Effects: string_type str(first, last); return use_facet >(

getloc()).transform(&*str.begin(), &*str.end()); Is it legal to dereference str.end()?

Reword to use legal iterator dereference.

Constructor definition should appear with the other constructors not after assignment ops.

Move para 22 to just after para 17.

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.

Remove the reference to constructible_with_allocator_prefix in 30.5.1

Remove paragraph 30.5.7

There is no mention of Clause 17.

Include Clause 17 among the list of Clauses that specify the Standard Library.

The paragraph omits to mention concepts and concept maps among its list of entities defined in the Standard Library.

Mention concepts and concept maps among the list of entities.

CWG: editorial

The syntax description does not account for lines that wrap.

The term thread is used before defined.

Reference 1.10 [intro.multithread]

The phrase "threads of execution" should be accompanied by a reference to [intro.multithread]

The paragraph begins with an empty line.

The final entry in the last column ("unsigned long int") is incorrect.

Replace the incorrect entries by "unsigned long long int".

CWG: editorial

The code does not have the effect predicted by its accompanying narrative.

Append a backslash to the first line of the code.

CWG: editorial

Bad paragraph break.

There is a superfluous/extraneous "and".

The closing braces of the first two sets are preceded by extraneous space.

The final italic "this" in the paragraph should be a teletype "this".

The list of unary operators should be in teletype font.

There is curious spacing in the expressions "E1 << E2" and "E1 >> E2".

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.

In the example, "template void f(T (* ...t)(int, int);" is missing a close parenthesis.

The discussion of delegating constructors should be in its own paragraph.

"shal" should be "shall"

Paragraph number on grammar rule

The listed phrases are not grammatically parallel.

Insert "in" before "one" so as to obtain "... in the concept, in one of its less refined concepts, or in an associated requirement."

"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.

Delete this cross reference. If necessary, expand the main text to include the relevant referenced text.

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

Align "rep" with other symbols in synopsis

Change "shrink_to_fint" to "shrink_to_fit"

The first sentence of para 1 suggests that no other library function is permitted to call operating system or low level APIs.

Rewrite para 1 as "Some functions described in this Clause are specified to throw exceptions of type system_error (19.4.5). Such exceptions shall be thrown if a call to an operating system or underlying API results in an error that prevents the library function from satisfying its postconditions or from returning a meaningful value."

LWG: editorial

Accepted with Modifications (14)

NB comments that raise editorial issues and have been resolved in the working draft in a way that's different from the way suggested in the comment.

Shouldn't the assert be

assert(std::strcmp(p, "a\nb\nc")==0);

Resolution comment: The assert is correct but the preceding raw string is wrong. See JP 3.

This paragraph seems out of place, assignment expressions are covered in 5.17.

move p3 to subsection 5.17

Resolution comment: Removed the paragraph; grammar changes make it moot.

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.

Strike the first sentence.

Resolution comment: Tweaked first sentence

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 no covered by this paragraph.

Move the example to paragraph 7, and/or replace it with an appropriate example.

Resolution comment: Changed the example slightly to make it clearer.

For consistency with narrow-oriented and wide-oriented streams, we should add terms for streams of Unicode character sequences.

Define Utf16_oriented stream classes and Utf32-oriented stream classes for streams of char16_t and char32_t values.

Resolution comment: The terms "narrow-oriented iostream classes" and "wide-oriented iostream classes" are never used in the standard (except in a somewhat garbled passage that I have rewritten without them), so rather than proliferate definitions of unused terms, I've removed the original culprits.

Missing cross reference to 17.3.17 [defns.repositional.stream]

Resolution comment: Removed the reference.

Change reference from 17.6.4.3 to 17.6.4.2

Resolution comment: Removed footnote.

Rephrase second bullet in terms of a new handler being installed, and update any definition of handler function necessary to be sure the term "installed" is defined.

Resolution comment: Reworded, but not with "installed".

Remove this paragraph

Resolution comment: Reworded the paragraph and its predecessor to reflect five basic sequence containers.

Latin abbreviations are presented incorrectly

Resolution comment: The "Chicago Manual of Style" says that i.e. and e.g. are never italicized and always followed by a comma, so that's how they now appear.

Insert "corresponding to" before "an lvalue reference type"

Resolution comment: The sentence in question is 20.1.1/5

Change "conversion are" to "conversion is"

Resolution comment: "conversions are" is correct.

[second US 74]

Concept name misspelled twice: change Hasconstructor to HasConstructor

Resolution comment: The text in question is in 20.7.2.2, not 20.8.2.2. USE TAGS!!!!

Fix section heading

Resolution comment: The heading is 20.8.2.1, not 20.9.2.1. USE TAGS!!!!

Rejected (24)

NB comments that raise editorial issues and have been rejected.

The note at the end of paragraph 10 appears to be garbled.

Remove "or references" in this note.

Resolution comment: looks okay: "captured" applies to "variables or references"

[intro.execution]/5 explicitly allows non causal undefined behaviour,

Adding it to the note outlying possible undefined behaviours.

Resolution comment: This is covered by the first alternative in the note, "ignoring the situation completely with unpredictable results".

The paragraph as it 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.

Resolution comment: Yes, that seems to be the intention. That's the mechanism for extensions: issue a diagnostic and then do the extension.

Change "[dcl.align]" of 7.6.2 to "decl.attr.align]".

Resolution comment: Tags don't change. This section used to be somewhere else, and the tag was appropriate there.

Change "between threads" to "among threads" in 17.6.5.7/4, 17.6.1/2, 17.6.5.7/6, 30.1/1, 30.3.1/1

Resolution comment: "Between" expresses one-to-one relations of pairs in a group; "among" refers to collective relations in a group. "Between" is correct here.

List of additional facilities over C has been extended with this standard, so should be mentioned in the introductory material.

Add the following to the list in 1.1/2: atomic operations concurrency alignment control user-defined literals attributes

Resolution comment: This list is highlights, not all differences. Okay as is.

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.

Resolution comment: 1.2 (Normative references) cites 9899:1999, 9899:1999/Corl.1:2001, and 9899:1999/Cor.2:2004, which collectively constitute C99.

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 standard is very clear not to actually describe their name as a distinct property.

Change "the allocation function's name is operator new" to "the allocation function is named operator new" and similarly for operator delete.

Resolution comment: CWG: rejected

It is helpful for each subclause to contain a short paragraph introducing its intent and purpose. 7.6 has such a paragraph, but it is nested under a more specific subsection.

7.6.1/1 should move up one level to become 7.6/1. Their grammar should remain under 7.6.1.

Resolution comment: ISO editing guidelines insist that only leaf clauses have text. Moving this sentence to 7.6 would violate that rule (not that the standard doesn't violate it in many places, but we shouldn't make this worse now)

We now have concepts that should (or should not?) map to the terms described in Clause 9 -- these should be at least referenced.

Add appropriate forward references to 14.9.4.

CWG: editorial

Resolution comment: This seems excessive. If people want to know about concepts they should read about concepts.

The third bullet is redundant with the first, as it is a subset of the same conditions.

Merge the third bullet into the first bullet as a note or example.

Resolution comment: They're subtly different. The first bullet is about calls made to create, copy, and destroy the exception object itself. The third bullet is about destructors of stack objects during stack unwinding.

Missing definition of a stable partition algorithm.

Add definition from 25.2.12/7.

Resolution comment: Since the term "stable partition algorithm" is never used, there is no need to define it. The requirements for the algorithm stable_partition are clear as written.

Strike redundant paragraph 17.5.2.4/4.

Resolution comment: 17.3 defines "handler function"; 17.5.2.4/4 imposes requirements on handler functions and replacement functions. There is no redundancy.

Strike redundant sentence, last sentence of third bullet

Resolution comment: The sentence is not redundant. It points out that the behavior is sometimes circumscribed by a prohibition on throwing exceptions.

It is odd to have a mix of declaration stlyes [sic] for operator+ overloads. Prefer if either all are member functions, or all are 'free' functions.

Make the member operators taking a difference_type argument non-member operators.

Resolution comment: LWG: NAD

the concept StrictWeakOrder covers the definition of a strict weak ordering, describe in paragraph 4.

Remove 4, and mention StrictWeakOrder in paragraph 1.

Resolution comment: There are at least a dozen places in the standard that refer to this defintion of stict weak ordering, including the concepts StrictWeakOrder and LessthanComparable.

This paragraph just describes is_partitioned

6 A sequence [start, finish) is partitioned with respect to an expression f(e) if is_partitioned(start, finish, e) != false

Resolution comment: The paragraph describes something different. is_partitioned takes a predicate;l "partitioned with respect to an expression" deal with an expression. While it's possible to wrap an expresion in a predicate, that would result in a circumlocution in the places where "partitioned with respect to an expression" is used.

The requires clauses of push_heap, pop_heap and make_heap are inconsistently formatted, despite being identical

Format them identically.

Resolution comment: Seems to be a comment about an earlier version. In N2800 the requires clauses of push_heap and pop_heap are similar, and are formatted the same. make_heap has no requires clause.

A memory location is not an object as the sentence claims.

Clarify that a memory location "holds" an object rather than that it "is" an object.

CWG: rejected, N2841

The paragraph, marked as a Note, contains an embedded example not marked as such.

Resolution comment: Marking things as Note or Example distinguishes them from normative text. Examples in Notes do not need to be marked.

The parenthesized phrase, introduced via "i.e." is in the nature of an example.

Change "i.e." to "e.g."

Resolution comment: The parenthesized phrase is in the nature of a clarification, so "i.e." is appropriate.

The discussion of attribute specifiers should be a separate paragraph.

Resolution comment: It's okay where it is. It's a list of constraints on the grammar.

Two references to 14.9.1.3 in same sentence

Resolution comment: Yes; they apply to different terms.

A word is misplaced, changing the intended meaning.

Change "only find ... if" to "find ... only if"

Resolution comment: These mean the same thing, and the latter is stilted.

Technical (24)

NB comments that were classified by the NB as editorial issues but are not considered editorial by the Project Editor, the Core Working Group, or the Library Working Group.

Are they part of object types or not? The section does not appear to indicate that clearly.

CWG: technical

There is no _RangeT type in the eqiuvalent code to "range-base for" statement. It existed in N2049.

Add typedef, per issue

CWG: technical

"any namespace from" should be "any namespace forming"

CWG: technical

"any namespace from" should be "any namespace forming"

Distinct from JP 17

CWG: technical

Various C-style typedefs for enums should be changed to C++-style

LWG: technical

Add "Throws: Nothing" in several places

Missing requirements for template types in packaged_task

LWG: technical

The definition of an argument does not seem to cover many assumed use cases, and we believe that is not intentional.

CWG: technical

This text is confusiong in isolation, as it implies pp-numbers do not have a value in translation phase 4 when evaluating #if preprocessor expressions.

Add a note with a cross-reference to 16.1 that a pp-number may briefly acquire a value during translatation phase 4 while evaluating #if expressions.

Resolution comment: Sorry, I have no idea what this means.

The grammar for string literal is becoming unwieldy and could easily be refactored into the type optional specifier and the string contents.

CWG: technical

alias-declarations are not definitions and should be added to the list.

CWG: technical

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.

Remove the : s() from the illustrated default constructor: (remaining code elided)

CWG: technical

A class type must be complete when catching exceptions, even by reference or pointer. See 15.3.

Add "when used in an exception-handler (15.3)" to the list.

CWG: technical

Primary expressions are literals, names, names qualified by the scope resolution oeprator ::, and lambda expressions. The immediately following grammar flatly contradicts this - this and (e) are also lambda expressions.

Delete this paragraph.

CWG: technical

Member function templates are not member functions, so should also be listed in the 3rd bullet.

CWG: technical

Why are the descriptions of order of evaluation of expressions and side effects different between && and || operator. The interaction with the memory model should be identical, so identical words should be used to avoid accidental inconsistencies in interpretation.

CWG: technical

dynamic_cast and reinterpret_cast cross reference 5.2.11 without creating an extra note. The second half of the note is unrelated to the cross reference, and would serve as well in normative text.

CWG: technical

Add note: the result of such a conversion will not be a safely-derived pointer value (3.7.4.3)

CWG: technical

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.

CWG: technical

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 word "literal" before "class type" will clarify this.

CWG: technical

Do we really need two differeent terms that say the same thing?

Pick either "block" or "compound statement" as the preferred term and use it consistently throughout the standard.

CWG: technical

... 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.").

Replace "global" with "namespace scope".

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.

Delete para. 10, moving its example into para. 13.

CWG: technical

Strike 23.3.2.2 (but not the corresponding signatures)

Typesetting (3)

National Body comments that reflect glitches in typesetting that are dependent on details of the surrounding text. For example, the placement of tables is determined by where the table occurs in the source text, where the nearest page breaks are, and where nearby titles occur. These glitches change as the surrounding words and structure change, so there is no way to fix them until the final step in creating the standard.

There is a page break between the title and the paragraph.

Table 12 is mentioned in and relates to section 17.2, but has been pushed down to appear directly after the title of section 17.3.

There is a bad line break in "C++".

Unresolved (26)

Editorial issues that have not yet been resolved.

The adoption of the library 'constexpr' proposal was not reflected in the draft, despite formal WG21 committee vote.

Is the lack of reference to ISO/CEI 9899/AC3:2007 voluntary?

Resolution comment: What is this document?

Some definitions seem not indexed (such as /trivially copyable/ or /sequenced before/), indexing them would be useful (and marking specially the page -- sya bold or italic -- which reference to the definition would increase the usefulness; having a separate index of all definitons is something which could also be considered).

Missing checklist of implementation defined behaviour (see ISO/IEC TR 10176, 4.1.1p6)

Provide a new annex with the missing checklist

CWG: editorial

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 features but to definitions used in the document.

Change the title to "Basic definitions".

CWG: editorial

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.

Rename the chapter Basic ???. The note in p2 specifically needs similar rewording.

Provide a diagram clearly showing refinement relationship between the different support concepts.

The addition of move semantics to the language means that many library APIs leave an object an a safely-destructible state, where no other operations can safely be performed unless it is assigned a new value. Library presentation would be simplified and made more precise if we introduce a term for this state. By analogy with singular iterators suggest the term "singular object" or "the object is in a singular state".

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

Change "Requires" clauses to "Preconditions" clauses

This phrasing predates concepts. While this kiind of description is still used, the examples provided are now all concepts, and should be replaced with appropriate examples.

Use better names for the examples. Ideally totally replace the need by constraining all templates in library, so that real concepts are all that is needed. Note if retained that CopyConstructible is misspelled.

Replace all typedef declarations in the standard library with alias-declarations, except in the standard C library.

The organization of clause 20 could be improved to better group related items, making the standard easier to navigate.

The pointer-safety API has nothing to do with smart pointers, so does not belong in 20.7.13. In fact it is a set of language support features and really belongs in clause 18, with the contents declared in a header that deals with language-support of memory management.

Move this specification to 18.5. Move the declarations into the header .

LWG: Agree in principle, but not with the proposed resolution. We gelive it belongs in a subsection of either 20 [utilities] or 20.8 [memory] as part of the general reorganization of 20 [utilities]. The declaration should stay in .

Much of the content of p1 and the whole of p2 is a redundant redefinition of InputIterator. It should be simplified.

Strike p2. Simplify p1 and add a cross-reference to the definition of InputIterator concept.

To the casual reader it is not clear if it is intended to be able to assign to istream_iterator objects. Specifying the copy constructor but relying on the implicit copy-assign operator is confusing.

Either provide a similar definition to the copy-assign operator as for the copy constructor, or strike the copy constructor.

The provided specification is vacuous, offering no useful information.

Either strike the specification of the copy constructor, or simply replace it with an = default definition.

It is very hard to pick up the correct specification for istream_iterator::operator== as the complete specification requires reading two quite disconnected paragraphs, 24.5.1p3 and 24.5.1.2p6. Reading just the specifications of the operation itself suggests that end-of-stream iterators are indistinguishable from 'valid' stream iterators, which is a very dangerous misreading.

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.

Prefer the use of the new nullptr constant to the zero literal when using a null pointer in text.

Change istreambuf_iterator(0) to istreambuf_iterator(nullptr)

The listed paragraphs redundantly redefine an input iterator, and redundancy can be a dangerous thing in a specification. Suggest a simpler phrasing below.

2. The result of operator*() on an end of stream is undefined. For any other iterator value a char_type value is returned. 3. Two end of stream iterators are always equal. An end of stream iterator is not equal to a non-end of stream iterator. 4. As istreambuf_iterator() is an InputIterator but not a ForwardIterator, istreambuf_iterators object [sic] can be used only for one-pass algorithms. It is not possible to assign a character via an input iterator.

Should be consistent in style use of concepts in template parameter lists. The auto-OutputIterator sytle used in std::copy is probably preferred.

Change way signature is declared:

template

RvalueOf::type> OutIter>

OutIter move(InIter first, InIter last, OutIter result);

Throughout this clause, the term "Requires:" is used to introduce compile time requirements, which we expect to be replaced with concepts and requires in code. Run-time preconditions are introduced with the term "Preconditions:" which is not a defined part of the library documentation structure (17.5.2.4). Howeveer, this is exactly the direction that BSI would like to see the organisation move, replacing Requires: clauses with Preconditions: clasues [sic] throught [sic] the library. See comment against clause 17 for more detils.

Decument [sic] Preconditions: paragraphs in 17.5.2.4, and use consistently through rest of library.

It is not clear without reference to the original proposal how to use a future. In particular, the only way for the user to construct a future is via the promise API which is documented after the presentation of future. Most library clauses feature a small description of their components and intended use, it woudl be most useful in this case.

Provide a small introductory paragraph, documenting intended purpose of the future class template and the way futures can only be created via the promise API.

LWG: wording from Detlef

The wording is unclear as to whether it is the input or the implementation "that is not a well-formed program".

Reword to clarify that it is the input that is here considered not well-formed.

CWG: editorial

In the example, the comments could be improved. See attached paper.

Bring tuple<> and pair<> together

The types in the table "Atomics for standard typedef types" should be typedefs, not classes. These semantics are necessary for compatibility with C.

Change the classes to typedefs.