Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r64768 - sandbox/committee/LWG/FCD
From: bdawes_at_[hidden]
Date: 2010-08-12 15:52:50

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r64769 - sandbox/committee/LWG/FCD"
Previous message: boris_at_[hidden]: "[Boost-commit] svn:boost r64767 - in sandbox/SOC/2010/process: boost/process/detail libs/process/test libs/process/test/inclusion"

Author: bemandawes
Date: 2010-08-12 15:52:43 EDT (Thu, 12 Aug 2010)
New Revision: 64768
URL: http://svn.boost.org/trac/boost/changeset/64768

Log:
Initial version from Mike
Added:
sandbox/committee/LWG/FCD/
sandbox/committee/LWG/FCD/comments.xml (contents, props changed)

Added: sandbox/committee/LWG/FCD/comments.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/LWG/FCD/comments.xml 2010-08-12 15:52:43 EDT (Thu, 12 Aug 2010)
@@ -0,0 +1,14529 @@
+<?xml version="1.0"?>
+
+<document date="2010-08-12"
+ rev="0"
+ docno="PL22.16 10/xxxx = WG21 Nyyyy"
+>
+
+<comment nb="ITTF" num="1" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+General
+</section>
+<para></para>
+<description>
+The ISO/IEC headers and footers should appear at the
+top and bottom of every page.
+</description>
+<suggestion>
+Insert the ISO/IEC headers and footers at the top
+and bottom of every page.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="1" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1-30
+</section>
+<para></para>
+<description>
+It appears that the C committee could possibly make
+some changes for C1X that we may still want to follow for
+C++0X to avoid gratuitous incompatibilities.
+</description>
+<suggestion>
+Make any appropriate changes to avoid
+unnecessary incompatibilities with C1X resulting
+from changes to the WG14 C standard draft.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="2" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1-30
+</section>
+<para></para>
+<description>
+The active issues identified in the CWG and LWG issues
+lists as if the date that the FCD was published (N3083 and
+N3087) must be addressed and appropriate action taken.
+</description>
+<suggestion>
+Appropriate action would include making changes
+to the FCD, identifying an issue as not requiring a
+change to the FCD, or deferring an issue to a later
+draft or a later standard.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="1" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1 through 15
+</section>
+<para></para>
+<description>
+Consider applying the resolutions of the active core issues
+in Ready status (see WG21 N3083).
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="1" type="ge/te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+all
+</section>
+<para></para>
+<description>
+The issues on the issues lists (WG21 N3083 and N3087)
+shall be addressed before the standard becomes final.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="3" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1 - 29
+</section>
+<para></para>
+<description>
+The threading model does not make basic guarantees
+needed to write correct programs. We should not repeat
+the error that POSIX made in early standards (and later
+corrected).
+</description>
+<suggestion>
+Add requirements that all no-blocked threads will
+(however slowly) make progress and that all
+visible side effects will (eventually) be seen by
+other threads. Possibly use the word “should” if
+an absolute requirement is impossible.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="4" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+all
+</section>
+<para>
+all
+</para>
+<description>
+Many identifiers are hyphenated and broken across line
+boundaries. As a consequence, searching for the
+identifier fails.
+</description>
+<suggestion>
+Protect all identifiers against hyphenation.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="5" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+all
+</section>
+<para>
+all
+</para>
+<description>
+The word "object" often copies as "ob ject".
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="6" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+various
+</section>
+<para>
+various
+</para>
+<description>
+~ (U+007E) is sometimes replaced with ∼ (U+223C),
+causing cut and paste from the standard to fail, notably in
+2.14.5.
+</description>
+<suggestion>
+Use U+007E consistently
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="7" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+various
+</section>
+<para>
+various
+</para>
+<description>
+' (U+0027) is consistently replaced with ’ (U+2019),
+causing cut and paste to fail. This is also an issue with
+the 1998 standard.
+</description>
+<suggestion>
+Use U+0027 consistently in code samples (i.e.
+monospace font)
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="1" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.1
+</section>
+<para>
+2
+</para>
+<description>
+The C99 standard supports inline functions, so this should
+not be listed as a distinguishing feature of C++.
+</description>
+<suggestion>
+strike "inline functions" from the list of C++
+'additional facilities'
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="2" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.2
+</section>
+<para></para>
+<description>
+In [intro.refs] the spec references ISO/IEC 9945:2003
+even though a later revision, ISO/IEC 9945:2008 has
+already been released:
+http://www.iso.org/iso/catalogue_detail.htm?csnumber=50
+516
+</description>
+<suggestion>
+The section should be updated to reference the
+latest version.<BR/>
+In addition, since POSIX is a registered trademark
+of the IEEE, the spec should use the registered
+trademark (R) symbol wherever it references it.
+Alternatively, it can refer to ISO/IEC 9945.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ITTF" num="2" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.2
+</section>
+<para></para>
+<description>
+The introductory text to the Normative references is not
+correct.
+</description>
+<suggestion>
+Delete the current introductory text to the
+Normative references and replace with the
+following:<BR/>
+“The following referenced documents are
+indispensable for the application of this document.
+For dated references, only the edition cited
+applies. For undated references, the latest edition
+of the referenced document (including any
+amendments) applies.”
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ITTF" num="3" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.3
+</section>
+<para></para>
+<description>
+The title to the subclause does not accurately reflect the
+content.
+</description>
+<suggestion>
+Change the title to “Terms and definitions”.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ITTF" num="4" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.3
+</section>
+<para></para>
+<description>
+3.1 of the ISO/IEC Directives, Part 2, states that the
+following introductory wording shall be used where all
+terms and definitions are given the document itself:
+“For the purposes of this document, the following terms
+and definitions apply.”
+</description>
+<suggestion>
+Change the introductory text to:<BR/>
+“For the purposes of this document, the following
+terms and definitions apply.”
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ITTF" num="5" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.3
+</section>
+<para></para>
+<description>
+D.1.5.3 of the ISO/IEC Directives, Part 2 states that the
+form of a definition shall be such that it can replace the
+term in context.
+</description>
+<suggestion>
+Delete the definite or indefinite article at the
+beginning of each definition.<BR/>
+Redraft definitions 1.3.11 and 1.3.13 so that they
+can replace the term in context (i.e. they should
+not be more than one sentence).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ITTF" num="6" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.3
+</section>
+<para></para>
+<description>
+D.3.1 of the ISO/IEC Directives, Part 2, states that the
+definition shall not be followed by a full stop.
+</description>
+<suggestion>
+Remove the full stops at the end of the definitions.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ITTF" num="7" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.3
+</section>
+<para></para>
+<description>
+D.3.9 of the ISO/IEC Directives, Part 2, provides
+examples on how to present examples and notes to terms
+and definitions. The examples and notes to the terms and
+definitions are not presented in accordance with D.3.9 of
+the ISO/IEC Directives, Part 2.
+</description>
+<suggestion>
+Redraft the notes and examples to the terms and
+definitions in accordance with D.3.9 of the
+ISO/IEC Directives, Part 2.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="3" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.3
+</section>
+<para>
+1
+</para>
+<description>
+The library stretches out to clause 30 now, and the terms
+in 17.3 should cover them too.
+</description>
+<suggestion>
+Update reference to clause 27 to say clause 30.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="15" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.3
+</section>
+<para>
+1
+</para>
+<description>
+There is a description, "17.3 defines additional terms that
+are used only in Clauses 17 through 27 and Annex D.",
+but the terms defined in 17.3 are also used in Clauses 28
+through 30, which are added recently. So the scope
+should be expanded to include them.
+</description>
+<suggestion>
+17.3 defines additional terms that are used only in
+Clauses 17 through 30 and Annex D.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="4" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.3.10
+</section>
+<para></para>
+<description>
+The phrase "catch clause" in the 2003 standard has
+become "catch Clause"
+</description>
+<suggestion>
+Change back the "catch clause"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="RU" num="1" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.7
+</section>
+<para>
+p.5, line 5 from end
+</para>
+<description>
+Reference missed
+</description>
+<suggestion>
+Insert reference "(2.3)" after "basic execution
+character set"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="5" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.9
+</section>
+<para>
+3
+</para>
+<description>
+The evaluation of function arguments are now
+indeterminately sequenced, rather than left completely
+unspecified, as part of the new language describing the
+memory model. A clearer example of unspecified behavior
+should be used here.
+</description>
+<suggestion>
+[Need to identify a better example to propose]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="6" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.9
+</section>
+<para>
+4
+</para>
+<description>
+There are core issues surrounding the undefined behavior
+of dereferencing a null pointer. It appears the intent is that
+dereferencing *is* well defined, but using the result of the
+dereference will yield undefined behavior. This topic is too
+confused to be the reference example of undefined
+behavior, or should be stated more precisely if it is to be
+retained.
+</description>
+<suggestion>
+[Identify a better example of undefined behavior to
+propose]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="2" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.9 and 1.10
+</section>
+<para></para>
+<description>
+It's not clear whether relaxed atomic operations are
+observable behaviour.
+</description>
+<suggestion>
+Clarify it.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="7" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.9.6
+</section>
+<para>
+p6
+</para>
+<description>
+From a naive, first-time reader's point of view, 1.9.6 made
+me double take, as it seemed it could imply any signal
+would leave the program in an unspecified state after
+completing. I believe I understand the intent, but to clarify
+it, I'd change it to make it clear that the unspecified state
+applies only for the duration of the signal handler.
+</description>
+<suggestion>
+Change:<BR/>
+6 When the processing of the abstract machine is
+interrupted by receipt of a signal, the values of
+objects which are neither
+of type volatile std::sig_atomic_t nor
+lock-free atomic objects (29.4)
+are unspecified, and the value of any object not in
+either of these two categories that is modified by
+the handler becomes undefined.
+
+to:
+
+6 When the processing of the abstract machine is
+interrupted by receipt of a signal, the values of
+objects which are neither
+of type volatile std::sig_atomic_t nor
+lock-free atomic objects (29.4)
+are unspecified for the duration of the signal
+handler, and the value of any object not in either
+of these two categories that is modified by the
+handler becomes undefined.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="8" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.9
+</section>
+<para>
+footnote 7
+</para>
+<description>
+The footnote "Overloaded operators are never assumed
+to be associative or commutative." is either meaningless
+or overly restrictive.
+</description>
+<suggestion>
+Change the footnote to "Overloaded operators are
+assumed to be non-associative and noncommutative
+until proven otherwise.".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="23" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10, 29
+</section>
+<para>
+1.10, 29
+</para>
+<description>
+C1x has added new atomics
+C1x has added new atomics syntax, and in some cases
+new semantics and operations. C++0x needs to consider
+aligning with the new C1x atomics
+</description>
+<suggestion>
+Add back compatibility between C++0x and C1x
+atomics
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="14" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p4
+</section>
+<para>
+1.10p4
+</para>
+<description>
+Initialisation of atomics
+
+Add the following to 1.10p4:
+
+[ Note: There may be non-atomic writes to atomic
+objects, for example on initialization and reinitialization.
+- end note]
+
+Rationale: We believe the intent is that for any atomic
+there is a distinguished initialisation write, but that this
+need not happens-before all the other operations on that
+atomic - specifically so that the initialisation write might be
+non-atomic and hence give rise to a data race, and hence
+undefined behaviour, in examples such as this (from
+Hans):
+<PRE>
+atomic< atomic<int> * > p
+f() |
+{ atomic<int>x; | W_na x
+p.store(&x,mo_rlx); | W_rlx p=&x
+} |
+</PRE>
+(where na is nonatomic and rlx is relaxed). We suspect
+also that no other mixed atomic/nonatomic access to the
+same location is intended to be permitted. The possibility
+of non-atomic writes on atomic objects is not mentioned in
+1.10, and (before talking with Hans) we didn't realise it
+was intended, so we suggest adding the note above to
+clarify things.
+</description>
+<suggestion>
+Add the following to 1.10p4:<BR/>
+[ Note: There may be non-atomic
+writes to atomic objects, for example
+on initialization and renitialization. - end note]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="12" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p6
+</section>
+<para>
+1.10p6
+</para>
+<description>
+The use of maximal in the definition of release sequence
+(proposed edit seems reasonable to Clark)<BR/>
+We suggest that 1.10p6 be changed to:<BR/>
+A release sequence from a release operation A on an
+atomic object M is a maximal contiguous sub-sequence
+of side effects in the modification order of M, where
+the first operation is A, and every subsequent
+operation<BR/>
+- is performed by the same thread that performed
+the release, or<BR/>
+- is an atomic read-modify-write operation.<BR/>
+Rationale: The current wording of the standard suggests
+that release sequences are maximal with respect to
+sequence inclusion, i.e. that if there are two release
+operations in the modification order,<BR/>
+<PRE>
+mod mod
+rel1----->rel2----->w
+</PRE>
+then [rel1;rel2;w] is the only release sequence, as the
+other candidate [rel2;w] is included in it. This interpretation
+precludes synchronizing with releases which have other
+releases sequenced-before them. We believe that the
+intention is actually to define the maximal release
+sequence from a particular release operation, which would
+admit both [rel1;rel2;w] and [rel2;w].</description>
+<suggestion>
+We suggest that 1.10p6 be changed to:<BR/>
+A release sequence from a release
+operation A on an atomic object M is
+a maximal contiguous sub-sequence
+of side effects in the modification
+order of M, where the first
+operation is A, and every subsequent
+operation<BR/>
+- is performed by the same thread
+that performed the release, or<BR/>
+- is an atomic read-modify-write
+operation.</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="9" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+para 4
+</para>
+<description>
+The "operations on locks" do not provide synchronization,
+as locks are defined in Clause 30.
+</description>
+<suggestion>
+Change "operations on locks" to "locking
+operations".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="20" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p1
+</section>
+<para>
+1.10p1
+</para>
+<description>
+Reading from the last element in a vsse?
+Paul wrote:<BR/>
+> If every element in a vsse happens-before a given value<BR/>
+> computation, then that value computation must return<BR/>
+> the value stored by the last element in the vsse.<BR/>
+We wrote:<BR/>
+We're not sure about that. Consider the following, with two
+relaxed writes to x on one thread that are not sequencedbefore
+related to each other (eg in different arguments to
+the same function), but are followed by a release/acquire
+on a different variable y to another thread that then reads
+x. We think the final read (e) could read from either (a) or
+(b), regardless of how (a) and (b) are related in
+modification order.
+<PRE>
+a:Wrlx x=1 b:Wrlx x=2
+\ /
+sb\ /sb
+\ /
+c:Wrel y-----------
+\sw
+\
+d:Racq y
+|
+|sb
+|
+e:Rrlx x=?
+</PRE>
+|
+Paul> In that case IIRC, the standard does not specify<BR/>
+Paul> the order, but the code will be generated in some<BR/>
+Paul> order, and that arbitrary choice on the part of the<BR/>
+Paul> compiler will determine the modification order.<BR/>
+We agree that in a normal implementation (eg where the<BR/>
+argument evaluations are not spawned off to new threads
+- is that intended to be forbidden?), the two writes will
+indeed be ordered according to the generated-code order
+(and before the release fence), and hardware coherence
+will ensure that (e) reads the later one.<BR/>
+But in the draft standard as written, that execution is
+allowed - the draft doesn't currently impose that aspect of
+coherence. To make the example more concrete, if there
+were another thread with<BR/>
+<PRE>
+c --sw--> f:Racq y --sb--> g:Rrlx x
+</PRE>
+then e and g could read different values.<BR/>
+Paul notes:<BR/>
+> But 1.10p1 says:<BR/>
+><BR/>
+> A thread of execution (also known as a thread) is a<BR/>
+> single flow of control within a program, including<BR/>
+> the initial invocation of a specific top-level<BR/>
+> function, and recursively including every function<BR/>
+> invocation subsequently executed by the thread.<BR/>
+><BR/>
+> This excludes the possibility of the implementation<BR/>
+> spawing off a new thread -unless- the implementation<BR/>
+> can make things appear as if there was only one thread.<BR/>
+> From this viewpoint, your example shows just how<BR/>
+> careful an implementation must be if it is to fully<BR/>
+> comply with this as-if rule.<BR/>
+We replied<BR/>
+>ok, thanks<BR/>
+to this, but in fact the situation is still unclear.<BR/>
+1.10p1 does indeed rule out the hypothetical
+implementation that we mentioned, but even if (a) and (b)
+would be ordered by any reasonable implementation, in
+terms of the concepts of the standard, that doesn't
+introduce a sequenced-before edge between (a) and (b).<BR/>
+It seems that Paul is assuming the individual memory
+accesses in function arguments are indeterminately
+sequenced rather than unsequenced?
+</description>
+<suggestion>
+Please clarify.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="19" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p5 1.10p13
+</section>
+<para>
+1.10p5 1.10p13
+</para>
+<description>
+Alternative definition of the value read by an atomic
+operation<BR/>
+Here's an interesting example involving a
+release/consume pair. We believe that in a direct
+implementation on hardware, this would be forbidden by
+coherence, but that the current text allows it. We don't
+know whether it should be allowed or not.
+<PRE>
+hb
+do
+rf
+Wx_release ----> Rx_consume
+^ |
+\ |sb,hb
+mo \ v
+--- Wx_release
+</PRE>
+Paul claims this is forbidden by 1.10p5, but we don't see
+how that can be the case. We don't see much room in
+1.10p5 for any other interpretation - it says:<BR/>
+- "All modifications to a particular atomic object M occur in
+some particular total order, called the modification order of
+M"<BR/>
+- "If A and B are modifications of an atomic object M and
+A happens before (as defined below) B, then A shall
+precede B in the modification order of M, which is defined
+below."<BR/>
+Both of which seem very clear. The only wiggle room is in
+the Note<BR/>
+- "[Note: This states that the modification orders must
+respect the "happens before" relationship]"<BR/>
+We took that "must respect" to be a gloss rather than to
+add any additional constraint.<BR/>
+Earlier we suggested a change, to the constraint on the
+value read by an atomic operation, that would forbid this
+example:<BR/>
+The standard introduces visible side effects, which are
+used first to define the values read by non-atomic
+operations. They are then re-used to constrain the value
+read by atomic operations: 1.10p13 says that an atomic
+operation must read from somewhere in "the" visible
+sequence of side effects, which must start from *a* visible
+side effect, i.e. a side effect that (a) happens before the
+read, and (b) is not happens-before-hidden. We suspect
+that this re-use of the notion of visible side effect may be a
+drafting artifact, in which case one might remove the
+requirement that there is a vse for atomics, and replacing
+the first two sentences of 1.10p13 by<BR/>
+"An atomic operation must read from somewhere in the
+modification order that is not happens-before-hidden
+and does not follow (in modification order) any side
+effect that happens-after the read."BR/>
+Now we're not sure how this would fit in with initialisation
+and reading of indeterminate values; we need to think
+about it more.
+</description>
+<suggestion>
+Please clarify.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="22" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p8
+</section>
+<para>
+1.10p8
+</para>
+<description>
+Control dependencies for atomics<BR/>
+Given the examples of compilers interchanging data and
+control dependencies, and that control dependencies are
+architecturally respected on Power/ARM for load->store
+(and on Power for load->load with a relatively cheap
+isync), we're not sure why carries-a-dependency-to does
+not include control dependencies between atomics.
+</description>
+<suggestion>
+Please clarify.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="15" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p9
+</section>
+<para>
+1.10p9
+</para>
+<description>
+Intra-thread dependency-ordered-before<BR/>
+The current draft has release/acquire synchronize-with
+edges only between a release on one thread and an
+acquire on a *different* thread, whereas the definition of
+We suggest changing the definition of
+dependency-ordered-before permits the release and
+consume to be on the same thread; it seems odd to permit
+the latter. (At the moment function arguments can't race or
+sync with each other, but they can be dependency
+ordered before each other.)<BR/>
+We don't currently have an example in which this makes a
+real difference, but for symmetry could suggest changing
+the definition of dependency-ordered-before in 1.10p9 to
+the following:<BR/>
+An evaluation A is dependency-ordered before an
+evaluation B if<BR/>
+- A performs a release operation on an atomic object
+M, and on another thread, B performs a consume
+operation on M and reads a value written by any
+side effect in the release sequence headed by A,<BR/>
+or<BR/>
+- for some evaluation X, A is dependency-ordered
+before X and X carries a dependency to B.
+</description>
+<suggestion>
+dependency-ordered-before in 1.10p9 to the
+following:<BR/>
+An evaluation A is dependency-ordered
+before an evaluation B if<BR/>
+- A performs a release operation
+on an atomic object M, and on
+another thread, B performs a
+consume operation on M and reads
+a value written by any side
+effect in the release sequence
+headed by A, or<BR/>
+- for some evaluation X, A is
+dependency-ordered before X and
+X carries a dependency to B.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="11" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p12
+</section>
+<para>
+1.10p12
+</para>
+<description>
+"Subsequent" in vsse definition<BR/>
+Remove the word "subsequent" from the definition of
+visible sequence of side effects in 1.10p12.<BR/>
+(as suggested by Hans)<BR/>
+Rationale: if every element in a vsse happens-before a
+read, the read should not take the value of the visible side
+effect.
+</description>
+<suggestion>
+Remove the word "subsequent" from the definition
+of visible sequence of side effects in 1.10p12.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="17" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p12
+</section>
+<para>
+1.10p12
+</para>
+<description>
+1.10p12 phrasing<BR/>
+1.10p12 last note:
+"...as defined here..." should be
+"...as defined below...".
+</description>
+<suggestion>
+1.10p12 last note:<BR/>
+"...as defined here..." should be
+"...as defined below...".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="13" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p13
+</section>
+<para>
+1.10p13
+</para>
+<description>
+Wording of the read-read coherence condition<BR/>
+In 1.10p13 a coherence condition is stated on the values
+of atomic reads:<BR/>
+"Furthermore, if a value computation A of an atomic
+object M happens before a value computation B of M,
+and the value computed by A corresponds to the value
+stored by side effect X, then the value computed by B
+shall either equal the value computed by A, or be the
+value stored by side effect Y, where Y follows X in
+the modification order of M."<BR/>
+We suggest that this be replaced with the following:<BR/>
+"Furthermore, if a value computation A of an atomic
+object M happens before a value computation B of M,
+and A takes its value from the side effect X, then
+the value computed by B shall either be the value
+stored by X, or the value stored by a side effect Y,
+where Y follows X in the modification order of M."<BR/>
+Rationale: The words "corresponds to" are not used
+elsewhere in the standard, as far as we can see, and it is
+unclear whether they have a special meaning here. In
+addition taking the value of the read B from the value read
+by A seems unnecessarily indirect. B could take its value
+from X instead.
+</description>
+<suggestion>
+In 1.10p13 a coherence condition is stated on the
+values of atomic reads:<BR/>
+"Furthermore, if a value
+computation A of an atomic object M
+happens before a value computation
+B of M, and the value computed by A
+corresponds to the value stored by
+side effect X, then the value
+computed by B shall either equal
+the value computed by A, or be the
+value stored by side effect Y,
+where Y follows X in the
+modification order of M."<BR/>
+We suggest that this be replaced with the
+following:<BR/>
+"Furthermore, if a value
+computation A of an atomic object M
+happens before a value computation
+B of M, and A takes its value from
+the side effect X, then the value
+computed by B shall either be the
+value stored by X, or the value
+stored by a side effect Y, where Y
+follows X in the modification order
+of M."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="18" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p13
+</section>
+<para>
+1.10p13
+</para>
+<description>
+Non-unique visible sequences of side effects and
+happens-before ordering<BR/>
+In 1.10p13, replace<BR/>
+"The visible sequence of side effects on..." by
+"A visible sequence of side effects on..."<BR/>
+and<BR/>
+"in the visible sequence of M with respect to B" by
+"in a visible sequence of M with respect to B"<BR/>
+Rationale: the current standard allows multiple visible
+sequences of side effects (vsse's) for a given read
+(despite the use of "The" at the start of 1.10p13). We
+demonstrate this by constructing an execution with two
+vsse's. The following execution has five memory
+operations, four of which are read modify writes (RMW's).
+There are two threads, one with four operations each
+ordered by sequenced before (sb), the other with a single
+RMW release.
+<PRE>
+RMW1 +---RMW3_release
+| /
+|sb do/
+v /
+R_consume<---+
+|
+|sb
+v
+RMW2
+|
+|sb
+v
+RMW4
+</PRE>
+The modification order in this example is as
+follows:
+<PRE>
+mod mod mod
+RMW1----->RMW2----->RMW3_release----->RMW4
+</PRE>
+With the modification order we give above, the
+happens-before relation
+has exactly these edges, according to 1.10p10:
+<PRE>
+From sequenced-before:
+RMW1 -> R_consume, RMW2, RMW4
+R_consume -> RMW2, RMW4
+RMW2 -> RMW4
+From ithb:
+From dependency-ordered-before:
+RMW3_release -> R_consume
+</PRE>
+In particular, there are no edges
+<PRE>
+RMW3_release -> RMW2 or RMW4.
+</PRE>
+As we understand it, this is the intended
+absence of transitivity from dependency-orderedbefore
+to sequenced-before.<BR/>
+1.10p5 says that if A happens-before B then A precedes B
+in the modification order, which is true for all the happensbefore
+edges and the modification order above.<BR/>
+RMW1 and RMW3_release are visible side effects<BR/>
+RMW2 and RMW4 follow R_consume in happens-before,
+so cannot be in a visible sequence of side effects.<BR/>
+Hence the two visible sequences of side effects are
+[RMW1] and [RMW3].<BR/>
+The R_consume here must read from the later vsse in
+modification order for the dependency_ordered edge to
+exist. The existence of two vsse's relies on the lack of
+transitivity of happens before (which only occurs in the
+presence of consume operations).
+</description>
+<suggestion>
+In 1.10p13, replace<BR/>
+"The visible sequence of side
+effects on..."<BR/>
+by<BR/>
+"A visible sequence of side effects
+on..."<BR/>
+and<BR/>
+"in the visible sequence of M with
+respect to B"<BR/>
+by<BR/>
+"in a visible sequence of M with
+respect to B"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="10" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+Paragraph 14
+</para>
+<description>
+The definition of a data race does not take into account
+two overlapping atomic operations
+</description>
+<suggestion>
+Augment the first sentence:<BR/>
+The execution of a program contains a data race if
+it contains two conflicting actions in different
+threads, at least one of which is not atomic <ins>(or
+both are atomic and operate on overlapping, but
+not-identical, memory locations)</ins>, and neither
+happens before the other.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="11" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+para7
+</para>
+<description>
+There is some confusion between locks and mutexes.
+</description>
+<suggestion>
+Change "lock" when used as a noun to "mutex".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="12" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+P4,p14, p6,p12,p13
+</para>
+<description>
+Adapt N3074:<BR/>
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3074.html
+</description>
+<suggestion>
+Proposed change in N3074:
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3074.html
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="2" type="various" owner="" issue="" disp="" date="" extdoc="">
+<section>
+various
+</section>
+<para>
+various
+</para>
+<description>
+Canada agrees with US 12, 14, 142, 145, 159
+</description>
+<suggestion>
+Resolve as suggested in these comments
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="8" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+4, 7
+</para>
+<description>
+The text says that the library "provides ... operations on
+locks". It should say "operations on mutexes", since it is
+the mutexes that provide the synchronization. A lock is
+just an abstract concept (though the library types
+unique_lock and lock_guard model ownership of locks)
+and as such cannot have operations performed on it. This
+mistake is carried through in the notes in that paragraph
+and in 1.10p7
+</description>
+<suggestion>
+Change 1.10p4 as follows:<BR/>
+"The library defines a number of atomic
+operations (Clause 29) and operations on
+mutexes (Clause 30) that are specially identified
+as synchronization operations. These operations
+play a special role in making assignments in one
+thread visible to another. A synchronization
+operation on one or more memory locations
+is either a consume operation, an acquire
+operation, a release operation, or both an acquire
+and release operation. A synchronization
+operation without an associated memory location
+is a fence and can be either an acquire fence, a
+release fence, or both an acquire and release
+fence. In addition, there are relaxed atomic
+operations, which are not synchronization
+operations, and atomic read-modify-write
+operations, which have special characteristics. [
+Note: For example, a call that acquires a lock on a
+mutex will perform an acquire operation on the
+locations comprising the mutex. Correspondingly,
+a call that releases the same lock will perform a
+release operation on those same locations.
+Informally, performing a release operation on A
+forces prior side effects on other memory
+locations to become visible to other threads that
+later perform a consume or an acquire operation
+on A. “Relaxed” atomic operations are not
+synchronization operations even though, like
+synchronization operations, they cannot contribute
+to data races. end note ]"<BR/>
+Change 1.10p7 as follows:<BR/>
+"Certain library calls synchronize with other library
+calls performed by another thread. In particular,
+an atomic operation A that performs a release
+operation on an atomic object M synchronizes
+with an atomic operation B that performs an
+acquire operation on M and reads a value written
+by any side effect in the release sequence headed
+by A. [ Note: Except in the specified cases,
+reading a later value does not necessarily ensure
+visibility as described below. Such a requirement
+would sometimes interfere with efficient
+implementation. end note ] [ Note: The
+specifications of the synchronization operations
+define when one reads the value written by
+another. For atomic objects, the definition is clear.
+All operations on a given mutex occur in a single
+total order. Each lock acquisition “reads the value
+written” by the last lock release on the same
+mutex. —end note ]"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="9" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+6
+</para>
+<description>
+See (B) in attachment Appendix 1 - Additional Details
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="10" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+10
+</para>
+<description>
+See (C) in attachment Appendix 1 - Additional Details<BR/>
+The GB would like WG21 to confirm there is no issue
+related to this.<BR/>
+GB adds:<BR/>
+We agree that if the read from x reads the value written by
+the write to
+x the write to x inter-thread-happens-before the write to y.
+However, the read from y is sequenced before the write to
+x, so if the
+read from x reads the value written by the write to x, then
+the read
+from y also inter-thread-happens-before the write to y.
+Consequently,
+the read from y cannot see the value written by the write
+to y.
+The reciprocal ordering also applies, but they cannot both
+apply in the
+same execution since if the write to x happens-before the
+read from x
+then the read from y happens-before the write to y, and
+vice-versa.
+There is thus no contradiction.
+[see comment below for proper formatting]
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="8" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10p10
+</section>
+<para>
+1.10p10
+</para>
+<description>
+Rationale: Without this the standard
+permits executions with a cyclic
+happens-before relation that it seems
+clear should be forbidden, e.g.
+<PRE>
+Rx_consume<--+ +-->Ry_consume
+| rf\ /rf |
+|sb X |sb
+v / \ v
+Wy_release---+ +---Wx_release
+</PRE>
+One could instead impose acyclicity on
+happens-before; that would be
+equivalent.
+</description>
+<suggestion>
+1.10p10, before the Note, add:<BR/>
+"The inter-thread happens-before relation of an
+execution must be acyclic"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="11" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+12
+</para>
+<description>
+See (E) in attachment Appendix 1 - Additional Details
+The GB would like WG21 to confirm there is no issue
+related to this.<BR/>
+GB adds:
+[see comment below for proper formatting]
+The variable in question has a single modification order,
+which is any of<BR/>
+(a) RMW3, RMW1, RMW2, RMW4.<BR/>
+(b) RMW1, RMW3, RMW2, RMW4.<BR/>
+(c) RMW1, RMW2, RMW3, RMW4.<BR/>
+(d) RMW1, RMW2, RMW4, RMW3.<BR/>
+since RMW1, RMW2 and RMW4 occur in a single thread
+in that sequence, and
+RMW3 occurs in a separate thread with no other ordering
+constraints.
+Since the R_consume lies between RMW1 and RMW2 in
+that thread, it must
+either read the value written by RMW1 (which could
+happen if it
+immediately follows RMW1 in any of the sequences), or
+RMW3 (which could
+happen with sequence (b)).
+The visible sequence of side effects for R_consume is
+thus either RMW3,
+RMW1 (from (a)), RMW1 (from (b), (c) or (d)), or RMW1,
+RMW3 (from (b)).
+Which sequence applies in practice may vary from
+execution to execution.
+There is however only a single sequence on any given
+execution.
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="12" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+13
+</para>
+<description>
+See (F) in attachment Appendix 1 - Additional Details<BR/>
+The GB would like WG21 to confirm there is no issue
+related to this.
+GB adds:<BR/>
+The cycle given is clearly forbidden by the current text.
+The read is sequenced-before the write in the same
+thread. If the read sees the value written by the other
+thread then that write is dependency-ordered-before the
+read, and thus happens-before the read,
+and happens-before the write from the reading thread.
+The write from the left-hand thread thus must occur before
+the write from the right-hand thread in the modification
+order of the object by 1.10p5.
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="13" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+13
+</para>
+<description>
+See (G) in attachment Appendix 1 - Additional Details<BR/>
+GB suggests alternative wording to that in the attached
+paper:<BR/>
+"Furthermore, if a value computation A of an atomic object
+M happens before a value computation B of M, and A
+uses the value of M from the side effect X, then the value
+computed by B shall either be the value stored by X, or
+the value stored by a side effect Y, where Y follows X in
+the modification order of M."
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="14" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+8
+</para>
+<description>
+See (I) in attachment Appendix 1 - Additional Details<BR/>
+GB adds:
+If an implementation can't guarantee the ordering it should
+refrain from performing the optimisation
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="15" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para></para>
+<description>
+See (J) in attachment Appendix 1 - Additional Details
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="16" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+1.10
+</section>
+<para>
+12
+</para>
+<description>
+See (L) in attachment Appendix 1 - Additional Details
+</description>
+<suggestion>
+"...as defined here..." should be "...as defined
+below...".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="13" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.2
+</section>
+<para>
+1
+</para>
+<description>
+“Raw” strings are still only Pittsburgh-rare strings: the
+reversion in phase 3 only applies to an r-char-sequence.
+</description>
+<suggestion>
+Make the reversion apply to the entire raw-string.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="14" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.2 2.3 2.5 2.14.5
+</section>
+<para>
+P1
+</para>
+<description>
+Precedence of reversal and tokenization<BR/>
+The current paper implies that determination of the
+characters forming an r-char-sequence occurs while the
+transformations done in phase 1 and phase 2 are still in
+effect.<BR/>
+Consider these cases:<BR/>
+<UL><LI> Line splicing occurred in translation phase 2; the
+backslash is not there on entry to phase 3 when
+we try to tokenize:<BR/>
+const char str[] = R"a()\a")a";</LI>
+<LI> Trigraph replacement occurred in phase 1. The
+right parenthesis is not there on entry to phase 3:<BR/>
+const char str[] = R"(??)";</LI>
+<LI> Trigraph replacement (again). In [lex.string]
+paragraph 2, there is a footnote 24 in N3092.
+Note that this provides fuel for anti-trigraph
+sentiment:<BR/>
+const char str[] = R"#()??=")#";</LI></UL>
+Change in [lex.string] from N3077:<BR/>
+Escape sequences and universal-characternames
+in non-raw string literals have the same
+meaning as in character literals ....<BR/>
+should be reflected in [lex.phases] paragraph 1, phase 5
+(CD2 wording):<BR/>
+Each source character set member and universalcharacter-
+name in a character literal or a string literal, as
+well as each escape sequence in a character literal or a
+non-raw string literal, is converted to the corresponding
+member of the execution character set (2.14.3, 2.14.5); if
+there is no corresponding member, it is converted to an
+implementation-defined member other than the null (wide)
+character<BR/>
+and [lex.charset] paragraph 2 (CD2 wording):<BR/>
+Additionally, if the hexadecimal value for a universalcharacter-
+name outside the <I>c-char-sequence</I>, <I>s-charsequence</I>,
+or <I>r-char-sequence</I> of a character or string
+literal corresponds to a control character (in either of the
+ranges 0x000x1F or 0x7F0x9F, both inclusive) or to a
+character in the basic source character set, the program is
+ill-formed.<BR/>
+UCNs simply do not occur in the grammar for r-char-sequence
+anyway.
+</description>
+<suggestion>
+In 2.14.5 [lex.string] paragraph 2: Remove
+footnote 24:<BR/>
+In 2.2 [lex.phases] paragraph 1, phase 1; insert
+exception:<BR/>
+Physical source file characters are
+mapped, in an implementation-defined
+manner, to the basic source character
+set (introducing new-line characters for
+end-of-line indicators) if necessary. The
+set of physical source file characters
+accepted is implementation-defined.
+Trigraph sequences (2.4) are replaced by
+corresponding single-character internal
+representations. Any source file
+character not in the basic source
+character set (2.3) is replaced by the
+universal-character-name that
+designates that character. (An
+implementation may use any internal
+encoding, so long as an actual extended
+character encountered in the source file,
+and the same extended character
+expressed in the source file as a
+universal-character-name (i.e., using the
+\uXXXX notation), are handled
+equivalently except where this
+replacement is reverted.)<BR/>
+In 2.2 [lex.phases] paragraph 1, phase 3:<BR/>
+The source file is decomposed into
+preprocessing tokens (2.5) and
+sequences of white-space characters
+(including comments). A source file shall
+not end in a partial preprocessing token
+or in a partial comment. Each comment
+is replaced by one space character.
+New-line characters are retained.
+Whether each nonempty sequence of
+white-space characters other than newline
+is retained or replaced by one space
+character is unspecified. The process of
+dividing a source file's characters into
+preprocessing tokens is contextdependent.
+[ Example: see the handling
+of < within a #include preprocessing
+directive. —end example ]<BR/>
+In 2.2 [lex.phases] paragraph 1, phase 5:<BR/>
+Each source character set member in a
+character literal or a string literal, as well
+as each escape sequence and universalcharacter-
+name in a character literal or a
+non-raw string literal, is converted to the
+corresponding member of the execution
+character set (2.14.3, 2.14.5); if there is
+no corresponding member, it is
+converted to an implementation-defined
+member other than the null (wide)
+character.<BR/>
+In 2.3 [lex.charset] paragraph 2:<BR/>
+.... Additionally, if the hexadecimal value
+for a universal-character-name outside
+the c-char-sequence or s-char-sequence
+of a character or string literal
+corresponds to a control character (in
+either of the ranges 0x000x1F or 0x7F
+0x9F, both inclusive) or to a character in
+the basic source character set, the
+program is ill-formed. [ Footnote: A
+sequence of characters resembling a
+universal-character-name in an r-char-sequence
+(2.14.5 [lex.string]) does not
+form a universal-character-name. ]<BR/>
+In 2.5 [lex.pptoken] paragraph 3:<BR/>
+If the input stream has been parsed into
+preprocessing tokens up to a given
+character:
+<UL><LI> if the next character begins a
+sequence of characters that
+could be the prefix and initial
+double quote of a raw string
+literal, such as R", the next
+preprocessing token shall be a
+raw string literal and any
+transformations performed in
+phases 1 and 2 on this input
+stream (trigraphs, universalcharacter-
+names, and line
+splicing) are reverted for the
+remainder of the stream until
+said raw string literal (2.14.5) is
+matched; [ Footnote: A raw
+string literal formed through
+token concatenation (16.3.3) is
+not parsed from an input stream
+and is not subject to this
+reverting. Destringization (16.9)
+involves an alternate input
+stream, thus there are no phase
+1 or phase 2 transformations to
+revert. ]</LI>
+<LI> otherwise, the next
+preprocessing token is the
+longest sequence of characters
+that could constitute a
+preprocessing token, even if
+that would cause further lexical
+analysis to fail.</LI></UL>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="15" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.6
+</section>
+<para>
+para 2
+</para>
+<description>
+The <: digraph causes problem with users unfamiliar with
+digraphs when passing global objects as template
+arguments.
+</description>
+<suggestion>
+Add a special hack for <:: much like the special
+hack for >>.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="24" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.11
+</section>
+<para>
+Various
+</para>
+<description>
+A list of issues related TR 10176:2003<BR/>
+1)
+"Combining characters should not appear as the first
+character of an identifier."
+Reference: ISO/IEC TR 10176:2003 (Annex A)
+This is not reflected in FCD.<BR/>
+2)
+Restrictions on the first character of an identifier are not
+observed as
+recommended in TR 10176:2003. The inclusion of digits
+(outside of those in
+the basic character set) under identifer-nondigit is implied
+by FCD.<BR/>
+3)
+It is implied that only the "main listing" from Annex A is
+included for C++.
+That is, the list ends with the Special Characters section.
+This is not made
+explicit in FCD. Existing practice in C++03 as well as WG
+14 (C, as of N1425)
+and WG 4 (COBOL, as of N4315) is to include a list in a
+normative Annex.<BR/>
+4)
+Specify width sensitivity as implied by C++03: \uFF21 is
+not the same as A
+Case sensitivity is already stated in [lex.name].
+</description>
+<suggestion>
+Please clarify.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="17" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.2
+</section>
+<para>
+Table 5
+</para>
+<description>
+[lex.icon] 2.14.2/2 Table 5 - 'Types of integer constants' In
+the penultimate row for this table (for suffix `ll or LL') it
+gives the `Octal or hexadecimal constant' in the third
+column as one of: long long int unsigned long int Unless I
+am misunderstanding something fundamental, this second
+should be: unsigned long long int
+</description>
+<suggestion>
+Replace the entry for "ll or LL" and "Octal or
+hexadecimal constant" in table 5 with "long long
+int unsigned long long int"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="16" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.3
+</section>
+<para>
+2 Note
+</para>
+<description>
+Typo, "wide-charater" should be "wide-character".
+</description>
+<suggestion>
+Correct typo.<BR/>
+[ Note: the type wchar_t is able to represent all
+members of the execution wide-character set (see
+3.9.1).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="RU" num="2" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.3
+</section>
+<para>
+p.23, par.3, line 1
+</para>
+<description>
+Reference missed
+</description>
+<suggestion>
+Insert reference "(3.9.1)" after "extended integer
+type"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="2" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.4
+</section>
+<para></para>
+<description>
+C++ does not support hexadecimal floating-point literals,
+although they are useful to specify exact floating-point
+constants.
+</description>
+<suggestion>
+Consider supporting the C99 syntax for
+hexadecimal floating-point literals.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="16" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.5 [lex.string]
+</section>
+<para></para>
+<description>
+Raw string literals have no implementation experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N2146 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="3" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.7
+</section>
+<para></para>
+<description>
+It is not sufficiently clear that std::nullptr_t is a distinct type
+and neither a pointer type nor a pointer-to-member type.
+</description>
+<suggestion>
+Add a note in 2.14.7 stating that, preferably with
+cross-references to the normative statements in
+3.9.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="RU" num="5" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.7
+</section>
+<para>
+p. 28
+</para>
+<description>
+Page layout bug
+</description>
+<suggestion>
+Move footnote 24 from page 28 to page 27
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="17" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.8
+</section>
+<para>
+6
+</para>
+<description>
+In general, the parameter type of a literal operator must be
+the same as the argument passed to it. That is not the
+case for a user-defined-character-literal, where the
+argument could inadvertently match a literal operator
+intended for use with user-defined-integer-literals:
+<PRE>
+typedef unsigned long long ULL;
+int operator "" X(ULL);
+int i = 'c'X; // operator"" X(ULL('c'))
+</PRE>
+</description>
+<suggestion>
+Add the following phrase to the description in
+paragraph 6:<BR/>
+S shall contain a literal operator whose parameter
+type is the same as the type of ch.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="17" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.8
+</section>
+<para>
+3
+</para>
+<description>
+Typo, missing ",".<BR/>
+If S contains a raw literal operator the literal L is treated as
+</description>
+<suggestion>
+Correct typo.<BR/>
+If S contains a raw literal operator, the literal L is
+treated as
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="18" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.14.8
+</section>
+<para>
+4
+</para>
+<description>
+Typo, missing ",".<BR/>
+If S contains a raw literal operator the literal L is treated as
+</description>
+<suggestion>
+Correct typo.<BR/>
+If S contains a raw literal operator, the literal L is
+treated as
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="18" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+2.24.8 [lex.ext]
+</section>
+<para></para>
+<description>
+User-defined literals have no implementation experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N2750 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="19" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3
+</section>
+<para>
+4
+</para>
+<description>
+It is not always clear when the term "use" is intended as a
+reference to the definition in 3.2 and when it has its
+normal English meaning. For example, 3 paragraph 4
+reads, "A name is a use of an identifier..."
+</description>
+<suggestion>
+Replace all occurrences of the word "use" that are
+not intended as references to 3.2 with some other
+term, such as "occurrence" or "appearance" or
+"reference to".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="20" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.1
+</section>
+<para>
+para 1 bullet 4
+</para>
+<description>
+Grammatical number mismatch in "an assignment
+expressions".
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="21" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.1
+</section>
+<para>
+2
+</para>
+<description>
+using N::d; does not declare N::d.
+</description>
+<suggestion>
+using N::d; // declares d
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="22" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.2
+</section>
+<para>
+4
+</para>
+<description>
+The type of the expression of a decltype-specifier is
+apparently required to be complete.
+</description>
+<suggestion>
+Make an exception so that a template
+specialization type is not instantiated merely
+because it's the type of the expression in
+decltype( expression )
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="19" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.2
+</section>
+<para>
+4
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(10)" to "(Clause 10)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="20" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.3.2
+</section>
+<para>
+7
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(9)" to "(Clause 9)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="23" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.4.5
+</section>
+<para>
+para 1
+</para>
+<description>
+Global class templates should not hide member
+templates.
+</description>
+<suggestion>
+Strike the end of para 1 starting with "If the lookup
+in the class of the object expression finds a
+template,". See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="24" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.5
+</section>
+<para>
+3
+</para>
+<description>
+One of the critieria for giving a name internal linkage is "a
+variable that is explicitly declared const and neither
+explicitly declared extern nor previously declared to have
+external linkage." This should presumably apply to
+variables declared constexpr as well.
+</description>
+<suggestion>
+Add parallel wording for the constexpr specifier.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="4" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.5
+</section>
+<para></para>
+<description>
+It is odd that "N" has no linkage and "g" has external
+linkage in this example:
+<PRE>
+namespace {
+namespace N // has no linkage
+{
+void g(); // has external linkage
+} }
+</PRE>
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="5" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.7.3
+</section>
+<para></para>
+<description>
+The term "local" was changed globally to "block-scope",
+but this section still contains the term "local" (see also
+core issue 642).
+</description>
+<suggestion>
+Change "local" to "block-scope" in the first
+paragraph.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="RU" num="3" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.7.4.3
+</section>
+<para>
+p.65, line 7
+</para>
+<description>
+Reference missed
+</description>
+<suggestion>
+Insert reference "(5.7)" after "well-define pointer
+arithmetic"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="RU" num="4" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.7.4.3
+</section>
+<para>
+p. 65, line 8
+</para>
+<description>
+Reference missed
+</description>
+<suggestion>
+Insert references "(4.10, 5.4)" after "well-define
+pointer conversion"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="18" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.8
+</section>
+<para>
+9
+</para>
+<description>
+It isn't clear that the comment in the example actually
+reflects the result of the placement new.
+If the intended placement operator new is supposed to be
+the one given by the standard library
+,by including , the example is ill-formed as the placementnew
+expression &b is const B*
+which doesn't implicitly convert to void*.
+</description>
+<suggestion>
+Replace:<BR/>
+new (&b) const B;<BR/>
+With:<BR/>
+new (const_cast<B*>(&b)) const B;
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="25" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.11
+</section>
+<para></para>
+<description>
+C/C++ compatibility problems defined in WG21/N3093.
+</description>
+<suggestion>
+Make the changes proposed in WG21/N3093
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="26" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.7.4, 5.3.5, 12.5, 17.6.3.6, 18.6
+</section>
+<para></para>
+<description>
+Programmers may define a static member function
+operator delete that takes a size parameter indicating the
+size of the object to be deleted. The equivalent global
+operator delete is not available. This omission has
+unfortunate performance consequences.
+</description>
+<suggestion>
+Permit implementations and programmers to
+define sized versions of the global operator delete
+for use in preference to the unsized version. See
+Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="27" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+3.8
+</section>
+<para>
+4
+</para>
+<description>
+Related to core issue 1027, consider:
+<PRE>
+int f() {
+union U { double d; } u1, u2;
+(int&)u1.d = 1;
+u2 = u1;
+return (int&)u2.d;
+}
+</PRE>
+Does this involve undefined behavior? 3.8/4 seems to say
+that it's OK to clobber u1 with an int object. Then union
+assignment copies the object representation, possibly
+creating an int object in u2 and making the return
+statement well-defined. If this is well-defined, compilers
+are significantly limited in the assumptions they can make
+about type aliasing. On the other hand, the variant where
+U has an array of unsigned char member must be welldefined
+in order to support std::aligned_storage.
+</description>
+<suggestion>
+Clarify that this testcase is undefined, but that
+adding an array of unsigned char to union U would
+make it well-defined--if a storage location is
+allocated with a particular type, it should be
+undefined to create an object in that storage if it
+would be undefined to access the stored value of
+the object through the allocated type.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="28" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+4.4
+</section>
+<para>
+para 3
+</para>
+<description>
+A const member function pointer could safely be applied
+to a non-const object without violating const correctness.
+</description>
+<suggestion>
+Add an implicit conversion. See Appendix 1 -
+Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="7" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+4.11 [conv.mem], 5.2.9 [expr.static.cast]
+</section>
+<para></para>
+<description>
+The CD1 comment CH1 should be reconsidered. The
+request for being able to cast a pointer to member to a
+pointer to a base class (or any other implicitly convertible
+type) of the member is a bugfix rather than an extension.
+It's a safe conversion, thus it should be allowed. There are
+valid use cases for such conversions that are currently
+forbidden.
+</description>
+<suggestion>
+The standard should allow implicit conversions
+from “pointer to member of T of type cv D” to
+'pointer to member of T 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.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="3" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+4.11 and 5.2.9
+</section>
+<para></para>
+<description>
+With respect to the target type, pointer to members should
+behave like normal pointers. The current situation creates
+an inconsistency in the C++ type system and is therefore
+a defect in the Standard.
+</description>
+<suggestion>
+The standard should allow implicit conversions
+from ``pointer to member of T of type cv D'' to
+``pointer to member of T of type cv B'', where D is
+of class type and B is a public base of D. It should
+allow explicit conversion in the other direction.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="21" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+4.13
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(5)" to "(Clause 5)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="1" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5
+</section>
+<para>
+Paragraph 6
+</para>
+<description>
+The first half of the Note(before "In general") indicates
+that the expression "E1.E2" produces xvalue if E1 is
+xvalue regardless of E2's type. It will be true even if E2 is
+of reference type. On the other hand, according to 5.2.5
+paragraph 4, if E2 is of reference type, the result of
+"E1.E2" is lvalue regardless of E1's type. These two
+descriptions contradict each other. As 5.2.5 paragraph 4
+seems correct, 5 paragraph 6 should be corrected.
+</description>
+<suggestion>
+Modify 5 paragraph 6 so that the result of E1.E2 is
+lvalue instead of xvalue when E2 is of reference
+type.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="8" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2 [expr.prim.lambda]
+</section>
+<para></para>
+<description>
+As requested in JP 9 on CD, capturing by moving should
+be allowed for lambdas. Roshan Naik presents a very
+compelling use case in the Core Reflector message
+c++std-core-16341.
+</description>
+<suggestion>
+Allow specifying capture by move.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="4" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para>
+p1
+</para>
+<description>
+Document N3067 changed the position of attribute
+specifiers in various places. However, it left out lambda
+expressions as an oversight, so that the position of
+attribute-specifier opt in a lambda-declarator is
+inconsistent with a function declarator
+</description>
+<suggestion>
+change the rule for lambda-declarator to<BR/>
+lambda-declarator:<BR/>
+( parameter-declaration-clause ) mutableopt
+exception-specificationopt attribute-specifieropt
+trailing-return-typeopt
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="5" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para>
+p4 first bullet
+</para>
+<description>
+typo
+</description>
+<suggestion>
+Change second 'if' to 'is'.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="29" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para>
+5
+</para>
+<description>
+default arguments should be allowed in lambdas (core
+issue 974)
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="30" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para>
+4
+</para>
+<description>
+lambda return type deduction should allow arbitrary
+function structure (core issue 975)
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="22" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para>
+7
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(5)" to "(Clause 5)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="6" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para>
+p8 and p10
+</para>
+<description>
+The current capturing rules seem too restrictive.
+</description>
+<suggestion>
+Consider to make those rules less restrictive.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="19" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para>
+16
+</para>
+<description>
+[expr.prim.lambda] 5.1.2/16 has text which begins "If a
+lambda-expression m1 captures an entity and that entity is
+captured by an immediately enclosing lambda expression
+m2..." - that is, it describes a situation with m2 enclosing
+m1, and then describes the capture transformation in
+these terms.
+The example given to support this, however, turns this all
+around and shows m1 enclosing m2. This doesn't make
+either the text or the example incorrect in any sense, but I
+would suggest that it adds a level of confusion that is
+easily avoided.
+</description>
+<suggestion>
+All references to m1 from the beginning of
+5.1.2/16 up to the last occurrence before
+'[Example ' to be replaced by m2, and vice versa.
+Rationale for suggested wording: all other
+examples that use the 'mN' notation for lambda
+expressions and which involve nesting apply
+increasing N (by 1, from 1) to indicate increasing
+nesting depth.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="20" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para>
+12
+</para>
+<description>
+[expr.prim.lambda] 5.1.2/12. In the example code given
+the local struct s1 has a member function with signature
+int s1::work(int n) whose definition does not include an
+appropriate return statement; neither does it include the
+conventional "// ..." to indicate that the example is
+intended to be incomplete.
+</description>
+<suggestion>
+Suggested change: change the signature of this
+member function to void s1::work(int n), as the
+return of int does not contribute to the example.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="21" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2
+</section>
+<para></para>
+<description>
+A lambda-capture can be &, which indicates it captures
+everything by reference (unless otherwise specified), or &
+/identifier/, which indicates it captures the /identifier/ by
+reference. It can also be =, to capture everything by value,
+or /identifier/, for a single thing. Why is = /identifier/ not
+allowed, for consistency?
+</description>
+<suggestion>
+Add "= identifier" to the grammar in 5.1.2p1. (The
+wording already covers the semantics of this,
+since it refers to captures that "are preceded by &"
+or "do not contain &")
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="19" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.1.2 [expr.prim.lambda]
+</section>
+<para>
+21
+</para>
+<description>
+“When the lambda-expression is evaluated, the entities
+that are captured by copy are used to direct-initialize each
+corresponding non-static data member of the resulting
+closure object.” This apparently means that if the capturedefault
+is to copy, entities captured by default, implicitly,
+are copied even in cases where the copy constructors of
+such entities are explicit.
+</description>
+<suggestion>
+Don't implicitly copy entities that have explicit copy
+constructors declared. Require that such entities
+be captured explicitly, by enumerating them in the
+capture list. This seems related to Core Issue
+1020, so I'd like that issue to be resolved as well.
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="23" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.2.2
+</section>
+<para>
+4
+</para>
+<description>
+Order of initialization of arguments in a function is
+fundamental to the memory model of C++, and the
+obvious place to look for the definition is in the clause
+defining function call operators - which currently says
+nothing. The rules covering this are buried in paragraph
+15 of [1.9]. A cross-reference to these words would be
+most helpful. In particular, it should be made clear that
+such initialization is indeterminately sequenced (and not
+unsequenced.)
+</description>
+<suggestion>
+Add a non-normative note with cross-reference
+after the first sentance of paragraph 4: "[Note -
+such initializations are indeterminately sequenced
+with respect to each other [1.9] - end note]"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="31" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.2.9;7.2
+</section>
+<para>
+10
+</para>
+<description>
+it is unclear from the text in 7.2 and 5.2.9 that the "values
+of the enumeration" term does not exclude a prvalue of an
+enumeration type from having other values representable
+in its underlying type (c++std-core-15652).
+</description>
+<suggestion>
+clarify this. "The value is unchanged if it is in the
+range of enumeration values of the enumeration
+type; otherwise the resulting <del>enumeration</del> value is
+unspecified <ins>(and might not be in that range)</ins>."
+Also add a note after paragraph 7 "[Footnote: this
+set of values is used to define promotion and
+conversion semantics for the enumeration type; it
+does not exclude an expression of enumeration
+type from having a value that falls outside this
+range.]"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="32" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.2.5
+</section>
+<para>
+5
+</para>
+<description>
+The description of ambiguity ("...if the class of which E2 is
+directly a member is an ambiguous base (10.2) of the
+naming class (11.2) of E2") does not cover the following
+case:
+<PRE>
+struct A { int i; };
+struct B: A { };
+struct C: A, B { };
+void f(C* p) {
+p->i; // Should be ambiguous
+}
+</PRE>
+</description>
+<suggestion>
+Change the wording to apply also to the case
+when the naming class is an ambiguous base of
+the class of the object expression.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="64" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.2.8
+</section>
+<para>
+5
+</para>
+<description>
+In some code examples, ellipsis(...) is used in ill-formed.
+In these cases, "..." represents omission of some codes
+like this:<BR/>
+class A { /* ... */ } ;<BR/>
+But in some cases, it is used without commented-out as
+below:<BR/>
+class A { ... } ;<BR/>
+It is an inconsistent usage. They all should be enclosed in
+a comment.
+</description>
+<suggestion>
+Change to:<BR/>
+class D { /* ... */ };
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="22" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.2.10
+</section>
+<para></para>
+<description>
+It is not legal to use reinterpret_cast<> with pointers to
+void.
+</description>
+<suggestion>
+Here's an additional paragraph to add to 5.2.10
+that would fix this:<BR/>
+* A pointer to an object type can be explicitly
+converted to a pointer to void, and vice versa.[1]
+The result of such a pointer conversion will have
+the same result as the standard pointer
+conversion described in 4.10. A value of type
+“pointer to object” converted to “pointer to void”
+and back, possibly with different cv-qualification,
+shall have its original value.<BR/>
+[1] The types may have different cv-qualifiers,
+subject to the overall restriction that a
+reinterpret_cast cannot cast away constness.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="33" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.3.1
+</section>
+<para>
+3
+</para>
+<description>
+The resolution of issue 983 added an error for finding the
+named member in an ambiguous base. This is an
+unnecessary special case, since the value of the
+expression is pointer to member of base. If this value is
+then converted to pointer to member of derived, an error
+will be given at that point.
+</description>
+<suggestion>
+Revert the change for issue 983 (and in the issues
+list, add a link to issue 203).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="24" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.3.3
+</section>
+<para>
+6
+</para>
+<description>
+The return type of the sizeof operator is defined as being
+of type std::size_t, defined in library clause 18.2. This, in
+turn, says that size_t is defined in the C standard, which in
+turn says that size_t is defined as the type of the result of
+the sizeof operator!
+The C definition of sizeof returns an implementationdefined
+unsigned integer type, recommended not to have
+"an integer conversion rank greater than signed long int,
+unless the implementation supports objects large enough
+to make this necessary."
+</description>
+<suggestion>
+The result type of the sizeof operator should
+explicitly be implementation defined in clause
+5.3.3.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="34" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.3.4, 5.3.5
+</section>
+<para></para>
+<description>
+Allocations functions are missing happens-before
+requirements and guarantees.
+</description>
+<suggestion>
+Add requirements. See Appendix 1 - Additional
+Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="35" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.3.7
+</section>
+<para>
+[expr.unary.noexcept], 15.4 [except.spec]
+</para>
+<description>
+noexcept has no implementation experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N3050 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="17" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.3.7 [expr.unary.noexcept]
+</section>
+<para></para>
+<description>
+Destructors should by default be noexcept. Such a rule
+should, I think, be obeyed even for cases where a
+destructor is defaulted. Then a throwing destructor would
+need to be declared noexcept(false), and I think the
+resulting code breakage is acceptable.
+</description>
+<suggestion>
+Clarify the implicit generation rules and defaulting
+rules so that destructors are noexcept unless
+explicitly declared noexcept(false).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="2" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.5
+</section>
+<para>
+6
+</para>
+<description>
+Should be corrected because it contradicts with rules in
+5.2.5 paragraph 4.
+</description>
+<suggestion>
+Add the condition that a type of e2 is not a
+reference type
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="36" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.19 [expr.const]
+</section>
+<para></para>
+<description>
+Generalized constant expressions have no
+implementation experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N2235 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="7" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.19
+</section>
+<para>
+4, note
+</para>
+<description>
+The note in paragraph 4 alludes to the possibility that
+compile-time and run-time evaluations of floating-point
+expressions might yield different results. There is no clear
+normative statement (other than the absence of a
+restriction) that gives such permission.
+</description>
+<suggestion>
+Move the second sentence of the note into
+normative text.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="8" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.19
+</section>
+<para>
+6
+</para>
+<description>
+In the definition of "potential constant expression" in
+paragraph 6, it is unclear how "arbitrary" the substitution
+of the function parameters is. Does it mean "there exists a
+value for which the result is a constant expression" or
+does it mean "for all possible values, the result needs to
+be a constant expression"? Example:
+<PRE>
+constexpr int f(int x){return x + 1; }
+</PRE>
+is a constant expression under the first interpretation, but
+not under the second (because overflow occurs for x ==
+INT_MAX, cf. 5.19p2 bullet 5). The answer also affects
+expressions such as:
+<PRE>
+constexpr int f2(bool v) { return v ? throw 0 : 0; }
+constexpr int f3(bool v) { return v && (throw 0, 0); }
+</PRE>
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="25" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.19
+</section>
+<para></para>
+<description>
+In trying to pin down the behaviour of constexpr functions,
+it became apparent that there is disagreement over
+whether or not the following example is well-formed.
+<PRE>
+constexpr int f() { return 42 + 84; }
+const int sz = f();
+int a[sz];
+</PRE>
+This should have the same effect as
+<PRE>
+const int sz = 42 + 84;
+int a[sz];
+</PRE>
+otherwise constexpr functions are broken.
+</description>
+<suggestion>
+Update the wording in 5.19 to make it clear that
+both the examples are valid.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="26" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+5.19
+</section>
+<para></para>
+<description>
+It is not clear how overload resolution applies within a
+constexpr function. In particular, if an expression in the
+function body yields an integral value of 0 for some
+parameter values, and not for others, is it usable as a null
+pointer constant when evaluated as a constant
+expression.
+<PRE>
+typedef char (&One)[1];
+typedef char (&Two)[2];
+One f(void*); // #1
+Two f(...); // #2
+constexpr int test(int n) { return sizeof f(n); }
+constexpr int test2(int n) { return sizeof f(n*0); }
+int q = 0;
+#include
+int main() {
+char a[test(0)];
+std::cout << sizeof(a) << std::endl; // #3
+std::cout << test(q) << std::endl; // #4
+char b[test2(0)];
+std::cout << sizeof(b) << std::endl; // #5
+std::cout << test2(q) << std::endl; // #6
+}
+</PRE>
+#3 and #4 should print 2, since n is not an integral
+constant expression with value 0 in the body of test() ---
+though it is a constant expression when test() is evaluated
+as a constant expression, it's value is dependent on the
+invocation. Permitting different results of overload
+resolution within the same function body in different calling
+contexts would violate ODR.<BR/>
+On the other hand, in test2(), the answer is no longer
+dependent on the value of n, since "n*0" always evaluates
+to 0. However, it is not clear from the FCD whether "n*0"
+is thus a constant expression (and therefore a valid null
+pointer constant) inside the body of test2. Either way both
+#5 and #6 should print the same value; it would violate
+ODR for #5 to print "1" (indicating that "n*0" was a valid
+null pointer constant when test2() is evaluated in a
+constant expression context) whilst #6 prints "2" (since
+n*0 is not a constant expression if n is not constant). #5
+and #6 should thus both print "1", or both print "2".
+</description>
+<suggestion>
+Updated 5.19 to make it clear that overload
+resolution in a constexpr function is not dependent
+on the context of use, or the value of the
+arguments.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="37" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+6.5
+</section>
+<para></para>
+<description>
+"for (auto e : range)" creates copies of elements. This
+seems like a gotcha for new users. Not only are copies
+inefficient for reading, but writing to copies won't modify
+the original elements.<BR/>
+Permitting "for ( identifier : expression )" and giving it the
+same meaning as "for ( auto& identifier : expression )"
+would make the range-based for statement easier to teach
+and to use, and should be trivial to specify and to
+implement.
+</description>
+<suggestion>
+Permit "for ( identifier : expression )" or similar,
+with the same meaning as "for ( auto& identifier :
+expression )".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="3" type="various" owner="" issue="" disp="" date="" extdoc="">
+<section>
+Various
+</section>
+<para>
+various
+</para>
+<description>
+Canada agrees with US 37, 44, 47, 85, 77, 92, 97, 102,
+105, 109
+</description>
+<suggestion>
+Resolve as suggested in these comments
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="38" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+6.5 5
+</section>
+<para></para>
+<description>
+The statement that certain infinite loops may be assumed
+to terminate should also apply to go-to loops and possibly
+infinite recursion. We expect that compiler analyses that
+would take advantage of this can often no longer identify
+the origin of such a loop.
+</description>
+<suggestion>
+As a strawman, replace the paragraph with<BR/>
+"The implementation may assume that any
+program will eventually do one of the following:<BR/>
+- terminate,<BR/>
+- make a call to a library I/O function,<BR/>
+- access or modify a volatile object, or<BR/>
+- perform a synchronization operation (1.10) or
+atomic operation (Clause 29)."<BR/>
+Possibly move this and the attached note to
+section 1.9, after p8.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="69" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+6.35.1
+</section>
+<para>
+2
+</para>
+<description>
+Constant width font should be used for 3 "while"s in the
+paragraph as described in Syntax notation (1.6).
+</description>
+<suggestion>
+Change the font for "while" to constant width type.
+When the condition of a while statement is a
+declaration, the scope of the variable that is
+declared extends
+from its point of declaration (3.3.2) to the end of
+the while statement. A while statement of the
+form
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="27" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+6.5.4p1
+</section>
+<para></para>
+<description>
+6.5.4/1 requires that range-based for loops behave as if
+they had "{ auto&& __range = (expression); for (auto
+__begin = begin_expr, __end = end_expr; ..." which
+implies that __begin and __end must have the same type.
+However, this prevents stateful iterators with an end
+sentinel of a different type. Since range-based for loops'
+equivalent code already introduces a block (for the
+__range variable), could __begin and __end be placed
+there, as "auto __begin = begin_expr; auto __end =
+end_expr;"?<BR/>
+Example of what this change would allow, only the
+relevant details shown with ctors, op*, op++, etc. omitted:
+(apologies if the formatting is lost)<BR/>
+struct End {}; struct Counter { Counter& begin() { return
+*this; } // used by begin_expr End end() { return End(); } //
+used by end_expr bool operator!=(End) const { return
+_current != _end; }<BR/>
+Counter(int begin, int end) : _current(begin), _end(end) {}
+int _current, _end; };<BR/>
+void use_example() { for (auto n : Counter(0, 10)) { // n
+takes values from 0..9 } }
+</description>
+<suggestion>
+Change the "as if" for a range-based for-loop in
+6.5.4p1 to move the initialization of __begin and
+__end outside the loop into the enclosing block:
+<PRE>
+{ auto&& __range = (expression);
+auto __begin = begin_expr; auto __end =
+end_expr;
+for (; ...
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="7" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+6.5.4
+</section>
+<para>
+p1
+</para>
+<description>
+The phrasing "is equivalent to" is too restrictive and might
+constrain future improvements.
+</description>
+<suggestion>
+Make clear that the specification is not necessarily
+the implementation, i.e. that the expressions in the
+specification are not necessarily called at all and
+that the order in which the statement is executed
+for different values of for-range-declaration is not
+necessarily the same as if the for loop would have
+been written the way in the specification.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="28" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7
+</section>
+<para>
+1
+</para>
+<description>
+"Attributes" is misspelled
+</description>
+<suggestion>
+Replace "Atrributes" with "Attributes"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="39" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.1
+</section>
+<para>
+1
+</para>
+<description>
+The current wording is, "The optional attribute-specifier in
+a decl-specifier-seq appertains to the type determined by
+the decl-specifier-seq." However, the rule for declspecifier-
+seq in the grammar is recursive, and the intent is
+for the attribute-specifier to appertain to the top declspecifier-
+seq, not the one in which the attribute-specifier
+directly appears.
+</description>
+<suggestion>
+Change the wording to indicate that the complete
+or outermost decl-specifier-seq is intended.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="29" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.1.5
+</section>
+<para></para>
+<description>
+A constexpr function is not permitted to return via an
+exception. This should be recognised, and a function
+declared 'constexpr' without an explicit exception
+specification should be treated as if declared
+'noexcept(true)' rather than the usual 'noexcept(false)'. For
+a function template declared constexpr without an explicit
+exception specification, it should be considered
+'noexcept(true)' if and only if the constexpr keyword is
+respected on a given instantiation.
+</description>
+<suggestion>
+Give constexpr functions an implicit non-throwing
+exception specification.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="40" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.1.6.2
+</section>
+<para>
+4
+</para>
+<description>
+The description of decltype does not specify whether the
+type of a parameter is the declared type or the type as
+adjusted in 8.3.5p5:
+<PRE>
+auto f(int a[])->decltype(a);
+// ill-formed or int*?
+auto g(const int i)->decltype(i);
+// int or const int?
+</PRE>
+</description>
+<suggestion>
+Clarify the wording to indicate that the type of a
+parameter is after the array- and function-to-pointer
+decay but before the removal of cv-qualification.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="9" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.1.6.2
+</section>
+<para>
+p4
+</para>
+<description>
+decltype applied to a function call expression requires a
+complete type (5.2.2 paragraph 3 and 3.2 paragraph 4),
+even though decltype's result might be used in a way that
+does not actually require a complete type. This might
+cause undesired and excessive template instantiations.
+</description>
+<suggestion>
+When immediately applying decltype, do not
+require a complete type, for example for the return
+type of a function call.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="41" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.1.6.3
+</section>
+<para>
+2
+</para>
+<description>
+The current wording disallows use of typedef-names in
+elaborated-type-specifiers. This prohibition should also
+apply to template aliases:
+<PRE>
+struct A { };
+template<typename T> using X = A;
+struct X<int>* p2; // ill-formed
+</PRE>
+</description>
+<suggestion>
+Add the necessary wording to prohibit a
+specialization of a template alias in an elaboratedtype-
+specifier.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="42" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.1.6.4
+</section>
+<para></para>
+<description>
+The overloaded meaning of the auto specifier is confusing
+and prevents possible future language enhancements.
+</description>
+<suggestion>
+Choose another keyword to indicate a latespecified
+return type. The identifiers lateret and
+postret have no Google code search hits. The
+identifiers late, latetype, and posttype have 30-40
+hits.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="43" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.6
+</section>
+<para>
+4
+</para>
+<description>
+The contexts in which an attribute-specifier can appear
+include statements, described in clause 6, but the crossreferences
+to clauses describing those contexts do not
+include clause 6.
+</description>
+<suggestion>
+Add clause 6 to the list of cross-references in the
+first sentence.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="30" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.6.1
+</section>
+<para>
+6
+</para>
+<description>
+Making the use of [[ illegal except where introducing an
+attribute specifier is just reintroducing the problem we had
+with >> for closing nested templates, albeit in a minor and
+less common form.
+As Jason Merrill commented in c++std-core-16046, there
+is no ambiguity in practice because code couldn't actually
+be well-formed under interpretation as both an attribute
+specifier and a lambda introducer. A small amount of
+lookahead would be required to differentiate the cases,
+but this should not be a problem.
+This restriction also means that lambdas in macros must
+be enclosed in parentheses to avoid accidental
+interpretation as an illegal attribute specifier if used as an
+array index.
+</description>
+<suggestion>
+Delete 7.6.1 paragraph 6.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="23" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.6.1
+</section>
+<para>
+4
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(clause 7, clause 8)" to "(Clause 7,
+Clause 8)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="31" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.6.2
+</section>
+<para></para>
+<description>
+After reviewing the case for attributes, wg14 has opted not
+to adopt this feature, and is instead using keywords for the
+few important cases identified in the attributes proposal.
+For compatibility with C, the change of the 'alignas'
+keyword to the '[[align]]' attribute should be reversed.
+</description>
+<suggestion>
+Revert the changes in the initial alignment
+proposal that changed the 'alignas' keyword into
+an attribute.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="32" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.6.3
+</section>
+<para></para>
+<description>
+C has rejected the notion of attributes, and introduced the
+noreturn facility as a keyword. To continue writing clean,
+portable code we should replace the [[noreturn]] attribute
+with a 'noreturn' keyword, following the usual convention
+that while C obfuscates new keywords with _Capital and
+adds a macro to map to the comfortable spelling, C++
+simply adopts the all-lowercase spelling.
+</description>
+<suggestion>
+Replace the [[noreturn]] attribute with a new
+keyword, 'noreturn', with identical semantics. Note
+that this implies the keyword will not be something
+that a function can be overloaded upon.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="44" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.6.5
+</section>
+<para></para>
+<description>
+Even if attributes continue to be standardized over
+continued objections from both of the two vendors who
+are cited as the principal prior art, we can live with them
+with the exception of the virtual override controls. This
+result is just awful, as already shown in the example in
+7.6.5 (excerpted):
+<PRE>
+class D [[base_check]] : public B {
+void sone_func [[override]] ();
+virtual void h [[ hiding]] (char*);
+};
+</PRE>
+Here we have six keywords (not counting void and char)
+three normal keywords, and three [[decorated]]
+keywords. There has already been public ridicule of
+C++0x about this ugliness. This is just a poor language
+design, even in the face of backward compatibility
+concerns (e.g., that some existing code may already use
+those words as identifiers) because those concerns have
+already been resolved in other ways in existing practice
+(see below).BR/>
+More importantly, this is exactly the abuse of attributes as
+disguised keywords that was objected to and was
+explicitly promised not to happen in order to get this
+proposal passed. The use of attributes for the virtual
+control keywords is the most egregious abuse of the
+attribute syntax, and at least that use of attributes must be
+fixed by replacing them with non-attribute syntax.
+These virtual override controls are language features, not
+annotations.<BR/>
+It is possible to have nice names and no conflicts with
+existing code by using contextual keywords, such as
+recognizing the word as having the special meaning when
+it appears in a grammar position where no user identifier
+can appear, as demonstrated in C++/CLI which has five
+years of actual field experience with a large number of
+customers (and exactly no name conflict or programmer
+confusion problems reported in the field during the five
+years this has been available):
+<PRE>
+class D : public B {
+void sone_func() override; // same meaning as
+[[override]] - explicit override
+virtual void h (char*) new; // same meaning as
+[[hiding]] - a new function, not an override
+};
+int override = 42; // ok, override is not a
+reserved keyword
+</PRE>
+The above forms are implementable, have been
+implemented, have years of practical field experience, and
+work. Developers love them. Whether the answer is to
+follow this existing practice or something else, there needs
+to be a more natural replacement for the currently
+[[attributed]] keywords for virtual override control which is
+an ugly novelty that has no field experience and that
+developers have already ridiculed.
+</description>
+<suggestion>
+Change the syntax for virtual override control to
+not use attributes.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="45" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+7.6.5
+</section>
+<para>
+6
+</para>
+<description>
+The example includes a line reading
+<PRE>
+class D [[base_check]] : public B {
+</PRE>
+However, the current syntax in 9p1 places the attribute-specifier
+before the class name.
+</description>
+<suggestion>
+Change the example to read
+<PRE>
+class [[base_check]] D : public B {
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="8" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.1
+</section>
+<para>
+p1 (syntax)
+</para>
+<description>
+'noptr-abstract-declarator:' rule misses 'opt' subscript from
+the constant expression within the array brackets. This
+seems to be an editorial oversight
+</description>
+<suggestion>
+change: "noptr-abstract-declarator<SUB>opt</SUB> [ constant-expression
+] attribute-specifier<SUB>opt</SUB>"<BR/>
+to<BR/>
+"noptrabstract-declarator<SUB>opt</SUB> [ constant-expression<SUB>opt</SUB> ]
+attribute-specifier<SUB>opt</SUB>"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="46" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.3.2 20.7.6.2
+</section>
+<para>
+all Table 49
+</para>
+<description>
+There is no way to create a prvalue of array type, so there
+ought to be no way create a (nonsensical) rvalue
+reference to array type.
+</description>
+<suggestion>
+In [dcl.ref]/2, disallow declarations of T (&&A)[].<BR/>
+In [dec.ref]/6 add a sentence: <ins>If a typedef, a type
+template-parameter, or a decltype-specifier
+denotes a type A that is an array type (of known or
+unknown size), an attempt to create the type
+“rvalue reference to cv A” creates the type A&.</ins><BR/>
+In [meta.trans.ref]/Table 49 change the third row
+as follows:<BR/>
+If <ins>T names an array type, then the member
+typedef type shall name T&, otherwise if</ins> T names
+an object or function type...
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="33" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.3.5
+</section>
+<para>
+5
+</para>
+<description>
+The register keyword is deprecated, so does not make for
+a good example. Suggest substituting the new storage
+class specifier, 'thread_local', instead.
+</description>
+<suggestion>
+Use 'thread_local' in place of 'register' in the
+following sentance: "[ Example: register char*
+becomes char* end example ]"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="47" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.4.2
+</section>
+<para></para>
+<description>
+8.4.2 [dcl.fct.def.default]/4 says: "A special member
+function is user-provided if it is user-declared and not
+explicitly defaulted on its first declaration. A user-provided
+explicitly-defaulted function is..." The second sentence
+here should say "A user-declared explicitly-defaulted
+function is...".
+</description>
+<suggestion>
+Change<BR/>
+"A user-provided explicitly-defaulted function is..."<BR/>
+to<BR/>
+"A user-declared explicitly-defaulted function is...".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="34" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.4.2
+</section>
+<para>
+p2
+</para>
+<description>
+It is confusing when a normative paragraph starts with a
+note. The note starting this paragraph, with its reference
+to 'this' relating to the previous paragraph and not the
+content that follows, should be moved into the first
+paragraph, or the rest of this paragraph after the note
+should start a new numbered paragraph.
+</description>
+<suggestion>
+The note starting this paragraph should be moved
+into the first paragraph, or the rest of this
+paragraph after the note should start a new
+numbered paragraph.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="1" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.4.2 [dcl.fct.def.default]
+</section>
+<para>
+Paragraph 2
+</para>
+<description>
+It should be allowed to explicitly default a non-public
+special member function on its first declaration. It is very
+likely that users will want to default protected/private
+constructors and copy constructors without having to write
+such defaulting outside the class.
+</description>
+<suggestion>
+Strike the “it shall be public” bullet.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="2" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.4.2 [dcl.fct.def.default]
+</section>
+<para>
+Paragraph 2
+</para>
+<description>
+It should be allowed to explicitly default an explicit special
+member function on its first declaration. It is very likely
+that users will want to default explicit copy constructors
+without having to write such defaulting outside of the
+class.
+</description>
+<suggestion>
+Strike the “it shall not be explicit” bullet.
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="3" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.4.2 [dcl.fct.def.default]
+</section>
+<para>
+Paragraph 2
+</para>
+<description>
+It should be allowed to explicitly default a virtual special
+member function on its first declaration. It is very likely
+that users will want to default virtual copy assignment
+operators and destructors without having to write such
+defaulting outside of the class.
+</description>
+<suggestion>
+Strike the “it shall not be virtual” bullet.
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="35" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.5.1
+</section>
+<para>
+7
+</para>
+<description>
+With the removal of the deprecated string-literal-to-nonconst-char*
+conversion, member 'b' of struct S should be
+declared as a 'const' char *.
+</description>
+<suggestion>
+Fix struct S as: "struct S { int a; const char* b; int
+c; };"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="71" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.5.1
+</section>
+<para>
+7
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing const'ness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+struct S { int a; const char* b; int c; };
+S ss = { 1, "asdf" };
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="72" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.5.1
+</section>
+<para>
+15
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing const'ness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+union u { int a; const char* b; };
+u a = { 1 };
+u b = a;
+u c = 1; // error
+u d = { 0, "asdf" }; // error
+u e = { "asdf" }; // error
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="36" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.5.1
+</section>
+<para>
+17
+</para>
+<description>
+The 'b' member of union u should be declared const char *
+to better illustrate the expected cause of failures.
+</description>
+<suggestion>
+Update union u as: "union u { int a; const char* b;
+};"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="48" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.5.3
+</section>
+<para>
+5
+</para>
+<description>
+The rule "...or the reference shall be an rvalue reference
+and the initializer expression shall be an rvalue or have a
+function type" is stated in terms of the rvalue-ness of the
+expression rather than the eventual target of the
+reference; this leads to some undesirable results, such as
+<PRE>
+struct A { };
+struct B {
+operator A&();
+};
+A&& aref = B(); // binds to lvalue
+</PRE>
+(c++std-core-16305)
+</description>
+<suggestion>
+Correct the formulation to deal with the rvalueness
+of the initializer after conversion to the
+appropriate type.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="49" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.5.3
+</section>
+<para>
+5
+</para>
+<description>
+The FCD does not specify direct binding for this example:
+<PRE>
+int i;
+int main()
+{
+int&& ir = static_cast<int&&>(i);
+ir = 42;
+return (i != 42);
+}
+</PRE>
+(c++std-core-16181)
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="37" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.5.3
+</section>
+<para></para>
+<description>
+It seems that lvalues of any sort don't bind to non-const
+rvalue ref args, even if an intermediate temporary would
+be created.
+See the discussion at
+http://stackoverflow.com/questions/2748866/c0x-rvalue-references-and-temporaries.
>
+I'll summarise that here: Assume that std::vector has
+push_back overloads declared as follows, with SFINAE
+omitted for clarity:
+<PRE>
+void push_back(const T &);
+//Copies the const T & into the vector's storage
+void push_back(T &&);
+//Moves the T && into the vector's storage
+</PRE>
+Then this code appears to behave as commented, as of
+N3090:
+<PRE>
+const char * cchar = "Hello, world"; std::vector<std::string>
+v;
+v.push_back(cchar);
+//makes a temporary string, copies the string
+into vector storage using push_back(const T&)
+v.push_back(std::string(cchar));
+//makes a temporary string, moves the string into vector
+storage using push_back(T&&)
+v.push_back(std::move(cchar));
+//makes a temporary string, moves the string into the
+vector using push_back(T&&)
+</PRE>
+Johannes Schaub (litb) convincingly argued that the
+reason for this is clause 8.5.3/5 describing reference
+binding - it allows direct binding of lvalues, bindings that
+require conversion sequences to const lvalue refs, and
+rvalues to rvalue refs. But it doesn't allow for lvalues to
+ever bind to rvalue refs, even if an intermediate temporary
+would otherwise need to be created.<BR/>
+This isn't what I (as a user of std::vector) expect to
+happen. I expect all of these push_back calls to do the
+same thing, namely, select the push_back(T&&) overload,
+create a temporary string object from 'cchar', bind the
+temporary string to the argument, and hence move (not
+copy) the temporary string into vector's storage.<BR/>
+It seems particularly strange that v.push_back(cchar)
+"requires" an extra copy, but
+v.push_back(std::move(cchar)) does not. It almost
+seems like indicating that 'cchar' is potentially-movable (by
+casting it to an rvalue ref using std::move) allows moving
+from a completely different object - the temporary string.<BR/>
+I suggest extending the rules for initializing const lvalue
+refs via implicit conversions (8.5.3/5), to also apply to
+rvalue refs.<BR/>
+This also raises an additional question of whether lvalues
+of _copyable_ types should be copied into a temporary
+object so that they may bind to an rvalue ref. Allowing this
+would not affect const T&/T&& overload pairs. But
+it could be potentially useful when writing functions that
+wish to accept a number of rvalue refs to copyable-butnot-
+movable types (such as all C++03 classes with userdefined
+copy constructors), or when writing functions that
+"take apart" a number their arguments in a way that is
+different from a straightforward move (perhaps some
+tree operations would want to do this).<BR/>
+Conversely, it might seem odd that declarations such as:
+<PRE>
+string && s = string_lvalue;
+string && s = string_rvalue_ref_variable;
+//mistake, std::move(string_rvalue_ref_variable) was
+intended
+</PRE>
+...would both
+silently copy their arguments and bind to the copy, instead
+of being invalid as they are now.<BR/>
+We believe this is core issue 953
+</description>
+<suggestion>
+Possible wording: amend the second list
+item in 8.5.3/5:<BR/>
+Otherwise, the reference shall be an lvalue
+reference to a non-volatile const type (i.e., cv1
+shall be const), or the reference shall be an rvalue
+reference [deleted the rest of the sentence]. [The
+last example would also need to be deleted.]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="10" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+8.5.3
+</section>
+<para>
+te
+</para>
+<description>
+Reference binding rules for rvalue references should
+consider temporaries generated from lvalues by implicit
+conversions. Consider to postpone the lvalue/rvalue
+analysis of an expression to after the implicit conversion
+chain has been deduced. Example:
+<PRE>
+void f(std::string&&);
+void g() {
+f(std::string("hello")); // #1, ok
+f("hello"); // #2, error,
+// but should be the same as #1
+}
+</PRE>
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="50" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9
+</section>
+<para>
+9
+</para>
+<description>
+the class "struct A { const int i; };" was a POD in C++98,
+but is not a POD under the FCD rules because it does not
+have a trivial default constructor; I believe that C++0x
+POD was intended to be a superset of C++98 POD.
+</description>
+<suggestion>
+change POD to be standard layout and trivially
+copyable?
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="16" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9 9 9 3.9
+</section>
+<para>
+5 trivial 6 std-layout 9 POD 10 literal type
+</para>
+<description>
+There are definitions for these types in the text, yet it is left
+unclear what use these classifications have. The types are
+very close to each other, which makes them confusing. If
+the reader must rely on external references, then these
+references should be specified (which is undesirable, or
+even disallowed by ISO(?)). As it stands, there is an
+example for using standard-layout classes (with other
+programming languages). There are also uses specified
+for literal types. One can imagine many uses for these
+four/five types, so it is important to have a clear
+specification of the intent as to where each of these types
+is expected to be used.
+</description>
+<suggestion>
+It is necessary to have detailed information on the
+expected uses of standard-layout, trivial, trivially
+copyable, literal and POD types.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="81" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9
+</section>
+<para>
+9
+</para>
+<description>
+Missing description of acronym "POD", which existed in
+C++03: The acronym POD stands for "plain old data."
+</description>
+<suggestion>
+Add "The acronym POD stands for "plain old
+data." as an annotation.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="51" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9.2 [class.mem]
+</section>
+<para></para>
+<description>
+Non-static data member initializers have no
+implementation experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N2756 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="52" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9.3
+</section>
+<para>
+7
+</para>
+<description>
+The current wording allows friend declarations to name
+member functions "after their class has been defined."
+This appears to prohibit a friend declaration in a nested
+class defined inside its containing class that names a
+member function of the containing class, because the
+containing class is still considered to be incomplete at that
+point.
+</description>
+<suggestion>
+Change the wording to allow a friend declaration
+of a "previously-declared member function."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="53" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9.3.1 [class.mfct.non-static]
+</section>
+<para></para>
+<description>
+Move semantics for *this have no implementation
+experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N1821 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="73" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9.3.1
+</section>
+<para>
+3
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing const'ness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+struct tnode {
+char tword[20];
+int count;
+tnode *left;
+tnode *right;
+void set(const char*, tnode* l, tnode* r);
+};
+void tnode::set(const char* w, tnode* l, tnode* r) {
+count = strlen(w)+1;
+if (sizeof(tword)<=count)
+perror("tnode string too long");
+strcpy(tword,w);
+left = l;
+right = r;
+}
+void f(tnode n1, tnode n2) {
+n1.set("abc",&n2,0);
+n2.set("def",0,0);
+}
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="54" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9.5 [class.union]
+</section>
+<para></para>
+<description>
+Unrestricted unions have no implementation experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N2544 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="74" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9.5
+</section>
+<para>
+6
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing const'ness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+void f() {
+union { int a; const char* p; };
+a = 1;
+p = "Jennifer";
+}
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="38" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9.6
+</section>
+<para></para>
+<description>
+The signedness of bit-fields is the only time when 'signed
+int' is any different to just 'int'.<BR/>
+In C it is possible to remember whether a typedef uses
+'signed' but in C++ it doesn't make sense and will result in
+ODR violations if A<long> and A<signed long> are not
+exactly equivalent.<BR/>
+This also causes portability problems because it is not
+specified whether typedefs such as int32_t are defined
+with 'signed' so using the <cstdint> types in bitfields is
+problematic.<BR/>
+It is common to want to guarantee a bit-field has a
+minimum number of bits, for which the <cstdint> types are
+useful, except that the signedness of a bit-field using
+int32_t might depend on both unspecified and
+implementation-defined behaviour.
+</description>
+<suggestion>
+'signed int' should always be equivalent to 'int' in
+all contexts.<BR/>
+A possible alternative would be to specify that
+signed types in <cstdint> are declared with
+'signed' so that using them for bit-fields has
+predictable results, but this doesn't address the
+ODR issue with A<long> and A<signed long>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="55" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+10.3
+</section>
+<para>
+Paragraph 5
+</para>
+<description>
+The following code not only does not compile on the
+compilers I've tested, but cannot be fixed through any
+combinations of forward references
+<PRE>
+class B {
+public:
+virtual B *f() = 0;
+};
+class D1 : public B {
+public:
+virtual D2 *f();
+};
+class D2 : public B {
+public:
+virtual D1 *f();
+};</PRE>
+</description>
+<suggestion>
+In the core mailing list, Daniel Krugler points out
+that the current wording is ambiguous as to
+whether this is legal (although an editorial
+example suggests otherwise), and observes that it
+should be OK as long as D2 is complete at the
+point of definition of D1::f. The standard should
+resolve the ambiguity by saying that D2 only
+needs to be complete at the point of definition of
+D1::f.<BR/>
+The core mailing list message text is below:<BR/>
+I would be happy, if the standard would just allow
+this, but IMO the
+current wording seems to be readable in different
+ways (e.g.
+Comeau rejects the code). I think the reason is
+that [class.virtual]/5
+just says:<BR/>
+"The return type of an overriding function shall be
+either identical to
+the return type of the overridden function or
+covariant with the
+classes of the functions.[..]"<BR/>
+This restriction is IMO only necessary for the
+*definition* of D::f.
+Secondly p. 6 says:<BR/>
+"If the return type of D::f differs from the return
+type of B::f, the class
+type in the return type of D::f shall be complete at
+the point of
+declaration of D::f or shall be the class type D.[..]"<BR/>
+and shows the following example that explicitly
+forbids that (simplified):
+<PRE>
+struct Base {
+virtual B* vf5();
+};
+class A;
+struct Derived : public Base {
+A* vf5(); // error: returns pointer to incomplete
+class
+};
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="56" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+11.3 [class.access.decl]
+</section>
+<para></para>
+<description>
+Access declarations were deprecated in the 1998
+standard and have no benefits over using declarations.
+</description>
+<suggestion>
+Remove access declarations from the working
+paper.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="4" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.1 [class.ctor]
+</section>
+<para>
+Paragraph 5
+</para>
+<description>
+What effect does defaulting have on triviality? Related to
+FI 1, non-public special members defaulted on their first
+declaration should retain triviality, because they shouldn't
+be considered user-provided. Related to FI 3, defaulted
+member functions that are virtual should not be
+considered trivial, but there's no reason why non-virtuals
+could not be.<BR/>
+Furthermore, a class with a non-public explicitly-defaulted
+constructor isn't ever trivially constructible under the
+current rules. If such a class is used as a subobject, the
+constructor of the aggregating class should be trivial if it
+can access the non-public explicitly defaulted constructor
+of a subobject.
+</description>
+<suggestion>
+Change the triviality rules so that a class can have
+a trivial default constructor if the class has access
+to the default constructors of its subobjects and
+the default constructors of the subobjects are
+explicitly defaulted on first declaration, even if said
+defaulted constructors are non-public.<BR/>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="15" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.3.1
+</section>
+<para>
+2
+</para>
+<description>
+12.3.1. 2: "A default constructor may be an explicit
+constructor; such a constructor will be used to perform
+default-initialization or value-initialization (8.5)."<BR/>
+12.3. 1 also says that an explicit ctor is different from a
+non-explicit ctor in that it is only invoked when
+direct-initialization (T a(1); T a{1}. presumably also T a;)
+or casting is used.<BR/>
+What are the scenarios for the default ctor where explicit
+actually matters? Temporaries, arrays, ???
+When, if ever, is an explicit default ctor different from a
+non-explicit ctor?
+</description>
+<suggestion>
+The difference between a no argument default
+constructor and an explicit no argument default
+constructor should be explained in the standard.
+If there is no difference, this should be explicitly
+specified.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="57" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.3.2 [class.conv.fct]
+</section>
+<para></para>
+<description>
+Explicit conversion operators have no implementation
+experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N2437 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="39" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.4
+</section>
+<para>
+4
+</para>
+<description>
+Contradiction between the note and normative language
+describing when defaulted function definitions might have
+an exception specification. (See 8.4.2p2 for requirement
+to provide the exception specification)
+</description>
+<suggestion>
+Either strike the second sentance of this note, or
+update it to reflect under which conditions a
+defaulted definition might have an exception
+specification.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="40" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.4
+</section>
+<para></para>
+<description>
+It is very difficult to write correct programs that do not call
+'terminate' in the presence of destructors that can throw
+exceptions, and this practice has long been discouraged.
+Many implicitly declared destructors already carry
+noexcept declarations (mostly types with trivial
+destructors) and it is anticipated it will become common
+practice to want a user-declared destructor to be declared
+noexcept. This becomes important evaluating the
+noexcept operator, where any of the unevaluated subexpressions
+may produce a temporary object. As this is
+expected to be the overwhelmingly common case, a userdeclared
+destructor that does not supply an exception
+specification should be considered as if declared
+noexcept(true) rather than noexcept(false), the default for
+every other function.
+</description>
+<suggestion>
+a user-declared destructor that does not supply an
+exception specification should be considered as if
+declared noexcept(true) rather than
+noexcept(false), the default for every other
+function
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="9" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.4 and 15.4
+</section>
+<para></para>
+<description>
+Destructors should generally not throw exceptions.
+Consider giving an explicit rule for this.
+</description>
+<suggestion>
+Add in 12.4 or 15.4 a paragraph to the effect that
+all destructors not having an exception
+soecification are considered noexcept(true).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="58" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.5
+</section>
+<para>
+foot 117
+</para>
+<description>
+Missing comma in "is not virtual the size might".
+</description>
+<suggestion>
+Add the comma.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="59" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.6.2 [class.base.init]
+</section>
+<para></para>
+<description>
+Delegating constructors have no implementation
+experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N1986 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="60" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.8 [class.copy]
+</section>
+<para></para>
+<description>
+Implicitly-defined move constructors and move
+assignment operators have no implementation
+experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N3053 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="11" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.8
+</section>
+<para></para>
+<description>
+It is unclear whether copy elision can or cannot apply to a
+case like C f(C c) { return c; }, i.e. where a parameter of
+class type is returned. Furthermore, if copy elision cannot
+apply there, it should still be possible to move (instead of
+copy) the return value.
+</description>
+<suggestion>
+Amend paragraph 34 to explicitly exclude function
+parameters from copy elision. Amend paragraph
+35 to include function parameters as eligible for
+move-construction.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="5" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.8 [class.copy]
+</section>
+<para>
+Paragraph 13, paragraph 27
+</para>
+<description>
+Same as FI 4, the parts involving copy constructors and
+copy assignment operators.<BR/>
+A class with a non-public explicitly-defaulted copy
+constructor isn't ever trivially copyable under the current
+rules. If such a class is used as a subobject, the copy
+constructor of the aggregating class should be trivial if it
+can access the non-public explicitly defaulted copy
+constructor of a subobject.
+</description>
+<suggestion>
+Change the triviality rules so that a class can
+have a trivial copy constructor if the class has
+access to the copy constructors of its subobjects
+and the copy constructors of the subobjects are
+explicitly defaulted on first declaration, even if said
+defaulted copy constructors are non-public.
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="41" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.8
+</section>
+<para>
+15, 29
+</para>
+<description>
+Contradiction between the notes claiming that defaulted
+definitions to not have exception specifications, and the
+normative language in 8.4.2 which declares that they
+might.
+</description>
+<suggestion>
+Either strike the second sentance of each note, or
+update it to reflect under which conditions a
+defaulted definition might have an exception
+specification.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="61" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.8;20.2.5
+</section>
+<para>
+17,31;table 42
+</para>
+<description>
+static_cast is broken across two lines
+</description>
+<suggestion>
+do not hyphenate static_cast
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="62" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.8
+</section>
+<para>
+16
+</para>
+<description>
+The new wording describing generated copy constructors
+does not describe the initialization of members of
+reference type. (Core issue 1051 in N3083.)
+</description>
+<suggestion>
+Add the required description.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="63" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.8
+</section>
+<para>
+16-18
+</para>
+<description>
+The new wording specifies the behavior of an implicitlydefined
+copy constructor for a non-union class (p16), an
+implicitly-defined move constructor for a non-union class
+(p17), and an implicitly-defined copy constructor for a
+union (p18), but not an implicitly-defined move constructor
+for a union. (Core issue 1064 in N3083.)
+</description>
+<suggestion>
+Add the required description.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="64" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.8
+</section>
+<para>
+28
+</para>
+<description>
+The current wording reads, "A copy/move assignment
+operator that is defaulted and not defined as deleted is
+implicitly defined when an object of its class type is
+assigned a value of its class type or a value of a class
+type derived from its class type or when it is explicitly
+defaulted after its first declaration." This sounds as if any
+assignment to a class object, regardless of whether it is a
+copy or a move assignment, defines both the copy and
+move operators. Presumably an assignment should only
+define the assignment operator chosen by overload
+resolution for the operation. (Compare the corresponding
+wording in p14 for the copy/move constructors:
+"...implicitly defined if it is used to initialize an object of its
+class type..." (Core issue 1066 in N3083.)
+</description>
+<suggestion>
+Clarify the wording so that only the operator
+needed for the operation is implicitly defined.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="65" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+12.9 [class.inhctor]
+</section>
+<para></para>
+<description>
+Inheriting constructors have no implementation
+experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N2540 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="65" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+13.1
+</section>
+<para>
+3
+</para>
+<description>
+In some code examples, ellipsis(...) is used in ill-formed.
+In these cases, "..." represents omission of some codes
+like this:<BR/>
+class A { /* ... */ } ;<BR/>
+But in some cases, it is used without commented-out as
+below:<BR/>
+class A { ... } ;<BR/>
+It is an inconsistent usage. They all should be enclosed in
+a comment.
+</description>
+<suggestion>
+Change to:<BR/>
+<PRE>
+int f (int) { /* ... */ } // definition of f(int)
+int f (cInt) { /* ... */ } // error: redefinition of f(int)
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="66" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+13.3.1.7
+</section>
+<para>
+1
+</para>
+<description>
+overload resolution should first look for a viable list
+constructor, then look for a non-list constructor if no list
+constructor is viable
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="67" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+13.3.2
+</section>
+<para>
+3
+</para>
+<description>
+To determine whether there is an ICS, 13.3.2 uses
+13.3.3.1 instead of just saying “there is an ICS if-and-only-if
+a copy init would be well-formed.” Apparently this is
+desired, but to a casual reader or an implementor reading
+these rules for the first time for a new implementation, it's
+not clear why that's desired.
+</description>
+<suggestion>
+Insert a note or annex explaining why 13.3.2 does
+things as it does.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="75" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+13.2
+</section>
+<para>
+1
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing const'ness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+struct B {
+int f(int);
+};
+struct D : B {
+int f(const char*);
+};
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="76" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+13.2
+</section>
+<para>
+2
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing const'ness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+void f(const char*);
+void g() {
+extern void f(int);
+f("asdf"); // error: f(int) hides f(const char*)
+// so there is no f(const char*) in this scope
+}
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="77" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+13.3.1.2
+</section>
+<para>
+1
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing const'ness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+struct String {
+String (const String&);
+String (const char*);
+operator char* ();
+};
+String operator + (const String&, const String&);
+void f(void) {
+char* p= "one" + "two"; // ill-formed because
+neither
+// operand has user-defined type
+int I = 1 + 1; // Always evaluates to 2 even if
+// user-defined types exist which
+// would perform the operation.
+}
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="68" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+13.4
+</section>
+<para>
+1
+</para>
+<description>
+Overload resolution within the operand of a unary &
+operator is done by selecting the function "whose type
+matches the target type required in the context." The
+criterion for determining whether the types match,
+however, is not defined. At least three possibilities
+suggest themselves:<BR/>
+1. The types are identical.<BR/>
+2. The source type can be implicitly converted to
+the target type.<BR/>
+3. The expression would be well-formed if the
+function under consideration were not
+overloaded.<BR/>
+This question arises for pointer-to-member types, where
+there is an implicit conversion from a pointer-to-basemember
+to a pointer-to-derived-member, as well as when
+the context is an explicit type conversion (which allows for
+static_cast a conversion from pointer-to-derived-member
+to a pointer-to-base-member and, in the reinterpret_cast
+interpretation of functional and old-style casts, essentially
+any conversion).
+</description>
+<suggestion>
+Specify the intended criterion for determining
+whether the types match.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="82" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+13.5.8
+</section>
+<para>
+8
+</para>
+<description>
+Typo, "lteral" should be "literal".<BR/>
+// error: invalid lteral suffix identifier
+</description>
+<suggestion>
+Correct typo.<BR/>
+// error: invalid literal suffix identifier
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="69" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.3.2
+</section>
+<para>
+para 1
+</para>
+<description>
+The standard permits the address of thread_local variable
+as a non-type template parameter. The addresses of
+these variables are not constant, however.
+</description>
+<suggestion>
+Require static storage duration for non-type
+parameters.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="12" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.3.2
+</section>
+<para></para>
+<description>
+Now that local classes can be used as template
+arguments, it seems odd that there are "external linkage"
+restrictions on non-type template parameters.
+</description>
+<suggestion>
+Permit addresses of objects and functions with
+internal linkage as arguments for non-type
+template parameters.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="78" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.3.2
+</section>
+<para>
+2
+</para>
+<description>
+"char*" should be "const char *".
+If not corrected, type mismatch is another cause of error in
+the example below, which is not appropriate for an
+example here.
+<PRE>
+template<class T, char* p> class X {
+X();
+X(const char* q) { / ... / }
+};
+X<int, "Studebaker"> x1; // error: string literal as templateargument
+char p[] = "Vivisectionist";
+X<int,p> x2; // OK
+</PRE>
+</description>
+<suggestion>
+template<class T, const char* p> class X {
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="83" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.3.2
+</section>
+<para>
+2
+</para>
+<description>
+Constructors in template declaration are not essential for
+this example to explain string literal error use.
+<PRE>
+template<class T, char* p> class X {
+X();
+X(const char* q) { /* ... */ }
+};
+X<int, "Studebaker"> x1; // error: string literal as templateargument
+char p[] = "Vivisectionist";
+X<int,p> x2; // OK
+</PRE>
+</description>
+<suggestion>
+Delete two constructors in template declaration as
+follows.
+<PRE>
+template<class T, const char* p> class X {
+/* ... */
+};
+X<int, "Studebaker"> x1; // error: string literal as
+template-argument
+char p[] = "Vivisectionist";
+X<int,p> x2; // OK
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="42" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.3
+</section>
+<para>
+1
+</para>
+<description>
+The name "eror" should probably be "error".
+</description>
+<suggestion>
+Replace:<BR/>
+Tuple<0> eror;<BR/>
+With:<BR/>
+Tuple<0> error;<BR/>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="24" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.3
+</section>
+<para>
+4
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(10)" to "(Clause 10)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="70" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.6.2
+</section>
+<para>
+2, 4
+</para>
+<description>
+14.8.2.4p3 specifies that the deduction used in partial
+ordering in a non-call context is based on the complete
+function type of the function templates. The wording in
+14.5.6.2p2 (and echoed in p4) reflects an earlier
+specification, however, saying that the deduction uses
+only "the function parameter types, or in the case of a
+conversion function the return type." This is a
+contradiction.
+</description>
+<suggestion>
+Update the wording in 14.5.6.2 to say only that
+deduction is performed as described in 14.8.2.4
+and not to specify which types are used.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="71" type="unused" owner="" issue="" disp="" date="" extdoc="">
+<section>
+unused
+</section>
+<para>
+unused
+</para>
+<description>
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="7" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.6.2p3
+</section>
+<para>
+P3
+</para>
+<description>
+r country In FCD sub-clause 14.5.6.2 [temp.func.order]
+paragraph 3, we are told to synthesize, "for each type,
+non-type, or template template parameter... a unique type,
+value, or class template respectively."
+These are then substituted for each occurrence of the
+respective parameter in the function type of the function
+template.
+It is not specified what the properties of said synthetics
+are, for example, members of a dependent type referred
+to in non-deduced contexts are not specified to exist,
+although the transformed function type would be invalid if
+they do not exist.
+We may assume, for example, that each synthetic will be
+given minimal properties such that the transformed
+function type is valid at the point of definition of the
+template.<BR/>
+Example 1:<BR/>
+template <typename T, typename U> struct A; template
+<typename T> void foo(A<T, typename T::u> *) { } // #1 //
+synthetic T1 has member T1::u template <typename T>
+void foo(A<T, typename T::u::v> *) { } // #2 // synthetic T2
+has member T2::u and member T2::u::v // T in #1 deduces
+to synthetic T2 in partial ordering; // deduced A for the
+parameter is A<T2, T2::u> *--this is not necessarily
+compatible // with A<T2, T2::u::v> * and it does not need
+to be. See Note 1. The effect is that // (in the call below)
+the compatibility of B::u and B::u::v is respected. // T in #2
+cannot be successfully deduced in partial ordering from
+A<T1, T1::u> *; // invalid type T1::u::v will be formed when
+T1 is substituted into non-deduced contexts. struct B {
+struct u { typedef u v; }; }; int main() { foo((A<B, B::u> *)0);
+// calls #2 } *Note 1: Template argument deduction is an
+attempt to match a P and to a deduced A; however,
+template argument deduction is not specified to fail if the
+P and the deduced A are incompatible. This may occur in
+the presence of non-deduced contexts. Notwithstanding
+the parenthetical statement in [temp.deduct.partial]
+paragraph 9, template argument deduction may succeed
+in determining a template argument for every template
+parameter while producing a deduced A that is not
+compatible with the corresponding P.<BR/>
+Example 2:<BR/>
+template <typename T, typename U, typename V> struct
+A; template <typename T> void foo(A<T, struct T::u, struct
+T::u::u> *); #2.1 // synthetic T1 has member non-union
+class T1::u template <typename T, typename U> void
+foo(A<T, U , U> *); #2.2 // synthetic T2 and U2 has no
+required properties // T in #2.1 cannot be deduced in
+partial ordering from A<T2, U2, U2> *;// invalid types T2::u
+and T2::u::u will be formed when T2 is substituted in nondeduced
+contexts. // T and U in #2.2 deduces to,
+respectively, T1 and T1::u from A<T1, T1::u, struct
+T1::u::u> * unless // struct T1::u::u does not refer to the
+injected-class-name of the class T1::u (if that is possible).
+struct B { struct u { }; }; int main() { foo((A<B, B::u, struct
+B::u::u> *)0); // calls #2.1 } It is however unclear to what
+extent an implementation will have to go to determine
+these minimal properties.
+</description>
+<suggestion>
+This is a test of the interpretation of the resolution
+to Issue 214. In particular, we would like for the
+committee to spell out how properties of the
+synthetics produced for partial ordering are
+determined
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="72" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.7 [temp.alias]
+</section>
+<para></para>
+<description>
+Template aliases have no implementation experience.
+</description>
+<suggestion>
+Either demonstrate a complete implementation of
+this feature or remove N2258 from the working
+paper prior the FDIS.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="73" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.7
+</section>
+<para>
+1
+</para>
+<description>
+The current wording of 7.1.3p2 requires that the identifier
+in an alias-declaration "...shall not appear in the type-id."
+With template aliases, however, the name of the alias can
+be used indirectly:
+<PRE>
+template<typename T> struct A;
+template<typename T> using B=typename A<T>::U;
+template<typename T> struct A {
+typedef B<T> U;
+};
+B<short> b;
+</PRE>
+Here the instantiation of B<short> causes the instantiation
+of A<short>, and the typedef in A<short> ends up
+attempting to use B<short>, which is still in the process of
+being instantiated.
+</description>
+<suggestion>
+Add wording to indicate that such usages in
+template aliases are ill-formed.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="74" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.7
+</section>
+<para>
+1
+</para>
+<description>
+An alias-declaration allows a class or enumeration type to
+be defined in its type-id (7.1.6p3). However, it's not clear
+that this is desirable when the alias-declaration is part of a
+template alias:
+<PRE>
+template<typename T> using A =
+struct { void f(T) { } };
+</PRE>
+</description>
+<suggestion>
+Either prohibit the definition of classes and
+enumerations in template aliases, or prohibit the
+use of template parameters in such definitions, or
+add an example illustrating this usage.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="10" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.7 [temp.alias]
+</section>
+<para></para>
+<description>
+Can template aliases be declared in class scope?
+</description>
+<suggestion>
+Allow declaring template aliases in class scope, if
+not allowed by the current grammar.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="11" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.7 [temp.alias]
+</section>
+<para></para>
+<description>
+We have class templates and function templates,
+shouldn't we call template aliases alias templates for
+consistency?
+</description>
+<suggestion>
+Change “template alias” -> “alias template”
+everywhere.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="25" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.5.7
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+US
+73
+14.5.7 1 te The current wording of 7.1.3p2 requires that the identifier
+in an alias-declaration "...shall not appear in the type-id."
+With template aliases, however, the name of the alias can
+be used indirectly:
+template<typename T> struct A;
+template<typename T> using B=typename A<T>::U;
+template<typename T> struct A {
+typedef B<T> U;
+};
+B<short> b;
+Here the instantiation of B<short> causes the instantiation
+of A<short>, and the typedef in A<short> ends up
+attempting to use B<short>, which is still in the process of
+being instantiated.
+Add wording to indicate that such usages in
+template aliases are ill-formed.
+US
+74
+14.5.7 1 te An alias-declaration allows a class or enumeration type to
+be defined in its type-id (7.1.6p3). However, it's not clear
+that this is desirable when the alias-declaration is part of a
+template alias:
+template<typename T> using A =
+struct { void f(T) { } };
+Either prohibit the definition of classes and
+enumerations in template aliases, or prohibit the
+use of template parameters in such definitions, or
+add an example illustrating this usage.
+FI
+10
+14.5.7
+[temp.alias]
+te Can template aliases be declared in class scope? Allow declaring template aliases in class scope, if
+not allowed by the current grammar.
+FI
+11
+14.5.7
+[temp.alias]
+te We have class templates and function templates,
+shouldn't we call template aliases alias templates for
+consistency?
+Change “template alias” -> “alias template”
+everywhere.
+JP
+25
+14.5.7 1 E Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+Change "(clause 7)" to "(Clause 7)".
+</description>
+<suggestion>
+Change "(clause 7)" to "(Clause 7)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="26" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.6.2.1
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(9)" to "(Clause 9)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="43" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.6.2.1p3
+</section>
+<para></para>
+<description>
+If I'm not missing something, 14.6.2.1/3 says that in the
+definition of a class template or member of a class
+template, the injected-class-name refers to the current
+instantiation. The template name followed by the
+argument list enclosed in “<..>” also refers to the current
+instantiation, but only in the definition of a primary class
+template. That results in an odd situation:<BR/>
+template<typename T> struct A { typedef int type; void
+f(type); }; // here we are outside the definition of 'A'<BR/>
+template<typename T> void A::f(A::type) { } // OK: 'A' is
+the injected-class-name<BR/>
+template<typename T> void A::f(A<T>::type) { } // ill-formed:
+'A<T>' is not the injected-class-name. Needs
+'typename '!<BR/>
+If you would define the member-function within the
+primary class template, bullet 2 would apply:<BR/>
+template<typename T> struct A {<BR/>
+typedef int type; void f(A<T>::type) { } // OK: name of A
+followed by arguments enclosed in <..><BR/>
+};<BR/>
+I think that this state of affairs isn't any good.<BR/>
+-> Suggested solution: Change 14.6.2.1/1 bullet2 to apply
+also to members of the primary class template. The same
+for bullet4 talking about partial specializations. Since
+partial specializations are also class templates, i wonder
+whether one could also smelt together bullet2 and bullet4
+and only talk about “class template”.
+</description>
+<suggestion>
+Updated 14.6.2.1 [temp.dep.type] p1 bullet 2:
+" in the definition of a primary class template or
+a member of a class template, the name of the
+class template followed by the template argument
+list of the primary template (as described below)
+enclosed in <>,"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="44" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.6p5
+</section>
+<para></para>
+<description>
+C++0x does not allow this code
+<PRE>
+template<typename T> struct id { typedef T type; };
+template<typename T> void f() { int id<T>::type::*p = 0; }
+struct A { };
+int main() { f<A>(); }
+</PRE>
+The reason is that it requires “typename” before
+“id<T>::type”, but “typename” is not allowed at that place
+by the syntax. Ultimately, current compilers accept this.
+</description>
+<suggestion>
+Change 14.6/5 to<BR/>
+A qualified name used as the name in a meminitializer-
+id, a base-specifier, an elaborated-typespecifier
+or the nested-name-specifier of a pointerto-
+member declarator is implicitly assumed to
+name a type, without the use of the typename
+keyword.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="6" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.6p5
+</section>
+<para>
+P5
+</para>
+<description>
+Given the change in N1376=02-0034 to [temp.res], found
+in FCD in [temp.res] paragraph 5:<BR/>
+A qualified name used as the name in a meminitializer-
+id, a base-specifier, or an elaboratedtype-
+specifier is implicitly assumed to name a
+type, without the use of the typename keyword<BR/>
+the following appears to be well-formed, with templates
+foo() being distinct since any type T will produce an invalid
+type for the second parameter for at least one foo() when
+T is replaced within the non-deduced context:
+<PRE>
+template <typename T>
+bool *foo(T *, enum T::u_type * = 0) { return 0; }
+template <typename T> char *foo(T *, struct T::u_type * =
+0) { return 0; }
+struct A { enum u_type { I }; }; int main(void) { foo((A*)0); }
+</PRE>
+In particular, while determining the signature (1.3.11
+[defns.signature]) for the function templates foo(), an
+elaborated-type-specifier qualifies as part of the declspecifier-
+seq under 8.3.5 [dcl.fct] paragraph 5 in
+determining the type of a parameter in the parametertype-
+list (absent additional wording).
+Also, the return type is included in the signature of a
+function template.<BR/>
+A portion of the GCC 4.5.0 output:<BR/>
+Internal compiler error: Error reporting routines re-entered.
+Please submit a full bug report, with preprocessed source
+if appropriate. See < http://gcc.gnu.org/bugs.html > for
+instructions.<BR/>
+Implementations do not appear to support this case and
+the ability to do so brings little value since type traits such
+as is_enum and is_class cannot be defined using this and
+equivalent functionality can be achieved using the
+aforementioned type traits.
+<PRE>
+template <typename T> struct MY_is_enum :
+std::false_type { };
+template <typename T> struct MY_is_enum<enum T> :
+std::true_type { }; // ill-formed,
+</PRE>
+elaborated-type-specifier resolves to typedef-name
+</description>
+<suggestion>
+Please clarify as the following case appears to be
+expensive to implement with little functional value
+to the language.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="75" type="TE" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.7
+</section>
+<para></para>
+<description>
+As described in c++std-core-16425 and its followup
+messages, writing metaprograms is needlessly hard
+because specializing template members inside a class is
+(inadvertently?) not permitted. In addition, this surprising
+restriction makes C++ less simple and more arbitrary-seeming.
+</description>
+<suggestion>
+Accept the code like that in c++std-core-16425,
+like Visual C++ does already
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="79" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.7.1
+</section>
+<para>
+10
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing constness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+namespace N {
+template<class T> class List {
+public:
+T* get();
+};
+}
+template<class K, class V> class Map {
+public:
+N::List<V> lt;
+V get(K);
+};
+void g(Map<const char*,int>& m) {
+int i = m.get("Nicholas");
+}
+</PRE>
+a call of lt.get() from Map<const char*,int>::get()
+would place List<int>::get() in the namespace N
+rather
+than in the global namespace. —end example ]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="9" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.7.3 [temp.expl.spec]
+</section>
+<para>
+Paragraph 2
+</para>
+<description>
+Explicit specializations in class scope inside class
+templates should be allowed. It's weird, confusing and
+inconsistent that they can be declared/defined in some
+scopes but not in others.
+</description>
+<suggestion>
+Allow explicit specialization of member templates
+inside class templates.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="80" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.8.1
+</section>
+<para>
+5
+</para>
+<description>
+"char*" should be "const char *".<BR/>
+The special rule to convert character literal to pointer has
+been removed from "4.2 Array-to-pointer conversion
+[conv.array]".
+<PRE>
+char * p1 = "..." ; // ill-formed.(removing const'ness)
+char const *p2 = "..." ;// well-formed.
+</PRE>
+There are many code fragments depending on the
+removed rule. They are ill-formed.
+</description>
+<suggestion>
+Change to:
+<PRE>
+template<class X, class Y, class Z> X f(Y,Z);
+template<class ... Args> void f2();
+void g() {
+f<int,const char*,double>("aa",3.0);
+f<int,const char*>("aa",3.0); // Z is deduced to be
+double
+f<int>("aa",3.0); // Y is deduced to be const char*,
+and
+// Z is deduced to be double
+f("aa",3.0); // error: X cannot be deduced
+f2<char, short, int, long>(); // OK
+}
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="76" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.8.2
+</section>
+<para>
+para 9
+</para>
+<description>
+"extern template" prevents inlining functions not marked
+inline.
+</description>
+<suggestion>
+Remove wording about "suppressing the implicit
+instantiation". See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="77" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+14.8.2.1
+</section>
+<para></para>
+<description>
+Core Issue 1014 claims that calling f(const T&) and f(T&&)
+with a const int lvalue is ambiguous. It's unambiguous
+because the partial ordering rules consider f(const T&) to
+be more specialized than f(T&&), for the same reasons
+that they consider h(const T&) to be more specialized than
+h(T&).<BR/>
+However, calling z(T&) and z(T&&) with an int lvalue is
+ambiguous. Because z(T&) accepts a strict subset of the
+things that z(T&&) accepts, it seems that the partial
+ordering rules should be modified to consider z(T&) to be
+more specialized than z(T&&). There may be additional
+subtleties.
+</description>
+<suggestion>
+Modify the partial ordering rules to consider z(T&)
+to be more specialized than z(T&&).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="78" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.2
+</section>
+<para>
+2
+</para>
+<description>
+This paragraph says that "An object that is... partially
+destroyed will have destructors executed... for subobjects
+for which the principal constructor (12.6.2) has completed
+execution and the destructor has not yet begun
+execution." This would presumably apply to an example
+like
+<PRE>
+struct S { ~S(); } s[10];
+</PRE>
+If the destructor for s[5] throws an exception, elements 0-4
+should still be destroyed. However, the wording
+specifically refers to "fully constructed base classes and
+non-variant members," even though array elements are
+subobjects of the array (1.8p2). This is presumably the
+effect of stack unwinding (p1), which applies to "all
+automatic objects constructed since the try block was
+entered," but whether that should also be expected for
+arrays of static, thread, and dynamic storage duration is
+not clear.
+</description>
+<suggestion>
+Clarify the intent with respect to array elements
+and storage duration.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="45" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.3
+</section>
+<para>
+16
+</para>
+<description>
+The phrasing of this clause suggests all exceptiondeclarations
+produce objects. There should be some
+additional wording to clarify that exception-declarations
+that declare references bind to the exception object by
+appropriate initialization, and *are* allowed to be
+references to abstract classes. Likewise, the elipsis form
+does not initialize any object or temporary.
+</description>
+<suggestion>
+Distinguish between initializing objects, initializing
+references, and initializing nothing in the case of
+an elipsis.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="5" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.3p8, 15.1p7
+</section>
+<para>
+P8, p7
+</para>
+<description>
+There is an issue with the definition of "currently handled
+exception" in 15.3 [except.handle] paragraph 8:<BR/>
+The exception with the most recently activated
+handler that is still active is called the currently
+handled exception.<BR/>
+This wording implies that the currently handled exception
+may be changed by another thread. Thus, by 15.1
+[except.throw] paragraph 7,<BR/>
+A throw-expression with no operand rethrows the
+currently handled exception (15.3).<BR/>
+the following may throw an exception that is not of type
+int. try { throw 0; } catch (...) { throw; } Any solution should
+also specify what the currently handled exception will be
+for a thread that is spawned during the handling of an
+exception by its parent.
+</description>
+<suggestion>
+Clarify and fix as suggested.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="79" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.4
+</section>
+<para>
+p1
+</para>
+<description>
+Because C has no exception mechanism, functions
+having "C" language linkage should implicitly be declared
+noexcept.
+</description>
+<suggestion>
+Insert a sentence such as:<BR/>
+Any function declared to have "C" linkage shall be
+treated as if declared noexcept even if the
+declaration lacks the noexcept keyword.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="46" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.4
+</section>
+<para></para>
+<description>
+It is not entirely clear that a function-try-block on a
+destructor will catch exceptions for a base or member
+destructor destructor; whether such exceptions might be
+swallowed with a simple return statement rather than
+being rethrown; and whether such a clause might be
+entered multiple times if multiple bases/members throw, or
+if that is an automatic terminate call.
+</description>
+<suggestion>
+[Add words to 15.4 clarifying the problem cases.]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="10" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.4
+</section>
+<para>
+p9
+</para>
+<description>
+In case of incorrect program specification, the general rule
+is that the behaviour is undefined. This should be true for
+noexcept as well.
+</description>
+<suggestion>
+Change the second bullet of p9 to "otherwise, the
+behaviour is undefined.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="47" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.5.1
+</section>
+<para>
+1
+</para>
+<description>
+15.5.1:1 [except.terminate] lists the situations in which
+"exception handling must be abandoned for less subtle
+error handling techniques".
+The list seems to omit some new situations added by
+other c++0x features.
+</description>
+<suggestion>
+The list should be augmented with the following:
+<UL><LI>when function
+std::nested_exception::rethrow_nested is called
+for an object that stores a null exception pointer.</LI>
+<LI>when execution of a function registered with
+std::at_quick_exit
+exits using an exception.</LI></UL>
+Also, after the list, add the following sentence:<BR/>
+Function std::terminate is also called by the
+implementation, when the
+destrductor or a copy constructor of a class
+std::thread is called for
+the object that is joinable.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="48" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.5.2
+</section>
+<para>
+1-4
+</para>
+<description>
+This subclause is dealing exclusively with dynamic
+exception specifications, and should clearly say so.
+</description>
+<suggestion>
+Replace each italicised occurrence of 'exceptionspecification'
+with 'dynamic-exceptionspecification'
+in clause 15.5.2,
+[except.unexpected]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="49" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+15.5.2
+</section>
+<para>
+all
+</para>
+<description>
+Dynamic exception specifications are deprecated, so
+clause 15.5.2 that describes how they work should move
+to Annex D.
+</description>
+<suggestion>
+Move 15.5.2 [except.unexpected] to Annex D.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="11" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+16.1
+</section>
+<para>
+p3
+</para>
+<description>
+constant-expression as given by C++'s grammar allows
+far more syntactical constructs than those that are allowed
+in preprocessor context. The footnote 145 provides some
+hints on the limitations, but in our opinion it should be
+made more clear that the "constant-expression" allows
+less than a lookup of the corresponding grammar rule
+suggests
+</description>
+<suggestion>
+Add a note or extend footnote 145 with "Note that
+constant-expression is much more limited than the
+C++ grammar rule would suggest. See the
+following paragraphs how it is limited in the
+context of conditional inclusion."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="12" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+16.3.5
+</section>
+<para>
+p5
+</para>
+<description>
+missing space between '~' and '5' in expansion
+</description>
+<suggestion>
+line
+<PRE>
+"f(2 * (2+(3,4)-0,1)) | f(2 *
+(~5)) & f(2 * (0,1))^m(0,1);"
+</PRE>
+should
+read
+<PRE>
+"f(2 * (2+(3,4)-0,1)) | f(2 * (~
+5)) & f(2 * (0,1))^m(0,1);"
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="13" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+16.3.5
+</section>
+<para>
+p7
+</para>
+<description>
+superfluous braces in source
+</description>
+<suggestion>
+change
+<PRE>
+"int j[] = { t(1,2,3), t(,4,5),
+t(6,{,}7), t(8,9,),"
+</PRE>
+to
+<PRE>
+"int j[] = {
+t(1,2,3), t(,4,5), t(6,,7), t(8,9,),"
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="14" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+16.3.5
+</section>
+<para>
+p9
+</para>
+<description>
+superfluous spaces after/before parentheses
+</description>
+<suggestion>
+change
+<PRE>
+fprintf(stderr, "Flag" );
+fprintf(stderr, "X = %d\n", x );
+puts( "The first, second, and
+third items." );
+</PRE>
+to
+<PRE>
+fprintf(stderr, "Flag");
+fprintf(stderr, "X = %d\n", x);
+puts("The first, second, and third
+items.");
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="13" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+16.8
+</section>
+<para></para>
+<description>
+Committee Draft comment DE 18 has only been partially
+addressed, and the record of response ignores the
+missing item, namely the absence of a macro
+__STDCPP_STRICT_POINTER_SAFETY__ that
+indicates that a given implementation has strict pointer
+safety (see 3.7.4.3).
+</description>
+<suggestion>
+Add the macro to the list of predefined macros in
+16.8.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="80" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[library] 17 - 30
+</section>
+<para></para>
+<description>
+Consider applying noexcept to all of the std::lib.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="60" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17-30
+</section>
+<para></para>
+<description>
+Dyanamic exception specifications are deprecated; the
+library should recognise this by replacing all non-throwing
+exception specifications of the form 'throw()' with the
+'noexcept' form.
+</description>
+<suggestion>
+Replace all non-throwing exception specifications
+of the form 'throw()' with the 'noexcept' form.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="61" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17-30
+</section>
+<para></para>
+<description>
+All library types should have non-throwing move
+constructors and move-assignment operators unless
+wrapping a type with a potentially throwing moveoperation.
+When such a type is a class-template, these
+operations should have a conditional noexcept
+specification.<BR/>
+There are many other places where a noexcept
+specification may be considered, but the move operations
+are a special case that must be called out, to effectively
+support the move_if_noexcept function template.
+</description>
+<suggestion>
+Review every class and class template in the
+library. If noexcept move constructor/assignment
+operators can be implicitly declared, then they
+should be implicitly declared, or explicitly
+defaulted. Otherwise, a move constructor/moveassingment
+operator with a 'noexcept' exception
+specification should be provided.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="62" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17-30
+</section>
+<para></para>
+<description>
+Issues with efficiency and unsatisfactory semantics mean
+many library functions document they do not throw
+exceptions with a Throws: Nothing clause, but do not
+advertise it with an exception specification. The semantic
+issues are largely resolved with the new 'noexcept'
+specifications, and the noexcept operator means we will
+want to detect these guarantees programatically in order
+to construct programs taking advantage of the guarantee.
+</description>
+<suggestion>
+Add a 'noexcept' exception specification on each
+libary API that offers an unconditional Throws:
+Nothing guarantee. Where the guarantee is
+conditional, add the appropriate
+noexcept(constant-expression) if an appropriate
+constant expression exists.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="63" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17-30
+</section>
+<para></para>
+<description>
+Since the newly introduced operator noexcept makes it
+easy (easier than previously) to detect whether or not a
+function has been declared with the empty exception
+specification (including noexcept) library functions that
+cannot throw should be decorated with the empty
+exception specification. Failing to do so and leaving it as a
+matter of QoI would be detrimental to portability and
+efficiency.
+</description>
+<suggestion>
+Review the whole library, and apply the noexcept
+specification where it is appropriate.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="64" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17-30
+</section>
+<para></para>
+<description>
+There are a number of unspecified types used throughout
+the library, such as the container iterators. Many of these
+unspecified types have restrictions or expectations on
+their behaviour in terms of exceptions. Are they permitted
+or required to use exception specifications, more
+specifically the new noexcept specification? For example,
+if vector<T>::iterator is implemented as a native pointer,
+all its operations will have an (effective) nothrow
+specification. If the implementation uses a class type to
+implement this iterator, is it permitted or required to
+support that same guarantee?
+</description>
+<suggestion>
+Clearly state the requirements for exception
+specifications on all unspecified library types. For
+example, all container iterator operations should
+be conditionally noexcept, with the condition
+matching the same operation applied to the
+allocator pointer_type, a certain subset of which
+are already required not to throw.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="65" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17-30
+</section>
+<para></para>
+<description>
+Nothrowing swap operations are key to many C++ idioms,
+notably the common copy/swap idiom to provide the
+strong exception safety guarantee.
+</description>
+<suggestion>
+Where possible, all library types should provide a
+swap operation with an exception specification
+guaranteeing no exception shall propagate.
+Where noexcept(true) cannot be guaranteed to
+not terminate the program, and the swap in
+questions is a template, an exception specification
+with the appropriate conditional expression could
+be specified.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="66" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17-30
+</section>
+<para></para>
+<description>
+The syntax for attributes was altered specifically to make it
+legal do declare attributes on functions by making the
+attribute the first token in the declaration, rather than
+inserting it between the function name and the opening
+paren of the parameter list. This is much more readable,
+and should be the preferred style throughout the library.
+For example, prefer:<BR/>
+[[noreturn]] void exit(int status);<BR/>
+to<BR/>
+void exit [[noreturn]] (int status);
+</description>
+<suggestion>
+Update all function declarations throughout the
+library to use the preferred placement of functionlevel
+attributes.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="15" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+Library clauses
+</section>
+<para></para>
+<description>
+Due to the new rules about implicit copy and move
+constructors some library facilities are now move-only.
+</description>
+<suggestion>
+Make them copyable again.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="16" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+Library clauses
+</section>
+<para></para>
+<description>
+Dynamic exception specifications are deprecated.
+Deprecated features shouldn't be used in the Standard.
+</description>
+<suggestion>
+Replace dynamic exception specifications with
+noexcept.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="17" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+Library clauses
+</section>
+<para></para>
+<description>
+The introduction of noexcept makes "Throws: Nothing"
+clauses looking strange.
+</description>
+<suggestion>
+Consider replacing "Throws: Nothing." clause by
+the respective noexcept specification.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="18" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17
+</section>
+<para></para>
+<description>
+The general approach on moving is that a library object
+after moving out is in a "valid but unspecified state". But
+this is stated at the single object specifications, which is
+error prone (especially if the move operations are implicit)
+and unnecessary duplication.
+</description>
+<suggestion>
+Consider putting a general statement to the same
+effect into clause 17.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="27" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.1
+</section>
+<para>
+9
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(25)" to "(Clause 25)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="52" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.3.7
+</section>
+<para></para>
+<description>
+The definition of deadlock in 17.3.7 excludes cases
+involving a single thread making it incorrect.
+</description>
+<suggestion>
+The definition should be corrected.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="50" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.3.13
+</section>
+<para></para>
+<description>
+This definition of move-assignment operator redundant
+and confusing now that the term move-assignment
+operator is defined by the core language in subclause
+12.8p21.
+</description>
+<suggestion>
+Strike suclause 17.3.13 [defns.move.assign.op].
+Add a cross-reference to (12.8) to 17.3.12.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="51" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.3.14
+</section>
+<para></para>
+<description>
+This definition of move-constructor redundant and
+confusing now that the term constructor is defined by the
+core language in subclause 12.8p3.
+</description>
+<suggestion>
+Strike subclause 17.3.14, [defns.move.ctor]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="67" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.5.2.1.2
+</section>
+<para>
+2
+</para>
+<description>
+In some code examples, ellipsis(...) is used in ill-formed.
+In these cases, "..." represents omission of some codes
+like this:<BR/>
+class A { /* ... */ } ;<BR/>
+But in some cases, it is used without commented-out as
+below:<BR/>
+class A { ... } ;<BR/>
+It is an inconsistent usage. They all should be enclosed in
+a comment.
+In addition, the number of period should be 3 rather than
+5.
+</description>
+<suggestion>
+Change to:
+<PRE>
+enum bitmask {
+V0 = 1 << 0, V1 = 1 << 1, V2 = 1 << 2, V3 = 1 <<
+3, ...
+};
+static const
+/* ... */
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="53" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.5.2.1.3
+</section>
+<para></para>
+<description>
+The bitmask types defined in 27.5.2 and 28.5 contradict
+the bitmask type requirements in 17.5.2.1.3, and have
+missing or incorrectly defined operators.
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="54" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.5.2.1.4.x
+</section>
+<para></para>
+<description>
+The defined terms NTC16S, NTC32S, NTWCS, char16-
+character sequence, null-terminated char16-character
+string, char32-character sequence, null-terminated
+char32-character string, wide-character sequence and
+null-terminated wide-character string do not occur at any
+point in the standard outside their definitional subclauses
+and associated footnotes.
+</description>
+<suggestion>
+Strike 17.5.2.1.4.3, 17.5.2.1.4.4, 17.5.2.1.4.5 and
+associated footnotes 170, 171, 172, 173, 174 and
+175.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="55" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.6.1.3
+</section>
+<para>
+Table 15
+</para>
+<description>
+The thread header uses duration types, found in the
+<chrono> header, and which rely on the ratio types
+declared in the <ratio> header.
+</description>
+<suggestion>
+Add the <chrono> and <ratio> headers to the
+freestanding requirements.
+It might be necessary to address scaled-down
+expectations of clock support in a freestanding
+environment, much like <thread>.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="56" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.6.1.3
+</section>
+<para>
+Table 15
+</para>
+<description>
+The <utility> header provides support for several
+important C++ idioms with move, forward and swap.
+Likewise, declval will be frequently used like a type trait.
+In order to complete cycles introduced by std::pair, the
+<tuple> header should also be made available. This is a
+similarly primitive set of functionality, with no dependency
+of a hosted environment, but does go beyond the minimal
+set of functionality otherwise suggested by the
+freestanding libraries.
+Alternatively, split the move/forward/swap/declval
+functions out of <utility> and into a new primitive header,
+requiring only that of freestanding implementation.
+</description>
+<suggestion>
+Add <utility> and <tuple> to table 15, headers
+required for a free-standing implementation.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="57" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.6.1.3
+</section>
+<para>
+Table 15
+</para>
+<description>
+The atomic operations facility is closely tied to clause 1
+and the memory model. It is not easily supplied as an
+after-market extension, and should be trivial to implement
+of a single-threaded serial machine. The consequence of
+not having this facility will be poor interoperability with
+future C++ libraries that memory model concerns
+seriously, and attempt to treat them in a portable way.
+</description>
+<suggestion>
+Add <atomic> to table 15, headers required for a
+free-standing implementation.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="58" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.6.2
+</section>
+<para></para>
+<description>
+It is not clear whether a library header specified in terms
+of a typedef name makes that same typedef name
+available for use, or if it simply requires that the specified
+type is an alias of the same type, and so the typedef name
+cannot be used without including the specific header that
+defines it. For example, is the following code required to
+be accepted:
+<PRE>
+#include <vector>
+std::size_t x = 0;
+</PRE>
+Most often, this question concerns the typedefs defined in
+header <cstddef>
+</description>
+<suggestion>
+Add a paragraph under 17.6.2 clarifying whether
+or not headers specified in terms of std::size_t can
+be used to access the typedef size_t, or whether
+the header <cstddef> must be included to reliably
+use this name.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="59" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.6.3.6
+</section>
+<para>
+2
+</para>
+<description>
+The replaceable functions in header <new> are all
+described in clause 18.6 [support.dynamic], where it can
+be seen that all the listed functions have an exception
+specification which must be compatible with any
+replacement function.
+Narrow the reference to (Clause 18) to (Clause
+18.6).
+</description>
+<suggestion>
+Add the missing exception specification on each
+function signature:<BR/>
+void* operator new(std::size_t size)
+throw(std::bad_alloc);<BR/>
+void* operator new(std::size_t size, const
+std::nothrow_t&) throw();<BR/>
+void operator delete(void* ptr) throw();<BR/>
+void operator delete(void* ptr, const
+std::nothrow_t&) throw();<BR/>
+void* operator new[](std::size_t size)
+throw(std::bad_alloc);<BR/>
+void* operator new[](std::size_t size, const
+std::nothrow_t&) throw();<BR/>
+void operator delete[](void* ptr) throw();<BR/>
+void operator delete[](void* ptr, const
+std::nothrow_t&) throw();<BR/>
+(note that other comments might further want to
+replace 'throw()' with 'noexcept')
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="81" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.6.3.9
+</section>
+<para>
+p1
+</para>
+<description>
+International Standards do not make “statements”; they
+“specify” or “require” instead.
+</description>
+<suggestion>
+s/statements/ specifications/
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="82" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.6.3.9
+</section>
+<para>
+p1, bullet 3
+</para>
+<description>
+The second Note can benefit by adopting recent
+nomenclature.
+</description>
+<suggestion>
+Rephrase the Note in terms of xvalue.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="83" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+17.6.3.10
+</section>
+<para>
+p2, first sent.
+</para>
+<description>
+The word “constructor” is misspelled.
+</description>
+<suggestion>
+s/contructor/constructor/
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="68" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.2
+</section>
+<para>
+4
+</para>
+<description>
+There is no reason for the offsetof macro to invoke
+potentially throwing operations, so the result of
+noexcept(offsetof(type,member-designator)) should be
+true.
+</description>
+<suggestion>
+Add to the end of 18.2p4:<BR/>
+"No operation invoked by the offsetof macro shall
+throw an exception, and
+noexcept(offsetof(type,member-designator)) shall
+be true."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="68" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.3.1.5
+</section>
+<para>
+2
+</para>
+<description>
+In some code examples, ellipsis(...) is used in ill-formed.
+In these cases, "..." represents omission of some codes
+like this:<BR/>
+class A { /* ... */ } ;<BR/>
+But in some cases, it is used without commented-out as
+below:<BR/>
+class A { ... } ;<BR/>
+It is an inconsistent usage. They all should be enclosed in
+a comment.
+More over, in this case, "implementation-defined" would
+be better than "...".
+</description>
+<suggestion>
+Change to:<BR/>
+<PRE>
+inline static constexpr float infinity() throw() {
+return /* ... */; }
+inline static constexpr float quiet_NaN() throw() {
+return /* ... */; }
+inline static constexpr float signaling_NaN()
+throw() { return /* ... */; }
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="84" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.5
+</section>
+<para>
+5 note
+</para>
+<description>
+Note in paragraph 5 says "the atexit() functions shall not
+introduce a data race" and Note in paragraph 10 says "the
+at_quick_exit() functions do not introduce ...".
+Such different expressions in similar functions are
+confusing.
+If these notes are written for unspecified behaviors just
+before the sentence, "do" would be preferred.
+</description>
+<suggestion>
+Replace "shall" with "do".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="69" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.5
+</section>
+<para>
+14
+</para>
+<description>
+("The function quick_exit() never returns to its caller.")
+should be removed as redundant. The function is already
+attributed
+with [[noreturn]].
+</description>
+<suggestion>
+Remove paragraph 14
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="19" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.8.5
+</section>
+<para></para>
+<description>
+It's not clear how exception_ptr is synchronized.
+</description>
+<suggestion>
+Make clear that accessing in different threads
+multiple exception_ptr objects that all refer to the
+same exception introduce a race.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="70" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.6
+</section>
+<para></para>
+<description>
+std::nothrow_t is a literal type (being an empty POD) so
+the preferred form of declaration for std::nothrow is as a
+constexpr literal, rather than an extern symbol.
+</description>
+<suggestion>
+Replace:<BR/>
+extern const nothrow_t nothrow;<BR/>
+with<BR/>
+constexpr nothrow_t nothrow{};
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="71" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.6.2.4 / 18.8.2.2 / 18.8.3.2
+</section>
+<para></para>
+<description>
+The thread safety of std::set_new_handler(),
+std::set_unexpected(), std::set_terminate(), is unspecified
+making the the functions impossible to use in a thread
+safe manner.
+</description>
+<suggestion>
+The thread safety guarantees for the functions
+must be specified and new interfaces should be
+provided to make it possible to query and install
+handlers in a thread safe way.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="14" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.6.1.4
+</section>
+<para></para>
+<description>
+It is unclear how a user replacement function can
+simultaneously satisfy the race-free conditions imposed in
+this clause and query the new-handler in case of a failed
+allocation with the only available, mutating interface
+std::set_new_handler.
+</description>
+<suggestion>
+Offer a non-mutating interface to query the current
+new-handler.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="72" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.8.2
+</section>
+<para></para>
+<description>
+Dynamic exception specifications are deprecated, so
+clause 18.8.2 that describes library support for this facility
+should move to Annex D, with the exception of the
+bad_exception class which is retained to indicate other
+failures in the exception dispatch mechanism (e.g. calling
+current_exception()).
+</description>
+<suggestion>
+With the exception of 18.8.2.1 [bad.exception],
+move clause 18.8.2 diectly to Annex D.
+[bad.exception] should simply become the new
+18.8.2.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="73" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.8.4
+</section>
+<para></para>
+<description>
+The thread safety std::uncaught_exception() and the
+result of the function when multiple threads throw
+exceptions at the same time are unspecified. To make the
+function safe to use in the presence of exceptions in
+multiple threads the specification needs to be updated.
+</description>
+<suggestion>
+Update this clause to support safe calls from
+multiple threads without placing synchronization
+requirements on the user.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="74" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.8.5
+</section>
+<para>
+10
+</para>
+<description>
+One idea for the exception_ptr type was that a referencecounted
+implementation could simply 'reactivate' the same
+exception object in the context of a call to
+'rethrow_exception'. Such an implementation would allow
+the same exception object to be active in multiple threads
+(such as when multiple threads join on a shared_future)
+and introduce potential data races in any exception
+handler that catches exceptions by reference - notably
+existing library code written before this capability was
+added. 'rethrow_exception' should *always* make a copy
+of the target exception object.
+</description>
+<suggestion>
+Throws: a copy of the exception object to which p
+refers.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="84" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+18.8.6 [except.nested]
+</section>
+<para>
+6-7
+</para>
+<description>
+The throw_with_nested spec passes in its argument as
+T&& (perfect forwarding pattern), but then discusses
+requirements on T without taking into account that T may
+be an lvalue-reference type. It is also not clear in the
+spec that t is intended to be perfectly forwarded.
+</description>
+<suggestion>
+Patch 6-7 to match the intent with regards to
+requirements on T and the use of
+std::forward<T>(t).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="75" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+19
+</section>
+<para></para>
+<description>
+None of the exception types defined in clause 19 are
+allowed to throw an exception on copy or move
+operations, but there is no clear specification that the
+operations have an exception specification to prove it.
+Note that the implicitly declared constructors, taking the
+exception specification from their base class (ultimately
+std::exception) will implicitly generate a noexcept
+exception specification if all of their data members
+similarly declare noexcept operations. As the
+representation is unspecified, we cannot assume nonthrowing
+operations unless we explicitly state this as a
+constraint on the implementation.
+</description>
+<suggestion>
+Add a global guarantee that all exception types
+defined in clause 19 that rely on implicitly declared
+operations have a non-throwing exception
+specification on those operations.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="76" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+19.5.1.5
+</section>
+<para></para>
+<description>
+The C++0x FCD recommends, in a note (see 19.5.1.1/1),
+that users
+create a single error category object for each user defined
+error
+category and specifies error_category equality
+comparsions based on
+equality of addresses (19.5.1.3). The Draft apparently
+ignores this
+when specifying standard error category objects in section
+19.5.1.5,
+by allowing the generic_category() and system_category()
+functions to
+return distinct objects for each invocation.
+</description>
+<suggestion>
+Append a new sentence to 19.5.1.5
+[syserr.errcat.objects]/1, which
+reads "All calls of this function return references to
+the same
+object.", and append the same sentence to
+19.5.1.5/3.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="77" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+19.5.6.2
+</section>
+<para>
+14
+</para>
+<description>
+The description for system_error::what (19.5.6.2/14)
+changed between
+the C++ Working Papers N2914 and N2960. The latter
+document indicates
+that the Returns clause shall read "Returns: An NTBS
+incorporating the
+arguments supplied in the constructor.". Instead, in the
+FCD it now
+reads "Returns: An NTBS incorporating and
+code().message() the
+arguments supplied in the constructor.".</description>
+<suggestion>
+Remove the extra words from 19.5.6.2
+[syserr.syserr.members]/14:
+"Returns: A NTBS incorporating the arguments
+supplied in the
+constructor."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="78" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+19.5.6.2
+</section>
+<para></para>
+<description>
+The FCD contains a requirement that all standard classes
+which are
+derived from std::exception have a copy constructor and
+copy
+assignment operator which essentially copy the stored
+what() message
+(See 18.8.1/2). In contrast, it is unspecified whether
+copies of
+system_error return the same error_code on calls to
+system_error::code().
+</description>
+<suggestion>
+Insert a new paragraph after 19.5.6.1
+[syserr.syserr.overview]/1 which
+reads "The copy constructor and copy assignment
+operator of class
+system_error both have a strengthened
+postcondition which supplements
+the basic postcondition for standard library
+exception classes copy
+construction and copy assigment (18.8.1): If two
+objects lhs and rhs
+both have type system_error and lhs is a copy of
+rhs, then lhs.code()
+== rhs.code() shall hold."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="79" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20, 22, 24, 28
+</section>
+<para></para>
+<description>
+The library provides several traits mechanisms intended a
+customization points for users. Typically, they are
+declared in headers that are growing quite large. This is
+not a problem for standard library vendors, who can
+manage their internal file structure to avoid large
+dependencies, but can be a problem for end users who
+have no option but to include these large headers.
+</description>
+<suggestion>
+Move the following traits classes into their own
+headers, and require the existing header to
+#include the traits header to support backwards
+compatibility:<BR/>
+iterator_traits (plus the iterator tag-types)<BR/>
+allocator_traits<BR/>
+pointer_traits<BR/>
+char_traits<BR/>
+regex_traits
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="85" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.2.1
+</section>
+<para>
+Table 34
+</para>
+<description>
+20.2.1 Table 34 "MoveConstructible requirements" says
+"Note: rv remains a valid object. Its state is unspecified".
+Some components give stronger guarantees. For
+example, moved-from shared_ptrs are guaranteed empty
+(20.9.11.2.1/25).
+In general, what the standard really should say (preferably
+as a global blanket statement) is that moved-from objects
+can be destroyed and can be the destination of an
+assignment. Anything else is radioactive. For example,
+containers can be "emptier than empty". This needs to be
+explicit and required generally.<BR/>
+Note: The last time that one of us mentioned "emptier
+than empty" (i.e. containers missing sentinel nodes, etc.)
+the objection was that containers can store sentinel nodes
+inside themselves in order to avoid dynamically allocating
+them. This is unacceptable because (a) it forces existing
+implementations (i.e. Dinkumware's, Microsoft's, IBM's,
+etc.) to change for no good reason (i.e. permitting more
+operations on moved-from objects), and (b) it invalidates
+end iterators when swapping containers. (The Working
+Paper currently permits end iterator invalidation, which we
+consider to be wrong, but that's a separate argument. In
+any event, *mandating* end iterator invalidation is very
+different from permitting it.)
+</description>
+<suggestion>
+State as a general requirement that moved-from
+objects can be destroyed and can be the
+destination of an assignment. Any other use is
+undefined behavior.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="80" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.2.3
+</section>
+<para>
+2
+</para>
+<description>
+See (A) in attachment std_issues.txt
+</description>
+<suggestion>
+as stated in the attached paper
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="10" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.2.3p2
+</section>
+<para>
+20.2.3p2
+</para>
+<description>
+Reads of indeterminate value result in undefined
+behaviour<BR/>
+In 20.2.3p2, NullablePointer requirements
+[nullablepointer.requirements], the standard specifies the
+behaviour of programs that read indeterminate values:<BR/>
+... A default-initialized object of type P may have
+an indeterminate value. [ Note: Operations involving
+indeterminate values may cause undefined behaviour.
+end note ]<BR/>
+We suggest changing the note to:<BR/>
+[ Note: Operations involving indeterminate values
+cause undefined behaviour. end note ]<BR/>
+Rationale: The note uses the word "may", but we believe
+the intention is that such reads will cause undefined
+behaviour, but implementations are not required to
+produce an error.<BR/>
+Clark adds:<BR/>
+> Unfortunately, this issue goes deeper than can be<BR/>
+> addressed by deleting the word "may" from a note in<BR/>
+> clause 20. The term "indeterminate value" and its<BR/>
+> meaning were introduced in C99. While the term is<BR/>
+> generally understood to be applicable to C++ (and<BR/>
+> section 20.2.3 reflects that), the term isn't actually<BR/>
+> defined in the C++ WD, and worse yet, there's no<BR/>
+> statement that use of an indeterminate value can result<BR/>
+> in undefined behavior (so the existing note can't be<BR/>
+> deduced from the normative statements of the<BR/>
+standard).
+> This is tracked by core issue 616. The wording in<BR/>
+> 20.2.3 should be noted as relating to that issue, and<BR/>
+> should be handled as part thereof.<BR/>
+Further on this, in the current draft standard, we can
+construct executions in which an atomic read happensbefore
+the initialization of the atomic object, so there is no
+place to take a read value from. We imagine that such
+reads should also be of indeterminate values and result in
+undefined behaviour?
+</description>
+<suggestion>
+In 20.2.3p2, the standard specifies the behaviour
+of programs that read indeterminate values:<BR/>
+... A default-initialized object of
+type P may have an indeterminate
+value. [ Note: Operations involving<BR/>
+We suggest changing the note to:<BR/>
+[ Note: Operations involving
+indeterminate values cause
+undefined behaviour. end note ]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="86" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.2.5
+</section>
+<para>
+Table 42
+</para>
+<description>
+In the row for
+X::propagate_on_container_move_assignment, the note
+says “copied” when it should say “moved”
+</description>
+<suggestion>
+Change the note as follows:<BR/>
+true_type only if an allocator
+of type X should be <del>copied</del><ins>moved</ins>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="87" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.2.5
+</section>
+<para>
+Table 42
+</para>
+<description>
+reference_type should not have been removed from the
+allocator requirements. Even if it is always the same as
+value_type&, it is an important customization point for
+extensions and future features.
+</description>
+<suggestion>
+Add a row (after value_type) with columns:<BR/>
+Expression: X::reference_type<BR/>
+Return type: T&<BR/>
+Assertion/note...: (empty)<BR/>
+Default: T&<BR/>
+[allocator.traits]: Add reference_type to
+allocator_traits template, defaulted to
+value_type&.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="88" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.2.5
+</section>
+<para></para>
+<description>
+Allocator interface is not backward compatible.
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="89" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3 [utility]
+</section>
+<para></para>
+<description>
+make_pair is missing from the <utility> synopsis.
+</description>
+<suggestion>
+Add template <class T1, class T2> pair<V1, V2>
+make_pair(T1&&, T2&&); to the synopsis in
+[utility].
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="81" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3
+</section>
+<para>
+1
+</para>
+<description>
+make_pair should be declared in the synopsis of <utility>
+</description>
+<suggestion>
+add to 20.3 [utility] paragraph 1:<BR/>
+template<BR/>
+see below make_pair(T1&&, T2&&);
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="82" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3
+</section>
+<para>
+1
+</para>
+<description>
+The <utility> synopsis precedes the tuple_size and
+tuple_element declarations with a comment saying "//
+20.3.5, tuple-like access to pair:" but the sub-clause
+should be 20.3.5.3 and the comment should probably be
+below those declarations (since they, like the tuple
+declaration above them, are defined in <tuple> and are
+not related to pair.)<BR/>
+Also, there should be a comment above
+piecewise_construct_t giving the sub-clause 20.3.5.5, and
+it should be at the end of the synopsis,
+</description>
+<suggestion>
+correct the sub-clause reference for tuple-like
+access to 20.3.5.3, move the comment after the
+uple_element declaration, and add "// defined in
+<tuple>" to the tuple_size and tuple_element
+declarations. Move the piecewise_construct_t and
+piecewise_constrct declarations to the end of the
+synopsis and precede them with "// 20.3.5.5
+Piecewise construction"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="90" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3
+</section>
+<para>
+3
+</para>
+<description>
+In n3090, at variance with previous iterations of the idea
+discussed in papers and incorporated in WDs,
+std::forward is constrained via std::is_convertible, thus is
+not robust wrt access control. This causes problems in
+normal uses as implementation detail of member
+functions. For example, the following snippet leads to a
+compile time failure, whereas that was not the case for an
+implementation along the lines of n2835 (using enable_ifs
+instead of concepts for the constraining, of course)
+<PRE>
+#include <utility>
+struct Base { Base(Base&&); };
+struct Derived
+: private Base
+{
+Derived(Derived&& d)
+: Base(std::forward<Base>(d)) { }
+};
+</PRE>
+In other terms, LWG 1054 can be resolved in a better
+way, the present status is not acceptable.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="28" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.1
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(31)" to "(Clause 31)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="29" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.1
+</section>
+<para>
+4, 6, 8
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(32)" to "(Clause 32)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="30" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.2
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(34)" to "(Table 34)".<BR/>
+Change "(36)" to "(Table 36)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="91" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+Merged with US 90
+</section>
+<para></para>
+<description>
+
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="92" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.3
+</section>
+<para></para>
+<description>
+std::identity was removed from 20.3.3 [forward],
+apparently because std::forward() no longer needs it.
+However, std::identity was useful by itself (to disable
+template argument deduction, and to provide no
+transformation when one is requested).
+</description>
+<suggestion>
+Restore std::identity, possibly in a different
+section.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="93" type="ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.3
+</section>
+<para>
+6
+</para>
+<description>
+When teaching C++0x, students have consistently found
+the name std::move confusing because it doesn't actually
+move the object (it just makes it possible to move). It was
+also confusing for me.
+</description>
+<suggestion>
+Choose a name that expresses the semantics
+more clearly. Suggestion: std::unpin
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="94" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.3
+</section>
+<para>
+9
+</para>
+<description>
+Returns clause for move_if_noexcept d refers to a nonexistent
+symbol, t, which should be x.
+</description>
+<suggestion>
+Modify the Returns clause:<BR/>
+Returns: std::move(<del>t</del><ins>x</ins>).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="15" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.5.2, 20.4.2.1
+</section>
+<para></para>
+<description>
+Several function templates of pair and tuple allow for too
+many implicit conversions, for example:
+<PRE>
+#include <tuple>
+std::tuple<char*> p(0); // Error?
+struct A { explicit A(int){} };
+A a = 1; // Error
+std::tuple<A> ta = std::make_tuple(1); // OK?
+</PRE>
+</description>
+<suggestion>
+Consider to add wording to constrain these
+function templates.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="31" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.5.1
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(section 3.9)" to "(3.9)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="84" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.5.2
+</section>
+<para></para>
+<description>
+[pairs.pair] defines the class template pair as well as
+related non-member functions such as comparison
+operators and make_pair. The related non-member
+functions should be in a separate sub-clause, otherwise
+it's not clear that paragraphs below 17 do not refer to
+members of pair.
+</description>
+<suggestion>
+Create a new "Pair specialized algorithms" section
+containing everything below paragraph 17 in
+[pairs.pair]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="95" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.5.2
+</section>
+<para>
+9
+</para>
+<description>
+Copy-assignment for pair is defaulted and does not work
+for pairs with reference members. This is inconsistent with
+conversion-assignment, which deliberately succeeds even
+if one or both elements are reference types, just as for
+tuple. The copy-assignment operator should be
+consistent with the conversion-assignment operator and
+with tuple's assignment operators.
+</description>
+<suggestion>
+Add to pair synopsis:<BR/>
+pair& operator=(const pair& p);<BR/>
+Add before paragraph 9:<BR/>
+pair& operator=(const pair& p);<BR/>
+Requires: T1 and T2 shall satisfy the
+requirements of CopyAssignable.<BR/>
+Effects: Assigns p.first to first and p.second to
+second.<BR/>
+Returns: *this.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="16" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.5.2, 20.4.2.1
+</section>
+<para></para>
+<description>
+Several pair and tuple functions in regard to move
+operations are incorrectly specified if the member types
+are references, because the result of a std::move cannot
+be assigned to lvalue-references. In this context the usage
+of the requirement sets MoveConstructible and
+CopyConstructible also doesn't make sense, because
+non-const lvalue-references cannot satisfy these
+requirements.
+</description>
+<suggestion>
+Replace the usage of std::move by that of
+std::forward and replace MoveConstructible and
+CopyConstructible requirements by other
+requirements.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="85" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.5.4
+</section>
+<para></para>
+<description>
+While std::pair may happen to hold a pair of iterators
+forming a valid range, this is more likely a coincidence
+than a feature guaranteed by the semantics of the pair
+template. A distinct range-type should be supplied to
+enable the new for-loop syntax rather than overloading an
+existing type with a different semantic.
+</description>
+<suggestion>
+Strike 20.3.5.4 and the matching declarations in
+20.3 header synopsis.
+If a replacement facility is required for C++0x,
+consider n2995.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ES" num="1" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.5.4 [pair.range]
+</section>
+<para></para>
+<description>
+Using pair to represent a range of iterators is too general
+and does not provide additional useful restrictions (see
+N2995 and preceding papers).
+</description>
+<suggestion>
+Provide a separate template range<Iterator>.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="96" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.5.2 20.4.2.1 20.4.2.2
+</section>
+<para>
+p 6-14 p 6-20 p 6-18
+</para>
+<description>
+pair and tuple constructors and assignment operators use
+std::move when they should use std::forward. This
+causes lvalue references to be erroneously converted to
+rvalue references. Related requirements clauses are also
+wrong.
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="97" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.3.5.2 and 20.4.2
+</section>
+<para></para>
+<description>
+pair's class definition in N3092 20.3.5.2 [pairs.pair]
+contains "pair(const pair&) = default;" and "pair&
+operator=(pair&& p);". The latter is described by
+20.3.5.2/12-13.<BR/>
+"pair(const pair&) = default;" is a user-declared explicitlydefaulted
+copy constructor. According to 12.8
+[class.copy]/10, this inhibits the implicitly-declared move
+constructor. pair should be move constructible. (12.8/7
+explains that "pair(pair<U, V>&& p)" will never be
+instantiated to move pair<T1, T2> to pair<T1, T2>.)<BR/>
+"pair& operator=(pair&& p);" is a user-provided move
+assignment operator (according to 8.4.2
+[dcl.fct.def.default]/4: "A special member function is userprovided
+if it is user-declared and not explicitly defaulted
+on its first declaration."). According to 12.8/20, this inhibits
+the implicitly-declared copy assignment operator. pair
+should be copy assignable, and was in C++98/03. (Again,
+12.8/7 explains that "operator=(const pair<U, V>& p)" will
+never be instantiated to copy pair<T1, T2> to pair<T1,
+T2>.)<BR/>
+Additionally, "pair& operator=(pair&& p);" is
+unconditionally defined, whereas according to 12.8/25,
+defaulted copy/move assignment operators are defined as
+deleted in several situations, such as when non-static data
+members of reference type are present.<BR/>
+If "pair(const pair&) = default;" and "pair&
+operator=(pair&& p);" were removed from pair's class
+definition in 20.3.5.2 and from 20.3.5.2/12-13, pair would
+receive implicitly-declared copy/move constructors and
+copy/move assignment operators, and 12.8/25 would
+apply. The implicitly-declared copy/move constructors
+would be trivial when T1 and T2 have trivial copy/move
+constructors, according to 12.8/13, and similarly for the
+assignment operators, according to 12.8/27. Notes could
+be added as a reminder that these functions would be
+implicitly-declared, but such notes would not be necessary
+(the Standard Library specification already assumes a
+high level of familiarity with the Core Language, and
+casual readers will simply assume that pair is copyable
+and movable).<BR/>
+Alternatively, pair could be given explicitly-defaulted
+copy/move constructors and copy/move assignment
+operators. This is a matter of style.<BR/>
+tuple is also affected. tuple's class definition in 20.4.2
+[tuple.tuple] contains:
+<PRE>
+tuple(const tuple&) = default;
+tuple(tuple&&);
+tuple& operator=(const tuple&);
+tuple& operator=(tuple&&);
+</PRE>
+They should all be removed or all be explicitly-defaulted,
+to be consistent with pair. Additionally, 20.4.2.1
+[tuple.cnstr]/8-9 specifies the behavior of an explicitlydefaulted
+function, which is currently inconsistent with
+pair.
+</description>
+<suggestion>
+Either remove "pair(const pair&) = default;" and
+"pair& operator=(pair&& p);" from pair's class
+definition in 20.3.5.2 and from 20.3.5.2/12-13, or
+give pair explicitly-defaulted copy/move
+constructors and copy/move assignment
+operators.<BR/>
+Change tuple to match.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="86" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.4
+</section>
+<para></para>
+<description>
+tuple and pair are essentially two implementations of the
+same type, with the same public interface, and their
+specification in becoming increasingly intertwined. The
+tuple library should be merged into the <utility> header to
+reduce library dependencies and simplify user
+expectations. The <tuple> header could optionally be
+retained as a deprecated alias to the <utility> header.
+</description>
+<suggestion>
+Merge everything declared in 20.4 into the
+<utility> header. Either remove the <tuple> header
+entirely, or move it to Annex D as a deprecated
+alias of the <utility> header.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="98" type="te/ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.4.2.4
+</section>
+<para>
+Paragraph 4
+</para>
+<description>
+pack_arguments is poorly named. It does not reflect the
+fact that it is a tuple creation function and that it forwards
+arguments.
+</description>
+<suggestion>
+Rename pack_arguments to forward_as_tuple
+throughout the standard.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="88" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.4.2.4
+</section>
+<para></para>
+<description>
+The tuple_cat template consists of four overloads and that
+can concatenate only two tuples. A single variadic
+signature that can concatenate an arbitrary number of
+tuples would be preferred.
+</description>
+<suggestion>
+Adopt a simplified form of the proposal in n2795,
+restricted to tuples and neither requiring nor
+outlawing support for other tuple-like types.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="99" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.4.2.4
+</section>
+<para>
+4 - 6
+</para>
+<description>
+pack_arguments is overly complex.
+</description>
+<suggestion>
+This issue resulted from a lack of understanding of
+how references are forwarded. The definition of
+pack_arguments should be simply:<BR/>
+template <class... Types>
+tuple<<del>A</del>Types<ins>&&</ins>>
+pack_arguments(Types&&...t);<BR/>
+<del>Types:Let Ti be each type in Types....</del><BR/>
+Effects: ...<BR/>
+Returns:<BR/>
+tuple<<del>A</del>Types<ins>&&</ins>...>(std::forward<Types>(t)...)<BR/>
+The synopsis should also change to reflect this
+simpler signature.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="87" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.4.2.10
+</section>
+<para></para>
+<description>
+There is no compelling reason to assume a
+heterogeneous tuple of two elements holds a pair of
+iterators forming a valid range. Unlike std::pair, there are
+no functions in the standard library using this as a return
+type with a valid range, so there is even less reason to try
+to adapt this type for the new for-loop syntax.
+</description>
+<suggestion>
+Strike 20.4.2.10 and the matching declarations in
+the header synopsis in 20.4.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="100" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.6.1 [ratio.ratio]
+</section>
+<para></para>
+<description>
+LWG 1281 was discussed in Pittsburgh, and the decision
+there was to accept the typedef as proposed and move to
+Review. Unfortunately the issue was accidentally applied
+to the FCD, and incorrectly. The FCD version of the
+typedef refers to ratio<N, D>, but the typedef is intended
+to refer to ratio<num, den> which in general is not the
+same type.
+</description>
+<suggestion>
+Accept the current proposed wording of LWG
+1281 which adds:<BR/>
+typedef ratio<num, den> type;
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="89" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.6.2
+</section>
+<para></para>
+<description>
+The alias representations of the ratio arithmetic templates
+do not allow implementations to avoid overflow, since they
+explicitly specify the form of the aliased template
+instantiation. For example
+ratio_multiply,ratio<2,LLONG_MAX>> is *required* to
+alias ratio<2*LLONG_MAX,LLONG_MAX*2>, which
+overflows, so is ill-formed. However, this is trivially equal
+to ratio<1,1>. It also contradicts the opening statement of
+20.6.2p1 "implementations may use other algorithms to
+compute these values".
+</description>
+<suggestion>
+Change the wording in 20.6.2p2-5 as follows:<BR/>
+template <class R1, class R2> using ratio_add =
+see below;<BR/>
+The type ratio_add<R1, R2> shall be a synonym
+for
+<del>ratio<T1,T2></del> <ins>ratio<U, V> such
+that ratio<U,V>::num and
+ratio<U,V>::den are the same as the
+corresponding members of
+ratio<T1,T2> would be in the absence of
+arithmetic overflow</ins>
+where T1 has the value R1::num * R2::den +
+R2::num * R1::den and T2
+has the value R1::den * R2::den. <ins>If the
+required values of
+ratio<U,V>::num and ratio<U,V>::den cannot be
+represented in intmax_t
+then the program is illformed.</ins><BR/>
+template <class R1, class R2> using
+ratio_subtract = see below;<BR/>
+The type ratio_subtract<R1, R2> shall be a
+synonym for
+<del>ratio<T1,T2></del> <ins>ratio<U, V> such
+that ratio<U,V>::num and
+ratio<U,V>::den are the same as the
+corresponding members of
+ratio<T1,T2> would be in the absence of
+arithmetic overflow</ins>
+where T1 has the value R1::num * R2::den -
+R2::num * R1::den and T2
+has the value R1::den * R2::den. <ins>If the
+required values of
+ratio<U,V>::num and ratio<U,V>::den cannot be
+represented in intmax_t
+then the program is illformed.</ins><BR/>
+template <class R1, class R2> using ratio_multiply
+= see below;<BR/>
+The type ratio_multiply<R1, R2> shall be a
+synonym for
+<del>ratio<T1,T2></del> <ins>ratio<U, V> such
+that ratio<U,V>::num and
+ratio<U,V>::den are the same as the
+corresponding members of
+ratio<T1,T2> would be in the absence of
+arithmetic overflow</ins>
+where T1 has the value R1::num * R2::num and
+T2 has the value R1::den
+* R2::den. <ins>If the required values of
+ratio<U,V>::num and
+ratio<U,V>::den cannot be represented in
+intmax_t then the program is
+illformed.</ins><BR/>
+template <class R1, class R2> using ratio_divide
+= see below;<BR/>
+The type ratio_divide<R1, R2> shall be a
+synonym for
+<del>ratio<T1,T2></del> <ins>ratio<U, V> such
+that ratio<U,V>::num and
+ratio<U,V>::den are the same as the
+corresponding members of
+ratio<T1,T2> would be in the absence of
+arithmetic overflow</ins>
+where T1 has the value R1::num * R2::den and T2
+has the value R1::den
+* R2::num. <ins>If the required values of
+ratio<U,V>::num and
+ratio<U,V>::den cannot be represented in
+intmax_t then the program is
+illformed.</ins>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="101" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7
+</section>
+<para></para>
+<description>
+Paper n2965 was largely rejected after the last CD on the
+grounds there was no associated national body comment,
+so I am submitting a national body comment this time.
+</description>
+<suggestion>
+Consider n2965 in the context of a national body
+comment.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="90" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7
+</section>
+<para></para>
+<description>
+type_traits is a core support facility offered by the
+compiler, and exposed with a library interface that is
+required in a free-standing implementation. It has far more
+in common with numeric_limits than the utility components
+in clause 20, and should move to clause 18.
+</description>
+<suggestion>
+Move clause 20.7 into clause 18.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="17" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7
+</section>
+<para></para>
+<description>
+Speculative compilation for std::is_constructible and
+std::is_convertible should be limited, similar to the core
+language (see 14.8.2 paragraph 8).
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="18" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7
+</section>
+<para></para>
+<description>
+Several type traits require compiler support, e.g.
+std::is_constructible or std::is_convertible. Their current
+specification seems to imply, that the corresponding test
+expressions should be well-formed, even in absense of
+access:
+<PRE>
+class X { X(int){} };
+constexpr bool test = std::is_constructible<X, int>::value;
+</PRE>
+The specification does not clarify the context of this test
+and because it already goes beyond normal language
+rules, it's hard to argue by means of normal language
+rules what the context and outcome of the test should be.
+</description>
+<suggestion>
+Specify that std::is_constructible and
+std::is_convertible will return true only for public
+constructors/conversion functions.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="102" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7.4
+</section>
+<para></para>
+<description>
+Despite Library Issue 520's ("Result_of and pointers to
+data members") resolution of CD1, the FCD's result_of
+supports neither pointers to member functions nor
+pointers to data members. It should.
+</description>
+<suggestion>
+Ensure result_of supports pointers to member
+functions and pointers to data members.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="91" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7.4.3
+</section>
+<para>
+Table 45
+</para>
+<description>
+It is mildly distasteful to dereference a null pointer as part
+of our specification, as we are playing on the edges of
+undefined behaviour. With the addition of the declval
+function template, already used in these same
+expressions, this is no longer necessary.
+</description>
+<suggestion>
+Replace the sub-expression '*(U*)0' with the subexpression
+'declval<U&>()' in the specification for
+has_nothrow_copy_assign and
+has_nothrow_move_assign type traits.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="92" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7.4.3
+</section>
+<para>
+Table 45
+</para>
+<description>
+Trivial functions implicitly declare a noexcept exception
+specification, so the references to has_trivial_* traits in the
+has_nothrow_* traits are redundant, and should be struck
+for clarity.
+</description>
+<suggestion>
+For each of the has_nothrow_something traits,
+remove all references to the matching
+has_trivial_something traits.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="18" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7.4.3, Table 45 (Type property predicates)
+</section>
+<para></para>
+<description>
+Related to the change proposed in FI 17, there should be
+a trait for checking whether a destructor throws.
+</description>
+<suggestion>
+Add the following type predicate:
+Template
+<PRE>
+template <typename T> struct
+has_nothrow_destructor;
+</PRE>
+Condition<BR/>
+has_trivial_destructor<T>::value is true or the
+expression
+noexcept((*(U*)0).~U()) is well-formed and true,
+where U is
+remove_all_extents<T>::type.<BR/>
+Precondition<BR/>
+T shall be a complete type, (possibly cv-qualified)
+void, or an array of
+unknown bound.<BR/>
+Reasoning:<BR/>
+With this metafunction the destructor of a class
+template can adjust its
+noexcept specification depending on whether
+destructors of its unbound
+members (or unbound base classes) might throw:
+<PRE>
+template <typename T>
+struct C
+{
+T t;
+~C()
+noexcept(has_nothrow_destructor<T>::value) {}
+};
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="19" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7.4.3
+</section>
+<para></para>
+<description>
+The fundamental trait is_constructible reports false
+positives, e.g.
+<PRE>
+is_constructible<char*, void*>::value
+</PRE>
+evaluates to true, even though a corresponding variable
+initialization would be ill-formed.
+</description>
+<suggestion>
+Remove all false positives from the domain of
+is_constructible.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="32" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7.5
+</section>
+<para>
+2, table 47
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(10)" to "(Clause 10)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="93" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7.6.2
+</section>
+<para>
+Table 49
+</para>
+<description>
+The comments for add_rvalue_reference say "this rule
+reflects the semantics of reference collapsing", but
+reference collapsing is not defined anywhere.
+</description>
+<suggestion>
+Add a new sentence at the end of 8.3.2p6 "This is
+called reference collapsing".
+Add a reference to 8.3.2 to the use of "reference
+collapsing" in 20.7.6.2/table 49
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="103" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.7.6.6 [meta.trans.other]
+</section>
+<para></para>
+<description>
+The current definition of result_of works for function
+pointers but the condition statement outlaws them. There
+is even an example in the WP that shows result_of
+working for function pointers.
+</description>
+<suggestion>
+Add “pointer to function” to the list of things that
+Fn shall be.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="104" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.8
+</section>
+<para></para>
+<description>
+std::basic_regex should have an allocator for all the
+reasons that a std::string does. For example, I can use
+boost::interprocess to put a string or vector in shared
+memory, but not a regex.
+</description>
+<suggestion>
+Add allocators to regexes
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="94" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8
+</section>
+<para></para>
+<description>
+This subclause has grown large, with many components,
+and so should stand alone.
+</description>
+<suggestion>
+Promote 20.8 and all its contents up to a new
+numbered clause.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="95" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8
+</section>
+<para></para>
+<description>
+The adaptable function protocol supported by
+unary_function/binary_function has been superceded by
+lambda expressions and std::bind. Despite the name, the
+protocol is not very adaptable as it requires intrusive
+support in the adaptable types, rather than offering an
+external traits-like adaption mechanism. This protocol and
+related support functions should be deprecated, and we
+should not make onerous requirements for the
+specification to support this protocol for callable types
+introduced in this standard revision, including those
+adopted from TR1. It is expected that high-quality
+implementations will provide such support, but we should
+not have to write robust standard specifications mixing this
+restricted support with more general components such as
+function, bind and reference_wrapper.
+</description>
+<suggestion>
+Move clauses 20.8.3, 20.8.9, 20.8.11 and 20.8.12
+to Annex D. Remove the requirements to
+conditionally derive from unary/binary_function
+from function, reference_wrapper, and the results
+of calling mem_fn and bind.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="96" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8
+</section>
+<para></para>
+<description>
+The function templates 'hash', 'less' and 'equal_to' are
+important customization points for user-defined types to
+be supported by several standard containers. These are
+accessed through the <functional> header which has
+grown significantly larger in C++0x, exposing many more
+facilities than a user is likely to need through there own
+header, simply to declare the necessary specialization.
+There should be a smaller header available for users to
+make the necessary customization.
+</description>
+<suggestion>
+Provide a tiny forwarding header for important
+functor types in the <functional> header that a
+user may want to specialize. This should contain
+the template declaration for 'equal_to', 'hash' and
+'less'.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="97" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8.10
+</section>
+<para></para>
+<description>
+The bind template is intended as a singe, simple to use
+replacement for the '98 adaptable function APIs and
+machinery. It works well in almost all respects, but lacks
+the ability to easily negate a predicate, or equivalently, act
+as a replacement for not1 and not2. Two easy ways to
+solve this omission would be to add a 'bind_not' function
+that produces a binder that negates its result. However,
+preference is given to requiring the unspecified bind result
+type to overload operator! to produce the same effect.
+This is preferred due to (i) its simpler usage, being the
+naively expected syntax, but more importantly (ii) some
+(limited) field experience.
+</description>
+<suggestion>
+Require the unspecified result of a bind
+expression to support unary operator! to yield
+another bind result that, when evaluated, yields
+'!res', where 'res' is the result of evaluating the
+original function.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="3" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8.14.2
+</section>
+<para></para>
+<description>
+explicit default contructor is defined in std::function.
+Although it is allowed according to 12.3.1, it seems
+unnecessary to qualify the constructor as explicit.
+If it is explicit, there will be a limitation in initializer_list.
+</description>
+<suggestion>
+Remove explicit.
+<PRE>
+namespace std {
+template<class> class function;
+// undefined
+template<class R, class... ArgTypes>
+class function<R(ArgTypes...)>
+: public unary_function<T1, R>
+// iff sizeof...(ArgTypes) == 1 and ArgTypes
+contains T1
+: public binary_function<T1, T2, R>
+// iff sizeof...(ArgTypes) == 2 and ArgTypes
+contains T1 andT2
+{
+public:typedef R result_type;
+// 20.8.14.2.1, construct/copy/destroy:function();
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="33" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8.15
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(37)" to "(Table 37)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="34" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8.15
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(33)" to "(Table 33)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="4" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8.14.2.1
+</section>
+<para>
+1
+</para>
+<description>
+Really does the function require that default constructor is
+explicit?
+</description>
+<suggestion>
+Remove explicit.
+<PRE>
+function();
+template <class A>
+function(allocator_arg_t, const A& a);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="105" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.8.15.2
+</section>
+<para></para>
+<description>
+unique_ptr and shared_ptr are inconsistent in their
+handling of arrays. We can write:
+<PRE>
+unique_ptr<int[]> p( new int[10] );
+// handles deletion correctly
+</PRE>
+But we cannot write:
+<PRE>
+shared_ptr<int[]> p( new int[10] );
+// incorrect
+</PRE>
+This is an inconsistency. It is true that we have the
+following workaround:
+<PRE>
+std::shared_ptr<int> s(new int[5],
+std::default_delete<int[]>());
+</PRE>
+But this is still inconsistent, not to mention awkward and
+error-prone because the programmer will occasionally
+forget the deleter and the code will silently compile and
+may appear to work on some platforms.
+</description>
+<suggestion>
+Support:
+<PRE>
+shared_ptr<int[]> p( new int[10] );
+</PRE>
+to handle deletion correctly by calling delete[] on
+the stored pointer.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="98" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9
+</section>
+<para></para>
+<description>
+This subclause has grown large, with many components,
+and so should stand alone.
+</description>
+<suggestion>
+Promote 20.9 and all of its contents to a new, toplevel,
+numbered clause.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="99" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9
+</section>
+<para>
+1
+</para>
+<description>
+One reason that the unique_ptr constructor taking a
+nullptr_t argument is not explicit is to allow conversion of
+nullptr to unique_ptr in contexts like equality comparison.
+Unfortunately operator== for unique_ptr is a little more
+clever than that, deducing template parameters for both
+arguments. This means that nullptr does not get deduced
+as unique_ptr type, and there are no other comparison
+functions to match.
+</description>
+<suggestion>
+Add the following signatures to 20.9p1, <memory>
+header synopsis:
+<PRE>
+template<typename T, typename D> bool
+operator==(const unique_ptr<T, D> & lhs,
+nullptr_t);
+template<typename T, typename D> bool
+operator==(nullptr_t, const unique_ptr<T, D> &
+rhs);
+template<typename T, typename D> bool
+operator!=(const unique_ptr<T, D> & lhs,
+nullptr_t);
+template<typename T, typename D> bool
+operator!=(nullptr_t, const unique_ptr<T, D> &
+rhs);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="100" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9
+</section>
+<para></para>
+<description>
+The unique_ptr and shared_ptr constructors taking
+nullptr_t delegate to a constexpr constructor, and could be
+constexpr themselves.
+</description>
+<suggestion>
+In the 20.9.10.2 [unique.ptr.single] synopsis add
+"constexpr" to unique_ptr(nullptr_t).<BR/>
+In the 20.9.10.3 [unique.ptr.runtime] synopsis add
+"constexpr" to unique_ptr(nullptr_t).<BR/>
+In the 20.9.11.2 [util.smartptr.shared] synopsis
+add "constexpr" to shared_ptr(nullptr_t).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="85" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.1
+</section>
+<para></para>
+<description>
+There are inconsistent definitions for allocator_arg.
+In 20.9 [memory] paragraph 1,
+<PRE>
+constexpr allocator_arg_t allocator_arg =
+allocator_arg_t();
+</PRE>
+and in 20.9.1,
+<PRE>
+const allocator_arg_t allocator_arg = allocator_arg_t();
+</PRE>
+</description>
+<suggestion>
+Change "const" to "constexpr" in 20.9.1 as
+follows.
+<PRE>
+constexpr allocator_arg_t allocator_arg =
+allocator_arg_t();
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="106" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.3
+</section>
+<para>
+all
+</para>
+<description>
+pointer_traits should have a size_type member for
+completeness.
+</description>
+<suggestion>
+Add “typedef see below size_type;” to the generic
+pointer_traits template and “typedef size_t
+size_type;” to pointer_traits<T*>. Use
+pointer_traits::size_type and
+pointer_traits::difference_type as the defaults for
+allocator_traits::size_type and
+allocator_traits::difference_type.<BR/>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="104" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.5.1
+</section>
+<para>
+13
+</para>
+<description>
+The ~ is missing from the invokation of the destructor of
+U.
+</description>
+<suggestion>
+Add the missing ~ : Effects: p->~U()
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="105" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.6
+</section>
+<para>
+1
+</para>
+<description>
+There is a missing '_' in the piecewise-construct call for
+pair in the class definition.
+</description>
+<suggestion>
+Fix the declaration:
+<PRE>
+template <class T1, class T2, class... Args1,
+class... Args2> void construct(pair<T1, T2>* p,
+piecewise_construct_t, tuple<Args1...> x,
+tuple<Args2...> y);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="107" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.6
+</section>
+<para></para>
+<description>
+scoped_allocator_adaptor should have its own header.
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="101" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.10
+</section>
+<para>
+5
+</para>
+<description>
+The first sentence of the paragraph says "Each object of a
+type U instantiated form the unique_ptr template..." "form"
+should be "from"
+</description>
+<suggestion>
+Replace "form" with "from" in the opening
+sentence:
+"Each object of a type U instantiated from the
+unique_ptr template..."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="13" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.10.
+</section>
+<para>
+5
+</para>
+<description>
+typo
+</description>
+<suggestion>
+"form the unique_ptr" should be "from the
+unique_ptr."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="102" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.10
+</section>
+<para></para>
+<description>
+unique_ptr is a smart pointer so [unique.ptr] should be a
+sub-clause of [util.smartptr]
+</description>
+<suggestion>
+move [unique.ptr] to a sub-clause of [util.smartptr]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="35" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.10.2
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(38)" to "(Table 38)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="36" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.10.2.1
+</section>
+<para>
+1, 6
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(33)" to "(Table 33)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="37" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.10.2.1
+</section>
+<para>
+18
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(34)" to "(Table 34)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="38" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.10.2.3
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(36)" to "(Table 36)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="5" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.11.2
+</section>
+<para>
+1
+</para>
+<description>
+Hash support based on ownership sharing should be
+supplied for shared_ptr and weak_ptr.
+For two shared_ptr objects p and q, two distinct
+equivalence relations can be defined. One is based on
+equivalence of pointer values, which is derived from the
+expression p.get() == q.get() (hereafter called addressbased
+equivalence relation), the other is based on
+equivalence of ownership sharing, which is derived from
+the expression !p.owner_before(q) && !q.owner_before(p)
+(hereafter called ownership-based equivalence relation).
+These two equivalence relations are independent in
+general. For example, a shared_ptr object created by the
+constructor of the signature shared_ptr(shared_ptr<U>
+const &, T *) could reveal a difference between these two
+relations. Therefore, hash support based on each
+equivalence relation should be supplied for shared_ptr.
+However, while the standard library provides the hash
+support for address-based one (20.9.11.6 paragraph 2), it
+lacks the hash support for ownership-based one. In
+addition, associative containers work well in combination
+with the shared_ptr's ownership-based comparison but
+unordered associative containers don't. This is
+inconsistent.>BR/>
+For the case of weak_ptr, hash support for the ownershipbased
+equivalence relation can be safely defined on
+weak_ptrs, and even on expired ones. The absence of
+hash support for the ownership-based equivalence
+relation is fatal, especially for expired weak_ptrs. And the
+absence of such hash support precludes some quite
+effective use-cases, e.g. erasing the unordered_map entry
+of an expired weak_ptr key from a customized deleter
+supplied to shared_ptrs.<BR/>
+Hash support for the ownership-based equivalence
+relation cannot be provided by any user-defined manner
+because information about ownership sharing is not
+available to users at all. Therefore, the only way to provide
+ownership-based hash support is to offer it intrusively by
+the standard library.<BR/>
+As far as we know, such hash support is implementable.
+Typical implementation of such hash function could return
+the hash value of the pointer of the counter object that is
+internally managed by shared_ptr and weak_ptr.
+</description>
+<suggestion>
+Add the following non-static member functions to
+shared_ptr and weak_ptr class template;
+<PRE>
+// 20.9.11.2 paragraph 1
+namespace std{
+template<class T> class shared_ptr {
+public:
+...
+size_t owner_hash() const;
+...
+};
+}
+// 20.9.11.3 paragraph 1
+namespace std{
+template<class T> class weak_ptr {
+public:
+...
+size_t owner_hash() const;
+...
+};
+}
+</PRE>
+These functions satisfy the following
+requirements. Let p and q be objects of either
+shared_ptr or weak_ptr, H be a hypothetical
+function object type that satisfies the hash
+requirements (20.2.4) and h be an object of the
+type H. The expression p.owner_hash() behaves
+as if it were equivalent to the expression h(p). In
+addition, h(p) == h(q) must become true if p and q
+share ownership.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="20" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.11.2
+</section>
+<para>
+p4
+</para>
+<description>
+Requiring shared_ptr and weak_ptr to always synchronize
+the use count makes it potentially slow and is inconsistent
+with the general approach to leave the synchronization to
+the user of a facility.
+</description>
+<suggestion>
+Strike 'not' from 'Changes in use_count() do not
+reflect modifications that can introduce data
+races.' Possibly add additional synchronized
+constructors and assignments.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="108" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.11.2.1 [util.smartptr.shared.const]
+</section>
+<para></para>
+<description>
+shared_ptr should have the same policy for constructing
+from auto_ptr as unique_ptr. Currently it does not.
+</description>
+<suggestion>
+Add “template <class Y> explicit
+shared_ptr(auto_ptr<Y>&); to
+[util.smartptr.shared.const] (and to the synopsis).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="109" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.11.2.6
+</section>
+<para></para>
+<description>
+20.9.11.2.6 [util.smartptr.shared.create]/2 says: "the
+placement new expression ::new (pv) T() or ::new (pv)
+T(std::forward<Args>(args)...)". It should simply say "the
+placement new expression ::new (pv)
+T(std::forward<Args>(args)...)", because empty parameter
+packs expand to nothing. This would be consistent with
+the requirements in paragraph 1.
+</description>
+<suggestion>
+Change<BR/>
+"the placement new expression ::new (pv) T() or
+::new (pv) T(std::forward<Args>(args)...)"<BR/>
+to<BR/>
+"the placement new expression ::new (pv)
+T(std::forward<Args>(args)...)"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="103" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.9.12
+</section>
+<para>
+12
+</para>
+<description>
+The precondition to calling declare_no_pointers is that no
+bytes in the range "have been previously registered" with
+this call. As written, this precondition includes bytes in
+ranges, even after they have been explicitly unregistered
+with a later call to 'undeclare_no_pointers'.
+</description>
+<suggestion>
+Replace "have been previously registered" with
+"are currently registered"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="106" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.10.3
+</section>
+<para></para>
+<description>
+duration is an arithmetic type, unlike time_point, and so
+should provide a specialization of numeric_limits.
+</description>
+<suggestion>
+Add a declaration of a partial specialization of
+numeric_limits for duration to the header synopsis
+in 20.10.<BR/>
+Add 20.3.8 [time.duration.limits]
+"duration is an arithmetic type, and so provides an
+appropriate specialization of numeric_limits."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="110" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.10.5
+</section>
+<para></para>
+<description>
+Significant parts of the clock section are "unspecified",
+rather than "implementation-defined".
+</description>
+<suggestion>
+Make those parts "implementation-defined".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="111" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.10.5.2
+</section>
+<para>
+para 1
+</para>
+<description>
+What it means for monotonic_clock to be a synonym is
+undefined. If it may or may not be a typedef, then certain
+classes of programs become unportable.
+</description>
+<suggestion>
+Require that it be a distinct class type.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="107" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.10.5.2
+</section>
+<para>
+2
+</para>
+<description>
+1.4p9 states that which conditionally supported constructs
+are available should be provided in the documentation for
+the implementation. This doesn't help programmers trying
+to write portable code, as they must then rely on
+implementation-specific means to determine the
+availability of such constructs. In particular, the presence
+or absence of std::chrono::monotonic_clock may require
+different code paths to be selected. This is the only
+conditionally-supported library facility, and differs from the
+conditionally-supported language facilities in that it has
+standard-defined semantics rather than implementationdefined
+semantics.
+</description>
+<suggestion>
+Provide feature test macro for determining the
+presence of std::chrono::monotonic_clock. Add
+_STDCPP_HAS_MONOTONIC_CLOCK to the
+<chrono> header, which is defined if
+monotonic_clock is present, and not defined if it is
+not present.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="20" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.10.5.2
+</section>
+<para></para>
+<description>
+The library component monotonic_clock is conditionally
+supported, but no compile-time flag exists that allows
+user-code to query its existence. Further-on there exist no
+portable means to simulate such a query. (To do so, user
+code would be required to add types to namespace
+std::chrono.)
+</description>
+<suggestion>
+Provide a compile-time flag (preferably a macro)
+that can be used to query the existence of
+monotonic_clock.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="21" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.10.5.2
+</section>
+<para>
+p2
+</para>
+<description>
+Monotonic clocks are generally easy to provide on all
+systems and are implicitely required by some of the library
+facilities anyway.
+</description>
+<suggestion>
+Make monotonic clocks mandatory, i.e. remove
+p2. Also change 30.2.4p2 accordingly.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="112" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+20.10.5.3
+</section>
+<para>
+para 1
+</para>
+<description>
+What it means for high_resolution_clock to be a synonym
+is undefined. If it may or may not be a typedef, then
+certain classes of programs become unportable.
+</description>
+<suggestion>
+Require that it be a distinct class type.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="39" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+21.2.2
+</section>
+<para>
+4
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(35)" to "(Table 35)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="108" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+21.2.3.1
+</section>
+<para>
+2,3
+</para>
+<description>
+The definition of streamoff/streampos defers to the
+definition of off_type and pos_type in 21.2.2, which defers
+back to 27.2.2 for the definition of streamoff/streampos.
+The actual definition appears to be supplied in 27.3, the
+synopsis of <iosfwd>.
+</description>
+<suggestion>
+Update the reference in 21.2.3.1 to refer forward
+to 27.2.2, rather than back to 21.2.2.
+Add a cross-reference to from 27.2.2 to 27.3.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="109" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+21.2.3.2/3/4
+</section>
+<para></para>
+<description>
+It is not clear what the specification means for
+u16streampos, u32streampos or wstreampos when they
+refer to the requirements for POS_T in 21.2.2, as there
+are no longer any such requirements. Similarly the annex
+D.7 refers to the requirements of type POS_T in 27.3 that
+no longer exist either.
+</description>
+<suggestion>
+Clarify the meaning of all cross-reference to the
+removed type POS_T.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="40" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+21.4
+</section>
+<para>
+3
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(96)" to "(Table 96)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="110" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+21.4.7.1
+</section>
+<para></para>
+<description>
+data() is the function of choice for calling into legacy 'C'-
+like APIs. Both vector and array designed this function to
+be callable in a const-correct way while allowing for
+functions that want to use the result to designate a return
+buffer.
+</description>
+<suggestion>
+Add the following overload to basic_string data():
+<PRE>
+charT * data();
+</PRE>
+Relax the requirement that programs do not alter
+values in the array through the pointe retrieved
+through this new overload.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="111" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+21.5
+</section>
+<para></para>
+<description>
+Section 17.6.4.8, Data Race Avoidance, requires the C++
+Standard Library to avoid data races that might otherwise
+result from two threads making calls to C++ Standard
+Library functions on distinct objects. The C standard
+library is part of the C++ Standard Library and some C++
+Standary library functions (parts of the Localization library,
+as well as Numeric Conversions in 21.5), are specified to
+make use of the C standard library. Therefore, the C++
+standard indirectly imposes a requirement on the thread
+safety of the C standard library. However, since the C
+standard does not address the concept of thread safety
+conforming C implementations exist that do no provide
+such guarantees. This conflict needs to be reconciled.
+</description>
+<suggestion>
+remove the requirement to make use of strtol()
+and sprintf() since these functions depend on the
+global C locale and thus cannot be made thread
+safe.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="86" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+21.7
+</section>
+<para>
+1
+</para>
+<description>
+Table numbers are listed incorrectly. "74,75. and" should
+be "74, 75, and".
+</description>
+<suggestion>
+Correct typo as follows.<BR/>
+Tables 71, 72, 73, 74, 75, and 76 describe
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="87" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+22.3.1
+</section>
+<para></para>
+<description>
+While usage of "traits" and "Traits" are explained in 21.2
+as template parameters and arguments respectively,
+specifying "Traits" as template parameter seems misuse.
+template <class charT, class Traits, class Allocator>
+bool operator()(const
+basic_string<charT,Traits,Allocator>& s1,
+const basic_string<charT,Traits,Allocator>& s2) const;
+</description>
+<suggestion>
+Change "Traits" to "traits" in three places.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="88" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+22.6
+</section>
+<para>
+3, Table 91
+</para>
+<description>
+Typo, duplicated "ispunct" and missing "iswpunct".
+</description>
+<suggestion>
+Correct as follows.<BR/>
+isprint<BR/>
+ispunct<BR/>
+isspace<BR/>
+:<BR/>
+iswprint<BR/>
+iswpunct<BR/>
+iswspace
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="89" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.1
+</section>
+<para>
+2, Table 92
+</para>
+<description>
+Typo, "<forwardlist>" should be "<forward_list>".
+</description>
+<suggestion>
+Correct typo.
+<forward_list>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="113" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2
+</section>
+<para>
+5
+</para>
+<description>
+Resolve LWG 579 one way or the other, but preferably in
+the direction of changing the two erase overloads to return
+void.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="114" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.1
+</section>
+<para>
+Paragraph 9
+</para>
+<description>
+Requirements on iterators swapping allegiance would
+disallow the small-string optimization.
+</description>
+<suggestion>
+Add an exclusion for basic_string to the sentence
+beginning “Every iterator referring to an
+element...”. Add a sentence to 21.4.6.8/2 saying
+that iterators and references to string elements
+remain valid, but it is not specified whether they
+refer to the same string or the other string.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="21" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.1, 23.3.3.4
+</section>
+<para></para>
+<description>
+23.2.1/11 provides a general no-throw guarantee for
+erase() container functions, exceptions from this are
+explicitly mentioned for individual containers. Because of
+its different name, forward_list's erase_after() function is
+not ruled by this but should so.
+</description>
+<suggestion>
+Add a "Throws: Nothing" clause to both
+erase_after overloads in 23.3.3.4.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="115" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.1
+</section>
+<para>
+Paragraph 15
+</para>
+<description>
+The terms CopyConstructible, MoveConstructible, and
+constructible from are redefined, then used inconsistently
+and often incorrectly within the section. New terms should
+have been introduced and used correctly.
+</description>
+<suggestion>
+Better terms would be X can copy-insert T, X can
+move-insert T, and X can construct-insert T with
+args. See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="116" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.1
+</section>
+<para>
+Table 96
+</para>
+<description>
+The requirement for X(rv) that move construction of the
+allocator not throw can be misread as requiring that move
+construction of the whole container not throw.
+</description>
+<suggestion>
+Add non-normative note:<BR/>
+Requires: move construction of A shall not exit via
+an exception. <ins>[Note: This requirement on
+allocators exists so that implementations can
+(optionally) provide a nothrow guarantee on move
+construction of some containers. end note]</ins>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="12" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.3 [sequence.reqmts]
+</section>
+<para>
+Table 97 Sequence container requirements (in addition to container)
+</para>
+<description>
+The requirement for insert says: “Requires:T shall be
+CopyConstructible. For vector and deque, T shall also be
+CopyAssignable.”. Why must T be CopyAssignable? Is it
+for cases where the object may be already constructed
+and insert will first copy the existing data out of the way
+and assign to an existing object? Can't such an
+implementation do the same with placement-new?
+</description>
+<suggestion>
+CopyAssignable seems like an overly strict
+requirement for insert, exposing implementation
+details in the specification. If such implementation
+details are achievable without assignment, eg.
+with placement-new, the CopyAssignable
+requirement should be removed.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="90" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.3
+</section>
+<para>
+17, Table 98
+</para>
+<description>
+In Operational semantics for "a.emplace_front(args)",
+<Arg> should be <Args>.
+Prepends an object of type T
+constructed with
+std::forward<Arg>(args)...."
+</description>
+<suggestion>
+Change <Arg> to <Args>.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="91" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.5
+</section>
+<para>
+10, Table 100
+</para>
+<description>
+Typo, unnecessary new-line.
+a_uniq.<BR/>
+emplace(args)<BR/>
+Typo, unnecessary space.
+a_eq. emplace(args)
+</description>
+<suggestion>
+Remove space characters between "." and
+"emplace" same as other word wrapped columns
+in the table.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="92" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.5
+</section>
+<para>
+11
+</para>
+<description>
+Typo, "unodified" should be "unmodified".
+</description>
+<suggestion>
+Correct typo.
+unmodified
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ES" num="2" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.2.5 [unord.req], Table 100 (Unordered associative container requirements (in addition to container))
+</section>
+<para>
+Row for expression a.erase(q)
+</para>
+<description>
+The expression is required to return the iterator
+immediately following <TT>q</TT> prior to the erasure. As explained
+in N2023, this requirement makes it impossible to achieve
+average O(1) complexity for unordered associative
+containers implemented with singly linked lists. This has a
+theoretical as well as a practical impact, as reported by
+users of early implementations of these containers.
+Discussions among committee members have not found
+any way of remedying this deficiency (other than
+acknowledging it) by some smart modification of usual
+singly linked lists implementations.
+</description>
+<suggestion>
+Change the return type of the expression from
+<TT>iterator</TT> to <TT>void</TT>. Eliminate the sentence
+“Return value is the iterator immediately following
+<TT>q</TT> prior to the erasure”. Change accordingly the
+appearances of “<TT>iterator
+erase(const_iterator position)</TT>” in
+23.5.1, 23.5.2, 23.5.3 and 23.5.4.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="112" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.1.7
+</section>
+<para>
+p3
+</para>
+<description>
+Should the effect of calling front/back on a zero sized
+array really be implementation defined i.e. require the
+implementor to define behaviour?
+</description>
+<suggestion>
+Change "implementation defined" to "undefined"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="113" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.2.2
+</section>
+<para>
+p1
+</para>
+<description>
+There is no mention of what happens if sz==size(). While
+it obviously does nothing I feel a standard needs to say
+this explicitely.
+</description>
+<suggestion>
+Append "If sz == size(), does nothing" to the
+effects.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="117" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.3
+</section>
+<para></para>
+<description>
+forward_list::erase_after should return an iterator.
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="41" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.3
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(table 93)" to "(Table 93)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="114" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.4.1
+</section>
+<para>
+p11 & p12
+</para>
+<description>
+It looks like the erase/insert effects given in p11 are
+intended for p12.
+</description>
+<suggestion>
+Move the erase/insert effects down to p12
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="115" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.4.2
+</section>
+<para>
+p1
+</para>
+<description>
+There is no mention of what happens if sz==size(). While
+it obviously does nothing I feel a standard needs to say
+this explicitly.
+</description>
+<suggestion>
+Express the semantics as pseudo-code similarly
+to the way it is done for the copying overload that
+follows (in p3). Include an else clause that does
+nothing and covers the sz==size() case.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="116" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.5
+</section>
+<para></para>
+<description>
+The sequence container adaptors consume sequence
+containers, but are neither containers nor sequences
+themselves. While they clearly belong in clause 23, they
+should not interrupt the presentation of the sequence
+container themselves.
+</description>
+<suggestion>
+Move clause 23.3.5 out of clause 23.3.
+Recommending inserting as a 'new' 23.4
+immediately following sequence containers, and
+before the current 23.4 (associative containers)
+which would be renumbered 23.5.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="22" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.5.1, 23.3.5.2, 23.3.5.3
+</section>
+<para></para>
+<description>
+With the final acceptance of move operations as special
+members and introduction of corresponding suppression
+rules of implicitly generated copy operations the some
+library types that were copyable in C++03 are no longer
+copyable (only movable) in C++03, among them queue,
+priority_queue, and stack.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="93" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.5.2
+</section>
+<para>
+1
+</para>
+<description>
+Typo, missing ";".
+<PRE>
+template <class... Args> void emplace(Args&&... args)
+</PRE>n
+</description>
+<suggestion>
+Correct typo.
+<PRE>
+template <class... Args> void emplace(Args&&...
+args);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="117" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.6.2
+</section>
+<para>
+p9
+</para>
+<description>
+(Same as for 23.3.2.2p1 i.e. deque::resize).
+There is no mention of what happens if sz==size(). While
+it obviously does nothing I feel a standard needs to say
+this explicitely.
+</description>
+<suggestion>
+Append "If sz == size(), does nothing" to the
+effects.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="118" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.3.7
+</section>
+<para></para>
+<description>
+vector<bool> iterators are not random access iterators
+because their reference type is a special class, and not
+'bool &'. All standard libary operations taking iterators
+should treat this iterator as if it was a random access
+iterator, rather than a simple input iterator.
+</description>
+<suggestion>
+Either revise the iterator requirements to support
+proxy iterators (restoring functionality that was lost
+when the Concept facility was removed) or add an
+extra paragraph to the vector<bool> specification
+requiring the library to treat vector<bool> iterators
+as-if they were random access iterators, despite
+having the wrong reference type.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="6" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.4.1
+</section>
+<para>
+2
+</para>
+<description>
+Constructor accepting an allocator as a single parameter
+should be qualified as explicit.
+<PRE>
+namespace std {
+template <class Key, class T, class Compare =
+less<Key>,
+class Allocator = allocator<pair<const Key, T> > >
+class map {
+public:
+...
+map(const Allocator&);
+</PRE>
+</description>
+<suggestion>
+Add explicit.
+<PRE>
+namespace std {
+template <class Key, class T, class Compare =
+less<Key>,
+class Allocator = allocator<pair<const Key, T> > >
+class map {
+public:
+...
+explicit map(const Allocator&);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="7" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.4.2
+</section>
+<para>
+2
+</para>
+<description>
+Constructor accepting an allocator as a single parameter
+should be qualified as explicit.
+</description>
+<suggestion>
+Add explicit.
+<PRE>
+namespace std {
+template <class Key, class T, class Compare =
+less<Key>,
+class Allocator = allocator<pair<const Key, T> > >
+class multimap {
+public:
+...
+explicit multimap(const Allocator&);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="8" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.4.3
+</section>
+<para>
+2
+</para>
+<description>
+Constructor accepting an allocator as a single parameter
+should be qualified as explicit.
+</description>
+<suggestion>
+Add explicit.
+<PRE>
+namespace std {
+template <class Key, class Compare = less<Key>,
+class Allocator = allocator<Key> >
+class set {
+public:
+...
+explicit set(const Allocator&);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="9" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.4.4
+</section>
+<para>
+2
+</para>
+<description>
+Constructor accepting an allocator as a single parameter
+should be qualified as explicit.
+</description>
+<suggestion>
+Add explicit.
+<PRE>
+namespace std {
+template <class Key, class Compare = less<Key>,
+class Allocator = allocator<Key> >
+class multiset {
+public:
+...
+explicit multiset(const Allocator&);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="118" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.5
+</section>
+<para></para>
+<description>
+Some unordered associative container operations have
+undesirable complexities when the container is
+implemented using singly linked lists.
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="10" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.5.1
+</section>
+<para>
+3
+</para>
+<description>
+Constructor accepting an allocator as a single parameter
+should be qualified as explicit.
+</description>
+<suggestion>
+Add explicit.
+<PRE>
+namespace std {
+template <class Key,
+template <class Key,
+class T,
+class Hash = hash<Key>,
+class Pred = std::equal_to<Key>,
+class Alloc = std::allocator<std::pair<const Key,
+T> > >
+class unordered_map
+{
+public:
+...
+explicit unordered_map(const Allocator&);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="11" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.5.2
+</section>
+<para>
+3
+</para>
+<description>
+Constructor accepting an allocator as a single parameter
+should be qualified as explicit.
+</description>
+<suggestion>
+Add explicit.
+<PRE>
+namespace std {
+template <class Key,
+class T,
+class Hash = hash<Key>,
+class Pred = std::equal_to<Key>,
+class Alloc = std::allocator<std::pair<const Key,
+T> > >
+class unordered_multimap
+{
+public:
+...
+explicit unordered_multimap(const Allocator&);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="94" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.5.2
+</section>
+<para>
+1
+</para>
+<description>
+"see below" should be in italic and need one space
+between words.<BR/>
+explicit unordered_multimap(size_type n = seebelow,
+</description>
+<suggestion>
+Change to:<BR/>
+explicit unordered_multimap(size_type n = see
+below,
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="12" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.5.3
+</section>
+<para>
+3
+</para>
+<description>
+Constructor accepting an allocator as a single parameter
+should be qualified as explicit.
+</description>
+<suggestion>
+Add explicit.
+<PRE>
+namespace std {
+template <class Key,
+class Hash = hash<Key>,
+class Pred = std::equal_to<Key>,
+class Alloc = std::allocator<Key> >
+class unordered_set
+{
+public:
+...
+explicit unordered_set(const Allocator&);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="13" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+23.5.4
+</section>
+<para>
+3
+</para>
+<description>
+Constructor accepting an allocator as a single parameter
+should be qualified as explicit.
+</description>
+<suggestion>
+Add explicit.
+<PRE>
+namespace std {
+template <class Key,
+class Hash = hash<Key>,
+class Pred = std::equal_to<Key>,
+class Alloc = std::allocator<Key> >
+class unordered_multiset
+{
+public:
+...
+explicit unordered_multiset(const Allocator&);
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="119" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[input.iterators] 24.2.3
+</section>
+<para>
+Table 104
+</para>
+<description>
+Although the section talks about operator==, there is no
+requirement that it exist.
+</description>
+<suggestion>
+Add a == b to Table 104
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="42" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.1
+</section>
+<para>
+8, 9
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(4)" to "(Clause 4)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="120" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.2.12
+</section>
+<para>
+para 1
+</para>
+<description>
+is_permutation is underspecified for anything but the
+simple case where both ranges have the same value type
+and the comparison function is an equivalence relation.
+</description>
+<suggestion>
+Restrict is_permutation to the case where it is well
+specified. See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="ES" num="3" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.2.12
+</section>
+<para></para>
+<description>
+is_permutation does not require ForwardIterator1 and
+ForwardIterator2 to have the same value type. This opens
+the door to nonsense heterogeneous usage where both
+ranges have different value types
+</description>
+<suggestion>
+Require both iterator types to have the same
+value type
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="43" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.3.9
+</section>
+<para>
+5
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(4)" to "(Clause 4)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="121" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.3.12 [alg.random.shuffle]
+</section>
+<para>
+1
+</para>
+<description>
+random_shuffle and shuffle should be consistent in how
+they accept their source of randomness: either both by
+rvalue reference or both by lvalue reference.
+</description>
+<suggestion>
+Change random_shuffle to accept its
+RandomNumberGenerator by lvalue reference.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="119" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.3.12
+</section>
+<para></para>
+<description>
+The functions random_shuffle and shuffle both take
+arguments providing a source of randomness, but one
+take its argument by rvalue reference, and the other
+requires an lvalue reference. The technical merits of which
+form of argument passing should be settled for this
+specific case, and a single preferred form used
+consistently.
+</description>
+<suggestion>
+[DEPENDS ON WHETHER RVALUE OR
+LVALUE REFERENCE IS THE PREFERRED
+FORM]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="44" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.4
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(4)" to "(Clause 4)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="45" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.4.7
+</section>
+<para>
+1, 10, 19
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(32)" to "(Table 32)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="122" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.4.7 [alg.min.max]
+</section>
+<para></para>
+<description>
+It was the LWG's intent in Pittsburgh that N2772 be
+applied to the WP
+</description>
+<suggestion>
+Apply N2772 to the WP.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="123" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+25.5
+</section>
+<para>
+p5b, and all uses of lshift
+</para>
+<description>
+N3056, as adopted, calls for each use of lshift to be
+followed by a subscripted value.
+</description>
+<suggestion>
+Adjust all occurrences of the lshift notation so as
+to match the notation of N3056.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="14" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.3.1.
+</section>
+<para>
+3
+</para>
+<description>
+typo
+</description>
+<suggestion>
+"floating-point environmnet" should be "floating-point
+environment."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="120" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.4.7
+</section>
+<para></para>
+<description>
+The complex number functions added for compatibility
+with the C99 standard library are defined purely as a
+cross-reference, with no hint of what they should return.
+This is distinct from the style of documentation for the
+functions in the earlier standard. In the case of the
+inverse-trigonometric and hyperbolic functions, a
+reasonable guess of the functionality may be made from
+the name, this is not true of the cproj function, which
+apparently returns the projection on the Reimann Sphere.
+A single line description of each function, associated with
+the cross-reference, will greatly improve clarity.
+</description>
+<suggestion>
+[ONE LINE DESCRIPTIONS, AND ASSOCIATED
+PARAGRAPH NUMBERS, TO FOLLOW IF THE
+INTENT IS APPROVED]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="46" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.1.6
+</section>
+<para>
+3
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "Clause 21 and 27" to "Clauses 21 and
+27".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="121" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.3
+</section>
+<para></para>
+<description>
+All the random number engine types in this clause have a
+constructor taking an unsigned integer type, and a
+constructor template for seed sequences. This means that
+an attempt to create a random number engine seeded by
+an integer literal must remember to add the appropriate
+unsigned suffix to the literal, as a signed integer will
+attempt to use the seed sequence template, yielding
+undefined behaviour, as per 26.5.1.1p1a. It would be
+helpful if at least these anticipated cases produced a
+defined behaviour, either an erroneous program with
+diagnostic, or a conversion to unsigned int forwarding to
+the appropriate constructor.
+</description>
+<suggestion>
+[WORDING TO FOLLOW ONCE A PREFERRED
+DIRECTION IS INDICATED]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="124" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.3.2
+</section>
+<para>
+p4
+</para>
+<description>
+The Mersenne twister algorithm is meaningless for word
+sizes less than two, as there are then insufficient bits
+available to be “twisted”.
+</description>
+<suggestion>
+Insert the following among the relations that are
+required to hold: 2u < w.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="125" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.4.1 [rand.adapt.disc]
+</section>
+<para>
+3
+</para>
+<description>
+The synopsis for min() and max() is lacking “()” in the
+return statements.
+</description>
+<suggestion>
+return Engine::min();<BR/>
+return Engine::max();
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="126" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.4.1 [rand.adapt.disc], 26.5.4.2 [rand.adapt.ibits], 26.5.4.3 [rand.adapt.shuf]
+</section>
+<para>
+3
+</para>
+<description>
+Each adaptor has a member function called base() which
+has no definition.
+</description>
+<suggestion>
+Give it the obvious definition.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="127" type="ed/te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.4.1
+</section>
+<para>
+synopsis after p3
+</para>
+<description>
+Engine::min is a function and ought be invoked in the
+context where mentioned, as should Engine::max.
+</description>
+<suggestion>
+Append parentheses so as to become return
+Engine::min() and return Engine::max().
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="128" type="ed/te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.4.3
+</section>
+<para>
+synopsis after p3
+</para>
+<description>
+Engine::min is a function and ought be invoked in the
+context where mentioned, as should Engine::max.
+</description>
+<suggestion>
+Append parentheses so as to become return
+Engine::min() and return Engine::max().
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="129" type="ed/te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.7.1
+</section>
+<para>
+p8b
+</para>
+<description>
+The expression begin[x+q] is incorrect since x is
+unspecified .
+</description>
+<suggestion>
+Replace x by k so as to obtain begin[k+q].
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="130" type="ed/te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.7.1
+</section>
+<para>
+p8c
+</para>
+<description>
+The phrase “three more times” is misleading.
+</description>
+<suggestion>
+s/three more times,/again,/
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="131" type="ed/te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.7.1
+</section>
+<para>
+p8c
+</para>
+<description>
+Values <I>r</I><SUB>3</SUB> and <I>r</I><SUB>4</SUB>
+are correctly specified, but in their
+subsequent use they are interchanged with respect to the
+original algorithm by Mutso Saito.
+</description>
+<suggestion>
+Exchange subscripts so as to read as follows: “...
+update begin[k + p] by xoring it with <I>r</I><SUB>3</SUB>, update
+begin[k + q] by xoring it with <I>r</I><SUB>4</SUB>, and ...”
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="132" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.7.1 [rand.util.seedseq]
+</section>
+<para>
+8b
+</para>
+<description>
+The last sentence includes “begin[x + q]” but “x”
+is nonsensical here.
+</description>
+<suggestion>
+Change “begin[x + q]” to “begin[k + q]”
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="133" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.7.1 [rand.util.seedseq]
+</section>
+<para>
+8c
+</para>
+<description>
+The use of r3 and r4 is reversed in the final sentence of 8c
+according to the defect report on comp.std.c++ that this
+specification is based on:
+http://groups.google.com/group/comp.std.c++/browse_thre
+ad/thread/e34cbee1932efdb8/aad523dccec12aed?q=grou
+p:comp.std.c%2B%2B+insubject:seed_seq
+If you follow the SFMT link to the software, the software
+also uses r3 and r4 in a manner inconsistent with N3092.
+I believe N3092 should be changed to be consistent with
+the defect report.
+</description>
+<suggestion>
+Change 8c to end:<BR/>
+... update begin[k + p] by xoring it with r3, update
+begin[k + q] by xoring it with
+r4, and ...
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="134" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.8.5.2 [rand.dist.samp.pconst], 26.5.8.5.3 [rand.dist.samp.plinear]
+</section>
+<para></para>
+<description>
+These two distributions have a member function called
+densities() which returns a vector<double>. The
+distribution is templated on RealType. The distribution
+also has another member called intervals() which returns
+a vector<RealType>. Why doesn't densities return
+vector<RealType> as well? If RealType is long double,
+the computed densities property isn't being computed to
+the precision the client desires. If RealType is float, the
+densities vector is taking up twice as much space as the
+client desires.
+</description>
+<suggestion>
+Change the piecewise constant and linear
+distributions to hold / return the densities in a
+vector<result_type>.<BR/>
+If this is not done, at least
+correct[rand.dist.samp.pconst]/13 which describes
+the return of densities as a vector<result_type>.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="135" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.5.8.5.3
+</section>
+<para>
+10
+</para>
+<description>
+This paragraph says: Let bk = xmin+k·δ for k = 0,...,n,
+and wk = fw(bk +δ) for k = 0,...,n.
+However I believe that fw(bk) would be far more desirable.
+I strongly suspect that this is nothing but a type-o.
+</description>
+<suggestion>
+Change p10 to read:<BR/>
+Let bk = xmin+k·δ for k = 0,...,n, and wk = fw(bk)
+for k = 0,...,n.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="47" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.7.1
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+</description>
+<suggestion>
+Change "(35)" to "(Table 35)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="48" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.7.2
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(35)" to "(Table 35)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="49" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.7.4
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(36)" to "(Table 36)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="136" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+26.8
+</section>
+<para></para>
+<description>
+Floating-point test functions are incorrectly specified.
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="9" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23
+</section>
+<para>
+27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23
+</para>
+<description>
+Imposed happens-before edges should be in
+synchronizes-with<BR/>
+Each use of the words "happens-before" should be
+replaced with the words "synchronizes-with" in the
+following sentences:<BR/>
+27.2.3p2<BR/>
+30.3.1.2p6<BR/>
+30.3.1.5p7<BR/>
+30.6.4p7<BR/>
+30.6.9p5<BR/>
+30.6.10.1p23<BR/>
+Rationale: Happens-before is defined in 1.10p11 in a way
+that (deliberately) does not make it explicitly transitively
+closed. Adding edges to happens-before directly, as in
+27.2.3p2 etc., does not provide transitivity with
+sequenced-before or any other existing happens-before
+edge. This lack of transitivity seems to be unintentional.
+</description>
+<suggestion>
+Each use of the words "happens-before" should
+be replaced with the words "synchronizes-with" in
+the following sentences:<BR/>
+27.2.3p2<BR/>
+30.3.1.2p6<BR/>
+30.3.1.5p7<BR/>
+30.6.4p7<BR/>
+30.6.9p5<BR/>
+30.6.10.1p23
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="122" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27, 30
+</section>
+<para></para>
+<description>
+See (D) in attachment Appendix 1 - Additional Details
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="123" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27.5.3.2
+</section>
+<para>
+Table 124
+</para>
+<description>
+Several rows in table 124 specify a Return type of
+'OFF_T', which does not appear to be a type defined in
+this standard.
+</description>
+<suggestion>
+Resolve outstanding references to the removed
+type 'OFF_T'.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="137" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27.7
+</section>
+<para></para>
+<description>
+Several iostreams member functions are incorrectly
+specified.
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="138" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27.7
+</section>
+<para></para>
+<description>
+For istreams and ostreams, the move-constructor does
+not move-construct, the move-assignment operator does
+not move-assign, and the swap function does not swap
+because these operations do not manage the rdbuf()
+pointer. Useful applications of these operations are
+prevented both by their incorrect semantics and because
+they are protected.
+</description>
+<suggestion>
+In short: reverse the resolution of issue 900, then
+change the semantics to move and swap the
+rdbuf() pointer. Add a new protected constructor
+that takes an rvalue reference to a stream and a
+pointer to a streambuf, a new protected assign()
+operator that takes the same arguments, and a
+new protected partial_swap() function that doesn't
+swap rdbuf().
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="139" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27.7
+</section>
+<para>
+1.1.3
+</para>
+<description>
+Resolve issue LWG 1328 one way or the other, but
+preferably in the direction outlined in the proposed
+resolution, which, however, is not complete as-is: in any
+case, the sentry must not set ok_ = false if is.good() ==
+false, otherwise istream::seekg, being an unformatted
+input function, does not take any action because the
+sentry object returns false when converted to type bool.
+Thus, it remains impossible to seek away from end of file.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="140" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27.8
+</section>
+<para></para>
+<description>
+It should be possible to construct a stringstream with a
+specific allocator.
+</description>
+<suggestion>
+Add an allocator_type and overloaded
+constructors that take an Allocator argument to
+basic_stringbuf, basic_istringstream,
+basic_ostringstream, and basic_stringstream.
+The semantics of allocator propagation should be
+the same as if the stringbuf contained an
+embedded basic_string using the same allocator.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="124" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27.8.1.3
+</section>
+<para>
+3
+</para>
+<description>
+N3092 27.8.1.3 Member functions contains this text
+specifying the postconditions of
+basic_stringbuf::str(basic_string):<BR/>
+"Postconditions: If mode & ios_base::out is true, pbase()
+points to the first underlying character and epptr() >=
+pbase() + s.size() holds; in addition, if mode &
+ios_base::in is true, pptr() == pbase() + s.data() holds,
+otherwise pptr() == pbase() is true. [...]"<BR/>
+Firstly, there's a simple mistake: It should be pbase() +
+s.length(), not pbase() + s.data().<BR/>
+Secondly, it doesn't match existing implementations. As
+far as I can tell, GCC 4.5 does not test for mode &
+ios_base::in in the second part of that sentence, but for
+mode & (ios_base::app | ios_base_ate), and Visual C++ 9
+for mode & ios_base::app. Besides, the wording of the
+C++0x draft doesn't make any sense to me. I suggest
+changing the second part of the sentence to one of the
+following:<BR/>
+Replace ios_base::in with (ios_base::ate | ios_base::app),
+but this would require Visual C++ to change (replacing
+only with ios_base::ate would require GCC to change, and
+would make ios_base::app completely useless with
+stringstreams):<BR/>
+in addition, if mode & (ios_base::ate | ios_base::app) is
+true, pptr() == pbase() + s.length() holds, otherwise pptr()
+== pbase() is true.<BR/>
+Leave pptr() unspecified if mode & ios_base::app, but not
+mode & ios_base::ate (implementations already differ in
+this case, and it's always possible to use ios_base::ate to
+get the effect of appending, so it's not necessary to
+require any implementation to change):
+in addition, if mode & ios_base::ate is true, pptr() ==
+pbase() + s.length() holds, if neither mode & ios_base::ate
+nor mode & ios_base::app is true, pptr() == pbase() holds,
+otherwise pptr() >= pbase() && pptr() <= pbase() +
+s.length() (which of the values in this range is
+unspecified).<BR/>
+Slightly stricter:<BR/>
+in addition, if mode & ios_base::ate is true, pptr() ==
+pbase() + s.length() holds, if neither mode & ios_base::ate
+nor mode & ios_base::app is true, pptr() == pbase() holds,
+otherwise pptr() == pbase() || pptr() == pbase() +
+s.length() (which of these two values is unspecified).
+A small table might help to better explain the three cases.
+BTW, at the end of the postconditions is this text: "egptr()
+== eback() + s.size() hold". Is there a perference for
+basic_string::length or basic_string::size? It doesn't really
+matter, but it looks a bit inconsistent.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="4" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+27.8.2
+</section>
+<para>
+various
+</para>
+<description>
+Subclause 27.9.2 [c.files] specifies that <cinttypes> has
+declarations for abs() and div(); however, the signatures
+are not present in this subclause. The signatures
+proposed under TR1 ([tr.c99.inttypes]) are not present in
+FCD (unless if intmax_t happened to be long long). It is
+unclear as to which, if any of the abs() and div() functions
+in [c.math] are meant to be declared by <cinttypes>. This
+subclause mentions imaxabs() and imaxdiv(). These
+functions, among other things, are not specified in FCD to
+be the functions from Subclause 7.8 of the C Standard.
+Finally, <cinttypes> is not specified in FCD to include
+<cstdint> (whereas <inttypes.h> includes <stdint.h> in C).
+</description>
+<suggestion>
+Please clarify.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="14" type="TL" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.4
+</section>
+<para></para>
+<description>
+Support of char16_t/char32_t is insufficient. The <regex>
+does not have typedefs for char16_t/char32_t.<BR/>
+The reason we need this typedefs is, because anybody
+may define
+exactly same type with different typedef names.
+Doesn't <locale> offer enough operations which is
+required by regex
+implementation?
+</description>
+<suggestion>
+Add typedefs below
+<PRE>
+typedef basic_regex<char16_t> u16regex;
+typedef basic_regex<char32_t> u32regex;
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="127" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.5.2
+</section>
+<para></para>
+<description>
+The Bitmask Type requirements in 17.5.2.1.3 p3 say that
+all elements on a bitmask type have distinct values, but
+28.5.2 defines regex_constants::match_default and
+regex_constants::format_default as elements of the
+bitmask type regex_constants::match-flag_type, both with
+value 0. This is a contradiction.
+</description>
+<suggestion>
+One of the bitmask elements should be removed
+from the declaration and should be defined
+separately, in the same manner as
+ios_base::adjustfield, ios_base::basefield and
+ios_base::floatfield are defined by 27.5.2.1.2p2
+and Table 120. These are constants of a bitmask
+type, but are not distinct elements, they have
+more than one value set in the bitmask.
+regex_constants::format_default should be
+specified as a constant with the same value as
+regex_constants::match_default.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="50" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.5.2
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "table 136" to "Table 136".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="51" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.5.3
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "table 137" to "Table 137".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="141" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.8
+</section>
+<para></para>
+<description>
+std::basic_regex should have an allocator for all the
+reasons that a std::string does. For example, I can use
+boost::interprocess to put a string or vector in shared
+memory, but not a regex.
+</description>
+<suggestion>
+Add allocators to regexes
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="125" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.10.3
+</section>
+<para>
+2
+</para>
+<description>
+The term "target sequence" is not defined.
+</description>
+<suggestion>
+Replace "target sequence" with "string being
+searched/matched"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="126" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.10.3
+</section>
+<para></para>
+<description>
+It's unclear how match_results should behave if it has
+been default-constructed. The sub_match objects
+returned by operator[], prefix and suffix cannot point to the
+end of the sequence that was searched if no search was
+done. The iterators held by unmatched sub_match objects
+might be singular.
+</description>
+<suggestion>
+Add to match_results::operator[],
+match_results::prefix and match_results::suffix:<BR/>
+Requires: !empty()
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="52" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.11.2
+</section>
+<para>
+3
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "table 139" to "Table 139".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="95" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.11.3
+</section>
+<para>
+1
+</para>
+<description>
+The section number "(24.1.4)" for "Bidirectional Iterator" is
+wrong. The correct one is "(24.2.6)".
+In addition, it is written as normal text, but it should be
+embedded as a link to the section.
+</description>
+<suggestion>
+Change "(24.1.4)" to "(24.2.6)" and make it a link
+to section (24.2.6).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="53" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.11.3
+</section>
+<para>
+3
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.</description>
+<suggestion>
+Change "table 140" to "Table 140".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="54" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+28.13
+</section>
+<para>
+6
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "table 135" to "Table 135".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="128" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29
+</section>
+<para></para>
+<description>
+WG14 has made some late changes to their specification
+of atomics, and care should be taken to ensure that we
+retain a common subset of language/library syntax to
+declare headers that are portable to both languages.
+Ideally, such headers would not require users to define
+their own macros, especially not macros that map to
+keywords (which remains undefined behaviour)
+</description>
+<suggestion>
+Depends on result of the review of WG14 work,
+which is expected to be out to ballot during the
+time wg21 is resolving its own ballot comments.
+Liaison may also want to file comments in WG14
+to ensure compatibity from both sides.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="22" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29
+</section>
+<para></para>
+<description>
+WG14 currently plans to introduce atomic facilities that are
+intended to be compatible with the facilities of clause 29.
+They should be compatible.
+</description>
+<suggestion>
+Make sure the headers in clause 29 are defined in
+a way that is compatible with the planned C
+standard.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="129" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29
+</section>
+<para>
+Table 143
+</para>
+<description>
+Table 143 lists the typedefs for various atomic types
+corresponding to the various standard integer typedefs,
+such as atomic_int_least8_t for int_least8_t, and
+atomic_uint_fast64_t for uint_fast64_t. However, there are
+no atomic typedefs corresponding to the fixed-size
+standard typedefs int8_t, int16_t, and so forth.
+</description>
+<suggestion>
+Add the following entries to table 143:<BR/>
+atomic_int8_t => int8_t (optional),<BR/>
+atomic_int16_t => int16_t (optional),<BR/>
+atomic_int32_t => int32_t (optional),<BR/>
+atomic_int64_t => int64_t (optional),<BR/>
+atomic_uint8_t => uint8_t (optional),<BR/>
+atomic_uint16_t => uint16_t (optional),<BR/>
+atomic_uint32_t => uint32_t (optional),<BR/>
+atomic_uint64_t => uint64_t (optional)<BR/>
+These typedefs should be available if the
+corresponding typedefs from are available.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="16" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.1p1 29.3p8
+</section>
+<para>
+29.1p1 footnote 343 29.3p8 footnote 344
+</para>
+<description>
+Radioactivity<BR/>
+Footnotes 343 and 344 from 29.1p1 and 29.3p8 read:
+"Atomic objects are neither active nor radioactive" and
+"Among other implications, atomic variables shall not
+decay".<BR/>
+We suggest that these be removed - the first is pretty
+clearly a joke, but it's not obvious that the second doesn't
+have some technical meaning.
+</description>
+<suggestion>
+Footnotes 343 and 344 from 29.1p1 and 29.3p8
+should be removed.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="142" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.1
+</section>
+<para>
+P2 table 141
+</para>
+<description>
+Missing 29.8 Fences
+</description>
+<suggestion>
+Add 29.8 Fences
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="143" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.syn] 29.2
+</section>
+<para>
+before 1
+</para>
+<description>
+There is no free function
+atomic_compare_exchange_strong for volatile atomic
+integral types; there is one for non-volatile types.
+</description>
+<suggestion>
+Add atomic_compare_exchange_strong for
+volatile integral types to the synopsis.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="144" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.syn] 29.2
+</section>
+<para>
+before 1
+</para>
+<description>
+The synopsis lists the macros
+ATOMIC_INTEGRAL_LOCK_FREE and
+ATOMIC_ADDRESS_LOCK_FREE; the Lock-free
+Property requirements don't have
+ATOMIC_INTEGRAL_LOCK_FREE, but have 8 macros
+for the various integral types.
+</description>
+<suggestion>
+Change 29.2 [atomics.syn] to match 29.4
+[atomics.lockfree].
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="145" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.2
+</section>
+<para></para>
+<description>
+missing atomic_compare_exchange_strong(volatile ....)
+and atomic_compare)exchange_strong_explict( ...//no
+volatile *?<BR/>
+> bool atomic_compare_exchange_weak(volatile
+atomic_itype*, integral*, integral);<BR/>
+> bool atomic_compare_exchange_weak(atomic_itype*,
+integral*, integral);<BR/>
+> bool atomic_compare_exchange_strong(atomic_itype*,
+integral*, integral);<BR/>
+> bool atomic_compare_exchange_weak_explicit(volatile
+atomic_itype*, integral*,<BR/>
+> integral, memory_order, memory_order);<BR/>
+> bool
+atomic_compare_exchange_weak_explicit(atomic_itype*,
+integral*,<BR/>
+> integral, memory_order, memory_order);<BR/>
+> bool atomic_compare_exchange_strong_explicit(volatile
+atomic_itype*, integral*,<BR/>
+> integral, memory_order, memory_order);
+</description>
+<suggestion>
+Repair as suggested
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="130" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.2
+</section>
+<para></para>
+<description>
+The synopsis for the <atomic> header lists the macros
+ATOMIC_INTEGRAL_LOCK_FREE and
+ATOMIC_ADDRESS_LOCK_FREE. The
+ATOMIC_INTEGRAL_LOCK_FREE macro has been
+replaced with a set of macros for each integral type, as
+listed in 29.4
+</description>
+<suggestion>
+Replace "#define
+ATOMIC_INTEGRAL_LOCK_FREE unspecified"
+with
+<PRE>
+#define ATOMIC_CHAR_LOCK_FREE
+implementation-defined
+#define ATOMIC_CHAR16_T_LOCK_FREE
+implementation-defined
+#define ATOMIC_CHAR32_T_LOCK_FREE
+implementation-defined
+#define ATOMIC_WCHAR_T_LOCK_FREE
+implementation-defined
+#define ATOMIC_SHORT_LOCK_FREE
+implementation-defined
+#define ATOMIC_INT_LOCK_FREE
+implementation-defined
+#define ATOMIC_LONG_LOCK_FREE
+implementation-defined
+#define ATOMIC_LLONG_LOCK_FREE
+implementation-defined
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="146" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.2
+</section>
+<para>
+syn 29.4
+</para>
+<description>
+The ATOMIC_..._LOCK_FREE macros have not had
+changes applied.
+</description>
+<suggestion>
+Change to match 29.4/0.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="147" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.2
+</section>
+<para>
+syn 29.7
+</para>
+<description>
+The declaration of ATOMIC_VAR_INIT should be
+referenced to section 29.6 [atomics.types.operations], not
+29.7.
+</description>
+<suggestion>
+Change it to 29.6.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="148" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.2
+</section>
+<para>
+syn 29.7
+</para>
+<description>
+The definition of ATOMIC_VAR_INIT should be
+'implementation defined' rather than 'see below'.
+</description>
+<suggestion>
+Change it to 'implementation defined'.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="149" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.2
+</section>
+<para>
+syn 29.5.1
+</para>
+<description>
+The synopsis is missing the atomic_init function
+declarations for the bool, integral and address types.
+</description>
+<suggestion>
+Copy them from 29.5.1.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="150" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.2
+</section>
+<para>
+syn 29.5.1
+</para>
+<description>
+There are missing function prototypes bool
+atomic_compare_exchange_strong(volatile atomic_itype*,
+integral*, integral); and integral atomic_fetch_add(volatile
+atomic_itype*, integral);
+</description>
+<suggestion>
+Add them.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="151" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.2
+</section>
+<para>
+syn 29.5.1
+</para>
+<description>
+There is a duplicate function declaration of integral
+atomic_fetch_or(volatile atomic_itype*, integral);
+</description>
+<suggestion>
+Remove the volatile qualifier from the second
+declaration.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="152" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.3
+</section>
+<para>
+para 1
+</para>
+<description>
+The table shows no disinct meaning for
+memory_order_seq_cst.
+</description>
+<suggestion>
+Add another bullet: "- memory_order_seq_cst:
+See below."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="131" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.3
+</section>
+<para>
+8
+</para>
+<description>
+See (H) in attachment Appendix 1 - Additional Details
+</description>
+<suggestion>
+Request the concurrency working group to
+determine if changes are needed. Consider
+changing the use of "sequence" in 29.3
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="21" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+9.3p8 1.9p13
+</section>
+<para>
+29.3p8 1.9p13
+</para>
+<description>
+Overlapping evaluations are allowed<BR/>
+29.3p8 states:<BR/>
+"An atomic store shall only store a value that has
+been computed from constants and program input values
+by a finite sequence of program evaluations, such
+that each evaluation observes the values of variables
+as computed by the last prior assignment in the
+sequence."<BR/>
+... but 1.9p13 states:
+"If A is not sequenced before B and B is not
+sequenced before A, then A and B are unsequenced.
+[ Note: The execution of unsequenced evaluations can
+overlap. -end note ]"<BR/>
+Overlapping executions can make it impossible to
+construct the sequence described in 29.3p8. We are not
+sure of the intention here and do not offer a suggestion for
+change, but note that 29.3p8 is the condition that prevents
+out-of-thin-air reads.<BR/>
+For an example, suppose we have a function invocation
+f(e1,e2). The evaluations of e1 and e2 can overlap.
+Suppose that the evaluation of e1 writes y and reads x
+whereas the evaluation of e2 reads y and writes x, with
+reads-from edges as below (all this is within a single
+thread).
+<PRE>
+e1 e2
+Wrlx y-- --Wrlx x
+rf\ /rf
+X
+/ \
+Rrlx x<- ->Rrlx y
+</PRE>
+This seems like it should be allowed, but there seems to
+be no way to produce a sequence of evaluations with the
+property above.<BR/>
+In more detail, here the two evaluations, e1 and e2, are
+being executed as the arguments of a function and are
+consequently not sequenced-before each other. In
+practice we'd expect that they could overlap (as allowed
+by 1.9p13), with the two writes taking effect before the two
+reads. However, if we have to construct a linear order of
+evaluations, as in 29.3p8, then the execution above is not
+permited. Is that really intended?
+</description>
+<suggestion>
+Please clarify.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="153" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.lockfree] 29.4
+</section>
+<para>
+before 1
+</para>
+<description>
+The macros are all specified as "implementation-deifned";
+they should be "see below", since the required values are
+spelled out.
+</description>
+<suggestion>
+Change the definitions of the macros in 29.4
+[atomics.lockfree] from "implementation-defined"
+to "see below".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="154" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.lockfree] 29.4
+</section>
+<para>
+before 1
+</para>
+<description>
+There is no ATOMIC_BOOL_LOCK_FREE macro.
+</description>
+<suggestion>
+Add ATOMIC_BOOL_LOCK_FREE to 29.4
+[atomics.lockfree] and to 29.2 [atomics.syn]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="155" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.4
+</section>
+<para>
+para 3
+</para>
+<description>
+The 'via' 'by' word pairing is awkward.
+</description>
+<suggestion>
+Replace 'by' with 'via' in 'communication via
+memory ... and by memory'.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CA" num="1" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.4, 29.6 29.7
+</section>
+<para>
+various
+</para>
+<description>
+All ATOMIC_... macros should be prefixed with STD_ as
+in STD_ATOMIC_... to indicate they are STD macros as
+other standard macros. The rationale that they all seem
+too long seems weak.
+</description>
+<suggestion>
+This covers the following macros which we
+suggest prepending with STD_:<BR/>
+29.4:<BR/>
+#define ATOMIC_CHAR_LOCK_FREE
+implementation-defined<BR/>
+#define ATOMIC_CHAR16_T_LOCK_FREE
+implementation-defined<BR/>
+#define ATOMIC_CHAR32_T_LOCK_FREE
+implementation-defined<BR/>
+#define ATOMIC_WCHAR_T_LOCK_FREE
+implementation-defined<BR/>
+#define ATOMIC_SHORT_LOCK_FREE
+implementation-defined<BR/>
+#define ATOMIC_INT_LOCK_FREE
+implementation-defined<BR/>
+#define ATOMIC_LONG_LOCK_FREE
+implementation-defined<BR/>
+#define ATOMIC_LLONG_LOCK_FREE
+implementation-defined<BR/>
+#define ATOMIC_ADDRESS_LOCK_FREE
+implementation-defined<BR/>
+29.6:<BR/>
+#define ATOMIC_VAR_INIT(value) see below<BR/>
+29.7:<BR/>
+#define ATOMIC_FLAG_INIT see below
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="156" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.types.integral] 29.5.1
+</section>
+<para>
+before 1
+</para>
+<description>
+The list of member functions for atomic_bool has four
+versions of compare_exchange_weak taking one
+memory_order argument; the last two should be
+compare_exchange_strong.
+</description>
+<suggestion>
+Change the last two member functions
+comapare_exchange_weak taking two
+memory_order arguments to
+compare_exchange_strong.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="55" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.5.1
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "table 142" to "Table 142".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="132" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.5.1
+</section>
+<para></para>
+<description>
+The atomic_itype types and atomic_address have two
+overloads of operator= --- one is volatile qualified, and the
+other is not. atomic_bool only has the volatile qualified
+version:<BR/>
+bool operator=(bool) volatile;<BR/>
+On a non-volatile-qualified object this is ambiguous with
+the deleted copy-assignment operator<BR/>
+atomic_bool& operator=(atomic_bool const&) = delete;<BR/>
+due to the need for a single standard conversion in each
+case when assigning a bool to an atomic_bool as in:
+<PRE>
+atomic_bool b;
+b=true;
+</PRE>
+The conversions are atomic_bool& -> atomic_bool
+volatile& vs bool -> atomic_bool
+</description>
+<suggestion>
+Add the "bool operator=(bool);" overload to
+atomic_bool in 29.5.1
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="157" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.types.integral] 29.5.1
+</section>
+<para>
+before 1
+</para>
+<description>
+atomic_bool has a volatile assignment operator but not a
+non-volatile operator The other integral types have both..
+</description>
+<suggestion>
+Add a non-volatile assignment operator to
+atomic_bool.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="158" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.5.1
+</section>
+<para>
+para 0
+</para>
+<description>
+There is a space before the second & in the declaration
+atomic_itype& operator=(const atomic_itype &) = delete;
+</description>
+<suggestion>
+Remove the space.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="159" type="Editorial" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.5.1
+</section>
+<para></para>
+<description>
+Last 2 should be compare_exchane_strong<BR/>
+> bool compare_exchange_weak(bool&, bool,
+memory_order, memory_order) volatile;<BR/>
+> bool compare_exchange_weak(bool&, bool,
+memory_order, memory_order);<BR/>
+> bool compare_exchange_strong(bool&, bool,
+memory_order, memory_order) volatile;<BR/>
+> bool compare_exchange_strong(bool&, bool,
+memory_order, memory_order);<BR/>
+> bool compare_exchange_weak(bool&, bool,
+memory_order = memory_order_seq_cst) volatile;<BR/>
+> bool compare_exchange_weak(bool&, bool,
+memory_order = memory_order_seq_cst);<BR/>
+> bool compare_exchange_weak(bool&, bool,
+memory_order = memory_order_seq_cst) volatile;<BR/>
+> bool compare_exchange_weak(bool&, bool,
+memory_order = memory_order_seq_cst);
+</description>
+<suggestion>
+Fix last 2
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="160" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomic.types.integral] 29.5.1
+</section>
+<para>
+1
+</para>
+<description>
+The last sentence of 29.5.1 [atomics.types.integral]/1 says
+"Table 143 shows typedefs to atomic integral classes and
+the corresponding typedefs." That's nice, but nothing says
+these are supposed to be part of the implementation, and
+they are not listed in the synopsis.
+</description>
+<suggestion>
+Remove Table 143 and the last sentence of
+29.5.1 [atomics.types.integral]/1.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="161" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomic.types.address] 29.5.2
+</section>
+<para>
+before 1
+</para>
+<description>
+atomic_address has operator+= and operator-=, but no
+operator++ or operator--. The template specialization
+atomic<Ty*> has all of them.
+</description>
+<suggestion>
+Add operator++(int) volatile, operator++(int),
+operator++() volatile, operator++(), operator--(int)
+volatile, operator--(int), operator--() volatile, and
+operator--() to atomic_address.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="162" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.typres.address] 29.5.2
+</section>
+<para></para>
+<description>
+The compare_exchange_weak and
+compare_exchange_strong member functions that take
+const void* arguments lead to a silent removal of const,
+because the load member function and other acessors
+return the stored value as a void*.
+</description>
+<suggestion>
+Remove the const void* overloads of
+compare_exchange_weak and
+compare_exchange_strong
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="163" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.type.address], [atomics.types.generic] 29.5.2, 29.5.3
+</section>
+<para></para>
+<description>
+Requiring atomic<Ty*> to be derived from atomic_address
+breaks type safety:
+<PRE>
+atomic<double*> ip;
+char ch;
+atomic_store(&ip, &ch);
+*ip.load() = 3.14159;
+</PRE>
+The last line overwrites ch with a value of type double
+</description>
+<suggestion>
+Remove the requirement that atomic<Ty*> be
+derived from atomic_address.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="164" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.types.address] 29.5.2
+</section>
+<para>
+before 1
+</para>
+<description>
+atomic_address has member functions
+compare_exchange_weak and
+compare_exchange_strong that take arguments of type
+const void*, in addition to the void* versions. If these
+member functions survive, there should be corresponding
+free functions.
+</description>
+<suggestion>
+Add atomic_compare_exchange_weak and
+atomic_compare_exchange_strong free functions
+taking pointers to volatile and non-volatile
+atomic_address objects and const void*
+arguments.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="56" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.5.3
+</section>
+<para>
+3
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "table 142 or table 143" to "Table 142 or
+Table 143".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="133" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.5.3
+</section>
+<para></para>
+<description>
+The free functions that operate on atomic_address can be
+used to store a pointer to an unrelated type in an
+atomic<T*> without a cast. e.g.
+<PRE>
+int i;
+atomic<int*> ai(&i);
+string s;
+atomic_store(&ai,&s);
+</PRE>
+</description>
+<suggestion>
+Overload the atomic_store, atomic_exchange and
+atomic_compare_exchange_[weak/strong]
+operations for atomic<T*> to allow storing only
+pointers to T:
+<PRE>
+template<typename T>
+void atomic_store(atomic<T*>&,T*);
+template<typename T>
+void atomic_store(atomic<T*>&,void*) = delete;
+template<typename T>
+void
+atomic_store_explicit(atomic<T*>&,T*,memory_or
+der);
+template<typename T>
+void
+atomic_store_explicit(atomic<T*>&,void*,memory
+_order) = delete;
+template<typename T>
+T* atomic_exchange(atomic<T*>&,T*);
+template<typename T>
+T* atomic_exchange(atomic<T*>&,void*) = delete;
+template<typename T>
+T*
+atomic_exchange_explicit(atomic<T*>&,T*,memor
+y_order);
+template<typename T>
+T*
+atomic_exchange_explicit(atomic<T*>&,void*,me
+mory_order) = delete;
+template<typename T>
+T*
+atomic_compare_exchange_weak(atomic<T*>&,T
+**,T*);
+template<typename T>
+T*
+atomic_compare_exchange_weak(atomic<T*>&,v
+oid**,void*) = delete;
+template<typename T>
+T*
+atomic_compare_exchange_weak_explicit(atomic
+<T*>&,T**,T*,memory_order);
+template<typename T>
+T*
+atomic_compare_exchange_weak_explicit(atomic
+<T*>&,void**,void*,memory_order) = delete;
+template<typename T>
+T*
+atomic_compare_exchange_strong(atomic<T*>&,
+T**,T*);
+template<typename T>
+T*
+atomic_compare_exchange_strong(atomic<T*>&,
+void**,void*) = delete;
+template<typename T>
+T*
+atomic_compare_exchange_strong_explicit(atomi
+c<T*>&,T**,T*,memory_order);
+template<typename T>
+T*
+atomic_compare_exchange_strong_explicit(atomi
+c<T*>&,void**,void*,memory_order) = delete;
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="165" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.5.3
+</section>
+<para>
+Paragraph 23
+</para>
+<description>
+“is the same that same as that of” is not grammatical (and
+is not clear)
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="166" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 2
+</para>
+<description>
+The first three bullets seem to be missing terminal
+punctuation.
+</description>
+<suggestion>
+Add semicolons to ends of the bullets.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="167" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 3
+</para>
+<description>
+The first three bullets seem to be missing terminal
+punctuation.
+</description>
+<suggestion>
+Add semicolons to ends of the bullets.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="168" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 4
+</para>
+<description>
+The definition of the default constructor needs exposition.
+</description>
+<suggestion>
+Add a new paragraph: A::A() = default; Effects:
+Leaves the atomic object in an uninitialized state.
+[Note: These semantics ensure compatiblity with
+C. --end note]
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="169" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 5
+</para>
+<description>
+The definition of ATOMIC_VAR_INIT should be
+'implementation defined' rather than 'see below'.
+</description>
+<suggestion>
+Change it to 'implementation defined'.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="170" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 6
+</para>
+<description>
+The definition of atomic_init should be grouped with the
+value constructor.
+</description>
+<suggestion>
+Move the atomic_init definition to just after the
+constructor definition.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="134" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+5
+</para>
+<description>
+Some of the declarations of is_lock_free seem to be
+missing return types.
+</description>
+<suggestion>
+Replace:<BR/>
+A::is_lock_free() const volatile;<BR/>
+A::is_lock_free() const;<BR/>
+With:<BR/>
+bool A::is_lock_free() const volatile;<BR/>
+bool A::is_lock_free() const;
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="171" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 6
+</para>
+<description>
+The atomic_init definition "Non-atomically assigns the
+value" is not quite correct, as the atomic_init purpose is
+initialization.
+</description>
+<suggestion>
+Change "Non-atomically assigns the value desired
+to *object." with "Initializes *object with value
+desired". Add the note: "[Note: This function
+should only be applied to objects that have been
+default constructed. These semantics ensure
+compatibility with C. --end note]"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="172" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 9, 13, 17, 20
+</para>
+<description>
+The order specifications are incomplete because the non-
+_explicit functions do not have such parameters.
+</description>
+<suggestion>
+Add a new sentence: "If the program does not
+specify an order, it shall be
+memory_order_seq_cst." Or perhaps: "The non-
+_explicit non-member functions shall affect
+memory as though they were _explicit with
+memory_order_seq_cst."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="173" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 20
+</para>
+<description>
+Misspelling.
+</description>
+<suggestion>
+Replace "operations ate atomic" with "operations
+are atomic".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="174" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 22
+</para>
+<description>
+The first note is about effects, not returns.
+</description>
+<suggestion>
+Move this note to just after the Effects paragraph.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="175" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 23
+</para>
+<description>
+The first sentence is grammatically incorrect.
+</description>
+<suggestion>
+Replace the sentence with two: "The weak
+compare-and-exchange operations may fail
+spuriously. That is, it may return false while
+leaving the contents of memory pointed to by
+expected the same as it was before the
+operation."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="23" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+p23
+</para>
+<description>
+The first sentence has non-English syntax.
+</description>
+<suggestion>
+Change to "The weak compare-and-exchange
+operations may fail spuriously, that is, return false
+while leaving the contents of memory pointed to
+by expected unchanged."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="176" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+para 23
+</para>
+<description>
+Unintended paragraph break.
+</description>
+<suggestion>
+Proposal: Remove the paragraph break between
+"will be in a loop." and "When a compare-andexchange
+is in a loop,".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="177" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[atomics.types.operations] 29.6
+</section>
+<para>
+23
+</para>
+<description>
+The first sentence of this paragraph doesn't make sense.
+</description>
+<suggestion>
+Figure out what it's supposed to say, and say it.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="135" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para>
+23
+</para>
+<description>
+The first sentence of 29.6p23 was changed by n2992 but
+now makes no sense: "that is, return false while leaving
+the contents of memory pointed to by expected before the
+operation is the same that same as that of the object and
+the same as that of expected after the operation."
+There's a minor editorial difference between n2992 ("is
+that same as that" vs "is the same that same as that") but
+neither version makes sense.
+Also, the remark talks about "object" which should
+probably be "object or this" to cover the member functions
+which have no object parameter.
+</description>
+<suggestion>
+Fix the Remark to say whatever was intended.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.6
+</section>
+<para></para>
+<description>
+See (K) in attachment Appendix 1 - Additional Details
+</description>
+<suggestion>
+GB requests normative clarification in 29.6p4 that
+concurrent access constitutes a race, as already
+done on p6 and p7.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="178" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.7
+</section>
+<para>
+para 7
+</para>
+<description>
+The sentence "The order argument shall not be
+memory_order_acquire nor memory_order_acq_rel." is
+awkwardly phrased.
+</description>
+<suggestion>
+Change the sentence to "The order argument
+shall be neither memory_order_acquire nor
+memory_order_acq_rel."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="179" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.8
+</section>
+<para>
+para 5, 6
+</para>
+<description>
+The fence functions should be extern "C", for C
+compatibility.
+</description>
+<suggestion>
+Add extern "C" to their declarations in 29.8 and in
+29.2.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="137" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+29.8
+</section>
+<para>
+6
+</para>
+<description>
+Thread fence not only establish synchronizes with
+relationships,
+there are semantics of fences that are expressed not in
+terms of
+synchronizes with relationships (for example see 29.3p5).
+These semantics also need to apply to the use of
+atomic_signal_fence in a restricted way.
+</description>
+<suggestion>
+Change 29.8p6 to "Effects: equivalent to
+atomic_thread_fence(order), except that the
+resulting ordering constraints are
+established only between a thread and a signal
+handler executed in the same thread."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="180" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.1
+</section>
+<para>
+para 1
+</para>
+<description>
+The introductory sentence is missing futures.
+</description>
+<suggestion>
+Replace "communicate conditions between
+threads" with "communicate conditions and values
+between threads".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="138" type="Te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.2
+</section>
+<para></para>
+<description>
+The FCD combines the requirements for lockable objects
+with those for the standard mutex objects. These should
+be separate. This is LWG issue 1268.
+</description>
+<suggestion>
+See attached Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="181" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.2.4
+</section>
+<para>
+para 2
+</para>
+<description>
+The timeout operations are under-specified.
+</description>
+<suggestion>
+Define precise semantics for timeout_until and
+timeout_for. See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="182" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[thread.req.native] 30.2.3
+</section>
+<para></para>
+<description>
+native_handle and native-handle_type should be
+removed. It is implementation-defined whether these
+names are present in the various thread support classes,
+and if present, it is implementation-defined what the name
+native_handle_type refers to. This is exactly what the
+implementor namespace is for. There is no benefit to
+programmers from providing a way to portably detect that
+an implementation provides non-portable extensions. The
+standard should not reserve these names, with
+unspecified semantics; it if does, the names will never
+become portable because implementations will differ on
+what they mean.
+</description>
+<suggestion>
+Remove [thread.req.native] 30.2.3 and remove all
+mentions of native_handle and
+native_handle_type.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="DE" num="23" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.3
+</section>
+<para></para>
+<description>
+Predefined macros usually start and end with two
+underscores, see 16.8 and FDIS 29124 = WG21 N3060
+clause 7. __STDCPP_THREADS should blend in.
+</description>
+<suggestion>
+Change the macro name to
+__STDCPP_THREADS__.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="183" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.3.1
+</section>
+<para></para>
+<description>
+There is no way to join a thread with a timeout.
+</description>
+<suggestion>
+Add join_for and join_until. Or decide one should
+never join a thread with a timeout since
+pthread_join doesn't have a timeout version.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="184" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.3.1.1
+</section>
+<para>
+para 2
+</para>
+<description>
+It is unclear when a thread::id ceases to be meaningful.
+The sentence "The library may reuse the value of a
+thread::id of a terminated thread that can no longer be
+joined." implies that some terminated threads can be
+joined. It says nothing about detached threads.
+</description>
+<suggestion>
+Require a unique thread::id for every thread that is
+(1) detached and not terminated or (2) has an
+associated std::thread object.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="98" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.3.1.5
+</section>
+<para>
+9
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="99" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.3.1.5
+</section>
+<para>
+14
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="24" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.3.2
+</section>
+<para>
+p1
+</para>
+<description>
+What would be the value this_thread::get_id() when called
+from a detached thread?
+</description>
+<suggestion>
+Add some text to clarify that get_id() still returns
+the same value even after detaching.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="25" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.3.2
+</section>
+<para>
+p8 and p11
+</para>
+<description>
+Clock related operations are currently not required not to
+throw. So "Throws: Nothing." is not always true.
+</description>
+<suggestion>
+Either require clock related operations not to throw
+(in 20.10) or change the Throws clauses in 30.3.2.
+Also possibly add a note that abs_time in the past
+or negative rel_time is allowed.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="185" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4
+</section>
+<para></para>
+<description>
+Cooperate with WG14 to improve interoperability between
+the C++0x and C1x threads APIs. In particular, C1x
+mutexes should be conveniently usable with a C++0x
+lock_guard. Performance overheads for this combination
+should be considered.
+</description>
+<suggestion>
+Remove C++0x timed_mutex and
+timed_recursive_mutex if that facilitates
+development of more compatible APIs.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="26" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4
+</section>
+<para></para>
+<description>
+Specifications of unlock member functions and unlock
+mutex requirements are inconsistent wrt to exceptions and
+pre- and postconditions.
+</description>
+<suggestion>
+unlock should specifiy the precondition that the
+current thread "owns the lock", this will make calls
+without holding the locks "undefined behavior".
+unlock in [mutex.requirements] should either be
+noexcept(true) or be allowed to throw
+system_error like unique_lock::unlock, or the latter
+should be nothrow(true) and have the precondition
+owns==true.
+Furthermore unique_lock's postcondition is wrong
+in the case of a recursive mutex where owns
+might stay true, when it is not the last unlock
+needed to be called.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="27" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1
+</section>
+<para>
+p18
+</para>
+<description>
+The mutex requirements force try_lock to be
+noexcept(true). However, where they are used by the
+generic algorithms, those relax this requirement and say
+that try_lock may throw. This means the requirement is
+too stringent, also a non-throwing try_lock does not allow
+for a diagnostic such as system_error that lock() will give
+us.
+</description>
+<suggestion>
+delete p18, adjust 30.4.4 p1 and p4 accordingly
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="99" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1
+</section>
+<para>
+11
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="186" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1
+</section>
+<para>
+14
+</para>
+<description>
+try_lock does not provide a guarantee of forward progress
+because it is allowed to spuriously fail.
+</description>
+<suggestion>
+The standard mutex types must not fail spuriously
+in try_lock. See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="187" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1
+</section>
+<para>
+14
+</para>
+<description>
+Paragraph mentions compare_exchange, which no longer
+exists.
+</description>
+<suggestion>
+Change “compare_exchange” to
+“compare_exchange_weak”.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="57" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1
+</section>
+<para>
+14
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(29)" to "(Clause 29)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="188" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1
+</section>
+<para>
+20, 21
+</para>
+<description>
+Mutex requirements should not be bound to threads
+</description>
+<suggestion>
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="58" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1.1
+</section>
+<para>
+3
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(9)" to "(Clause 9)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="189" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1.1 30.4.1.2
+</section>
+<para></para>
+<description>
+mutex and recursive_mutex should have an is_locked()
+member function. is_locked allows a user to test a lock
+without acquiring it and can be used to implement a lightweight
+try_try_lock.
+</description>
+<suggestion>
+Add a member function:
+<PRE>
+bool is_locked() const;
+</PRE>
+to std::mutex and std::recursive_mutex. These
+functions return true if the current thread would
+not be able to obtain a mutex. These functions do
+not synchronize with anything (and, thus, can
+avoid a memory fence).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="59" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.1.2
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(9)" to "(Clause 9)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="60" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.2.1
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(9)" to "(Clause 9)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="61" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.2.2
+</section>
+<para>
+2
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(9)" to "(Clause 9)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="70" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.3.2
+</section>
+<para>
+18
+</para>
+<description>
+Constant width font should be used for
+"std::system_error"s in the paragraph as described in
+Syntax notation (1.6).
+</description>
+<suggestion>
+Change the font for "std::system_error" to
+constant width type.<BR/>
+Throws: <B><TT>system_error</TT></B> when an exception is
+required
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="100" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.3.2.2
+</section>
+<para>
+18
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="190" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.5.2
+</section>
+<para>
+para 2, 3
+</para>
+<description>
+The term "are serialized" is never defined.
+</description>
+<suggestion>
+Remove the sentence with "are serialized" from
+paragraph 2. Add "Calls to call_once on the same
+once_flag object shall not introduce data races
+(17.6.4.8)." to paragraph 3.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="101" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.4.5.2
+</section>
+<para>
+4
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="191" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5
+</section>
+<para></para>
+<description>
+The condition variable wait_for returning cv_status is
+insufficient.
+</description>
+<suggestion>
+Return a duration of timeout remaining instead.
+See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="139" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5
+</section>
+<para>
+7
+</para>
+<description>
+The text says "... ownership of the lock as the current
+thred exits, ...", with "thread" misspelled.
+</description>
+<suggestion>
+Replace "thred" with "thread"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="140" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5
+</section>
+<para>
+9
+</para>
+<description>
+The text says "... waiting threds ..." with "threads"
+misspelled.
+</description>
+<suggestion>
+Replace "threds" with "threads".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="28" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1
+</section>
+<para></para>
+<description>
+Requiring wait_until makes it impossible to implement
+condition_variable correctly using respective objects
+provided by the operating system (i.e. implementing the
+native_handle() function) on many platforms (e.g. POSIX,
+Windows, MacOS X) or using the same object as for the
+condition variable proposed for C.
+</description>
+<suggestion>
+Remove the wait_until functions or make them at
+least conditionally supported.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="102" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1
+</section>
+<para>
+3
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="30" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1 and 30.5.2
+</section>
+<para>
+p13, last bullet, and corresponding paragraphs in all wait functions
+</para>
+<description>
+If lock.lock() throws an exception, the postcondition can
+not be generally achieved.
+</description>
+<suggestion>
+Either state that the postcondition might not be
+achieved, depending on the error condition, or
+state that terminate() is called in this case.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="103" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1
+</section>
+<para>
+15
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="31" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1 and 30.5.2
+</section>
+<para>
+p19, third bullet, and corresponding paragraphs in all wait_for/wait_until functions
+</para>
+<description>
+The sentences contain superflous "or"s.
+</description>
+<suggestion>
+Change "The function will unblock when signaled
+by a call to notify_one() or a call to notify_all(), if
+abs_time <= Clock::now(), or spuriously." to "The
+function will unblock when signaled by a call to
+notify_one(), a call to notify_all(), if abs_time <=
+Clock::now(), or spuriously."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="104" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1
+</section>
+<para>
+22
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="192" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1
+</section>
+<para>
+para 26
+</para>
+<description>
+The identifier cv_status::no_timeout is not in code font.
+</description>
+<suggestion>
+Change it to code font.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="29" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1 and 30.5.2
+</section>
+<para>
+p34 and p28, respectively
+</para>
+<description>
+It is unclear if a spurious wake-up during the loop and reentering
+of the blocked state due to a repeated execution
+of the loop will adjust the timer of the blocking with the
+respect to the previously specified rel_time value.
+</description>
+<suggestion>
+Make it clear (e.g. by a note) that when reexecuting
+the loop the waiting time when blocked
+will be adjusted with respect to the elapsed time of
+the previous loop executions.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="193" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1, 30.5.2
+</section>
+<para></para>
+<description>
+Condition variables preclude a wakeup optimization.
+</description>
+<suggestion>
+Change condition_variable to allow such
+optimization. See Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="62" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.1
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(9)" to "(Clause 9)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="32" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.2
+</section>
+<para></para>
+<description>
+Given that the lock type can be something the underlying
+doesn't know 'native_handle()' is probably
+unimplementable on essentially all platforms.
+</description>
+<suggestion>
+Consider the removal of 'native_handle()'.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="105" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.2
+</section>
+<para>
+12
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="106" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.2
+</section>
+<para>
+18
+</para>
+<description>
+In Throw clause, both "Throws: system_error" and
+"Throws: std::system_error" are used. They should be in a
+unified way, and we propose to use system_error instead
+of std::system_error.
+</description>
+<suggestion>
+Change to:<BR/>
+Throws: system_error
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="33" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.2
+</section>
+<para>
+before p25
+</para>
+<description>
+Template function wait_until is missing class Clock
+template parameter.
+</description>
+<suggestion>
+Change "template <class Lock, class Duration,
+class Predicate>" to "template <class Lock, class
+Clock, class Duration, class Predicate>".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="96" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.5.3
+</section>
+<para>
+2
+</para>
+<description>
+Inconsistency between 30.4 paragraph 1 and 30.4.3
+paragraph 2.
+In 30.4 paragraph 1:
+<PRE>
+namespace std {
+...
+constexpr defer_lock_t defer_lock { };
+constexpr try_to_lock_t try_to_lock { };
+constexpr adopt_lock_t adopt_lock { };
+}
+</PRE>
+In 30.4.3 paragraph 2:
+<PRE>
+namespace std {
+...
+extern const defer_lock_t defer_lock { };
+extern const try_to_lock_t try_to_lock { };
+extern const adopt_lock_t adopt_lock { };
+}
+</PRE>
+The writer seems to have forgotten to rewrite latter cases,
+so 30.4.3 paragraph 2 should be modified as this
+proposal.
+</description>
+<suggestion>
+Change "extern const" to "constexpr".
+<PRE>
+namespace std {
+...
+constexpr defer_lock_t defer_lock { };
+constexpr try_to_lock_t try_to_lock { };
+constexpr adopt_lock_t adopt_lock { };
+}
+</PRE>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="194" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6
+</section>
+<para></para>
+<description>
+The specification for managing associated asynchronous
+state is confusing, sometimes omitted, and redundantly
+specified.
+</description>
+<suggestion>
+Define terms-of-art for releasing, making ready,
+and abandoning an associated asynchronous
+state. Use those terms where appropriate. See
+Appendix 1 - Additional Details
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="34" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.1
+</section>
+<para>
+p1
+</para>
+<description>
+The paragraph is misleading and incorrect wrt to the
+current specification, since an async call with launch::sync
+will execute in the same thread.
+</description>
+<suggestion>
+Change the paragraph to '30.6 describes
+components that a C++ program can use to
+retrieve the result (value or exception) of a
+function that has run in a (potentially different)
+thread.'
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="195" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.4
+</section>
+<para>
+para 8
+</para>
+<description>
+The intent and meaning of the paragraph is not apparent.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="35" type="ed/te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.4ff
+</section>
+<para></para>
+<description>
+The term "associated asynchronous state" is long, ugly
+and misleading terminology. When introduced we agreed
+upon that we should come up with a better name. Here it
+is: "liaison state". Since the state is hidden and provides
+synchronization of a future with its corresponding promise,
+we believe "liaison state" is a much better and shorter
+name (liaison ~ (typically hidden) relationship)
+</description>
+<suggestion>
+Change all occurrences of "associated
+asynchronous state" to "liaison state".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="196" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.5
+</section>
+<para>
+para 21, 25
+</para>
+<description>
+The term "are serialized" is not defined.
+</description>
+<suggestion>
+Replace "are serialized" with "shall not introduce a
+data race (17.6.4.8)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="197" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.5
+</section>
+<para>
+para 21, 25
+</para>
+<description>
+There is no defined synchronization between
+promise::set_value and future::get.
+</description>
+<suggestion>
+Replace "[Note: and they synchronize and
+serialize with other functions through the referred
+associated asynchronous state. --end note]" with
+the normative "They synchronize with (1.10) any
+operation on a future object with the same
+associated asynchronous state marked ready."
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="198" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.5
+</section>
+<para>
+22
+</para>
+<description>
+promise::set_exception can be called with a null pointer,
+but none of the descriptions of the get() functions for the
+three types of futures say what happens for this case.
+</description>
+<suggestion>
+Add the following sentence to the end of
+30.6.5/22: The behavior of a program that calls
+set_exception with a null pointer is undefined.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="199" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[futures.promise] 30.6.5
+</section>
+<para>
+26ff, 29ff
+</para>
+<description>
+promise::XXX_at_thread_exit functions have no
+synchronization requirements. Specifying synchronization
+for these member functions requires coordinating with the
+words in 30.6.5/21 and 25, which give synchronization
+requirements for promise::set_value and
+promise::set_exception.
+</description>
+<suggestion>
+Change 30.6.5/21 to mention
+set_value_at_thread_exit and
+set_exception_at_thread_exit; with this text,
+replace 30.6.5/25 and add two new paragraphs,
+after 30.6.5/28 and 30.6.5/31.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="200" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.6
+</section>
+<para>
+para 26
+</para>
+<description>
+The paragraph is missing the "Returns:" label.
+</description>
+<suggestion>
+Add the label.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="201" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[futures.unique_future], [futures.shared_future], [futures.atomic_future], [futures.task] 30.6.6 30.6.7 30.6.8 30.6.10
+</section>
+<para></para>
+<description>
+packaged_task provides operator bool() to check whether
+an object has an associated asynchronous state. The
+various future types provide a member function valid() that
+does the same thing. The names of these members
+should be the same.
+</description>
+<suggestion>
+Replaced the name packaged_task::operator
+bool() with packaged_task::valid() in the synopsis
+(30.6.10 [futures.task]/2) and the member function
+specification (before 30.6.10.1
+[futures.task.members]/15).
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="202" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[futures.atomic_future] 30.6.8
+</section>
+<para>
+18
+</para>
+<description>
+The note in this paragraph says "unlike future, calling get
+more than once on the same atomic_future object is well
+defined and produces the result again." There is nothing
+in future that says anything negative about calling get
+more than once.
+</description>
+<suggestion>
+Remove this note, or add words to the
+requirements for future that reflect what this note
+says.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="203" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[futures.atomic_future] 30.6.8
+</section>
+<para></para>
+<description>
+Both future and shared_future specify that calling most
+member functions on an object for which valid() == false
+produces undefined behavior. There is no such statement
+for atomic_future.
+</description>
+<suggestion>
+Add a new paragraph after 30.6.8
+[futures.atomic_future]/2 with the same words as
+30.6.7 [futures.shared_future]/3.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="204" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.8
+</section>
+<para>
+Paragraph 7-8
+</para>
+<description>
+According to the definition of atomic_future, all members
+of atomic_future are synchronizing except constructors.
+However, it would probably be appropriate for a move
+constructor to be synchronizing on the source object. If
+not, the postconditions on paragraphs 7-8, might not be
+satisfied. This may be applicable if a collection of futures
+are being doled out to a set of threads that process their
+value.
+</description>
+<suggestion>
+Make the move constructor for atomic future lock
+the source
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="205" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[futures.async] 30.6.9
+</section>
+<para>
+3
+</para>
+<description>
+The third sentence says "If the invocation is not deferred,
+a call to a waiting function on an asynchronous return
+object that shares the associated asynchronous state
+created by this async call shall block until the associated
+thread has completed." The next sentence says "If the
+invocation is not deferred, the join() on the created
+thread..." Blocking until a thread completes is not
+necessarily a join.
+</description>
+<suggestion>
+Decide whether the requirement is to block until
+finished or to call join, and rewrite to match.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="CH" num="36" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.9 and 30.6.1
+</section>
+<para>
+<future> synopsis and p3, respectively
+</para>
+<description>
+Providing only three different possible values for the enum
+launch and saying that launch::any means either
+launch::sync or launch::async is very restricting. This
+hinders future implementors to provide clever
+infrastructures that can simply by used by a call to
+async(launch::any,...). Also there is no hook for an
+implementation to provide additional alternatives to launch
+enumeration and no useful means to combine those (i.e.
+interpret them like flags). We believe something like
+async(launch::sync | launch::async, ...) should be allowed
+and can become especially useful if one could say also
+something like async(launch::any & ~launch::sync, ....)
+respectively. This flexibility might limit the features usable
+in the function called through async(), but it will allow a
+path to effortless profit from improved hardware/software
+without complicating the programming model when just
+using async(launch::any,...)
+</description>
+<suggestion>
+Change in 30.6.1 'enum class launch' to allow
+further implementation defined values and provide
+the following bit-operators on the launch values
+(operator|, operator&, operator~ delivering a
+launch value).<BR/>
+Note: a possible implementation might use an
+unsigned value to represent the launch enums,
+but we shouldn't limit the standard to just 32 or 64
+available bits in that case and also should keep
+the launch enums in their own enum namespace.<BR/>
+Change [future.async] p3 according to the
+changes to enum launch. change --launch::any to
+"the implementation may choose any of the
+policies it provides." Note: this can mean that an
+implementation may restrict the called function to
+take all required information by copy in case it will
+be called in a different address space, or even, on
+a different processor type. To ensure that a call is
+either performed like launch::async or
+launch::sync describe one should call
+async(launch::sync|launch::async,...)
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="107" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.9
+</section>
+<para>
+3
+</para>
+<description>
+Typo, "." should be ">".
+decay_copy(std::forward<Args.(args))...
+</description>
+<suggestion>
+Correct typo.
+decay_copy(std::forward<Args>(args))...
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="108" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+30.6.9
+</section>
+<para>
+3
+</para>
+<description>
+<Arg> should be <Args>.
+launch::sync Stores decay_copy(std::forward<F>(f))
+and
+decay_copy(std::forward<Arg>(args))...
+</description>
+<suggestion>
+Change to:<BR/>
+launch::sync Stores
+decay_copy(std::forward<F>(f)) and
+decay_copy(std::forward<Args>(args))...
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="206" type="ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[futures.task.members] 30.6.10.1
+</section>
+<para>
+27, 28
+</para>
+<description>
+The text of paragraph 27 says that reset() moves the
+function object, but the text of paragraph 28 talks about
+exceptions thrown by the copy constructor.
+</description>
+<suggestion>
+Change "copy constructor" to "move constructor"
+in 30.6.10.1/28, bullet 2.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="207" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[futures.task.members] 30.6.10.1
+</section>
+<para>
+1-8
+</para>
+<description>
+The constructor that takes R(*)(ArgTypes...) is not
+needed; the constructor that takes a callable type works
+for this argument type. More generally, the constructors
+for packaged_task should parallel those for function.
+</description>
+<suggestion>
+Review the constructors for packaged_task and
+provide the same ones as function, except where
+inappropriate.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="US" num="208" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+[futures.task.members] 30.6.10.1
+</section>
+<para>
+24-26
+</para>
+<description>
+packaged_task::make_ready_at_thread_exit has no
+synchronization requirements.
+</description>
+<suggestion>
+Figure out what the synchronization requirements
+should be and write them.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="141" type="Ed" owner="" issue="" disp="" date="" extdoc="">
+<section>
+Appendix A [gram] paragraph 1
+</section>
+<para></para>
+<description>
+The links for disambiguation rules go to 6.8, 7.1 and 10.2.
+Section 8.2 covers ambiguity in declarators, so should be
+added
+</description>
+<suggestion>
+Added a link to 8.2 [dcl.ambig.res] to Appendix A
+p1
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="63" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+A.1
+</section>
+<para>
+1
+</para>
+<description>
+Representations of reference link are not unified.
+Most reference links to clause (table) number, say X, are
+in the form "Clause X" ("Table X") capitalized, and
+subsection Y.Y.Y is referenced with its number only in the
+form "Y.Y.Y". Whether they are parenthesized or not
+depends on the context.
+However there are some notations "(Z)" consisting of only
+a number Z in parentheses to confer Clause or Table
+number Z.
+</description>
+<suggestion>
+Change "(clause 9)" to "(Clause 9)".
+Change "(clause 14)" to "(Clause 14)".
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="FI" num="6" type="te" owner="" issue="" disp="" date="" extdoc="">
+<section>
+D.2 [depr.static]
+</section>
+<para>
+Paragraph 1
+</para>
+<description>
+The use of static in namespace scope should not be
+deprecated. Anonymous namespaces are not a sufficient
+replacement for the functionality.
+</description>
+<suggestion>
+Strike [depr.static] completely.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="GB" num="142" type="Ge" owner="" issue="" disp="" date="" extdoc="">
+<section>
+D10
+</section>
+<para></para>
+<description>
+auto_ptr does not appear in the <memory> synopsis and
+[depr.auto.ptr] doesn't say which header declares it.
+Conversely, the deprecated binders bind1st etc. are in the
+<functional> synopsis, this is inconsistent
+</description>
+<suggestion>
+Either auto_ptr should be declared in the
+<memory> synopsis, or the deprecated binders
+should be removed from the <functional> synopsis
+and appendix D should say which header declares
+the binders and auto_ptr
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="109" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+Annex B
+</section>
+<para></para>
+<description>
+Although implementation limits for at_quick_exit() is
+mentioned in 18.5 paragraph 5, it is not on the list of
+Implementation quantities.
+</description>
+<suggestion>
+Add the following line.
+— Functions registered by at_quick_exit()[32].
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+<comment nb="JP" num="110" type="E" owner="" issue="" disp="" date="" extdoc="">
+<section>
+Index
+</section>
+<para></para>
+<description>
+"local scope" has been renamed to "block scope", but the
+reference to "local scope" still remains in Index.<BR/>
+block scope; see local scope, 37<BR/>
+"local scope" should refer to "block scope".
+</description>
+<suggestion>
+Change to:<BR/>
+local scope; see block scope, 37
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+</document>

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r64769 - sandbox/committee/LWG/FCD"
Previous message: boris_at_[hidden]: "[Boost-commit] svn:boost r64767 - in sandbox/SOC/2010/process: boost/process/detail libs/process/test libs/process/test/inclusion"

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