[Boost-commit] svn:boost r51827 - sandbox/committee/LWG/cd_status

Subject: [Boost-commit] svn:boost r51827 - sandbox/committee/LWG/cd_status
From: bdawes_at_[hidden]
Date: 2009-03-18 06:53:45

Author: bemandawes
Date: 2009-03-18 06:53:41 EDT (Wed, 18 Mar 2009)
New Revision: 51827
URL: http://svn.boost.org/trac/boost/changeset/51827

Log:
Initial commit
Added:
   sandbox/committee/LWG/cd_status/comments.xml   (contents, props changed)

Added: sandbox/committee/LWG/cd_status/comments.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/LWG/cd_status/comments.xml	2009-03-18 06:53:41 EDT (Wed, 18 Mar 2009)
@@ -0,0 +1,22944 @@
+<?xml  version="1.0"?>
+
+<document
+  date="2009-03-13"
+  rev="0"
+  docno="PL22.16 09/xxxx = WG21 Nyyyy"
+>
+
+<comment
+  nb="FR"
+  num="1"
+  uknum=""
+  type="ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+General Comment
+</section>
+<para>
+</para>
+<description>
+        Interactions between several
+        new features appear obscure, and very few examples are
+        offered to guide understanding of the formal text on
+        interaction between these new additions.
+        We worry about the complexity
+        of the programming model so created.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="1"
+  uknum=""
+  type="ge/te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1-16
+</section>
+<para>
+</para>
+<description>
+        The
+        active issues identified in WG21 N2803, C++ Standard Core
+        Language Active Issues, must be addressed and appropriate
+        action taken.
+        <BR/>
+        <a href=
+        "http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html">
+        http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html>
+</description>
+<suggestion>
+        Appropriate action would include making changes to the CD,
+        identifying an issue as not requiring a change to the CD,
+        or deferring the issue to a later point in time.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="CA"
+  num="1"
+  uknum=""
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+</section>
+<para>
+</para>
+<description>
+        There are quite a number of defects for the current CD
+        recorded in SC22/WG21-N2803 and N2806
+</description>
+<suggestion>
+        Consider these comments and update ISO/IEC CD 14882
+        accordingly
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="1"
+  uknum=""
+  type="ge/te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1 through 16
+</section>
+<para>
+</para>
+<description>
+        DE-1 Consider addressing a significant part of the
+        unresolved core language issues presented in WG21 document
+        N2791 "C++ Standard Core Language Active Issues, Revision
+        59", available at
+        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
+        .
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="CH"
+  num="2"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+all
+</section>
+<para>
+</para>
+<description>
+        The issues on the issues lists shall be addressed before
+        the standard becomes final.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="3"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+all
+</section>
+<para>
+</para>
+<description>
+        Latin abbreviations are presented incorrectly.
+</description>
+<suggestion>
+        Italicize all
+        Latin abbreviations, append commas after each occurrence of
+        <i>i.e</i>. and <i>e.g.</i>, and remove extraneous space
+        after each such abbreviation.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="3"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1 [intro.scope]
+</section>
+<para>
+2
+</para>
+<description>
+        C++ is split at the end of line.
+</description>
+<suggestion>
+        
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="4"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.1
+</section>
+<para>
+2
+</para>
+<description>
+        There is a bad line break in
+        "C++".
+</description>
+<suggestion>
+        
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="1"
+  uknum="214"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.1
+</section>
+<para>
+2
+</para>
+<description>
+        List of additional facilities over C has
+        been extended with this standard, so should be mentioned in
+        the introductory material.
+</description>
+<suggestion>
+        Add the following to the list in 1.1p2:
+        atomic operations concurrency alignment control
+        user-defined literals attributes
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="4"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.2 [intro.refs]
+</section>
+<para>
+1
+</para>
+<description>
+        Is the lack of reference to ISO/CEI 9899/AC3:2007
+        voluntary?
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="2"
+  uknum="215"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.2
+</section>
+<para>
+1
+</para>
+<description>
+        <span lang="en-US">We recommend taking the latest update to
+        each listed standard, yet the C standard is quite
+        deliberately held back to the 1990 version without
+        comment.+</span>
+</description>
+<suggestion>
+        ... not sure ...
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="3"
+  uknum="217"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.3.1
+</section>
+<para>
+</para>
+<description>
+        The definition of an argument does not seem
+        to cover many assumed use cases, and we believe that is not
+        intentional.
+</description>
+<suggestion>
+        Revise the
+        definition of argument to answer question such as: Are
+        lambda-captures arguments? Are type names in a throw-spec
+        arguments? 'Argument' to casts, typeid, alignof, alignas,
+        decltype and sizeof? why in x[arg] : arg is not an
+        agrument, but the value forwarded to operator[]() is ? Does
+        not apply to operators as call-points not bounded by
+        parenthises ? Similar for copy initialization and
+        conversion? what are Deduced template 'arguments'? what are
+        'default arguments'? can attributes have arguments? what
+        about concepts, requires clauses and concept_map
+        instantiations? What about user-defined literals where
+        parens are not used?
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="4"
+  uknum="216"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.3.3
+</section>
+<para>
+</para>
+<description>
+        This definition is essentially worthless,
+        as it says nothing about what distinguished a diagnostic
+        message from other output messages provided by the
+        implementation
+</description>
+<suggestion>
+        ... add
+        something about the diagnostic message being a message
+        issues by the implementation when translating a program
+        that violates the rules of the standard. ...
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="5"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.3.4
+        [defns.
+        dynamic.type]
+</section>
+<para>
+</para>
+<description>
+        "The dynamic type of an rvalue expression is its static
+        type." Is this true with rvalue references?
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="5"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.3.5
+</section>
+<para>
+</para>
+<description>
+        The wording is unclear as to whether it is the input or
+        the implementation "that is not a well-formed program".
+</description>
+<suggestion>
+        Reword to clarify that it is the input that is here
+        considered not well-formed.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="6"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.3.6
+        [defns.
+        impl.defined]
+</section>
+<para>
+</para>
+<description>
+        There is a page break between the title and the
+        paragraph.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="7"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.3.13
+        [defns.
+        undefined]
+</section>
+<para>
+</para>
+<description>
+        [intro.execution]/5 explicitly allows non causal
+        undefined behaviour,
+</description>
+<suggestion>
+        Adding it to the note outlying possible undefined
+        behaviours.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="6"
+  uknum=""
+  type="ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.3.14
+</section>
+<para>
+</para>
+<description>
+        Unspecified behavior does not clearly state whether or not
+        undefined behavior is permitted. (The standard says that
+        "usually, the range of possible behaviors is delineated",
+        but what happens if the range is not delineated? Is a
+        crash, or worse, allowed?) 
+</description>
+<suggestion>
+        Clearly state whether or not
+        Unspecified behavior includes undefined behavior.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="8"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.4
+        [intro.
+        compliance]
+</section>
+<para>
+8
+</para>
+<description>
+        The paragraph as its stands seems to require that
+        violations of the ODR (which make a program ill-formed) are
+        required to be diagnosed if the program also uses an
+        extension which defines some cases of ODR.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="5"
+  uknum="1"
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.5
+</section>
+<para>
+</para>
+<description>
+        Missing checklist of implementation defined
+        behaviour (see ISO/IEC TR 10176, 4.1.1p6)
+</description>
+<suggestion>
+        Provide a new annex with the missing
+        checklist
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="6"
+  uknum="2"
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.5
+</section>
+<para>
+</para>
+<description>
+        Missing annex describing potential
+        incompatibility to previous edition of the standard (see
+        ISO/IEC TR 10176, 4.1.1p9)
+</description>
+<suggestion>
+        Provide a new annex with the missing
+        documentation. See n2733(08-0243) for a starting point
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="7"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.5
+</section>
+<para>
+2
+</para>
+<description>
+        There is no mention of Clause 17.
+</description>
+<suggestion>
+        Include Clause 17 among the list of Clauses that specify
+        the Standard Library.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="8"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.5
+</section>
+<para>
+2
+</para>
+<description>
+        The paragraph
+        omits to mention concepts and concept maps among its list
+        of entities defined in the Standard Library. 
+</description>
+<suggestion>
+        Mention concepts and concept maps among the list of
+        entities.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="9"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.6
+</section>
+<para>
+1
+</para>
+<description>
+        The
+        syntax description does not account for lines that wrap.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="10"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.7
+</section>
+<para>
+3
+</para>
+<description>
+        The term thread is used before
+        defined.
+</description>
+<suggestion>
+        <font color=
+        "#000000">R</font>eference 1.10 [intro.multithread].
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="11"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.7
+</section>
+<para>
+&#182; 3 last sent.
+</para>
+<description>
+        The phrase &#8220;threads of execution&#8221; should be
+        accompanied by a reference to [intro.multithread].
+</description>
+<suggestion>
+        Insert the recommended reference.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="12"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.7
+</section>
+<para>
+&#182; 3 first sent.
+</para>
+<description>
+        A memory location is not an object as the sentence
+        claims.
+</description>
+<suggestion>
+        Clarify that a memory location &#8220;holds&#8221; an
+        object rather than that it &#8220;is&#8221; an object.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="13"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.7
+</section>
+<para>
+&#182; 3 last sent.
+</para>
+<description>
+        It is unclear what is meant by memory locations that are
+        "separate": are they distinct? non-overlapping? how much
+        "separation" is needed?
+</description>
+<suggestion>
+        Provide either a better definition of
+        &#8220;separate&#8221; or reword (this and subsequent
+        paragraphs) to avoid this term.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="14"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.7
+</section>
+<para>
+&#182; 4
+</para>
+<description>
+        The phrase "no matter what the sizes of the intervening
+        bit-fields happen to be" contradicts the claim of
+        separation "by a zero-length bit-field declaration".
+</description>
+<suggestion>
+        Delete the &#8220;no matter&#8230;&#8221; phrase, or
+        resolve the contradiction in a different way.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="15"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.7
+</section>
+<para>
+&#182; 5
+</para>
+<description>
+        A struct does not &#8220;contain&#8221; memory
+        locations.
+</description>
+<suggestion>
+        Reword so that a struct is &#8220;held in&#8221; one or
+        more memory locations.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="16"
+  uknum=""
+  type=""
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.9
+</section>
+<para>
+</para>
+<description>
+        The discussion of observable behavior in 1.9 is not
+        consistent with the addition of threads to the language.
+        Volatile reads and writes and other observable actions no
+        longer occur in a single "sequence&#8221;.
+</description>
+<suggestion>
+        Remove/replace various occurrences of "sequence" in 1.9.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="8"
+  uknum="222"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.9
+</section>
+<para>
+5
+</para>
+<description>
+        With parallel execution there is no longer
+        the idea of a single execution sequence for a program.
+        Instead, a program may be considered a set of exectution
+        sequences.
+</description>
+<suggestion>
+        Update first sentance as: A conforming
+        implementation executing a well-formed program shall
+        produce the same observable behavior as one of the possible
+        SETS OF execution sequences of the corresponding instance
+        of the abstract machine CONFORMING TO THE MEMORY MODEL
+        (1.10) with the same program and the same input.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="7"
+  uknum="218"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.9
+</section>
+<para>
+6
+</para>
+<description>
+        Does the term 'sequence' imply all
+        reads/writes through volatile memory much be serialized,
+        and cannot occur in parallel on truly parallel hardware?
+        Allow for multiple concurrent sequences where each sequence
+        is constrained by this observable behaviour rule, and
+        multiple sequences are constrained by the memory model and
+        happens-before relationships defined in 1.10
+</description>
+<suggestion>
+        Replace 'sequence' with 'sequences'.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="9"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.9
+        [intro.execution]
+</section>
+<para>
+16
+</para>
+<description>
+        This example use int *v while the other examples seems
+        to use notation like int* v.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="17"
+  uknum=""
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+1.10
+</section>
+<para>
+1
+</para>
+<description>
+        This definition of
+        &#8220;thread&#8221; is poor, and assumes the user already
+        knows what multi-threaded means (probably true!). In
+        particular, it does not deal adequately with the concept
+        that all threads share the same address space.
+</description>
+<suggestion>
+        Replace first
+        sentence of para 1 as follows:
+<BLOCKQUOTE>
+        Under a hosted
+        implementation, a C++ program can have more than one thread
+        of execution (a.k.a. thread) running concurrently. Each
+        thread is a single flow of control within a program.
+        Anything whose address may be determined by a thread,
+        including but not limited to static objects, storage
+        obtained via new or by any dynamic allocator, directly
+        addressable storage obtained through implementation-defined
+        functions, and automatic variables, are accessible to all
+        threads in the same program.
+</BLOCKQUOTE>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="9"
+  uknum="133"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.1
+</section>
+<para>
+2, 4
+</para>
+<description>
+        Undefined behaviour is a drastic way to
+        silently ignore minor issues. The cases in this paragraph
+        could be easily defined. In this case opt for conditionally
+        supported behaviour, which mandates a diagnostic if the
+        compiler is not prepared to handle the syntax consistently.
+</description>
+<suggestion>
+        Replace
+        undefined behaviour with conditionally supported behavior.
+        Conditional behaviour may be implementation defined,
+        although suggest there is a reasonable default in each
+        case. For creating a universal-character name, splice text
+        to create a universal-character. In the case of a file
+        ending without a newline, treat as if the newline was
+        implictly added, with an empty line to follow if the last
+        character was a back-slash.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="10"
+  uknum="134"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.1
+</section>
+<para>
+3
+</para>
+<description>
+        Implementation
+        defined seems unnecessarily burdensome for negligible gain.
+        I am yet to see code that depended on whether non-empty
+        sequences of whitespace were concatenated. Better left
+        unspecified.
+</description>
+<suggestion>
+        How the compiler treats non-empty sequences
+        of whitespace should be left unspecified, rather than
+        implementation-defined.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="10"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.1 [lex.phases]/5
+        and
+        2.2 [lex.charset]/3
+</section>
+<para>
+</para>
+<description>
+        [defns.multibyte] "the
+        extended character set."
+        <BR/><BR/>[lex.charset]/3 cited below
+        implies that there is an extended character set per locale.
+        <BR/><BR/>[lex.phases]/5 "Each [...]
+        universal-character-name [...] is converted to the
+        corresponding member of the execution character set"
+        <BR/><BR/>[lex.charset]/3 "The values
+        of the members of the execution character sets are
+        implementation defined, and any additional members are
+        locale-specific."
+        <BR/><BR/>Together they seem to imply
+        that what is locale-specific is if a value is valid or not
+        for the current locale, not the representation of a given
+        universal character.
+        <BR/><BR/>This is not the behaviour of
+        at least some compilers I've access to which are allowing
+        different codes for the same abstract character in
+        different locale. During phase 5, they are using an
+        implementation defined char set.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="11"
+  uknum="135"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.3
+</section>
+<para>
+</para>
+<description>
+        Trigraphs are a complicated solution to an
+        old problem, that cause more problems than they solve in
+        the modern environment. Unexpected trigraphs in string
+        literals and occasionally in comments can be very confusing
+        for the non-expert.
+</description>
+<suggestion>
+        Deprecate the whole of 2.3 and move it to
+        appendix D.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="12"
+  uknum="137"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.4, 2.8
+</section>
+<para>
+2
+</para>
+<description>
+        This undefined
+        behaviour in token concatenation is worrying and we believe
+        hard to justify. An implementation should either support
+        this in a defined way, or issue a diagnosic. Documenting
+        existing practice should not break existing
+        implementations, although unconditionally requiring a
+        diagnostic would lead to more portable programs.
+</description>
+<suggestion>
+        Replace undefined behaviour with
+        conditionally supported behaviour with implementation
+        defined semantics.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="18"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.4
+</section>
+<para>
+&#182; 2
+</para>
+<description>
+        The paragraph begins with an empty line.
+</description>
+<suggestion>
+        Delete the empty line.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="11"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.4
+[lex.pptokens]
+</section>
+<para>
+3
+</para>
+<description>
+        There are spurious empty lines.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="12"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.5 [lex.digraph]
+and 2.11
+[lex.key]/2
+</section>
+<para>
+</para>
+<description>
+        The alternative representations are reserved as such
+        even in attribute. Is that what is wanted?
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FI"
+  num="2"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.5
+</section>
+<para>
+Table 2
+</para>
+<description>
+        Add eq, for spelling out == in order to distinguish it
+        from the assignment operator.
+</description>
+<suggestion>
+        See eq-keyword.doc, eq-keyword.ppt
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="13"
+  uknum="138"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.9
+</section>
+<para>
+2
+</para>
+<description>
+        This text is confusing in isolation, as it
+        implies pp-numbers do not have a value in translation phase
+        4 when evaluating #if preprocessor expressions.
+</description>
+<suggestion>
+        Add a note with a cross-refernce to 16.1
+        that a pp-number may briefly acquire a value during
+        translation phase 4 while evaluating #if expressions.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="14"
+  uknum="395"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.11
+</section>
+<para>
+table 3
+</para>
+<description>
+        The table is
+        nearly sorted, but not quite. It was sorted in previous
+        versions of the standard.
+</description>
+<suggestion>
+        Sort the table.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="1"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.11
+</section>
+<para>
+Table 3
+</para>
+<description>
+        Keywords in the table are listed disorderly. Also, a
+        part of a frame of the table is not drawn.
+</description>
+<suggestion>
+        Sort it in alphabetical order.
+        Complete the table frame.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="19"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.1
+</section>
+<para>
+Table 5,
+rows &#8220;l or
+L&#8221; and &#8220;ll or
+        LL&#8221;
+</para>
+<description>
+        The final entry in the last column (&#8220;unsigned long
+        int&#8221;) is incorrect.
+</description>
+<suggestion>
+        Replace the incorrect entries by &#8220;unsigned long
+        long int&#8221;.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="20"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.1,
+        2.13.3
+</section>
+<para>
+</para>
+<description>
+        Long strings of digits in
+        literals are a continuing problem in the production and
+        maintenance of programs.
+</description>
+<suggestion>
+        Adopt the 1983 technology of Ada and use underscores to
+        separate digits. <font color="#000080" size="2" style="font-size: 11pt"><u><a href=
+        "http://www.google.com/url?sa=D&amp;q=http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2007%2Fn2281.html"
+        target=
+        "_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html></u></font>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="15"
+  uknum="139"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.2
+</section>
+<para>
+2
+</para>
+<description>
+        Inconsistency between definition of a
+        multicharacter literal and a wide character literal
+        containing multiple c-chars.
+</description>
+<suggestion>
+        Define the term
+        multicharacter wide literal for a wchar_t literal
+        containing multiple elements, and specify its type is
+        integer (or wider)
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="16"
+  uknum="140"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.2
+</section>
+<para>
+3
+</para>
+<description>
+        Not immediately clear why the question mark
+        needs escaping. A note would help.
+</description>
+<suggestion>
+        Add a note
+        explaining that the ? character may need escaping to avoid
+        accidentally creating a trigraph.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="2"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+        1<sup>st</sup> <font size="2" style=
+        "font-size: 11pt">para, 2<sup>nd</sup> line</font>
+</para>
+<description>
+        Typo, R"..." should be
+        R"[...]"
+</description>
+<suggestion>
+        Correct typo.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="3"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+2<sup>nd</sup> paragraph
+</para>
+<description>
+        We think that the explanation of d-char-sequence is not
+        enough.
+</description>
+<suggestion>
+        Add
+        the following.
+        <OL>
+          <LI>
+            Add the
+            following to the explanation of d-char-sequence, more
+            easily to understand.
+        <BR/><BR/>...prefix is a
+        raw string literal.
+        The
+        d-char-sequence is used as delimiter.
+        The terminating
+        d-char-sequence of ...</LI><BR/>
+          <LI>
+            Add the
+            following note that there are square brackets in
+            r-char-sequence.
+        <BR/><BR/>[<I>Note:</I>
+        <PRE>
+  char foo[] =
+  R"<i>delimiter</i>[[a-z] specifies a range
+  which matches any lowercase letter
+  from "a" to "z".]<i>delimiter</i>";
+</PRE>
+the expression
+statement behaves exactly the same as
+<PRE>
+  char foo[] = "[a-z] specifies a range
+  which matches any lowercase letter
+  from \"a\" to \"z\".";
+</PRE>
+&#8212;<I>end note</I>]</LI></OL>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="4"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+3<sup>rd</sup> <font size="2"
+        style="font-size: 11pt">para, 
+        1st line of
+        example</font>
+</para>
+<description>
+        Typo. Lack of a necessary backslash in the first line of
+        the example as follows:
+        <BR/>
+        <PRE>
+  const char *p = R"[a
+  b
+  c]";
+        </PRE>
+        should be
+        <BR/>
+        <PRE>
+  const char *p = R"[a\
+  b
+  c]";
+</PRE>
+</description>
+<suggestion>
+        Correct typo.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="21"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+&#182; 3
+</para>
+<description>
+        The paragraph, marked as a Note, contains an embedded
+        example not marked as such.
+</description>
+<suggestion>
+        Denote the code (and perhaps also its commentary) as an
+        Example.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="22"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+&#182; 3
+</para>
+<description>
+        The code does not have the effect predicted by its
+        accompanying narrative.
+</description>
+<suggestion>
+        Append a backslash to the first line of the code.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="5"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+        11<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">para, Table 7</font>
+</para>
+<description>
+        It is not explicit how to combine raw-string and
+        non-raw-string.
+</description>
+<suggestion>
+        Add rules containing raw-string in the table 7.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="13"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+        [lex.string]
+</section>
+<para>
+3
+</para>
+<description>
+        Shouldn't the assert be
+        <PRE>
+  assert(std::strcmp(p, "a\nb\nc") == 0);
+</PRE>
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="17"
+  uknum="141"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+10
+</para>
+<description>
+        It would be
+        preferred for attempts to modify string literals to be
+        diagnosable errors. This is not possible due to the
+        deprecated implicit conversion to pointer to
+        null-terminated character sequence of non-const characters.
+        If this deprecated conversion were remove (see other
+        comments) then string literals are always accessed through
+        const types, and the compiler can enforce the no
+        modification rule. The only exception would be using
+        const_cast to cast away constness, but this is already
+        covered under the const_cast rules so needs no further
+        detail here.
+</description>
+<suggestion>
+        (asssuming deprecated conversion to
+        non-const array is removed or can be turned off) Strike the
+        sentence on undefined behaviour.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="18"
+  uknum="142"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+</para>
+<description>
+        The addition of
+        static_assert (7p4) to the language raises the need to
+        concatenate string representations of integral constant
+        expressions (typically from a sizeof or alignof expression)
+        with narrow string literals to provide an informative error
+        message. There is no need to support arbitrary constant
+        expressions and especially not floating point values or
+        formatting flags. Likewise, the need is purely to support
+        static_assert so only narrow string literal support is
+        required, although generalizing to other literal types
+        would be useful.
+</description>
+<suggestion>
+        Define a syntax to support string-ization
+        of integral constant expressions in a form eligible for
+        string literal concatenation, 2.13.4p6. Suggested syntax:
+        I" integral-constant-expression ". There is no raw variant,
+        although it could combine with type specifier in the same
+        way that the R prefix does, supporting u8I, uI, UI and LI.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="19"
+  uknum="143"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+2.13.4
+</section>
+<para>
+</para>
+<description>
+        The grammar for string literal is becoming
+        unwieldy and could easily be refactored into the type
+        optional specifier and the string contents.
+</description>
+<suggestion>
+        Refactor
+        string-literal grammar as: (note - current Drupal view
+        loses formatting which is vital to clearly read the
+        grammar) string-literal: string-literal-type-specifierOPT
+        string-literal-body string-literal-type-specifier: one of
+        u8 u U L string-literal-body: " s-char-sequenceOPT " R
+        raw-string
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="14"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3 [basic]
+</section>
+<para>
+7
+</para>
+<description>
+        "In general it is necessary to determine whether a name
+        denotes one of these entities before parsing the program
+        that contains it."
+</description>
+<suggestion>
+        Would prefer
+        <BR/><BR/>"... before continuing to
+        parse the program that contains it."
+        <BR/><BR/>or even
+        <BR/><BR/>"... to complete the parsing
+        of the program that contains it."
+        <BR/><BR/>as some names denotes entities declared after the first
+        occurrence.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="15"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3 [basic]
+</section>
+<para>
+8
+</para>
+<description>
+        /operator-function-id/,
+        /conversion-function-id/, /template-id/ are followed by a
+        space and then a "s" while usually such production names
+        aren't followed by a space when put in plural (see
+        /identifier/).
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="20"
+  uknum="209"
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3
+</section>
+<para>
+</para>
+<description>
+        Chapter 3
+        ("Basic concepts") provides common definitions used in the
+        rest of the document. Now that we have concepts as a
+        primary feature, the title of this chapter can be confusing
+        as it does not refer to the language feature but to
+        definitions used in the document.
+</description>
+<suggestion>
+        Change the title to "Basic definitions".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="21"
+  uknum="359"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3
+</section>
+<para>
+2
+</para>
+<description>
+        Concepts is now the name of a specific
+        feature of the language, the term now risks confusion and
+        ambiguity when used in the more general sense.
+</description>
+<suggestion>
+        Rename the chapter Basic ???. THe note in
+        p2 specifically needs similar rewording
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="22"
+  uknum="362"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3
+</section>
+<para>
+6
+</para>
+<description>
+        References are
+        frequently considered variables, but this definition only
+        applies to objects.
+</description>
+<suggestion>
+        Add "or reference" after both uses of
+        "object"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="23"
+  uknum="277"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.1
+</section>
+<para>
+2
+</para>
+<description>
+        alias-declarations are not definitions and should be added
+        to the list
+</description>
+<suggestion>
+        Add alias-declaration after typedef
+        declaration.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="24"
+  uknum="360"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.1
+</section>
+<para>
+2
+</para>
+<description>
+        The current
+        words suggest the declaration of a static integral constant
+        data member of a class cannot be a definition. Trying to
+        fix this wording in-place will be verbose and risk raising
+        more confusion than it solves, so suggest a footnote to
+        call out the special case
+</description>
+<suggestion>
+        Add a footnote attached to the static data
+        membmer rule: *static data member delcarations of intergral
+        type may also be definitions if a constant integral
+        expression is provided for an initializer.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="25"
+  uknum="361"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.1
+</section>
+<para>
+3
+</para>
+<description>
+        Example is
+        misleading as implicitly defined default constructor uses
+        default initialization, not value initialization, for
+        non-static data members. In the case of std::String this
+        makes no difference, but it makes a big difference for
+        fundamental types and pointers.
+</description>
+<suggestion>
+        Remove the : s() from the illustrated
+        default constructor: struct C { std::string s; C() { }
+        C(const C&amp; x): s(x.s) { } C&amp; operator=(const C&amp;
+        x) { s = x.s; return *this; } ~C() { } };
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="26"
+  uknum="363"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.2
+</section>
+<para>
+1
+</para>
+<description>
+        THe one
+        definition rule should cover references, and unless the
+        term 'variable' is extended to cover references the list in
+        this paragraph is incomplete.
+</description>
+<suggestion>
+        Either include references in the definition
+        of 'variable' (see earlier comment) or add reference to the
+        list in this paragraph.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="27"
+  uknum="364"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.2
+</section>
+<para>
+4
+</para>
+<description>
+        A class type
+        must be complete when catching exceptions, even by
+        reference or pointer. See 15.3.
+</description>
+<suggestion>
+        Add "when used in an exception-handler
+        (15.3)" to the list.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="16"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.3
+        [Declarative
+        regions and scopes.]
+</section>
+<para>
+</para>
+<description>
+        The scope of function
+        parameters is defined, but what is the scope of template
+        parameters?
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="28"
+  uknum="365"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.3.1
+</section>
+<para>
+3
+</para>
+<description>
+        Class templates
+        are not classes, so we should include this case.
+</description>
+<suggestion>
+        ammend "class" to "class or class template"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="29"
+  uknum="366"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.3.10
+</section>
+<para>
+3
+</para>
+<description>
+        operators and conversion functions do not
+        have names, yet are susceptible to 'name hiding' within a
+        class - indeed we rely on this for the implicitly declared
+        copy-assignment operator.
+</description>
+<suggestion>
+        Add the
+        additional phrase "The declaration of an operator or
+        conversion function in a derived class (Clause 10) hides
+        the declaration of an operator or conversion function of a
+        base class of the same operator or type;"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="17"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.5 [Program
+and linkage]
+</section>
+<para>
+</para>
+<description>
+        This section does not specify
+        whether concept names have linkage.
+        Do they or not? If concept
+        names do not have linkage, then a note is appropriate, and
+        that would be a bit surprising and curious. What is the
+        rationale?
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="30"
+  uknum="367"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.5
+</section>
+<para>
+2
+</para>
+<description>
+        This paragraph implies concepts have no
+        linkage (do they need it?) and that the entities behind
+        names without linkage cannot be used in other scopes. This
+        maybe a bigger problem for concept maps?
+</description>
+<suggestion>
+        Add a note to clarify that concepts don't
+        need linkage.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="31"
+  uknum="368"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.5
+</section>
+<para>
+4
+</para>
+<description>
+        What is the linkage of names declared
+        inside a namespace, in turn declared inside an anonymous
+        namespace? It is not clear why such a namespace has no
+        linkage, and there is no language suggesting its memmbers
+        should lose linkage with it, which we assume is the
+        intended consequence.
+</description>
+<suggestion>
+        Clarify rules for namespaces inside nested
+        namespaces, or remove the restriction.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="23"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.5
+</section>
+<para>
+6
+</para>
+<description>
+        Bad
+        paragraph break.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="18"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.5
+        [basic.link]
+</section>
+<para>
+6
+</para>
+<description>
+        The paragraph number is not aligned with the text.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="19"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.6 [Start
+and
+termination]
+</section>
+<para>
+</para>
+<description>
+        This section completely
+        ignores the real world and practical case of dynamically
+        linked or loaded libraries. In current computing
+        environments, they are ubiquitous and they cannot be
+        ignored in
+        practical C++ programs. The
+        Standard
+        should address this aspect.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="32"
+  uknum="369"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.6.1
+</section>
+<para>
+3
+</para>
+<description>
+        Do we really want to allow: constexpr int
+        main() { return 0; } as a valid program?
+</description>
+<suggestion>
+        Add constexpr to
+        the list of ill-formed things to annotate main 
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="24"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.6.1
+</section>
+<para>
+4
+</para>
+<description>
+        std::quick_exit is not
+        referenced.
+</description>
+<suggestion>
+        Reference std::quick_exit as well as std::exit in saying
+        that automatic objects are not destroyed. It should
+        <font size="2" style="font-size: 11pt"><strong>not</strong>
+        do so in saying that calling std::quick_exit is undefined
+        from within destructors for static or thread duration
+        objects.</font>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="25"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.6.3
+</section>
+<para>
+&#182; 2 last sent.
+</para>
+<description>
+        The parenthesized phrase, introduced via
+        &#8220;i.e.&#8221; is in the nature of an example.
+</description>
+<suggestion>
+        Change &#8220;i.e.&#8221; to &#8220;e.g.&#8221;
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="6"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.7.4.1
+</section>
+<para>
+4<sup>th</sup> <font size="2"
+        style="font-size: 11pt">para,
+4<sup>th</sup>
+        line</font>
+</para>
+<description>
+        Typo.
+        <BR/><BR/>
+        Lack of a comma right after &#8220;(3.7.2)&#8221; in the
+        sentence while there are commas after any other recitations
+        like &#8220;(3.7.1)&#8221;. It is just a unification
+        matter.
+        <BR/><BR/>
+        
+        <BR/><BR/>[
+        Note: in particular, a global allocation function is not
+        called to allocate storage for objects with static storage
+        duration (3.7.1), for objects or references with thread
+        storage duration (3.7.2) for objects of type std::type_info
+        (5.2.8), or for the copy of an object thrown by a throw
+        expression (15.1). -end note ]
+        <BR/><BR/>
+        
+        <BR/><BR/>should be
+        <BR/><BR/>
+        
+        <BR/><BR/>[
+        Note: in particular, a global allocation function is not
+        called to allocate storage for objects with static storage
+        duration (3.7.1), for objects or references with thread
+        storage duration (3.7.2), for objects of type
+        std::type_info (5.2.8), or for the copy of an object thrown
+        by a throw expression (15.1). -end note ]
+        <BR/><BR/>
+</description>
+<suggestion>
+        Correct typo.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="3"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.7.4.3
+</section>
+<para>
+</para>
+<description>
+        DE-3 It is
+        unclear whether the following code has well-defined
+        behavior; none of the bullets in the second paragraph seem
+        to apply.
+        <BR/><BR/>int&amp; i =
+        *new int(5);
+        <BR/><BR/>delete &amp;i;
+</description>
+<suggestion>
+        Clarify that &amp;i is considered a safely-derived
+        pointer value.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="26"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.8
+</section>
+<para>
+1 and 5
+</para>
+<description>
+        Use of object fields during
+        destruction is excessively and erroneously constrained.
+</description>
+<suggestion>
+        See
+        the attached document "Issues with the C++ Standard" under
+        Chapter 3 "Use of objects, especially from other threads,
+        during destruction".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="27"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.9
+</section>
+<para>
+&#182; 9 first sent.
+</para>
+<description>
+        There is a superfluous/extraneous &#8220;and&#8221;.
+</description>
+<suggestion>
+        Delete &#8220;and&#8221; from the phrase &#8220;and
+        std::nullptr_t&#8221;.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="20"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.9 [Types]
+</section>
+<para>
+</para>
+<description>
+        The phrase 'effective type'
+        is defined and used in a way that is incompatible with C99.
+        Such a deliberate incompatible choice of terminology is
+        both unfortunate and confusing, given past practice of the
+        committee to maintain greater compatibility with C99. We
+        strongly suggest that the phrase 'effective type' not be
+        used in such an incompatible way.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="7"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.9.2
+</section>
+<para>
+3<sup>rd</sup> <font size="2"
+        style="font-size: 11pt">para,
+13<sup>th</sup>
+        line</font>
+</para>
+<description>
+        over-aligned type was added as new notion. So it is
+        preferable to add the link after that.
+</description>
+<suggestion>
+        Add
+        (3.11) after over-aligned type as the link.
+        <BR/><BR/>[ Note: pointers to
+        over-aligned types<font color="#008000">(3.11)</font>
+        <font size="2" style="font-size: 11pt">have no special
+        representation, but their range of valid values is
+        restricted by the extended alignment requirement. This
+        International Standard specifies only two ways of obtaining
+        such a pointer: taking the address of a valid object with
+        an over-aligned type<font color="#008000">(3.11)</font>,
+        and using one of the runtime pointer alignment functions.
+        An implementation may provide other means of obtaining a
+        valid pointer value for an over-aligned type<font color=
+        "#008000">(3.11)</font>.&#8212;end note ]</font>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="28"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+3.9.3
+</section>
+<para>
+&#182; 5 first sent.
+</para>
+<description>
+        The closing
+        braces of the first two sets are preceded by extraneous
+        space.
+</description>
+<suggestion>
+        Delete the extra spaces.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="4"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+4.2
+</section>
+<para>
+p2
+</para>
+<description>
+        DE-4 The deprecated conversion from string literals to
+        pointer to non-const character types should be limited to
+        those conversions and types of string literals that were
+        already present in ISO/IEC 14882:2003, or the deprecated
+        conversions should be removed entirely.
+</description>
+<suggestion>
+        Consider
+        applying the proposed resolution presented in core issue
+        693 in WG21 document N2714 &#8220;C++ Standard Core
+        Language Active Issues, Revision 58&#8220;, available at
+        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2714.html
+        ; or remove only the conversions to "pointer to char16_t",
+        "pointer to char32_t" in 4.2 paragraph 2 and 15.1 paragraph
+        3.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="CH"
+  num="1"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+4.9 and 5.2.9
+</section>
+<para>
+</para>
+<description>
+        With respect to the target type, pointer to members
+        should behave like normal pointers (least surprise
+        principle).
+</description>
+<suggestion>
+        The standard
+        should allow implicit conversions from ``pointer to member
+        of <tt>T</tt> of type <i>cv</i> <tt>D</tt>'' to ``pointer
+        to member of <tt>T</tt> of type <i>cv</i> 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>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="5"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+4.11,
+5.3.1,
+5.5
+</section>
+<para>
+</para>
+<description>
+        DE-5 Ref-qualification has not been integrated with
+        pointer-to-members.
+</description>
+<suggestion>
+        Review implicit
+        conversions (4.11), forming pointer-to-members (5.3.1), and
+        dereferencing pointer-to-members (5.5) for type-safety
+        concerns in the presence of ref-qualifiers on the member.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="33"
+  uknum="374"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+4.13
+</section>
+<para>
+1
+</para>
+<description>
+        We have: "No two signed integer types shall
+        have the same rank ..." "the rank of char shall equal the
+        rank of signed char" Can we therefore deduce that char may
+        not be signed?
+</description>
+<suggestion>
+        Replace the
+        first sentence with "No two signed integer types shall have
+        the same rank, even if they have the same representation,
+        except that signed char shall have the same rank as char
+        even if char is signed (3.9.1/1)."
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="34"
+  uknum="375"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+4.13
+</section>
+<para>
+1
+</para>
+<description>
+        6th bullet, "the
+        rank of char" - first letter should be capitalised for
+        consistency with the other bullets
+</description>
+<suggestion>
+        The rank of char
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="36"
+  uknum="407"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1
+</section>
+<para>
+1
+</para>
+<description>
+        Primary
+        expressions are literals, names, names qualified by the
+        scope resolution operator ::, and lambda expressions. The
+        immediately following grammar flatly contradicts this -
+        this and (e) are also lambda expressions.
+</description>
+<suggestion>
+        Delete this paragraph.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="37"
+  uknum="224"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1
+</section>
+<para>
+11
+</para>
+<description>
+        Member function
+        templates are not member functions, so should also be
+        listed in the 3rd bullet
+</description>
+<suggestion>
+        Add member function templates to the 3rd
+        bullet
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="38"
+  uknum="230"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1
+</section>
+<para>
+3
+</para>
+<description>
+        this might be useful in a few more places
+        than it is permitted, specifically in decltype expressions
+        within a class. Two examples that would be ill-formed at
+        class scope without changes: typedef decltype( *this )
+        this_type; decltype( [this]{ return this-&gt;memfun(); } )
+        my_lambda;
+</description>
+<suggestion>
+        ... words to follow ...
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="8"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1
+</section>
+<para>
+7<sup>th</sup> <font size="2"
+        style="font-size: 11pt">para, Syntax rules</font>
+</para>
+<description>
+        In
+        the current syntax definition, a scope operator(::) cannot
+        be applied to decltype, but it should be. It would be
+        useful in the case to obtain member type(nested-type) from
+        an instance as follows:
+        <BR/><BR/>
+        vector&lt;int&gt; v;
+        <BR/><BR/>decltype(v)::value_type i = 0;
+        // int i = 0;
+</description>
+<suggestion>
+        Add
+        &#8220;decltype ( expression ) :: &#8220; to
+        nested-name-specifier syntax like below.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        nested-name-specifier:
+        <BR/><BR/>type-name ::
+        <BR/><BR/>namespace-name ::
+        <BR/><BR/>
+        nested-name-specifier identifier ::
+        <BR/><BR/>
+        nested-name-specifier templateopt simple-template-id ::
+        <BR/><BR/>
+        nested-name-specifieropt concept-id ::
+        <BR/><BR/>decltype (
+        expression ) ::
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="9"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+</para>
+<description>
+        It
+        would be preferable that &#8220;&amp;&amp;&#8221; could be
+        specified in a lambda expression to declare move capture.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        Here is an example from N2709.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;typename F&gt;
+        <BR/><BR/>
+        std::unique_future&lt;typename
+        std::result_of&lt;F()&gt;::type&gt; spawn_task(F f){
+        <BR/><BR/>
+        typedef typename std::result_of&lt;F()&gt;::type
+        result_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        struct local_task {
+        <BR/><BR/>
+        std::promise&lt;result_type&gt; promise;
+        <BR/><BR/>F
+        func;
+        <BR/><BR/>
+        local_task(local_task const&amp; other)=delete;
+        <BR/><BR/>
+        local_task(F func_):
+        <BR/><BR/>
+        func(func_)
+        <BR/><BR/>{}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        local_task(local_task&amp;&amp; other):
+        <BR/><BR/>
+        promise(std::move(other.promise)),
+        <BR/><BR/>
+        f(std::move(other.f))
+        <BR/><BR/>{}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        void operator() {
+        <BR/><BR/>try
+        <BR/><BR/>{
+        <BR/><BR/>
+        promise.set_value(f());
+        <BR/><BR/>}
+        <BR/><BR/>
+        catch(...)
+        <BR/><BR/>{
+        <BR/><BR/>
+        promise.set_exception(std::current_exception());
+        <BR/><BR/>}
+        <BR/><BR/>}
+        <BR/><BR/>};
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        local_task task(std::move(f));
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        std::unique_future&lt;result_type&gt;
+        res(task.promise.get_future());
+        <BR/><BR/>
+        std::thread(std::move(task));
+        <BR/><BR/>
+        return res;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        This can be rewritten simply as follows if move capture can
+        be used in a lambda expression.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;typename F&gt;
+        <BR/><BR/>
+        std::unique_future&lt;typename
+        std::result_of&lt;F()&gt;::type&gt; spawn_task(F f){
+        <BR/><BR/>
+        typedef typename std::result_of&lt;F()&gt;::type
+        result_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        std::promise&lt;result_type&gt; promise;
+        <BR/><BR/>
+        std::unique_future&lt;result_type&gt;
+        res(promise.get_future());
+        <BR/><BR/>
+        std::thread([&amp;&amp;promise, &amp;&amp;f]() {
+        <BR/><BR/>try
+        <BR/><BR/>{
+        <BR/><BR/>
+        promise.set_value(f());
+        <BR/><BR/>}
+        <BR/><BR/>
+        catch(...)
+        <BR/><BR/>{
+        <BR/><BR/>
+        promise.set_exception(std::current_exception());
+        <BR/><BR/>}
+        <BR/><BR/>});
+        <BR/><BR/>
+        return res;
+        <BR/><BR/>}
+        <BR/><BR/>
+</description>
+<suggestion>
+        Add
+        move capture in a lambda expression.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="10"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+</para>
+<description>
+        In
+        the current syntax definition, a returned type of a
+        function object cannot be obtained by using result_of from
+        an unnamed function object generated by a lambda expression
+        because it doesn&#8217;t have result type.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class F&gt;
+        <BR/><BR/>
+        void foo(F f)
+        <BR/><BR/>{
+        <BR/><BR/>
+        typedef std::result_of&lt;F()&gt;::type result; // error
+        <BR/><BR/>}
+        <BR/><BR/>
+        foo([]{});
+        <BR/><BR/>
+        
+        <BR/><BR/>If
+        &#8220;Callable&#8221; or &#8220;Predicate&#8221; concept
+        is specified, a returned type can be obtained from a
+        function object without result_type. But it is preferable
+        to be able to obtain it with template.
+</description>
+<suggestion>
+        Add
+        result_type to the syntax of an unnamed function object
+        generated by a lambda expression.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="29"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+</para>
+<description>
+        The
+        standard does not state whether or not direct recursion of
+        lambdas is possible.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="30"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+</para>
+<description>
+        <font color="#000000">The standard does not clarify the
+        meaning of</font> <font size="2" style=
+        "font-size: 11pt"><code><font color=
+        "#000000">this</font></code> <font color="#000000">in
+        lambdas. Does it mean this lambda, or this class within
+        which the lambda is nested?</font></font>
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="31"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+</para>
+<description>
+        <font color="#000000">The current wording does not specify
+        how context capturing and name resolution</font>
+        <font size="2" style="font-size: 11pt">take place when the
+        inner lambda refers to the outer lambda's locals variables
+        and parameters.</font>
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="45"
+  uknum="444"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+para 2
+</para>
+<description>
+        Lambda is a language feature with an
+        apparent dependency on &lt;functional&gt;. This increases
+        dependency of language on library, and is inconsistent with
+        the definition of freestanding in 17.6.2.4.
+</description>
+<suggestion>
+        Change the text
+        "a closure object behaves as a function object" to "a
+        closure object is a built-in object which behaves as a
+        function object"; and after "context.", insert " A closure
+        object may be used without any need for
+        &lt;functional&gt;." This makes clear what may already be
+        implied, namely that lambdas can be used in freestanding
+        implementations and don't increase dependency of language
+        on library. (Marked as technical comment anyway because
+        this clarity is technically important).
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="32"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+3
+</para>
+<description>
+        The
+        final italic "this" in the paragraph should be a teletype
+        "this".
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="39"
+  uknum="408"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+11
+</para>
+<description>
+        This paragraph lists all the special member
+        functions for the class representing a lambda. But it omits
+        the destructor, which is awkward.
+</description>
+<suggestion>
+        Add "F has an implicitly-declared
+        destructor".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="40"
+  uknum="409"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+12
+</para>
+<description>
+        If one or more
+        names in the effective capture set are preceded by &amp;,
+        the effect of invoking a closure object or a copy after the
+        innermost block scope of the context of the lambda
+        expression has been exited is undefined. That is too
+        restrictive. The behaviour should be undefined iff the
+        lifetime of any of the variables referenced has ended. This
+        should be safe and legal; currently it has undefined
+        behaviour: int i; reference_closure&lt;void ()&gt; f; if
+        (blah) { f = [&amp;i]() { }; } if (f) f();
+</description>
+<suggestion>
+        If one or more names in the effective
+        capture set are preceded by &amp;, the effect of invoking a
+        closure object or a copy after the lifetime of any of the
+        variables referenced has ended is undefined.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="41"
+  uknum="225"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+12
+</para>
+<description>
+        For argument dependant lookup (3.4.2) the
+        associated namespaces for a class include its bases, and
+        associated namespaces of its bases. Requiring the result of
+        a lambda expression *to dervide from*
+        std::reference_closure means that ADL will look in
+        namespace std when the lambda capture is entirely by
+        reference, which might have surprising results. Also,
+        relying on the idea of implicitly slicing objects is
+        uncomfortable.
+</description>
+<suggestion>
+        Replace inheritance with implicit
+        conversion.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="42"
+  uknum="226"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+</para>
+<description>
+        A lambda with an empty capture list has
+        identical semantics to a regular function type. By
+        requiring this mapping we get an efficient lambda type with
+        a known API that is also compatible with existing operating
+        system and C library functions.
+</description>
+<suggestion>
+        Add a new
+        paragraph: "A lambda expression with an empty capture set
+        shall be convertible to pointer to function type R(P),
+        where R is the return type and P is the parameter-type-list
+        of the lambda expression." Additionally it might be good to
+        (a) allow conversion to function reference (b) allow extern
+        "C" function pointer types
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="43"
+  uknum="231"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+12
+</para>
+<description>
+        The note spells
+        out the intent that objects from lambda-expressions with an
+        effective capture list of references should be implemented
+        as a pair of pointers. However, nothing in the rest of
+        5.1.1 lifts the requirement of to declare a reference
+        member for each captured name, and a non-normative note is
+        not enough to relax that.
+</description>
+<suggestion>
+        ... provvide exceptions in the right places
+        ...
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="44"
+  uknum="252"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+12
+</para>
+<description>
+        There is a
+        strong similarity between a [&amp;]{} lambda capturing a
+        stack frame, and a [this]{} lambda binding a member
+        function to a class instance. The reference_closure
+        requirement should be extended to the second case, although
+        we need some syntax to create such an object that is
+        distinct from the existing pointer-to-member syntax. This
+        would be a cleaner alternative to the new std::mem_fn
+        library component.
+</description>
+<suggestion>
+        Extend reference_closure requirement to
+        cover [this] lambdas. Consider a simple syntax for creating
+        such bound expressions.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="46"
+  uknum="449"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+para 12
+</para>
+<description>
+        The requirement that a lambda meeting
+        appropriate conditions be an object derived from
+        reference_closure makes lambda the language feature
+        dependent on &lt;functional&gt;, which increases dependency
+        of the language on the library and bloats the definition of
+        freestanding C++.
+</description>
+<suggestion>
+        Replace text "is
+        publicly derived from" with "shall be implemented in a
+        manner indistinguishable from". This places an ABI
+        constraint on reference closures such that compiler and
+        library implementer have to do compatible things. But it
+        cuts the dependency of lambda syntax on &lt;functional&gt;.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="6"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1, 20.7.18
+</section>
+<para>
+</para>
+<description>
+        DE-6 Some uses of lambda expressions refer to
+        specializations of the unconstrained class template
+        std::reference_closure (5.1.1). If the lambda expression
+        appears in a constrained context and the return type or a
+        parameter type for the lambda depend on a template
+        parameter (see 14.10), such a use is ill-formed.
+</description>
+<suggestion>
+        In 20.7.18, for the class template
+        std::reference_closure, require Returnable for R and
+        VariableType for each of the ArgTypes.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="7"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+p10
+</para>
+<description>
+        DE-7 The note at the end of paragraph 10 appears to be
+        garbled.
+</description>
+<suggestion>
+        Remove "or references" in the note.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="8"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+p10
+</para>
+<description>
+        DE-8 The construction of the function call operator
+        signature is missing specifications for the ref-qualifier
+        and the attribute-specifier.
+</description>
+<suggestion>
+        Add bullets that say that the ref-qualifier and the
+        attribute-specifier are absent.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="33"
+  uknum=""
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+11
+</para>
+<description>
+        There is no definition of &#8220;move constructor&#8221;
+        or &#8220;move operation&#8221;
+</description>
+<suggestion>
+        Since this is
+        the first place the terms are used, a definition should
+        either be added here, or a cross reference to one.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="9"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.1.1
+</section>
+<para>
+</para>
+<description>
+        DE-9 There is not a single example of a
+        lambda-expression in the standard. See also core issue 720
+        in WG21 document N2791 "C++ Standard Core Language Active
+        Issues, Revision 59", available at
+        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
+        .
+</description>
+<suggestion>
+        Add a few well-chosen examples.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="52"
+  uknum="232"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2
+</section>
+<para>
+3
+</para>
+<description>
+        This paragraph seens out of place,
+        assignment expressions are covered in 5.17
+</description>
+<suggestion>
+        Move p3 to subsection 5.17
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="53"
+  uknum="233"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.1
+</section>
+<para>
+</para>
+<description>
+        The definition in p1 makes no allowance for
+        overloaded operator[] that treats the expression as a
+        simple function call, and does not support the
+        interchangability of arguments. Howver p2 relies on this
+        definition when describing the use of brace-init-lists
+        inside [].
+</description>
+<suggestion>
+        Insert a new p2 describing the changed
+        semantics for overloaded operator[]. This should be a note
+        to avoid introducing normative text that could potentially
+        conflict with the later definiton of these semantics.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="59"
+  uknum="410"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.2
+</section>
+<para>
+7
+</para>
+<description>
+        When there is no parameter for a given
+        argument, the argument is passed in such a way that the
+        receiving function can obtain the value of the argument by
+        invoking va_arg. That shouldn't apply to parameter packs.
+        template &lt;class ... Types&gt; void f(Types ... pack);
+        f(1, 2, 3);
+</description>
+<suggestion>
+        Clarify that this sentence only applies
+        where the ellipsis is used.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="60"
+  uknum="411"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.5
+</section>
+<para>
+3
+</para>
+<description>
+        In the remainder of 5.2.5, cq represents
+        either const or the absence of const vq represents either
+        volatile or the absence of volatile.
+</description>
+<suggestion>
+        Add "and" before vq
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="61"
+  uknum="234"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.5
+</section>
+<para>
+p1
+</para>
+<description>
+        Together with footnote 60 there may be
+        confusion that the postfix expression is always evaluated -
+        even when part of an unevaluated operand. We believe the
+        standard does not require this, and a comment in the
+        existing note would be a useful clarification.
+</description>
+<suggestion>
+        Clarify in footnote 60 that this will not
+        happen if the whole expression is an unevaluated operand.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="62"
+  uknum="235"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.5
+</section>
+<para>
+4
+</para>
+<description>
+        In the final bullet, what does 'not an
+        lvalue' mean? Does it imply rvalue, or are there other
+        possible meanings? Should clauses that trigger on rvalues
+        pick up on this?
+</description>
+<suggestion>
+        Replace 'not an lvalue' with 'is an
+        rvalue'.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="10"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.5
+</section>
+<para>
+</para>
+<description>
+        DE-10 If E1.E2 is referring to a non-static member
+        function, the potential ref-qualification on E2 should be
+        taken into account.
+</description>
+<suggestion>
+        Adjust the presentation of the types involved as
+        appropriate.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="63"
+  uknum="412"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.6
+</section>
+<para>
+2
+</para>
+<description>
+        Paragraph 2 is missing its number.
+</description>
+<suggestion>
+        Add one.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="64"
+  uknum="413"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.7
+</section>
+<para>
+3
+</para>
+<description>
+        A new name R is introduced for use in
+        paragraphs 3 and 4. But R is the same as T.
+</description>
+<suggestion>
+        Replace R with T
+        and replace "the required result type (which, for
+        convenience, will be called R in this description)" with
+        "T".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="65"
+  uknum="414"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.7
+</section>
+<para>
+8
+</para>
+<description>
+        In the first two
+        bullets we have "the result is a pointer (an lvalue
+        referring) to". But para 2 makes clear that a dynamic_cast
+        of an rvalue references produces a rvalue. (Can an lvalue
+        refer to anything anyway?)
+</description>
+<suggestion>
+        Replace "an lvalue referring to" with
+        "reference", twice.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="66"
+  uknum="415"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.8
+</section>
+<para>
+1
+</para>
+<description>
+        typeid may
+        return "an implementation-defined class derived from std ::
+        type_info". The derivation must be public.
+</description>
+<suggestion>
+        an implementation-defined class publicly
+        derived from std :: type_info
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="67"
+  uknum="416"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.9
+</section>
+<para>
+1, 2, 3
+</para>
+<description>
+        Paragraph 1 specifies when the result of
+        static_cast is an lvalue; repeating it is unnecessary.
+</description>
+<suggestion>
+        In para 2,
+        delete "It is an lvalue if the type cast to is an lvalue
+        reference; otherwise, it is an rvalue." and "The result is
+        an rvalue.". In para 3, delete "The result is an lvalue if
+        T is an lvalue reference type (8.3.2), and an rvalue
+        otherwise."
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="54"
+  uknum="417"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.10
+</section>
+<para>
+3, 6
+</para>
+<description>
+        Para 3: "The mapping performed by
+        reinterpret_cast is implementation-defined.". Para 6: "...
+        the result of such a pointer conversion is unspecified."
+        Which is it?
+</description>
+<suggestion>
+        In para 6,
+        replace unspecified with implementation-defined.
+        Alternatively, delete paragraph 3, since individual cases
+        are labelled appropriately.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="55"
+  uknum="236"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.10
+</section>
+<para>
+2
+</para>
+<description>
+        dynamic_cast and reinterpret_cast
+        crossreference 5.2.11 without creating an extra note. The
+        second half of the note is unrelated to the crossrefernce,
+        and would serve as well in normative text.
+</description>
+<suggestion>
+        Strike the note
+        about definition of casting away constness, preserve the
+        cross-reference. The second sentance on reintrepret_cast to
+        its own type should move out of the note into the normative
+        text.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="56"
+  uknum="237"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.10
+</section>
+<para>
+5
+</para>
+<description>
+        The notion of
+        safely derived pointers means this conversion may not be as
+        safe in the revised standard as the original. It would be
+        good to call attention to the changed semantics with a
+        note.
+</description>
+<suggestion>
+        Add: [Note: the result of such a conversion
+        will not be a safely-derived pointer value (3.7.4.3) -- end
+        note]
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="57"
+  uknum="238"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.10
+</section>
+<para>
+8
+</para>
+<description>
+        Conditionally supported behaviour gives a
+        wide range or permission, so clarify relationship between
+        safely-derived object pointers and function pointers in a
+        note.
+</description>
+<suggestion>
+        Add: [Note: In such cases, the
+        implementation shall also define whether a safely-derived
+        object pointer cast to a function pointer can be safely
+        cast back -- end note]
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="58"
+  uknum="418"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.2.11
+</section>
+<para>
+9
+</para>
+<description>
+        Casting from an
+        lvalue of type T1 to an lvalue of type T2 using a reference
+        cast casts away constness if a cast from an rvalue of type
+        &#8220;pointer to T1&#8221; to the type &#8220;pointer to
+        T2&#8221; casts away constness. That doesn't cover rvalue
+        references.
+</description>
+<suggestion>
+        Replace lvalue with "lvalue or rvalue"
+        twice.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="34"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3
+</section>
+<para>
+1
+</para>
+<description>
+        The list of unary operator
+        should be in teletype font.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="68"
+  uknum="419"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.1
+</section>
+<para>
+2-9
+</para>
+<description>
+        All the unary operands other than * return
+        rvalues - but this is not stated.
+</description>
+<suggestion>
+        Add a paragraph
+        1a "The following unary operators all produce results that
+        are rvalues."
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="69"
+  uknum="240"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.1
+</section>
+<para>
+2
+</para>
+<description>
+        If we cannot
+        bind references/take address of functions in concept_maps,
+        does that mean we cannot use generic bind in constrained
+        templates? Launch threads with expressions found via
+        concept map lookup? Hit problems creating std::function
+        objects? Does the problem only occur if we use qualified
+        lookup to explicitly name a concept map? Does it only kick
+        in if we rely on the implicit function implementation
+        provided by a concept_map, so some types will work and
+        others won't for the same algorithm?!
+</description>
+<suggestion>
+        ... unknown ...
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="70"
+  uknum="420"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.3
+</section>
+<para>
+1
+</para>
+<description>
+        The sizeof
+        operator shall not be applied to ... an enumeration type
+        before all its enumerators have been declared We should
+        allow enum E : int; sizeof(E).
+</description>
+<suggestion>
+        Change "an enumeration type" to "an
+        enumeration type whose underlying type is not fixed".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="71"
+  uknum="254"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.4
+</section>
+<para>
+2
+</para>
+<description>
+        The type of an allocated object wih the
+        type specifier auto is determined by the rules of copy
+        initialization, but the initialization applied will be
+        direct initialization. This would affect classes which
+        declare their copy constructor explicit, for instance. For
+        consistency, use the same form of initiailization for the
+        deduction as the new expression.
+</description>
+<suggestion>
+        Replace T x = e; with T x(e);
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="72"
+  uknum="257"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.4
+</section>
+<para>
+7
+</para>
+<description>
+        The library
+        headers have been carefully structured to limit the
+        dependencies between core language and specific headers.
+        The exception thrown should be catchable by a handler for a
+        type lised in &lt;exception&gt; header in cluase 18. This
+        might be accomplished by moving length_error into the
+        &lt;exception&gt; header, but its dependency on logic_error
+        with its std::string constructors suggest this is not a
+        good idea. Prefer to pick an existing exception instead.
+</description>
+<suggestion>
+        Throw std::bad_alloc instead of
+        std::length_error.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="73"
+  uknum="258"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.4
+</section>
+<para>
+6
+</para>
+<description>
+        A class type
+        with conversion operator can only be used if the conversion
+        type is constexpr and the class is a literal type. Adding
+        the single word 'literal' before class type will clarify
+        this.
+</description>
+<suggestion>
+        Add 'literal' before 'class type'
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="74"
+  uknum="259"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.4
+</section>
+<para>
+8
+</para>
+<description>
+        operators, like
+        constructors and destructors, do not have names. However,
+        in certain circumstances they can be treated as if they had
+        a name, but usually the stanadard is very clear not to
+        actually describe their name as a distinct property.
+</description>
+<suggestion>
+        Change "the allocation function&#8217;s
+        name is operator new" to "the allocation function is named
+        operator new" and similarly for operator delete.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="35"
+  uknum="260"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.4
+</section>
+<para>
+9
+</para>
+<description>
+        Missing period in middle of paragraph
+        between "in the scope of T" and "If this lookup fails"
+</description>
+<suggestion>
+        Add a period
+        between "in the scope of T" and "If this lookup fails"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="75"
+  uknum="262"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.5
+</section>
+<para>
+8
+</para>
+<description>
+        A paragraph
+        strarting with [Note... is easily skipped when reading,
+        missing the normative text at the end.
+</description>
+<suggestion>
+        Swap order of the note and normative text.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="21"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.3.6
+        [Alignof
+</section>
+<para>
+</para>
+<description>
+        Should not the type of alignof-expression be of type
+        std::max_align_t?
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="35"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.8
+</section>
+<para>
+2 and 3
+</para>
+<description>
+        There is curious spacing in the expressions "E1 &lt;&lt;E2"
+        and "E1 &gt;&gt;E2". This is a formatting change since
+        previous versions of the Standard.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="47"
+  uknum="242"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.14 / 5.15
+</section>
+<para>
+2
+</para>
+<description>
+        Why are the
+        descriptions of order of evaluation of expressions and side
+        effects different between &amp;&amp; and || operators. The
+        interaction with the memory model should be identical, so
+        identical words should be used to avoid accidential
+        inconsistencies in interpretation.
+</description>
+<suggestion>
+        Pick one form of wording as 'the best' and
+        apply it in both places.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="48"
+  uknum="249"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.18
+</section>
+<para>
+1
+</para>
+<description>
+        The defining
+        feature of the comma operator is the guaranteed sequencing
+        of two expressions. This guarantee is lost when presented
+        with an overloaded operator, and this change is subtle
+        enough to call attention to it.
+</description>
+<suggestion>
+        Add: [Note: There are no guarantees on the
+        order of value computation for an overloaded comma operator
+        -- end note]
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="49"
+  uknum="376"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.19
+</section>
+<para>
+2
+</para>
+<description>
+        Is an implementation permitted to reject
+        this? constexpr int f() { return f(); } int a[f()]; AFAICT
+        it is well-formed; f() seems to satisfy all the rules to
+        make it a constant expression. I would hate compilation to
+        become a potentially non-terminating experience.
+</description>
+<suggestion>
+        Add an escape
+        clause to allow the implementation to reject excessively
+        deep nesting of constexpr function evaluations. (This can
+        possibly be a note, since it is arguable that this point is
+        handled by the general rule on resource limits in 1.4/2. A
+        sufficiently smart compiler could use tail recursion above,
+        meaning that it would never run out of memory given this
+        program though.)
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="50"
+  uknum="378"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.19
+</section>
+<para>
+2
+</para>
+<description>
+        The following should be valid: enum E { foo
+        = 4}; const E c = foo; int a[c]; But currently it is not -
+        c is not an lvalue of effective integral type (4th bullet).
+        (See also 7.1.6.1/2)
+</description>
+<suggestion>
+        Change
+        "effective integral type" to "effective integral or
+        enumeration type" in the 4th bullet, 1st sub-bullet.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="51"
+  uknum="251"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+5.19
+</section>
+<para>
+2
+</para>
+<description>
+        typeid
+        expressions can never be constant, whether or not the
+        operand is a polymorphic class type. The result of the
+        expression is a reference, and the typeinfo class that the
+        reference refers to is polymorphic, with a virtual
+        destructor - it can never be a literal type.
+</description>
+<suggestion>
+        Strike the words "whose operand is of a
+        polymorphic class type" on the bullet for typeid
+        expressions.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="76"
+  uknum="131"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+6.3
+</section>
+<para>
+</para>
+<description>
+        Do we really need two different terms that
+        say the same thing?
+</description>
+<suggestion>
+        Pick either
+        'block' or 'compound statement' as the preferred term and
+        use it consistently throughout the standard.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="22"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+6.4.2
+[The switch
+statement]
+</section>
+<para>
+</para>
+<description>
+        The constant-expression in
+        <BR/><BR/>
+        <BR/><BR/>case constant-expression
+        <BR/><BR/>
+        <BR/><BR/>should be allowed to be of
+        any constant expression of literal type for which a
+        constexpr comparison operator (operator&lt; and operator==)
+        is in scope. Now that constant expressions of other
+        integral types are evaluated at compile time, the
+        restriction for case-labels is at best artificial.
+        <BR/><BR/>
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="77"
+  uknum="132"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+6.5
+</section>
+<para>
+5
+</para>
+<description>
+        The terms i/o
+        operation, synchronize operation and atomic operation have
+        very specific meanings within the standard. The paragraph
+        would be much easier to understand with the terms
+        crossreferenced.
+</description>
+<suggestion>
+        Profide a cross-reference for the terms:
+        i/o operation, synchronize operation and atomic operation
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="11"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+6.5.4
+</section>
+<para>
+1<sup>st</sup> <font size="2"
+        style="font-size: 11pt">para,
+5<sup>th</sup>
+        line</font>
+</para>
+<description>
+        There is no _RangeT type in the equivalent code to
+        &#8220;range-base for&#8221; statement. It existed in
+        N2049.
+</description>
+<suggestion>
+        Add
+        a typedef for _RangeT in the example as follows:
+        <BR/><BR/>
+        
+        <BR/><BR/>{
+        <BR/><BR/>
+         <u>typedef decltype( expression )
+        _RangeT;</u>
+        <BR/><BR/>
+         auto &amp;&amp; __range = ( expression
+        );
+        <BR/><BR/>
+         for ( auto __begin =
+        std::Range&lt;_RangeT&gt;:: begin(__range),
+        <BR/><BR/>
+        
+         __end = std::Range&lt;_RangeT&gt;:: end(__range);
+        <BR/><BR/>
+        
+        __begin != __end;
+        <BR/><BR/>
+        
+        ++__begin )
+        <BR/><BR/>
+         {
+        <BR/><BR/>
+        
+        for-range-declaration = *__begin;
+        <BR/><BR/>
+         statement
+        <BR/><BR/>
+         }
+        <BR/><BR/>}
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="78"
+  uknum="130"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+6.5.4
+</section>
+<para>
+2
+</para>
+<description>
+        Including the header
+        &lt;iterator_concepts&gt; is far too unwieldy to enable an
+        important and (expected to be) frequently used syntax.
+</description>
+<suggestion>
+        Merge
+        &lt;iterator_concepts&gt; into &lt;concepts&gt; and change
+        6.5.4p2 to refer to &lt;concepts&gt;, or make the Range
+        concept fundamental along with the other support concepts
+        in 14.9.4 and strike any reference to including a header.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="79"
+  uknum="445"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+6.5.4
+</section>
+<para>
+</para>
+<description>
+        The definition
+        of for (for-range-declaration : expression) statement is
+        expanded in terms which require a Range concept, and the
+        program is ill-formed if &lt;iterator_concepts&gt; isn't
+        included. For users, iterating through old-fashioned
+        arrays, this is a sledge-hammer to crack a nut and compares
+        poorly with other languages. It's also not possible to
+        implement this without adversely impacting the freestanding
+        definition in 17.6.2.4.
+</description>
+<suggestion>
+        When expression is an array a of length N
+        whose length is known at compile time, expand range-for as
+        'for (... p=a, p!=a+N, p++) ...' without requiring the
+        Range concept or &lt;iterator_concepts&gt;. Also, when
+        expression is an initializer_list, expand range-for
+        similarly without requiring &lt;iterator_concepts&gt;.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="11"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+6.9
+</section>
+<para>
+p1
+</para>
+<description>
+        DE-11 A
+        sentence in paragraph 1 reads: "Outside of a constrained
+        context, the late-checked block has no effect." This, at
+        face value, specifies that the <em>compound-statement</em>
+        of such a late-checked block is never executed, which
+        appears to be unintended.
+</description>
+<suggestion>
+        State that such a late-checked block has the same
+        meaning as if the late_check keyword were absent.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="80"
+  uknum="370"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7
+</section>
+<para>
+1
+</para>
+<description>
+        Many of the
+        sections and major subsections open with a sentence
+        summarising the content. I'm not sure this is necessary;
+        this isn't a tutorial. The problem with these summaries is
+        that because they omit much of the detail, they tend to be
+        inaccurate. This may not matter, but I feel the document
+        would be improved by omitting them. There's a prime example
+        here: "Declarations specify how names are to be
+        interpreted." Not true for static_assert, an asm
+        declaration nor an anonymous bit field.
+</description>
+<suggestion>
+        Strike the first sentence.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="81"
+  uknum="371"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7
+</section>
+<para>
+4
+</para>
+<description>
+        String literal
+        concatenation happens in phase 6, before parsing, so it is
+        legal and useful to use it for the string literal in a
+        static_assert. It would be useful to add a note mentioning
+        this.
+</description>
+<suggestion>
+        Add a note: Multiple adjacent string
+        literals may be used instead of a single /string-literal/;
+        see [lex.phases].
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="82"
+  uknum="386"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7
+</section>
+<para>
+2
+</para>
+<description>
+        Paragraph 2
+        talks about declarations that can have nested declarations
+        within them. It doesn't mention scoped enumerations - but
+        according to 7.2/11, "Each scoped enumerator is declared in
+        the scope of the enumeration."
+</description>
+<suggestion>
+        Add "scoped enumeration" to the list in the
+        second sentence.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="83"
+  uknum="372"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1
+</section>
+<para>
+2
+</para>
+<description>
+        The longest
+        sequence of decl-specifiers that could possibly be a type
+        name is taken as the decl-specifier-seq of a declaration.
+        But many sequences of decl-specifiers cannot possibly be a
+        type name - eg the sequence "friend int", or "typedef int".
+</description>
+<suggestion>
+        Not sure. I understand the rule, just not
+        how to say it.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="84"
+  uknum="404"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1
+</section>
+<para>
+1
+</para>
+<description>
+        The grammar
+        includes alignment-specifier as a production for
+        decl-specifier, but there is no production for
+        alignment-specifier. I suspect this is a holdover from
+        before alignment was handled as an attribute.
+</description>
+<suggestion>
+        Delete the production (including the
+        duplicate in A6)
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FI"
+  num="3"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1
+</section>
+<para>
+[dcl.
+        spec.
+        auto]
+</para>
+<description>
+        While
+        it&#8217;s considered too late for this standard revision,
+        consider loosening the restrictions for auto specifier and
+        making it more a mirror of a deduced template function
+        parameter.
+</description>
+<suggestion>
+        See restricted-auto.ppt
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="85"
+  uknum="373"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.1
+</section>
+<para>
+1
+</para>
+<description>
+        ... the
+        init-declarator-list of the declaration shall not be empty
+        (except for global anonymous unions, which shall be
+        declared static). Global here means "declared at namespace
+        scope". (cf 9.5/3 "Anonymous unions declared in a named
+        namespace or in the global namespace shall be declared
+        static.").
+</description>
+<suggestion>
+        Replace "global" with "namespace scope".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="86"
+  uknum="403"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.1
+</section>
+<para>
+2,3
+</para>
+<description>
+        The register
+        keyword serves very little function, offering no more than
+        a hint that a note says is typically ignored. It should be
+        deprecated in this version of the standard, freeing the
+        reserved name up for use in a future standard, much like
+        auto has been re-used this time around for being similarly
+        useless.
+</description>
+<suggestion>
+        Deprecate current usage of the register
+        keyword.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="87"
+  uknum="405"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.1
+</section>
+<para>
+1, 4, 5
+</para>
+<description>
+        Why require two
+        keywords, where one on its own becomes ill-formed?
+        thread_local should imply 'static' in this case, and the
+        combination of keywords should be banned rather than
+        required. This would also eliminate the one of two
+        exceptions documented in 7.1.1p1.
+</description>
+<suggestion>
+        Drop requirement to combine static keyword
+        with thread_local at block-scope inside a function
+        definition.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="36"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.1
+</section>
+<para>
+4
+</para>
+<description>
+        The
+        permission to use thread_local static data members is
+        missing.
+</description>
+<suggestion>
+        Add the static members as a
+        permitted use.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="23"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.5
+        [constexpr]
+</section>
+<para>
+</para>
+<description>
+        'constexpr' functions should
+        be allowed to take const reference parameters, as long as
+        their uses are in a context where a constant expression may
+        be required. For example, the following should be allowed
+        <BR/><BR/>
+        <BR/><BR/>template&lt;typename T, int
+        N&gt;
+        <BR/><BR/>int size(const T(&amp;)[N]) {
+        return N; }
+        <BR/><BR/>
+        <BR/><BR/>int a[] = { 41,42,43,44 };
+        <BR/><BR/>enum { v = size(a) };
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="12"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.5
+</section>
+<para>
+</para>
+<description>
+        It should be
+        allowed to define constexpr recursively.
+        <BR/><BR/>
+        There is an explanation in N2235, Generalized Constant
+        Expressions&#8212;Revision 5, as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>We (still)
+        prohibit recursion in all its form in constant expressions.
+        That is not strictly necessary because an implementation
+        limit on recursion depth in constant expression evaluation
+        would save us from the possibility of the compiler
+        recursing forever. However, until we see a convincing use
+        case for recursion, we don&#8217;t propose to allow it.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        Then, here are the use cases where allowing recursion for
+        constexpr is very useful.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        Range of problem to be handled with constexpr would become
+        extended. For example, user defined type (e.g. Complex
+        type) could be placed in ROM area. But with current
+        specification, a function defined with constexpr cannot be
+        called recursively. As a side effect is not allowed in
+        compile-time, it cannot be implemented to repeat anything
+        without recursion. Although it could be implemented without
+        recursion like func0, func1, func2 in an example below, it
+        is not elegant solution.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        constexpr double func0(double x) { /* ... */}
+        <BR/><BR/>
+        constexpr double func1(double x) { /* call for func0 */ }
+        <BR/><BR/>
+        constexpr double func2(double x) { /* call for func1 */ }
+        <BR/><BR/>/*
+        ... */
+        <BR/><BR/>
+        
+        <BR/><BR/>-
+        Compile-time and runtime
+        <BR/><BR/>As
+        constexpr can be also evaluated both in compile-time and
+        runtime, we need to discuss about both cases.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        Runtime evaluation is just to execute it. If you eliminate
+        constexpr keyword, it is executable as of now. Any modern
+        compiler may optimize tail recursion easily.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        Compile-time evaluation is the same thing as template
+        recursion. It is necessary to support floating point
+        operation, but it is already possible to calculate it in
+        compile-time, so it&#8217;s ok.
+        <BR/><BR/>
+        
+        <BR/><BR/>-
+        Sample
+        <BR/><BR/>
+        Here is an example to calculate a square root using
+        constexpr recursively.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        /*constexpr*/ double SqrtHelper(double x, double a, int n)
+        <BR/><BR/>{
+        <BR/><BR/>
+        return n == 0 ? a : SqrtHelper(x, (x / a + a) / 2.0, n -
+        1);
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        /*constexpr*/ double Sqrt(double x)
+        <BR/><BR/>{
+        <BR/><BR/>
+        return SqrtHelper(x, x, 20);
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>/*constexpr*/
+        double root2 = Sqrt(2.0); // 1.41421...
+        <BR/><BR/>
+</description>
+<suggestion>
+        Allow constexpr recursion.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="37"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.1
+</section>
+<para>
+1
+</para>
+<description>
+        There is a "Note: 3.9.3 describes how cv-qualifiers affect
+        object and function types." So far as I can see, 3.9.3
+        CV-qualifiers only describes cv-qualifiers for objects,
+        cv-qualifiers for (member) functions being described in
+        8.3.5 Functions.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="89"
+  uknum="377"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.1
+</section>
+<para>
+2
+</para>
+<description>
+        The two
+        normative sentences in this paragraph appear to duplicate
+        text elsewhere - but they aren't exact duplicates, which
+        introduces uncertainty. 1. "An object declared in namespace
+        scope with a const-qualified type has internal linkage
+        unless it is explicitly declared extern or unless it was
+        previously declared to have external linkage.". This nearly
+        repeats 7.1.1/7: "Objects declared const and not explicitly
+        declared extern have internal linkage." The former seems to
+        allow more wiggle room - can an object be "previously
+        declared to have external linkage" without having been
+        "explicitly declared extern"? 2. "A variable of
+        non-volatile const-qualified integral or enumeration type
+        initialized by an integral constant expression can be used
+        in integral constant expressions (5.19)." This nearly
+        duplicates 5.19/2, bullet 4, 1st sub-bullet - "[... an
+        integaral constant expression can use] an lvalue of
+        effective integral type that refers to a non-volatile const
+        variable or static data member initialized with constant
+        expressions". The latter does not allow for lvalues of
+        enumeration type (neither scoped not unscoped enumerations
+        are integral types - 3.9.1/7, and note 44). This seems to
+        be a flaw in 5.19/2.
+</description>
+<suggestion>
+        Make the normative text in this section
+        into one or more notes, with cross references, and correct
+        the referenced text if necessary.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="90"
+  uknum="379"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.2
+</section>
+<para>
+para 1 and table 9
+</para>
+<description>
+        The grammar in
+        paragraph one makes "nested-name-specifier template
+        simple-template-id" a simple-type-specifier, but unlike all
+        the others it is omitted from table 9.
+</description>
+<suggestion>
+        Add a row to table 9 mentioning
+        simple-template-id and punting to clause 14 (cf
+        decltype(expression)).
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="91"
+  uknum="380"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.2
+</section>
+<para>
+4
+</para>
+<description>
+        5.1/5 says "[A]
+        parenthesized expression can be used in exactly the same
+        contexts as those where the enclosed expression can be
+        used, and with the same meaning, except as otherwise
+        indicated." When the first bullet point of this paragraph,
+        describing the type denoted by decltype(e), says "if e is
+        an id-expression ... decltype(e) is the type of the entity
+        named by e", 5.1/5 is not excluded, which would imply that
+        decltype((e)) was also the type of e. But the intention
+        appears that it should be caught by the third bullet and
+        treated as an lvalue expression, so decltype((e)) should be
+        a reference to the type of e. Conversely, the second bullet
+        point says "(parentheses around e are ignored)", which is
+        redundant because of 5.1/5.
+</description>
+<suggestion>
+        Insert "unparenthised" in the first bullet
+        point - "if e is an *unparenthised* id-expression ...". In
+        the second bullet point, move "(parentheses around e are
+        ignored)" into a note.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="92"
+  uknum="382"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.3
+</section>
+<para>
+2
+</para>
+<description>
+        The note
+        correctly indicates that, if T is a template type
+        parameter, then "friend class T;" is ill-formed. It might
+        be worth pointing out at the same time that the alternative
+        "friend T;" is now allowed - see 11.4/3.
+</description>
+<suggestion>
+        Either strike the note or add reference to
+        11.4/3 and/or mention of "friend T;".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="93"
+  uknum="454"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.3
+</section>
+<para>
+Grammar before para 1
+</para>
+<description>
+        In the third
+        production, "enum ::opt nested-name-specifieropt
+        identifier", enum should not be in italics; its referring
+        to the enum keyword.
+</description>
+<suggestion>
+        Change to keyword font
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="94"
+  uknum="383"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.4
+</section>
+<para>
+1
+</para>
+<description>
+        The auto type-specifier signifies that the
+        type of an object being declared shall be deduced from its
+        initializer or specified explicitly at the end of a
+        function declarator. A function declarator does not declare
+        an object.
+</description>
+<suggestion>
+        The auto
+        type-specifier signifies that the type of an object being
+        declared shall be deduced from its initializer or that the
+        return type of a function is specified explicitly at the
+        end of a function declarator.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="95"
+  uknum="396"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.4
+</section>
+<para>
+4
+</para>
+<description>
+        (See also
+        c++std-core-13583) This paragraph allows auto "in the
+        type-specifier-seq in a new-type-id (5.3.4)" (and nowhere
+        else not listed). Specifically, it isn't allowed in a
+        type-id in a new-expression. That allows "new auto (42)",
+        but not "new (auto)(42)". However, 5.3.4/2 suggests the
+        latter should be allowed "If the auto type-specifier
+        appears in the type-specifier-seq of a new-type-id or
+        type-id of a new-expression ...". The inconsistency should
+        be resolved, ideally in favour of allowing both forms.
+</description>
+<suggestion>
+        Change "in a new-type-id" to "in a
+        new-type-id or type-id in a new-expression".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="24"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.1.6.4
+[auto
+specifier]
+</section>
+<para>
+</para>
+<description>
+        Now that 'auto' is finally
+        used in its most obvious sense to state `deduce the type of
+        this variable from initializer', it should also be allowed
+        in template parameter declarations, as in
+        <BR/><BR/>
+        <BR/><BR/>template&lt;auto n&gt; struct
+        X { /* &#8230; */ };
+        <BR/><BR/>
+        <BR/><BR/>X&lt;903&gt; x;
+        <BR/><BR/>
+        <BR/><BR/>
+        X&lt;&amp;Widget::callback&gt; y;
+        <BR/><BR/>
+        <BR/><BR/>instead of the current, often
+        verbose and cumbersome
+        <BR/><BR/>
+        <BR/><BR/><span lang=
+        "fr-FR">template&lt;typename T, T n&gt; struct X { /*
+        &#8230;</span> <font face="Consolas, monospace">*/
+        };</font>
+        <BR/><BR/>
+        <BR/><BR/>X&lt;int,903&gt; x;
+        <BR/><BR/>X&lt;void
+        (Widget::*)(),&amp;Widget::callback&gt; y;
+        <BR/><BR/>
+        <BR/><BR/>We understand that 'auto' is
+        used in 14.1/18 in a different way (for constrained
+        template), but that usable appears very strange syntax,
+        unnatural and does not fit well with the usage in this
+        section.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="38"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.2
+</section>
+<para>
+1
+</para>
+<description>
+        The
+        discussion of attribute specifiers should be a separate
+        paragraph.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="39"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.2
+</section>
+<para>
+2
+</para>
+<description>
+        The
+        paragraph says in part "An opaque-enum-declaration
+        declaring an unscoped enumeration shall not omit the
+        enum-base." This statement implies that the base may be
+        omitted for scoped enumerations, which is somewhat
+        inconsistent with paragraph 3 and somewhat consistent with
+        paragraph 5.
+</description>
+<suggestion>
+        As this implication leaves no
+        representation, it should be either affirmed here or the
+        statement should be expanded. Perhaps a note is warranted.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="13"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.2
+</section>
+<para>
+para 3
+</para>
+<description>
+        In
+        the description for an unscoped enumeration, enum-base in
+        redeclaration must be the same underlying type as in the
+        1st declaration, but it is not described explicitly, while
+        it is referred that all enum-bases in redeclarations must
+        specify the same underlying type.
+</description>
+<suggestion>
+        Replace the description, "same underlying type", with
+        "same as underlying type of (previous) declaration."
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="96"
+  uknum="384"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.2
+</section>
+<para>
+7
+</para>
+<description>
+        enum E { }; What
+        are the values of E? It has neither a smallest nor largest
+        enumerator, so paragraph 7 doesn't help. (Paragraph 6
+        indicates that the underlying type is as if E had a single
+        enumerator with value 0, but that does not define the
+        values of E.)
+</description>
+<suggestion>
+        Add a second sentence to paragraph 7
+        (before "Otherwise"): "If the enumerator-list is empty, 0
+        is the only value of the enumeration."
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="97"
+  uknum="385"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.2
+</section>
+<para>
+9
+</para>
+<description>
+        Missing
+        punctuation after "blue" in: "The possible values of an
+        object of type color are red, yellow, green, blue these
+        values can be converted ..."
+</description>
+<suggestion>
+        Add a semicolon: "The possible values of an
+        object of type color are red, yellow, green, blue; these
+        values can be converted ..."
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="98"
+  uknum="402"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.2
+</section>
+<para>
+5
+</para>
+<description>
+        It would be
+        useful to be able to determine the underlying type of an
+        arbitrary enumeration type. This would allow safe casting
+        to an integral type (especially needed for scoped enums,
+        which do not promote), and would allow use of
+        numeric_limits. In general it makes generic programming
+        with enumerations easier.
+</description>
+<suggestion>
+        Add a TransformationTrait to 20.5.6 that
+        returns the underlying type of an enumeration type.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="99"
+  uknum="421"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.2
+</section>
+<para>
+3
+</para>
+<description>
+        It is unclear
+        whether an enumeration type is complete after an
+        opaque-enum-declaration. This paragraph only says so in a
+        note, and the general rule in 3.9/5 ("Incompletely-defined
+        object types ... are incomplete types") is unclear in this
+        situation.
+</description>
+<suggestion>
+        Move "an enumeration declared by an
+        opaque-enum-declaration ... is a complete type" from the
+        note to normative text.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="14"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.3.1
+</section>
+<para>
+</para>
+<description>
+        The description of the behavior when a member that was
+        defined with same name in other namespace was referred.
+        <BR/><BR/>
+        - It seems that the behavior of the following case is not
+        defined. So we think that it is necessary to define that.
+        <BR/><BR/>namespace Q {
+        <BR/><BR/>inline namespace
+        V {
+        <BR/><BR/>int g;
+        <BR/><BR/>}
+        <BR/><BR/>int g;
+        <BR/><BR/>}
+        <BR/><BR/>Q::g =1;//
+        ill-fromed, Q::V::g =1;, or Q::g = 1;?
+        <BR/><BR/>
+        - Add that the following case is ill-formed to more easily
+        to understand.
+        <BR/><BR/>namespace Q {
+        <BR/><BR/>inline namespace
+        V1{
+        <BR/><BR/>int g;
+        <BR/><BR/>}
+        <BR/><BR/>inline namespace
+        V2{
+        <BR/><BR/>int g;
+        <BR/><BR/>}
+        <BR/><BR/>}
+        <BR/><BR/>Q::g
+        =1;//ill-formed
+</description>
+<suggestion>
+        Add the description of the behavior when a member that was
+        defined with same name in other namespace was referred.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="100"
+  uknum="387"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.3.3
+</section>
+<para>
+10 and 13
+</para>
+<description>
+        Para 10 says "A
+        using-declaration is a declaration and can therefore be
+        used repeatedly where (and only where) multiple
+        declarations are allowed." Para 13 says "Since a
+        using-declaration is a declaration, the restrictions on
+        declarations of the same name in the same declarative
+        region (3.3) also apply to using-declarations." These
+        appear to be saying exactly the same thing.
+</description>
+<suggestion>
+        Delete para 10, moving its example into
+        para 13.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="101"
+  uknum="388"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.3.3
+</section>
+<para>
+20
+</para>
+<description>
+        If a
+        using-declaration uses the keyword typename and specifies a
+        dependent name (14.6.2), the name introduced by the
+        using-declaration is treated as a typedef-name (7.1.3).
+        That doesn't specify at all what the effect of using
+        typename with a non-dependent name is. Is it allowed? What
+        about outside any template? What if the name isn't a type?
+        (14.6/4 doesn't cover this, I think.)
+</description>
+<suggestion>
+        Allow typename for non-dependent names iff
+        they refer to a type.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="12"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.3.3
+</section>
+<para>
+p15
+</para>
+<description>
+        DE-12
+        Overriding and hiding of member functions named in
+        using-declarations should consider ref-qualifiers, because
+        they are part of the function type.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="25"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.3.3
+[The using
+declaration]
+</section>
+<para>
+Para 21
+</para>
+<description>
+        The syntax for concept map alias is unnecessarily both
+        confused and verbose.
+</description>
+<suggestion>
+        We strongly suggest
+        simplifications, e.g.
+        <BR/><BR/>using N1::C&lt;int&gt;;
+        <BR/><BR/>that fits well with existing
+        constructs. The syntactic complexity is too high for a new
+        feature presumably designed to support sound programming.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="102"
+  uknum="389"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.3.4
+</section>
+<para>
+6
+</para>
+<description>
+        This paragraph
+        says "If name lookup finds a declaration for a name in two
+        different namespaces, and the declarations do not declare
+        the same entity and do not declare functions, the use of
+        the name is ill-formed." But the example uses declaration
+        of functions, so is not covered by this paragraph.
+</description>
+<suggestion>
+        Move the example to paragraph 7, and/or
+        replace it with an appropriate example.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="40"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6
+</section>
+<para>
+</para>
+<description>
+        The
+        list of attributes is missing an attribute to indicate that
+        a function with a <font size="2" style=
+        "font-size: 11pt"><code>throw()</code> (throws nothing)
+        clause need not have the <code>unexpected()</code> catch
+        clause generated. This attribute was a motivating example
+        for the attribute syntax, and its omission is
+        surprising.</font>
+</description>
+<suggestion>
+        Add the attribute.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="41"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6
+</section>
+<para>
+</para>
+<description>
+        A
+        common problem is unintentionally declaring a new virtual
+        member function instead of overriding a base virtual member
+        function.
+</description>
+<suggestion>
+        An attribute stating intent to
+        override would enable better diagnostics.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="26"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6[Attributes]
+</section>
+<para>
+</para>
+<description>
+        Are they part of object types
+        or not? The section does not appear to indicate that
+        clearly.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FI"
+  num="1"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6
+</section>
+<para>
+</para>
+<description>
+        Add override-attribute for functions in order to avoid
+        mistakes when overriding functions.
+</description>
+<suggestion>
+        See override&#173;-attribute.doc, override-attribute.ppt
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="27"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.1
+</section>
+<para>
+</para>
+<description>
+        This section specifies that
+        no name lookup is performed on any identifier contained in
+        an attribute-token. This in particular implies that, for
+        example, it is impossible to define a template class
+        parameterized by its alignment. That restriction is
+        unacceptable.
+        <BR/><BR/>The original alignment
+        proposal made that useful construct possible.
+        <BR/><BR/>Furthermore paragraph 7.6.1/2
+        appears contradictory with the rest of that section --
+        since no name lookup is performed, how a 'type-id'is
+        determined?
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="103"
+  uknum="397"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.1
+</section>
+<para>
+</para>
+<description>
+        Attributes should support pack expansion.
+        For example, this would be extremely useful with the align
+        attribute, directly supporting the (removed) functionality
+        of aligned_union. NOte that aligned_union was removed as
+        varaiant-unions were considered a complete replacement -
+        however this is not true for variadic templates. Adding
+        this support to attributes would remove the remaining need,
+        and support similar attributes in the future.
+</description>
+<suggestion>
+        Add: attribute... to the grammar for
+        attribute-list Add to list in 14.5.3p4: "In an
+        attribute-list(7.6.1); the pattern is an attribute."
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="104"
+  uknum="398"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.1
+</section>
+<para>
+1
+</para>
+<description>
+        It is helpful
+        for each subclause to contain a short paragraph introducing
+        its intent an purpose. 7.6 has such a paragraph, but it is
+        nested under a more specific subsection.
+</description>
+<suggestion>
+        7.6.1p1 should move up one level to become
+        7.6p1. There grammar should remain under 7.6.1
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="105"
+  uknum="448"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.1
+</section>
+<para>
+1
+</para>
+<description>
+        Allowing only one level of namespaces in
+        attributes seems unnecessarily limiting.
+</description>
+<suggestion>
+        To: attribute-scoped-token:
+        attribute-namespace :: identifier add attribute-namespace
+        :: attribute-scoped-token
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="106"
+  uknum="391"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.2
+</section>
+<para>
+1
+</para>
+<description>
+        Extensive use of
+        alignment and related terms without cross reference.
+</description>
+<suggestion>
+        Add cross-reference to 3.11.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="15"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.2
+</section>
+<para>
+</para>
+<description>
+        An abbreviation
+        of 7.6.2 should be &#8220;[decl.attr.align]&#8221; instead
+        of &#8220;[dcl.align]&#8221;.
+        Section name &#8220;[dcl.align]&#8221; is not consistent
+        with others, because others in 7.6 are the form of
+        &#8220;dcl.attr.*&#8221;. In N2761, the section name of
+        7.1.7 had been changed from &#8220;[dcl.align]&#8221; to
+        &#8220;[dcl.attr.align]&#8221;, but in N2800 it was
+        reverted to &#8220;[dcl.align]&#8221; along with a change
+        of section number, 7.1.7 to 7.6.2.
+</description>
+<suggestion>
+        Change "[dcl.align]" of 7.6.2 to "[decl.attr.align]".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="107"
+  uknum="399"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.3
+</section>
+<para>
+</para>
+<description>
+        While undefined
+        behaviour might be the best we can guarantee, it would be
+        helpful to encourage implementations to diagnose function
+        definitions that might execute a return.
+</description>
+<suggestion>
+        Adda a [Note : implementations are
+        encouraged to issue a diagnostic where the definition of a
+        function marked [[noreturn]] might execute a return
+        statement -- end note]
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="108"
+  uknum="401"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.4
+</section>
+<para>
+2
+</para>
+<description>
+        It is unclear
+        why no diagnostic is required for an easily detectable
+        violation. It is even more surprising that the associated
+        footnote mandates behaviour for an ill-formed program.
+</description>
+<suggestion>
+        Strike "no diagnostic required" and the
+        associated footnote.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="42"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.4
+</section>
+<para>
+</para>
+<description>
+        The
+        meaning of the <font size="2" style=
+        "font-size: 11pt"><code>[[final]]</code> attribute applied
+        to classes is inconsistent with other languages and not
+        desirable in its own right.</font>
+</description>
+<suggestion>
+        Modify the semantics of <font size="2" style=
+        "font-size: 11pt"><code>[[final]]</code> applied to
+        classes. See the attached paper "Issues with the C++
+        Standard" under Chapter 7 "Meaning of
+        <code>[[final]]</code> attribute applied to
+        classes".</font>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="109"
+  uknum="392"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.5
+</section>
+<para>
+4
+</para>
+<description>
+        The example code
+        refers in comments to "Compilation unit" A and B. The term
+        should be "Translation unit" (2/1)
+</description>
+<suggestion>
+        Replace "Compilation" with "Translation" in
+        two places
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="110"
+  uknum="393"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+7.6.5
+</section>
+<para>
+4
+</para>
+<description>
+        The code in the
+        example (compilation unit A) has:
+        "foo_head[i].load(memory_order_consume)". foo_head[i] is of
+        type foo *, so it does not have a load member.
+</description>
+<suggestion>
+        Change the type of foo_head to
+        atomic&lt;foo *&gt;[].
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="43"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+8
+</section>
+<para>
+</para>
+<description>
+        With the introduction of late-specified return types for
+        functions and lambda expressions, we now have three
+        different syntaxes for declaring functions. The <font size=
+        "2" style="font-size: 11pt"><code>-&gt;</code> late
+        declaration is used in two. The <code>auto</code> keyword
+        is used in one, but also used differently in variable
+        definitions.</font>
+</description>
+<suggestion>
+        Some simplification is needed.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="111"
+  uknum="457"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+8.3.5
+</section>
+<para>
+13
+</para>
+<description>
+        Example missing
+        closing bracket in template&lt;typename... T&gt; void f(T
+        (* ...t)(int, int);
+</description>
+<suggestion>
+        Add closing bracket like this:
+        template&lt;typename... T&gt; void f(T (* ...t)(int, int));
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="44"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+8.3.5
+</section>
+<para>
+13
+</para>
+<description>
+        In
+        the Example, "template void f(T (* ...t)(int, int);" is
+        missing a close parenthesis.
+</description>
+<suggestion>
+        It presumably should read:
+        "template void f(T (* ...t))(int, int);".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="45"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+8.3.5
+</section>
+<para>
+13
+</para>
+<description>
+        At present,
+        function parameter packs can only occur at the end of a
+        parameter-declaration-list. This restriction unnecessarily
+        prohibits uses of function parameter packs in cases where
+        template argument deduction isn&#8217;t needed, e.g.,
+        <BR/><BR/>
+        <BR/><BR/>
+        template&lt;class... T&gt; struct X { };
+        <BR/><BR/>
+        template&lt;class... T1, class... T2&gt;
+        <BR/><BR/>struct
+        X&lt;pair&lt;T1, T2&gt;...&gt; {
+        <BR/><BR/>void f(T1...,
+        T2...);
+        <BR/><BR/>};
+        <BR/><BR/>
+        <BR/><BR/>More
+        importantly, this restriction is inconsistent with the way
+        pack expansions are handled. For example, this template is
+        well-formed (but X&lt;T..., int&gt; is a non-deduced
+        context):
+        <BR/><BR/>
+        <BR/><BR/>
+        template&lt;class... T&gt; void f(X&lt;T..., int&gt;);
+        <BR/><BR/>
+        <BR/><BR/>Therefore, the restriction that limits
+        function parameter packs to the end of the
+        parameter-declaration-list should be removed. Instead,
+        function parameter packs not at the end of the
+        parameter-declaration-list should be considered non-deduced
+        contexts.
+</description>
+<suggestion>
+        In 8.3.5p13,
+        remove the sentence &#8220;<span lang="">A function
+        parameter pack, if present, shall occur at the end of the
+        parameter-declaration-list.&#8221;</span>
+        <BR/><BR/>
+        <BR/><BR/><span lang="">In
+        14.8.2.1p1, replace the phrase &#8220;For a function
+        parameter pack&#8221; with &#8220;For a function parameter
+        pack that occurs at the end of a</span> <font size="3"
+        face="Helvetica, sans-serif"><span lang=
+        ""><i>parameter-declaration-list</i>&#8221;.</span></font>
+        <BR/><BR/>
+        <BR/><BR/><span lang=
+        "">Replace the note text &#8220;A function parameter pack
+        can only occur at the end of a
+        parameter-declaration-</span>list (8.3.5).&#8221; with
+        &#8220;A function parameter pack that does not occur at the
+        end of a parameter-declaration-list is a non-deduced
+        context.&#8221;
+        <BR/><BR/>
+        <BR/><BR/>In 14.8.2.5p5,
+        add a new bullet: &#8220;A function parameter pack that
+        does not occur at the end of its
+        parameter-declaration-list.&#8221;
+        <BR/><BR/>
+        <BR/><BR/>In 14.8.2.5p10,
+        replace &#8220;<span lang="">If</span> <font size="3" face=
+        "Helvetica, sans-serif">the parameter-declaration
+        corresponding to Pi is a function parameter pack&#8221;
+        with &#8220;<span lang="">If</span> <font size="3">the
+        parameter-declaration corresponding to Pi is a function
+        parameter pack and Pi occurs at the end of the
+        parameter-declaration-list&#8221;.</font></font>
+        <BR/><BR/>
+        <BR/><BR/>Replace
+        <font size="3" face="Helvetica, sans-serif"><span lang=
+        "">the note text &#8220;A function parameter pack can only
+        occur at the end of a parameter-declaration-</span>list
+        (8.3.5).&#8221; with &#8220;A function parameter pack that
+        does not occur at the end of a parameter-declaration-list
+        is a non-deduced context.&#8221;</font>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="13"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+8.4
+</section>
+<para>
+p2
+</para>
+<description>
+        DE-13 The second paragraph, quoting the grammar for the
+        declarator of a function declaration, is not considering
+        late-specified return types and attributes.
+</description>
+<suggestion>
+        Properly quote the grammar from 8.3.5.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="16"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+8.5
+</section>
+<para>
+        15<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">para, 1<sup>st</sup> line</font>
+</para>
+<description>
+        Typo, duplicated "in"
+        <BR/><BR/>"The initialization that
+        occurs in in the forms"
+</description>
+<suggestion>
+        Remove one.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="46"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+8.5.3
+</section>
+<para>
+</para>
+<description>
+        The ability for
+        an rvalue reference to bind to an lvalue opens a
+        type-safety hole that becomes very dangerous with concepts.
+        For example, consider vector&#8217;s push_back operation:
+        <BR/><BR/>requires
+        MoveConstructible&lt;T&gt; void push_back(T&amp;&amp;);
+        <BR/><BR/>requires
+        CopyConstructible&lt;T&gt; void push_back(const T&amp;);
+        <BR/><BR/>
+        <BR/><BR/>For a
+        copy-constructible T (which is also move-constructible),
+        push_back does the right thing. However, if T is something
+        that is move-constructible (e.g., unique_ptr&lt;int&gt;),
+        the second overload is removed from considered (it is
+        effectively SFINAE&#8217;d away), so only the first
+        overload remains. Therefore, one could accidentally call
+        push_back with an lvalue of type T, and push_back would
+        silently move from the lvalue. The same problem occurs
+        without concepts (albeit less frequently).
+</description>
+<suggestion>
+        Prohibit rvalue
+        references from binding to lvalues.
+        <BR/><BR/>
+        <BR/><BR/>Unfortunately
+        this change will break some current use cases of rvalue
+        reference including the use of rvalue streams, and of the
+        forward function itself. To resolve this we may want to
+        consider three types of references:
+        <BR/><BR/>
+        <ol>
+          <li>
+            <BR/><BR/>The current
+            reference.</li>
+          <li>
+            <BR/><BR/>A non-const
+            reference that only binds to rvalues.</li>
+          <li>
+            <BR/><BR/>A non-const
+            reference that will bind to both lvalues and rvalues.</li>
+          </ol>
+        <BR/><BR/>
+        <BR/><BR/>Still another solution would be to adopt
+        the &#8220;deleted function&#8221; solution for all
+        functions. This solution is described in comment for 12.1,
+        12.4, 12.8, but restricted to special functions in that
+        comment. (See US NN).
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="49"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+8.5.4
+</section>
+<para>
+6
+</para>
+<description>
+        In the Example, the comments
+        could be improved.
+</description>
+<suggestion>
+        See
+        the attached paper "Issues with the C++ Standard" under
+        "Editorial Issues" and "8.5.4/6".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="112"
+  uknum="440"
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+9
+</section>
+<para>
+4-9
+</para>
+<description>
+        We now have
+        concepts that should (or should not?) map to the terms
+        described in Clause 9 - these should be at least
+        referenced.
+</description>
+<suggestion>
+        Add appropriate forward references to
+        14.9.4
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="113"
+  uknum="250"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+9.4.2
+</section>
+<para>
+3
+</para>
+<description>
+        Mis-applied edit from the paper n2756
+</description>
+<suggestion>
+        The term 'constant-initializer' should have
+        been struck out when replaced by
+        brace-or-equal-initializer. There are two occurrences in
+        this paragraph
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="50"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+12.1,
+12.4,
+12.8
+</section>
+<para>
+</para>
+<description>
+        Implicitly-declared default constructors, destructors, copy
+        constructors, and copy assignment operators are deleted
+        when their definitions would be ill-formed. However, unlike
+        with overloading and template argument deduction, access
+        control is performed as part of the check for making one of
+        these special function deleted. This inconsistency should
+        be removed.
+        <BR/><BR/>
+        <BR/><BR/>This change
+        would sacrifice some backward compatibility in favor of
+        consistency. With the current wording, checking that the
+        following class &#8216;A&#8217; is CopyConstructible would
+        proceed without error (it is not CopyConstructible):
+        <BR/><BR/>class A {
+        A(const A&amp;); };
+        <BR/><BR/>With the
+        proposed change, testing whether A is CopyConstructible
+        would produce a diagnostic. To fix the problem, the user
+        would have to use a deleted function:
+        <BR/><BR/>class A {
+        A(const A&amp;) = delete; };
+</description>
+<suggestion>
+        In 12.1p5,
+        remove the phrase &#8220;<span lang="">or inaccessible from
+        the implicitly-declared default</span> <font size="3" face=
+        "Helvetica, sans-serif">constructor&#8221;.</font>
+        <BR/><BR/>
+        <BR/><BR/>In 12.4p3,
+        remove the phrase &#8220;<span lang="">or a destructor that
+        is inaccessible from the implicitly-declared
+        destructor,&#8221; and the phrase &#8220;or a destructor
+        that is inaccessible from the</span> <font size="3" face=
+        "Helvetica, sans-serif">implicitly-declared
+        destructor<span lang="">&#8221;.</span></font>
+        <BR/><BR/>
+        <BR/><BR/>In 12.8p5,
+        remove the phrase &#8220;<span lang="">or inaccessible from
+        the implicitly-declared copy constructor&#8221; from the
+        two places it occurs.</span>
+        <BR/><BR/>
+        <BR/><BR/>In 12.8p10,
+        remove the phrase &#8220;<span lang="">or inaccessible from
+        the implicitly-declared copy assignment operator&#8221;
+        from the two places it occurs.</span>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="28"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+12.6.1
+[Explicit
+initialization]
+</section>
+<para>
+</para>
+<description>
+        This section, in particular the example with `g' appears
+        contradictory with the syntax for uniform initialization.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="51"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+12.6.2
+</section>
+<para>
+2
+</para>
+<description>
+        The
+        discussion of delegating constructors should be in its own
+        paragraph.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="114"
+  uknum="167"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+12.6.2
+</section>
+<para>
+1
+</para>
+<description>
+        Despite all the attempts to unify
+        initialization syntax, it is still not possible to
+        copy-initialize base classes or non-static data members,
+        which means the explicit keyword cannot have a bearing
+        during evaluation of a constructor. A minimal addition to
+        the grammar, allowing an optional = between the
+        mem-initializer-id and braced-init-list would allow the
+        user to choose between copy and direct initialization
+</description>
+<suggestion>
+        Ammend the
+        grammar for mem-initializer: mem-initializer-id =OPT
+        braced-init-list Extend p3 to allow for Copy Initialization
+        if the optional = is present: 3 The expression-list or
+        braced-init-list in a mem-initializer is used to initialize
+        the base class or non-static data member subobject denoted
+        by the mem-initializer-id according to the initialization
+        rules of 8.5 for direct-initialization, OR
+        COPY-INITIALIZATION IF THE OPTIONAL = IS PRESENT BETWEEN
+        THE MEM-INITIALIZER-ID and the BRACED-INIT-LIST.
+        [Example:...
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="52"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+13.5.8
+</section>
+<para>
+&#182; 5
+</para>
+<description>
+        A word is misspelled.
+</description>
+<suggestion>
+        Change &#8220;shal&#8221; to &#8220;shall&#8221;.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="115"
+  uknum="432"
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14
+</section>
+<para>
+6-11
+</para>
+<description>
+        Exported
+        templates were a great idea that is generally understood to
+        have failed. In the decade since the standard was adopted,
+        only one implementation has appeared. No current vendors
+        appear interested in creating another. We tentatively
+        suggest this makes the feature ripe for deprecation. Our
+        main concern with deprecation is that it might turn out
+        that exported constrained templates become an important
+        compile-time optimization, as the constraints would be
+        checked once in the exported definition and not in each
+        translation unit consuming the exported declarations.
+</description>
+<suggestion>
+        Consider deprecating exported templates,
+        but no action yet. Examine interaction with constrained
+        templates, and see if other more appropriate mechanism will
+        support compile-time optimization.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="116"
+  uknum="434"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14
+</section>
+<para>
+6-11
+</para>
+<description>
+        Is it possible
+        to export a concept map template? The current wording
+        suggests it is possible, but it is not entirely clear what
+        it would mean.
+</description>
+<suggestion>
+        Either prohibit exporting concept map
+        templates, or more directly address what it means to export
+        a concept map.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="117"
+  uknum="430"
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14
+</section>
+<para>
+2
+</para>
+<description>
+        It would be nice
+        to allow template alias within a function scope, and
+        possibly a scoped concept map. As these affect name lookup
+        and resolution, rather than defining new callable code,
+        they are not seen to present the same problems that
+        prevented class and function templates in the past.
+</description>
+<suggestion>
+        Allow template aliases to be declared
+        inside a function scope, and consider scoped concept maps.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="118"
+  uknum="431"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14
+</section>
+<para>
+6-11
+</para>
+<description>
+        Exported
+        templates are a complicated feature with surprisingly
+        little text. To make this important text more visible,
+        split it off into its own subclause [temp.export]
+</description>
+<suggestion>
+        Create a new subclause [temp.export]
+        containing 14p6-11. Move 14p12 ahead of this subclause.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="119"
+  uknum="433"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14
+</section>
+<para>
+4
+</para>
+<description>
+        Does a concept
+        map have linkage? Reading this paragraph and 3.5 suggests a
+        concept map template has external linkage, but not a
+        'regular' concept map. Believe this is an oversight that
+        the linkage words were not updated to provide an exception,
+        rather than linkage of concept maps is intended.
+</description>
+<suggestion>
+        Add an exception that concept map templates
+        have no linkage, or add concept maps to the list of
+        entities with linkage in 3.5
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="120"
+  uknum="422"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.1
+</section>
+<para>
+9
+</para>
+<description>
+        As this is the
+        first time the phrase &#8220;parameter pack&#8221; appears
+        in Ch 14 I would like to see the section 8.3.5 referenced
+        here (as well as in 14.1p17).
+</description>
+<suggestion>
+        Insert &#8220;(8.3.5)&#8221; after
+        &#8220;parameter pack&#8221;
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="121"
+  uknum="423"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.1
+</section>
+<para>
+18
+</para>
+<description>
+        The example
+        (that follows the normative text) has no begin example
+        marker
+</description>
+<suggestion>
+        Prefix the example code with "[ Example:"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="29"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.3
+[Template
+arguments]
+</section>
+<para>
+</para>
+<description>
+        Constant expressions of any literal type should be
+        allowed as template arguments.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="53"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.5.1
+</section>
+<para>
+5
+</para>
+<description>
+        If the
+        requirements of a constrained member that is a copy
+        constructor, copy assignment operator, or destructor are
+        not satisfied, then that user-declared special function
+        will not exist. It appears that, in this case, the special
+        function will then be <font size="3" face=
+        "Helvetica, sans-serif"><i>implicitly</i> <font size=
+        "3">defined, which is likely to either (a) fail to compile
+        or (b) produce a function with the wrong semantics. For
+        example:</font></font>
+        <BR/><BR/>
+        template&lt;ObjectType T&gt; class vector {
+        <BR/><BR/>T* first, last,
+        end;
+        <BR/><BR/>public:
+        <BR/><BR/>requires
+        CopyConstructible&lt;T&gt; vector(const vector&amp;);
+        <BR/><BR/>};
+        <BR/><BR/>
+        <BR/><BR/>If instantiated with a type that is not
+        CopyConstructible, vector will get an implicitly-defined
+        copy constructor that performs a copy of the pointers.
+</description>
+<suggestion>
+        Add to 14.5.1p5:
+        <BR/><BR/>If the constrained member is a copy
+        constructor (12.8), destructor (12.4), or copy assignment
+        operator and its template requirements are not satisfied,
+        then a copy constructor, destructor, or copy assignment
+        operator, respectively, with the same signature as the
+        constrained member (after substituting the class
+        template&#8217;s template arguments for its template
+        parameters) will be declared as a deleted function (8.4).
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="122"
+  uknum="426"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.5.3
+</section>
+<para>
+4
+</para>
+<description>
+        Variadic
+        templates should be supported in axioms. There are axioms
+        in the library that rely on this feature, such as the
+        FrontEmplacement axiom in FrontEmplacementContainer
+        (23.1.6.1p10)
+</description>
+<suggestion>
+        Add clarification in p2 that function
+        parameter packs can be used to declare axioms, much like p1
+        clarifies they can be used to declare concepts as well as
+        templates.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="30"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.5.7
+[Template
+aliases]
+</section>
+<para>
+</para>
+<description>
+        When are two template alias
+        names equivalent?
+        <BR/><BR/>
+        <BR/><BR/>E.g. given
+        <BR/><BR/>
+        template&lt;template&lt;class&gt; class&gt; struct X { };
+        <BR/><BR/>
+        <BR/><BR/>
+        template&lt;typename,typename&gt; struct Y { };
+        <BR/><BR/>
+        <BR/><BR/>template&lt;typename T&gt;
+        <BR/><BR/>using Z1 = Y&lt;int,T&gt;;
+        <BR/><BR/>
+        <BR/><BR/>template&lt;typename T&gt;
+        <BR/><BR/>using Z2 = Y&lt;int,T&gt;;
+        <BR/><BR/>
+        <BR/><BR/>Are the types X&lt;Z1&gt; and
+        X&lt;Z2&gt; equivalent?
+        <BR/><BR/>We would suggest yes (since
+        Z1&lt;T&gt; and Z2&lt;T&gt; are the same for all T), but we
+        do not see any wording to that effect.
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="17"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.7.2
+</section>
+<para>
+2<sup>nd</sup> <font size="2"
+        style="font-size: 11pt">para, 15<sup>th</sup>
+        line</font>
+</para>
+<description>
+        Typo.
+        <BR/><BR/>if
+        that namespace is inline, any namespace from its enclosing
+        namespace set.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>if
+        that namespace is inline, any namespace <font size="2"
+        style="font-size: 11pt"><font color=
+        "#339966">forming</font> its enclosing namespace
+        set.</font>
+</description>
+<suggestion>
+        Replace "from" with "forming"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="14"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.7.3
+</section>
+<para>
+p1
+</para>
+<description>
+        DE-14 The bulleted list neither addresses "member
+        function template of a class" nor "member class template of
+        a class".
+</description>
+<suggestion>
+        Add the respective bullets.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="18"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.7.3
+</section>
+<para>
+2<sup>nd</sup> <font size="2"
+        style="font-size: 11pt">para, 2<sup>nd</sup>
+        line</font>
+</para>
+<description>
+        Typo,
+        <BR/><BR/>any
+        namespace from its enclosing namespace set
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>any
+        namespace <font size="2" style=
+        "font-size: 11pt"><font color="#339966">forming</font> its
+        enclosing namespace set</font>
+</description>
+<suggestion>
+        Replace "from" with "forming"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="19"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.8.2
+</section>
+<para>
+6<sup>th</sup> <font size="2"
+        style="font-size: 11pt">para, 1<sup>st</sup>
+        line</font>
+</para>
+<description>
+        Typo, duplicated "is"
+        <BR/><BR/>"At certain
+        points in the template argument deduction process it <u>is
+        is</u> necessary"
+</description>
+<suggestion>
+        Remove one
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="54"
+  uknum=""
+  type="ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9
+[concept],
+        14.10
+[temp.
+        constrained]
+</section>
+<para>
+</para>
+<description>
+        Concepts is of course the largest new feature in C++0x
+        (in terms of new text inserted into the wording), and
+        already we have found some significant defects with it. So
+        far nothing devastating has been found, but more time is
+        needed to shake more bugs out.
+</description>
+<suggestion>
+        I propose no specific change here.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="55"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1
+</section>
+<para>
+&#182; 6
+</para>
+<description>
+        The paragraph number is in the wrong place, causing a
+        grammar rule to be indented more than its fellows.
+</description>
+<suggestion>
+        Move the paragraph number so as to follow the grammar
+        rules, thus numbering the single sentence, &#8220;The body
+        of a concept &#8230; .&#8221;
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="56"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1
+</section>
+<para>
+&#182; 6
+</para>
+<description>
+        The sentence contains two references to 14.9.1.3
+        [concept.req].
+</description>
+<suggestion>
+        Change the second such reference (at the end of the
+        sentence) to 14.9.1.4 [concept.axiom].
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="57"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1.4
+</section>
+<para>
+&#182; 3
+</para>
+<description>
+        A word is misplaced, changing the intended meaning.
+</description>
+<suggestion>
+        Change &#8220;only find &#8230; if&#8221; to &#8220;find
+        &#8230; only if&#8221;.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="58"
+  uknum=""
+  type="ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1.4
+</section>
+<para>
+&#182; 3
+</para>
+<description>
+        The listed phrases are not grammatically parallel.
+</description>
+<suggestion>
+        Insert &#8220;in&#8221; before &#8220;one&#8221; so as
+        to obtain &#8220;... in the concept, in one of its less
+        refined concepts, or in an associated requirement.&#8221;
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="59"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1.4
+</section>
+<para>
+</para>
+<description>
+        Axioms are under-specified and provide
+        little benefit to programmers, so they should be removed
+        from the working paper. The optimizations permitted by
+        axioms (see 14.9.1.4p4-5) are not compulsory (and,
+        therefore, programmers cannot rely on them) and the
+        semantics expressed by axioms cannot be verified by any
+        implementation. The resulting specification has lead to
+        great confusion (see the reflector thread &#8220;Are
+        floating point types Regular?&#8221; starting with
+        c++std-lib-22717). Given the level of confusion and the
+        inability to verify the correctness of axioms, it is likely
+        that many axioms written by programmers (including those
+        specified in the candidate draft) will be incorrect.
+</description>
+<suggestion>
+        Remove clause
+        14.9.1.4 [concept.axiom]
+        <BR/><BR/>In 2.11p1,
+        remove &#8220;axiom&#8221; from the list of keywords.
+        <BR/><BR/>
+        <BR/><BR/>In 14.5.8p7,
+        remove &#8220;, or if the resulting concept map fails to
+        satisfy the axioms of the corresponding concept&#8221;
+        <BR/><BR/>
+        <BR/><BR/>In 14.9.1p6,
+        remove axiom-definition from the list of grammar
+        productions for concept-member-specifier. Remove &#8220;,
+        and axioms&#8221; from the final sentence, and instead
+        &#8220;and&#8221; prior to &#8220;associated
+        requirements&#8221; in the final sentence.
+        <BR/><BR/>
+        <BR/><BR/>
+        <BR/><BR/>Remove paragraph
+        14 of clause 14.9.2.
+        <BR/><BR/>
+        <BR/><BR/>In 14.10.1p6,
+        remove the sentence, &#8220;When the
+        concept-instance-alias-def appears in the optional
+        requires-clause of an axiom-definition (14.9.1.4), the
+        potential scope of the identifier begins at its point of
+        declaration and terminates at the end of the
+        axiom-de&#64257;nition.&#8221;
+        <BR/><BR/>
+        <BR/><BR/>In clauses
+        20.2.5, 20.2.8, 23.1.6.1, 23.1.6.2, and 24.1.4, remove the
+        axiom-definitions and replace them with paragraphs (denoted
+        Requires, Postconditions, or Effects, as appropriate) that
+        express the intended semantics of the concepts from which
+        the axiom-definitions were removed.
+        <BR/><BR/>
+        <BR/><BR/>In 24.1.4p2,
+        replace the word &#8220;axiom&#8221; with
+        &#8220;condition.&#8221;
+        <BR/><BR/>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="31"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1.4
+[Axioms]
+</section>
+<para>
+</para>
+<description>
+        This section states that an
+        axiom-definition defines a new semantics axiom but is
+        unusually vague as to what those semantics might be.
+        <BR/><BR/>
+        <BR/><BR/>The use of the '==' and '!='
+        with completely new semantics, unrelated to anything we
+        have seen before in C++ is both unwise and confusing,
+        especially if the types involved in the expressions happen
+        to have operator== and operator!= defined.
+        <BR/><BR/>We strongly suggest use of
+        different tokens, e.g. <font face=
+        "Consolas, monospace">&#61683;, and opposed to this obscure
+        usage/overload.</font>
+        <BR/><BR/>The description is very
+        vague. How many times is an implementation permitted to
+        replace one expression by another one when they have side
+        effects?
+</description>
+<suggestion>
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="15"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1.4
+</section>
+<para>
+</para>
+<description>
+        DE-15 There is no implementation experience for axioms.
+        Use of axioms is an area of active scientific research. It
+        is likely that syntax changes will become necessary to make
+        good use of axioms; having the syntax space already crowded
+        is unhelpful. Axioms ought to be useful in concepts
+        applicable to floating-point types (such as
+        EqualityComparable), but IEEE floating-point types have
+        special values such as NaN violating the axioms.
+</description>
+<suggestion>
+        Remove section 14.9.1.4 and any reference to axioms in
+        the rest of the proposed standard other than the keyword
+        reservation in section 2.11.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="123"
+  uknum="248"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1.4
+</section>
+<para>
+</para>
+<description>
+        auto concepts
+        and axioms are incompatible. An axiom defines the semantics
+        of an operaton or set of operations that describes the run
+        time behaviour. A concept describes purely syntactic
+        requirements at compile time. Where an auto concept will
+        match anything that meets the syntax requirements, there is
+        no way to know if the axioms will be met or not, and no way
+        to opt out via some kind of negative concept map.
+</description>
+<suggestion>
+        Add a paragraph making axioms ill-formed
+        inside an auto concept.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="124"
+  uknum="288"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1.4
+</section>
+<para>
+6
+</para>
+<description>
+        Spelling mistake, double-e in were.
+</description>
+<suggestion>
+        weere -&gt; were
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="125"
+  uknum="289"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.1.4
+</section>
+<para>
+2
+</para>
+<description>
+        The implicit
+        equality comparison operator available to axioms has no
+        semantic. It is not clear what expressing the condition if(
+        a == b ) { conditional-axiom } would mean if a and b are
+        not truly EqualityComparable. We suspect the intent of the
+        'implicit defefinition' is to support declaring the
+        equivalence of statements, a context where the operator
+        will not actually be evaluated.
+</description>
+<suggestion>
+        Define the semantics of the implicitly
+        declared comparison operators, or restrict their usage to
+        declaring equivalence between statements.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="126"
+  uknum="438"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.4
+</section>
+<para>
+41
+</para>
+<description>
+        This paragraph
+        contains the only definition of the underlying_type member
+        - but it's a note, so not normative.
+</description>
+<suggestion>
+        Move the second sentence to the Requires
+        clause in paragraph 42.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="127"
+  uknum="118"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.4
+</section>
+<para>
+</para>
+<description>
+        Provide a
+        diagram clearly showing refinement relationship between the
+        different support concepts. Several were created during
+        development of this clause and they were very helpful.
+</description>
+<suggestion>
+        Provide the diagram.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="128"
+  uknum="435"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.4
+</section>
+<para>
+4
+</para>
+<description>
+        It is surprising for many people that
+        non-copyable move-only types can be used with a return
+        statement, and so Returnable does not always imply
+        CopyConstructible.
+</description>
+<suggestion>
+        A non-normative
+        note: [Note: 'move only' types that are constructible from
+        rvalue references may be Returnable, but not
+        CopyConstructible(20.1.8) - end note]
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="20"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.9.4
+</section>
+<para>
+2<sup>nd</sup> <font size="2"
+        style="font-size: 11pt">para</font>
+</para>
+<description>
+        Trivially copyable type was added in &#8220;3.9
+        Types&#8221;, so we think that it is necessary to add
+        concept to trivially copyable type like
+        &#8220;TriviallyCopyableType&#8221;.
+</description>
+<suggestion>
+        Add
+        TriviallyCopyableType that is trivially copyable type as
+        concept.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="129"
+  uknum="128"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.10.1,
+20.1.2
+</section>
+<para>
+</para>
+<description>
+        It should be
+        possible to support boolean constant expressions as
+        requirements without resorting to defining the True concept
+        in the library. Boolean expressions are very likely to be
+        constraints when deadline with non-type template parameters
+        and variadic templates, and constraints in these cases
+        should feel just as natural as constraints on the type
+        system.
+</description>
+<suggestion>
+        Remove the True concept and library
+        subclause 20.1.2. Provide support in 14.10.1 for boolean
+        constant expressions as constraints. This may involve
+        overloading the true keyword to disambiguate but ideally
+        would not.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="60"
+  uknum=""
+  type="te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+14.10.1
+</section>
+<para>
+1
+</para>
+<description>
+        The use of &amp;&amp; as the separator for
+        a list of requirements has shown itself to be a serious
+        teachability problem. The mental model behind
+        &#8216;&amp;&amp;&#8217; treats concepts as simple
+        predicates, which ignores the role of concepts in
+        type-checking templates. The more programmers read into the
+        &#8216;&amp;&amp;&#8217; (and especially try to fake ||
+        with &amp;&amp; and !), the harder it is for them to
+        understand the role of concept maps. Simply changing the
+        separator to &#8216;,&#8217; would eliminate a significant
+        source of confusion.
+</description>
+<suggestion>
+        Replace
+        <BR/><BR/>
+        requirement-list:
+        <BR/><BR/>requirement-list
+        ... [opt] &amp;&amp; requirement
+        <BR/><BR/>requirement ...
+        [opt]
+        <BR/><BR/>
+        <BR/><BR/>with
+        <BR/><BR/>
+        <BR/><BR/>requirement-list
+        <BR/><BR/>requirement-list
+        ...[opt] , requirement
+        <BR/><BR/>requirement ...
+        [opt]
+        <BR/><BR/>
+        <BR/><BR/>In 14.5.4p6,
+        replace the first sentence with:
+        <BR/><BR/>The
+        instantiation of an expansion produces a comma-separated
+        list E1, E2, ..., EN, where N is the number of elements in
+        the pack expansion parameters.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="130"
+  uknum="32"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.1
+</section>
+<para>
+4
+</para>
+<description>
+        With the new
+        crrent_exception API it is possible to capture a reference
+        to an exception that will outlive its last active handler.
+        That is in conflict with the sentance "When the last
+        remaining active handler for the exception exits by any
+        means other than throw; the temporary object is destroyed
+        and the implementation may deallocate the memory for the
+        temporary object;"
+</description>
+<suggestion>
+        Update sentence to allow for exceptions
+        held in excpetion_ptr objects.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="131"
+  uknum="34"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.3
+</section>
+<para>
+3
+</para>
+<description>
+        A handler
+        catching its parameter by rvalue-reference is syntactically
+        valid, but will never be activated.
+</description>
+<suggestion>
+        Disallow handlers catching by
+        rvalue-reference.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="132"
+  uknum="36"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.3
+</section>
+<para>
+16
+</para>
+<description>
+        There are
+        obscure cases whrere a copy constructor is not usually the
+        best match to copy-initialize an object, e.g. A converting
+        constructor template taking arguments by non-const
+        reference. A footnote explaining such cases would be
+        helpful, or the sentance could be rewritten using
+        copy-initialization instead of directly calling a copy
+        constructor.
+</description>
+<suggestion>
+        Rewite using copy-initialization rather
+        than directly invoking the copy constructor
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="133"
+  uknum="37"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.4
+</section>
+<para>
+2
+</para>
+<description>
+        Template aliases
+        have the same semantics as a typedef so should also be
+        disallowed
+</description>
+<suggestion>
+        add "or alias-declaration" after "shall not
+        appear in a typedef declaration".
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="134"
+  uknum="38"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.4
+</section>
+<para>
+6
+</para>
+<description>
+        The sentance "An
+        exception-specification can also include the class
+        std::bad_exception (18.7.2.1)." is redundant.
+</description>
+<suggestion>
+        Either strike the quoted sentance, or add a
+        note explaining why it is worth calling special attention
+        to this class.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="135"
+  uknum="39"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.4
+</section>
+<para>
+8
+</para>
+<description>
+        Unclear if std::unexpected is called before
+        or after the function arguments have been destroyed
+</description>
+<suggestion>
+        Clarify the sequence of calling unexpected
+        with respect to interesting objects, such as function
+        arguments or partially constructed bases and members when
+        called from a constructor or destructor
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="136"
+  uknum="40"
+  type="Ge"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.4
+</section>
+<para>
+</para>
+<description>
+        Exception specifications have proven close
+        to worthless in practice, while adding a measurable
+        overhead to programs. The feature should be deprecated. The
+        one exception to the rule is the empty throw specification
+        which could serve a legitimate optimizing role if the
+        requirement to call the runtime unexpected mechanism was
+        relaxed in this case.
+</description>
+<suggestion>
+        Move 15.4 and the parts of 15.5 that refer
+        to it to Appendix D. Replace 15.4 with a simpler
+        specification for empty throw specifications, where the
+        std::unexpected call is conditionally supported allowing
+        vendors to choose between optimizing and providing runtime
+        checks. Ideally require vendors to provide a mode where the
+        runtime checks are always disabled.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="137"
+  uknum="44"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.5
+</section>
+<para>
+</para>
+<description>
+        There is no
+        mention of the current_exception API which can extend the
+        lifetime of an exception object. There should at least be a
+        forward reference to the library clause 18.7.5
+</description>
+<suggestion>
+        Add another paragraph outlining 18.7.5 and
+        the ability of an exception_ptr to extend the lifetime of
+        an exception object
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="138"
+  uknum="41"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.5.1
+</section>
+<para>
+1
+</para>
+<description>
+        The third bullet
+        is redundant with the first, as it is a subset of the same
+        conditions.
+</description>
+<suggestion>
+        Merge the third bullet into the first
+        bullet as a note or example.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="139"
+  uknum="42"
+  type="Te"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.5.1
+</section>
+<para>
+1
+</para>
+<description>
+        According to the
+        first bullet it is perfectly alright for a library function
+        to exit by throwing an exception during stack unwinding,
+        This is clearly not true.
+</description>
+<suggestion>
+        Strike the word 'user' from the first
+        bullet point.
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="140"
+  uknum="43"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.5.2
+</section>
+<para>
+2
+</para>
+<description>
+        The detailed
+        specification can fool people into thinking an exception
+        will automatically be translated into bad_exception, where
+        the default behaviour of std::unexcepted is to immediately
+        call std::terminate();
+</description>
+<suggestion>
+        Add a note highlighting the default
+        behaviour of std::unexpected if the user does not supply a
+        hander-function
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="141"
+  uknum="45"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+15.6
+</section>
+<para>
+</para>
+<description>
+        This whole
+        subclause is redundant due to 15.1p5 and 15.3p17
+</description>
+<suggestion>
+        Strike 15.6
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="142"
+  uknum="455"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+16.3.5
+</section>
+<para>
+3
+</para>
+<description>
+        This paragraph
+        opens with "[ Note" but has no corresponding "end note ]"
+</description>
+<suggestion>
+        Add "end note ]"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="143"
+  uknum="456"
+  type="Ed"
+  owner=""
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+16.3.5
+</section>
+<para>
+7
+</para>
+<description>
+        Example uses #define t(x,y.z) x ## y ## z
+</description>
+<suggestion>
+        Change "x,y.z" to "x,y,z"
+</suggestion>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="2"
+  uknum=""
+  type="ge/te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+17-30
+</section>
+<para>
+</para>
+<description>
+        The
+        active issues identified in WG21 N2806, C++ Standard
+        Library Active Issues, must be addressed and appropriate
+        action taken.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        <font color="#000080"><u><a href=
+        "http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
+        http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html></u></font>
+</description>
+<suggestion>
+        Appropriate action would
+        include making changes to the CD, identifying an issue as
+        not requiring a change to the CD, or deferring the issue to
+        a later point in time.
+</suggestion>
+<notes>Acknowledged</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="2"
+  uknum=""
+  type="ge"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+General
+Comment
+</section>
+<para>
+Library
+</para>
+<description>
+        The adoption of the library `constexpr' proposal was not
+        reflected in the draft, despite formal WG21 committee vote.
+</description>
+<suggestion>
+        FR 2
+</suggestion>
+<notes>Editorial; sent to Pete Becker</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="61"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+17 onward
+</section>
+<para>
+</para>
+<description>
+        The concepts core language feature is applied to only
+        some of the Standard Library clauses, and even then not
+        always consistently.
+</description>
+<suggestion>
+        Review all
+        clauses of the Standard Library, and consistently apply
+        concept technology wherever possible and appropriate. The
+        proposed wording in WG21 N2781 exemplifies the necessary
+        level of detail.
+</suggestion>
+<notes>Agreed. Duplicates CA2</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="CA"
+  num="2"
+  uknum=""
+  type="Ge"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+17 Library
+</section>
+<para>
+</para>
+<description>
+        &#8220;Concepts&#8221; are a significant new addition to
+        the language, but are not exploited uniformly in the
+        library as documented in CD 14882.
+</description>
+<suggestion>
+        Fix
+        the standard library so that &#8220;Concepts&#8221; are
+        used appropriately in the library.
+</suggestion>
+<notes>Agreed; We intend to address this.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="62"
+  uknum=""
+  type="ge"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+17-30
+</section>
+<para>
+</para>
+<description>
+        Provide concepts
+        and requirements clauses for all standard library templates
+</description>
+<suggestion>
+</suggestion>
+<notes>Agreed. Duplicates CA2
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="63"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17-30
+</section>
+<para>
+</para>
+<description>
+        The behavior of the library in the presence of threads
+        is incompletely specified.
+        <BR/><BR/>For example, if thread 1 assigns to X, then writes data
+        to file f, which is read by thread 2, and then accesses
+        variable X, is thread 2 guaranteed to be able to see the
+        value assigned to X by thread 1? In other words, does the
+        write of the data "happen before" the read?
+        <BR/><BR/>Another example: does simultaneous access using operator
+        at() to different characters in the same non-const string
+        really introduce a data race?
+</description>
+<suggestion>
+</suggestion>
+<notes>17 SG: should go to threads group; misclassified in document
+<BR/><BR/>
+    Concurrency SG: Create an issue. Hans will look into it.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="2"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17 through 30
+</section>
+<para>
+</para>
+<description>
+        DE-2 Marking a constructor with "explicit" has semantics
+        even for a constructor with zero or several parameters:
+        Such a constructor cannot be used with list-initialization
+        in a copy-initialization context, see 13.3.1.7. The
+        standard library apparently has not been reviewed for
+        marking non-single-parameter constructors as "explicit".
+</description>
+<suggestion>
+        Consider marking zero-parameter and multi-parameter
+        constructors "explicit" in classes that have at least one
+        constructor marked "explicit" and that do not have an
+        initializer-list constructor.
+</suggestion>
+<notes>Robert Klarer to address this one</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="21"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+        17
+        Library
+        21.2, 21.4,
+        27.2, 27.6,
+27.7,
+27.8.1,
+28.4
+</section>
+<para>
+</para>
+<description>
+        Support of char16_t/char32_t is insufficient. The basic_xxx
+        classes of &lt;iostream&gt;, &lt;fstream&gt;,
+        &lt;regex&gt;, etc. does not have typedefs for
+        char16_t/char32_t.
+        <BR/><BR/>
+        Functions such as stoi, to_string in &#8216;21.4 Numeric
+        Conversion&#8217; does not support char16_t/char32_t types.
+</description>
+<suggestion>
+        Add commented
+        lines corresponding to char16_t, char32_t.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        21.2 paragraph1
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        // 21.4: numeric conversions
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        int stoi(const u16string&amp; str, size_t *idx = 0,
+        int base = 10);
+        <BR/><BR/>
+        long stol(const u16string&amp; str, size_t *idx = 0,
+        int base = 10);
+        <BR/><BR/>
+        unsigned long stoul(const u16string&amp; str, size_t
+        *idx = 0, int base = 10);
+        <BR/><BR/>
+        long long stoll(const u16string&amp; str, size_t *idx
+        = 0, int base = 10);
+        <BR/><BR/>
+        unsigned long long stoull(const u16string&amp; str,
+        size_t *idx = 0, int base = 10);
+        <BR/><BR/>
+        float stof(const u16string&amp; str, size_t *idx =
+        0);
+        <BR/><BR/>
+        double stod(const u16string&amp; str, size_t *idx =
+        0);
+        <BR/><BR/>
+        long double stold(const u16string&amp; str, size_t
+        *idx = 0);
+        <BR/><BR/>
+        u16string to_u16string(long long val);
+        <BR/><BR/>
+        u16string to_u16string(unsigned long long val);
+        <BR/><BR/>
+        u16string to_u16string(long double val);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+         int stoi(const u32string&amp; str, size_t *idx = 0,
+        int base = 10);
+        <BR/><BR/>
+        long stol(const u32string&amp; str, size_t *idx = 0,
+        int base = 10);
+        <BR/><BR/>
+        unsigned long stoul(const u32string&amp; str, size_t
+        *idx = 0, int base = 10);
+        <BR/><BR/>
+        long long stoll(const u32string&amp; str, size_t *idx
+        = 0, int base = 10);
+        <BR/><BR/>
+        unsigned long long stoull(const u32string&amp; str,
+        size_t *idx = 0, int base = 10);
+        <BR/><BR/>
+        float stof(const u32string&amp; str, size_t *idx =
+        0);
+        <BR/><BR/>
+        double stod(const u32string&amp; str, size_t *idx =
+        0);
+        <BR/><BR/>
+        long double stold(const u32string&amp; str, size_t
+        *idx = 0);
+        <BR/><BR/>
+        u32string to_u32string(long long val);
+        <BR/><BR/>
+        u32string to_u32string(unsigned long long val);
+        <BR/><BR/>
+        u32string to_u32string(long double val);
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        27.2
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        typedef basic_ios&lt;char&gt; ios;
+        <BR/><BR/>
+        typedef basic_ios&lt;wchar_t&gt; wios;
+        <BR/><BR/>
+        typedef basic_ios&lt;char16_t&gt; u16ios;
+        <BR/><BR/>
+        typedef basic_ios&lt;char32_t&gt; u32ios;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        typedef basic_ifstream&lt;wchar_t&gt; wifstream;
+        <BR/><BR/>
+        typedef basic_ofstream&lt;wchar_t&gt; wofstream;
+        <BR/><BR/>
+        typedef basic_fstream&lt;wchar_t&gt; wfstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_streambuf&lt;char16_t&gt; u16streambuf;
+        <BR/><BR/>
+        typedef basic_istream&lt;char16_t&gt; u16istream;
+        <BR/><BR/>
+        typedef basic_ostream&lt;char16_t&gt; u16ostream;
+        <BR/><BR/>
+        typedef basic_iostream&lt;char16_t&gt; u16iostream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_stringbuf&lt;char16_t&gt; u16stringbuf;
+        <BR/><BR/>
+        typedef basic_istringstream&lt;char16_t&gt;
+        u16istringstream;
+        <BR/><BR/>
+        typedef basic_ostringstream&lt;char16_t&gt;
+        u16ostringstream;
+        <BR/><BR/>
+        typedef basic_stringstream&lt;char16_t&gt;
+        u16stringstream;
+        <BR/><BR/>
+        typedef basic_filebuf&lt;char16_t&gt; u16filebuf;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_ifstream&lt;char16_t&gt; u16ifstream;
+        <BR/><BR/>
+        typedef basic_ofstream&lt;char16_t&gt; u16ofstream;
+        <BR/><BR/>
+        typedef basic_fstream&lt;char16_t&gt; u16fstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_streambuf&lt;char32_t&gt; u32streambuf;
+        <BR/><BR/>
+        typedef basic_istream&lt;char32_t&gt; u32istream;
+        <BR/><BR/>
+        typedef basic_ostream&lt;char32_t&gt; u32ostream;
+        <BR/><BR/>
+        typedef basic_iostream&lt;char32_t&gt; u32iostream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_stringbuf&lt;char32_t&gt; u32stringbuf;
+        <BR/><BR/>
+        typedef basic_istringstream&lt;char32_t&gt;
+        u32istringstream;
+        <BR/><BR/>
+        typedef basic_ostringstream&lt;char32_t&gt;
+        u32ostringstream;
+        <BR/><BR/>
+        typedef basic_stringstream&lt;char32_t&gt;
+        u32stringstream;
+        <BR/><BR/>
+        typedef basic_filebuf&lt;char32_t&gt; u32filebuf;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_ifstream&lt;char32_t&gt; u32ifstream;
+        <BR/><BR/>
+        typedef basic_ofstream&lt;char32_t&gt; u32ofstream;
+        <BR/><BR/>
+        <u>typedef basic_fstream&lt;char32_t&gt;
+        u32fstream;</u>
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        template &lt;class state&gt; class fpos;
+        <BR/><BR/>
+        typedef
+        fpos&lt;char_traits&lt;char&gt;::state_type&gt; streampos;
+        <BR/><BR/>
+        typedef
+        fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;
+        wstreampos;
+        <BR/><BR/>
+        typedef
+        fpos&lt;char_traits&lt;char16_t&gt;::state_type&gt;
+        u16streampos;
+        <BR/><BR/>
+        typedef
+        fpos&lt;char_traits&lt;char32_t&gt;::state_type&gt;
+        u32streampos;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        27.6
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_istream;
+        <BR/><BR/>
+        typedef basic_istream&lt;char&gt; istream;
+        <BR/><BR/>
+        typedef basic_istream&lt;wchar_t&gt; wistream;
+        <BR/><BR/>
+        <u>typedef basic_istream&lt;char16_t&gt;
+        u16istream;</u>
+        <BR/><BR/>
+        typedef basic_istream&lt;char32_t&gt; u32istream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_iostream;
+        <BR/><BR/>
+        typedef basic_iostream&lt;char&gt; iostream;
+        <BR/><BR/>
+        typedef basic_iostream&lt;wchar_t&gt; wiostream;
+        <BR/><BR/>
+        <u>typedef basic_iostream&lt;char16_t&gt;
+        u16iostream;</u>
+        <BR/><BR/>
+        typedef basic_iostream&lt;char32_t&gt; u32iostream;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_ostream;
+        <BR/><BR/>
+        typedef basic_ostream&lt;char&gt; ostream;
+        <BR/><BR/>
+        typedef basic_ostream&lt;wchar_t&gt; wostream;
+        <BR/><BR/>
+        <u>typedef basic_ostream&lt;char16_t&gt;
+        u16ostream;</u>
+        <BR/><BR/>
+        typedef basic_ostream&lt;char32_t&gt; u32ostream;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        27.7 paragraph 1
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+         class Allocator =
+        allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_stringbuf;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_stringbuf&lt;char&gt; stringbuf;
+        <BR/><BR/>
+        typedef basic_stringbuf&lt;wchar_t&gt; wstringbuf;
+        <BR/><BR/>
+        <u>typedef basic_stringbuf&lt;char16_t&gt;
+        u16stringbuf;</u>
+        <BR/><BR/>
+        typedef basic_stringbuf&lt;char32_t&gt; u32stringbuf;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+         class Allocator =
+        allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_istringstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_istringstream&lt;char&gt;
+        istringstream;
+        <BR/><BR/>
+        typedef basic_istringstream&lt;wchar_t&gt;
+        wistringstream;
+        <BR/><BR/>
+        <u>typedef basic_istringstream&lt;char16_t&gt;
+        u16istringstream;</u>
+        <BR/><BR/>
+        typedef basic_istringstream&lt;char32_t&gt;
+        u32istringstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+         class Allocator =
+        allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_ostringstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_ostringstream&lt;char&gt;
+        ostringstream;
+        <BR/><BR/>
+        typedef basic_ostringstream&lt;wchar_t&gt;
+        wostringstream;
+        <BR/><BR/>
+        <u>typedef basic_ostringstream&lt;char16_t&gt;
+        u16ostringstream;</u>
+        <BR/><BR/>
+        typedef basic_ostringstream&lt;char32_t&gt;
+        u32ostringstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+         class Allocator =
+        allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_stringstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        typedef basic_stringstream&lt;char&gt; stringstream;
+        <BR/><BR/>
+        typedef basic_stringstream&lt;wchar_t&gt;
+        wstringstream;
+        <BR/><BR/>
+        typedef basic_stringstream&lt;char16_t&gt;
+        u16stringstream;
+        <BR/><BR/>
+        typedef basic_stringstream&lt;char32_t&gt;
+        u32stringstream;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        27.8.1 paragraph 1
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_filebuf;
+        <BR/><BR/>
+        typedef basic_filebuf&lt;char&gt; filebuf;
+        <BR/><BR/>
+        typedef basic_filebuf&lt;wchar_t&gt; wfilebuf;
+        <BR/><BR/>
+        <u>typedef basic_filebuf&lt;char16_t&gt;
+        u16filebuf;</u>
+        <BR/><BR/>
+        typedef basic_filebuf&lt;char32_t&gt; u32filebuf;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_ifstream;
+        <BR/><BR/>
+        typedef basic_ifstream&lt;char&gt; ifstream;
+        <BR/><BR/>
+        typedef basic_ifstream&lt;wchar_t&gt; wifstream;
+        <BR/><BR/>
+        <u>typedef basic_ifstream&lt;char16_t&gt;
+        u16ifstream;</u>
+        <BR/><BR/>
+        typedef basic_ifstream&lt;char32_t&gt; u32ifstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_ofstream;
+        <BR/><BR/>
+        typedef basic_ofstream&lt;char&gt; ofstream;
+        <BR/><BR/>
+        typedef basic_ofstream&lt;wchar_t&gt; wofstream;
+        <BR/><BR/>
+        <u>typedef basic_ofstream&lt;char16_t&gt;
+        u16ofstream;</u>
+        <BR/><BR/>
+        typedef basic_ofstream&lt;char32_t&gt; u32ofstream;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_fstream;
+        <BR/><BR/>
+        typedef basic_fstream&lt;char&gt; fstream;
+        <BR/><BR/>
+        typedef basic_fstream&lt;wchar_t&gt; wfstream;
+        <BR/><BR/>
+        <u>typedef basic_fstream&lt;char16_t&gt;
+        u16fstream;</u>
+        <BR/><BR/>
+        typedef basic_fstream&lt;char32_t&gt; u32fstream;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        28.4
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        typedef basic_regex&lt;char&gt; regex;
+        <BR/><BR/>
+        typedef basic_regex&lt;wchar_t&gt; wregex;
+        <BR/><BR/>
+        typedef basic_regex&lt;char16_t&gt; u16regex;
+        <BR/><BR/>
+        typedef basic_regex&lt;char32_t&gt; u32regex;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        typedef sub_match&lt;const char*&gt; csub_match;
+        <BR/><BR/>
+        typedef sub_match&lt;const wchar_t*&gt; wcsub_match;
+        <BR/><BR/>
+        typedef sub_match&lt;const char16_t*&gt;
+        u16csub_match;
+        <BR/><BR/>
+        typedef sub_match&lt;const char32_t*&gt;
+        u16csub_match;
+        <BR/><BR/>
+        typedef sub_match&lt;string::const_iterator&gt;
+        ssub_match;
+        <BR/><BR/>
+        typedef sub_match&lt;wstring::const_iterator&gt;
+        wssub_match;
+        <BR/><BR/>
+        typedef sub_match&lt;u16string::const_iterator&gt;
+        u16ssub_match;
+        <BR/><BR/>
+        typedef sub_match&lt;u32string::const_iterator&gt;
+        u32ssub_match;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        typedef match_results&lt;const char*&gt; cmatch;
+        <BR/><BR/>
+        typedef match_results&lt;const wchar_t*&gt; wcmatch;
+        <BR/><BR/>
+        typedef match_results&lt;const char16_t*&gt;
+        u16cmatch;
+        <BR/><BR/>
+        typedef match_results&lt;const char32_t*&gt;
+        u32cmatch;
+        <BR/><BR/>
+        typedef match_results&lt;string::const_iterator&gt;
+        smatch;
+        <BR/><BR/>
+        typedef match_results&lt;wstring::const_iterator&gt;
+        wsmatch;
+        <BR/><BR/>
+        typedef
+        match_results&lt;u16string::const_iterator&gt; u16smatch;
+        <BR/><BR/>
+        typedef
+        match_results&lt;u32string::const_iterator&gt; u32smatch;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        typedef regex_iterator&lt;const char*&gt;
+        cregex_iterator;
+        <BR/><BR/>
+        typedef regex_iterator&lt;const wchar_t*&gt;
+        wcregex_iterator;
+        <BR/><BR/>
+        typedef regex_iterator&lt;const cha16r_t*&gt;
+        u16cregex_iterator;
+        <BR/><BR/>
+        typedef regex_iterator&lt;const char32_t*&gt;
+        u32cregex_iterator;
+        <BR/><BR/>
+        typedef regex_iterator&lt;string::const_iterator&gt;
+        sregex_iterator;
+        <BR/><BR/>
+        typedef regex_iterator&lt;wstring::const_iterator&gt;
+        wsregex_iterator;
+        <BR/><BR/>
+        typedef
+        regex_iterator&lt;u16string::const_iterator&gt;
+        u16sregex_iterator;
+        <BR/><BR/>
+        typedef
+        regex_iterator&lt;u32string::const_iterator&gt;
+        u32sregex_iterator;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        ...
+        <BR/><BR/>
+        typedef regex_token_iterator&lt;const char*&gt;
+        cregex_token_iterator;
+        <BR/><BR/>
+        typedef regex_token_iterator&lt;const wchar_t*&gt;
+        wcregex_token_iterator;
+        <BR/><BR/>
+        typedef regex_token_iterator&lt;const char16_t*&gt;
+        u16cregex_token_iterator;
+        <BR/><BR/>
+        typedef regex_token_iterator&lt;const char32_t*&gt;
+        u32cregex_token_iterator;
+        <BR/><BR/>
+        typedef
+        regex_token_iterator&lt;string::const_iterator&gt;
+        sregex_token_iterator;
+        <BR/><BR/>
+        typedef
+        regex_token_iterator&lt;wstring::const_iterator&gt;<span lang="zxx">
+        &#12288;&#12288;&#12288;</span>wsregex_token_iterator;
+        <BR/><BR/>
+        typedef
+        regex_token_iterator&lt;u16string::const_iterator&gt;
+        u16sregex_token_iterator;
+        <BR/><BR/>
+        typedef
+        regex_token_iterator&lt;u32string::const_iterator&gt;<span lang="zxx">
+        &#12288;</span>u32sregex_token_iterator;
+        <BR/><BR/>}
+</suggestion>
+<notes>
+Previously considered; we decided not to do it. We believe it is
+not too onerous to use <TT>wbuffer_convert</TT> and
+<TT>wstring_convert</TT> which were added as intermediaries to
+avoid proliferation of types.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="144"
+  uknum="72"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.1
+</section>
+<para>
+2
+</para>
+<description>
+        List of contents of library should be
+        extened to cover new clauses
+</description>
+<suggestion>
+        Add "regular expressions, atomic operations
+        and threads"
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="145"
+  uknum="73"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.1
+</section>
+<para>
+6
+</para>
+<description>
+        <span lang="en-US">Summary of numeric facilities should
+        mention random numbers</span>
+</description>
+<suggestion>
+        Add random number framework to the list of
+        library facilities
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="146"
+  uknum="74"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.1
+</section>
+<para>
+</para>
+<description>
+        Add a summary paragraph for regular
+        expressions
+</description>
+<suggestion>
+        Add a summary paragraph for regular
+        expressions
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="147"
+  uknum="75"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.1
+</section>
+<para>
+</para>
+<description>
+        Add a summary paragraph for threads
+</description>
+<suggestion>
+        Add a summary paragraph for threads
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="148"
+  uknum="247"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.2
+</section>
+<para>
+Table 12
+</para>
+<description>
+        Table 12 is
+        mentioned in and relates to section 17.2, but has been
+        pushed down to appear directly after the title of section
+        17.3 which is rather unfortunate/confusing for the reader.
+</description>
+<suggestion>
+        Make sure tables are rendered in the
+        section to which they relate.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="149"
+  uknum="84"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.3
+</section>
+<para>
+</para>
+<description>
+        For consistency
+        with narrow-oriented and wide-oriented streams, we should
+        add terms for streams of Unicode character sequences
+</description>
+<suggestion>
+        Define Utf16-oriented stream classes and
+        Uft32-oriented stream classes for streams of
+        char16_t/char32_t values.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="150"
+  uknum="199"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.3
+</section>
+<para>
+</para>
+<description>
+        The addition of move semantics to the
+        language means that many library APIs leave an object in a
+        safely-destructible state, where no other operations can
+        safely be performed unless it is assigned a new value.
+        Library presentation would be simplified and made more
+        precise if we introduce a term for this state. By analogy
+        with singular iterators suggest the term 'singular object'
+        or 'the object is in a singular state'.
+</description>
+<suggestion>
+        Define 'singular
+        state' such that an object with a singular state can only
+        be assigned to or safely destroyed. Assiging a new value
+        typically removes the singular state. Note that objects
+        with a singular state may not be safely copied, so you
+        cannot put an object into a singular state by copying
+        another object in a singular state. Use this new term in
+        the postcondition of all library APIs that move from an
+        rvalue reference. It might also be used to simplify the
+        definition of singular iterator to an iterator value with a
+        singular state.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="151"
+  uknum="77"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.3.1
+</section>
+<para>
+</para>
+<description>
+        Missing
+        crossreference to 17.3.17 [defns.repositional.stream]
+</description>
+<suggestion>
+        Add cross-reference in the existing empty
+        brackets
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="152"
+  uknum="80"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.3.12
+</section>
+<para>
+</para>
+<description>
+        Object state is
+        using a definition of object (instance of a class) from
+        outside the standard, rather than the 'region of storage'
+        definiton in 1.8p1
+</description>
+<suggestion>
+        Clarify terms and usage
+</suggestion>
+<notes>we think we're removing this; Howard to create LWG issue.
+Howard, see [func.referenceclosure.cons]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="153"
+  uknum="82"
+  type="Te"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.3.17
+</section>
+<para>
+</para>
+<description>
+        If a
+        repositional stream can only seek to a position previously
+        encountered, then an arbitrary-positional-stream cannot
+        satisfy this definition, as cross-referenced in 17.3.17
+</description>
+<suggestion>
+        Strike the word 'only'. A note might be
+        added to reinforce the intent
+</suggestion>
+<notes>editorial; sent to Pete Becker</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="154"
+  uknum="83"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.3.20
+</section>
+<para>
+</para>
+<description>
+        Missing definition of a stable partition
+        algorithm
+</description>
+<suggestion>
+        Add definition from 25.2.12p7
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="155"
+  uknum="78"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.3.3
+</section>
+<para>
+</para>
+<description>
+        Add clause 28 to list that use this
+        definition of character
+</description>
+<suggestion>
+        Add clause 28 to list that use this
+        definition of character
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="156"
+  uknum="79"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.3.4
+</section>
+<para>
+</para>
+<description>
+        Add regular
+        expressions to set of templates using character container
+        type
+</description>
+<suggestion>
+        Add regular expressions to set of templates
+        using character container type
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="157"
+  uknum="86"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.2.2
+</section>
+<para>
+3
+</para>
+<description>
+        Add concepts to
+        the ordered list of presentation
+</description>
+<suggestion>
+        Add concepts into the sequence
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="158"
+  uknum="87"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.2.2
+</section>
+<para>
+3
+</para>
+<description>
+        templates are neither classes nor functions
+</description>
+<suggestion>
+        Replace
+        'classes' and 'functions' with 'classes and class
+        templates' and 'functions and function templates'
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="159"
+  uknum="88"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.2.4
+</section>
+<para>
+Footnote 152
+</para>
+<description>
+        This informative
+        footnote was relevant in 1998, not 2008. The term 'existing
+        vendors' may imply something different now
+</description>
+<suggestion>
+        Strike the footnote, or replace 'existing'
+        with 'original' or similar
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="160"
+  uknum="89"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.2.4
+</section>
+<para>
+3
+</para>
+<description>
+        requires is now
+        a keyword with a specific meaning related to concepts, and
+        its use in library specifcation may be confusing. Generally
+        the Requires clause is used to make requirements on the
+        caller, not the library, so typically providing runtime
+        pre-conditions. Suggest a new name to refflect that. Note
+        that Clause 30 already seems to be written to this
+        convention.
+</description>
+<suggestion>
+        Replace 'Requires' with 'Preconditions'
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="161"
+  uknum="90"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.2.4
+</section>
+<para>
+4
+</para>
+<description>
+        This paragraph
+        is redundant as the definition of the term 'handler
+        function' is already provided in 17.3. Are we in danger of
+        proving two definitions of the same terms? Which is the
+        'controlling' definition?
+</description>
+<suggestion>
+        Strike 17.5.2.4p4
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="162"
+  uknum="170"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.2.4
+</section>
+<para>
+3
+</para>
+<description>
+        Clause 30 makes
+        use of a 'Synchronization' semantic element, that
+        frequently appears either between Effects: and
+        Postconditions:, or between Returns: and Throws:
+</description>
+<suggestion>
+        Add 'Synchronization' to the list either
+        between Effects: and Postconditions:, or between Returns:
+        and Throws:.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="163"
+  uknum="219"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.2.4
+</section>
+<para>
+3
+</para>
+<description>
+        Many functions
+        are defined as "Effects: Equivalent to a...", which seems
+        to also define the preconditions, effects, etc. But this is
+        not made clear.
+</description>
+<suggestion>
+        Introduce an explicit "Equivalent to",
+        which defines all of the properties of the function.
+</suggestion>
+<notes>
+Tom Plum to open LWG issue; we believe this is related to 
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">
+LWG625</a>
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="164"
+  uknum="91"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.3.2.1
+</section>
+<para>
+1
+</para>
+<description>
+        This phrasing predates concepts. While this
+        kind of description is still used, the examples provided
+        are now all concepts, and should be replaced with
+        appropriate examples
+</description>
+<suggestion>
+        Use better names
+        for the examples. Ideally totally replace the need by
+        constraining all templates in library, so that real
+        concepts are all that is needed. Note if retained that
+        CopyConstructible is mis-spelled.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="165"
+  uknum="92"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.3.2.2,
+17.5.3.2.3
+</section>
+<para>
+</para>
+<description>
+        constraints on
+        bitmask and enumation types were supposed to be tightened
+        up as part of the motivation for the constexpr feature -
+        see paper n2235 for deails
+</description>
+<suggestion>
+        Adopt wording in line with the motivation
+        described in N2235
+</suggestion>
+<notes>Robert Klarer to review</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="166"
+  uknum="93"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.3.2.4.1,
+17.5.3.3
+</section>
+<para>
+</para>
+<description>
+        List of library clauses should go up to 30,
+        not 27
+</description>
+<suggestion>
+        Replace initial refernce to ch27 with ch30
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="167"
+  uknum="246"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.5.3.4
+Private
+members
+</section>
+<para>
+</para>
+<description>
+        Comment marker in wrong place.
+</description>
+<suggestion>
+        Change: //
+        streambuf* sb; exposition only to streambuf* sb; //
+        exposition only To reflect actual usage.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="168"
+  uknum="406"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.2.2
+</section>
+<para>
+2
+</para>
+<description>
+        We should make
+        it clear (either by note or normatively) that namespace std
+        may contain inline namespaces, and that entities specified
+        to be defined in std may in fact be defined in one of these
+        inline namespaces. (If we're going to use them for
+        versioning, eg when TR2 comes along, we're going to need
+        that.)
+</description>
+<suggestion>
+        Replace "namespace std or namespaces nested
+        within namespace std" with "namespace std or namespaces
+        nested within namespace std or inline namespaces nested
+        directly or indirectly within namespace std"
+</suggestion>
+<notes>Howard will create issue to adopt UK words (some have reservations whether 
+    it is correct)</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="169"
+  uknum="95"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.2.2
+</section>
+<para>
+</para>
+<description>
+        This phrasing
+        contradicts later freedom to implement the C standard
+        library portions in the global namespace as well as std.
+        (17.6.2.3p4)
+</description>
+<suggestion>
+        Resolve conflict in either place
+</suggestion>
+<notes>Bill Plauger to open issue. If the wording is too broad we need to add an 
+    exception to the standard C library.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="170"
+  uknum="96"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.2.3
+</section>
+<para>
+</para>
+<description>
+        One of goals of
+        C++0x is to make language easier to teach and for
+        'incidental' programmers. The fine-grained headers of the
+        C++ library are valuable in large scale systems for
+        managing dependencies and optimising build times, but
+        overcomplicated for simple development and tutorials. Add
+        additional headers to support the whole library through a
+        single include statement.
+</description>
+<suggestion>
+        Add a new header &lt;std&gt; that has the
+        effect of including everything in tables 13 and 14, except
+        &lt;iosfwd&gt; and &lt;cassert&gt;. Add an additional
+        header &lt;fwd&gt; that adds all declarations from
+        &lt;std&gt; but no definitions.
+</suggestion>
+<notes>Alisdair to open issue. We prefer &lt;std&gt; only.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="171"
+  uknum="98"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.2.4
+</section>
+<para>
+3
+</para>
+<description>
+        Does
+        freestanding implementation require a full implementation
+        of all listed headers? The reference to abort, at_exit and
+        exit is confusing. Is a conforming implementation allow to
+        deliver partial forms of these headers? If so which ones?
+        Are empty versions of everything but &lt;cstdlib&gt;
+        conforming?
+</description>
+<suggestion>
+        Either strike the references to abort,
+        at_exit and exit, or clarify which headers only require
+        partial support.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="172"
+  uknum="99"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+17.6.2.4
+</section>
+<para>
+3
+</para>
+<description>
+        No reference to
+        new functions quick_exit and at_quick_exit
+</description>
+<suggestion>
+        Add reference to quick_exit and
+        at_quick_exit
+</suggestion>
+<notes>NAD. We do not belive at_exit and at_quick_exit should be required by 
+    freestanding implementations.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="173"
+  uknum="450"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.2.4
+</section>
+<para>
+table 15
+</para>
+<description>
+        &lt;initializer_list&gt; is missing from headers required
+        in freestanding implementations.
+</description>
+<suggestion>
+        Add 18.8, initializer lists,
+        &lt;initializer_list&gt;, to the end of the table.
+</suggestion>
+<notes>
+LWG is interested in 
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">
+N2814</a>, but we're concerned whether CWG will accept 
+language recommendations.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="23"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.2.4
+</section>
+<para>
+2<sup>nd</sup> <font size="2"
+        style="font-size: 11pt">para, Table 15</font>
+</para>
+<description>
+        There is a
+        freestanding implementation including &lt;type_traits&gt;,
+        &lt;array&gt;, &lt;ratio&gt;, lately added to Table 13, C++
+        library headers.
+        Programmers think them useful and hope that these headers
+        are also added to Table 15, C++ headers for freestanding
+        implementations, that shows the set of headers which a
+        freestanding implementation shall include at least.
+</description>
+<suggestion>
+        Add
+        &lt;type_traits&gt;, &lt;array&gt;, &lt;ration&gt; to Table
+        15.
+</suggestion>
+<notes>
+LWG is interested in 
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">
+N2814</a>, but we're concerned whether CWG will accept 
+language recommendations.<BR/><BR/>
+add &lt;type_traits&gt; only. Alisdair will draft an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="174"
+  uknum="100"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.3.2
+</section>
+<para>
+3
+</para>
+<description>
+        The phrasing is
+        mildly ambiguous when using the word 'it' to refer back to
+        the header - an unfotunate reading might confuse it with
+        the translate unit, which is the subject of the surrounding
+        clause.
+</description>
+<suggestion>
+        Replace 'the first reference to any of the
+        entities declared in that header by the translation unit'
+        with 'the first reference to any of the entities that
+        header declares in the translation unit'
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="175"
+  uknum="101"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+17.6.4.2.1
+</section>
+<para>
+2
+</para>
+<description>
+        Local types can
+        now be used to instantiate templates, but don't have
+        external linkage
+</description>
+<suggestion>
+        Remove the reference to external linkage
+</suggestion>
+<notes>we accept the proposed solution. Martin will draft an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="176"
+  uknum="102"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.4.3.3
+</section>
+<para>
+Footnote 175
+</para>
+<description>
+        Reference to namespace ::std should be
+        17.6.4.2
+</description>
+<suggestion>
+        Change referfence from 17.6.4.3 to 17.6.4.2
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="177"
+  uknum="103"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.4.3.4
+</section>
+<para>
+3
+</para>
+<description>
+        Sentence is
+        redundant as double underscores are reserved in all
+        contexts by 17.6.4.3.3
+</description>
+<suggestion>
+        Strike the sentence
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="178"
+  uknum="104"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.4.8
+</section>
+<para>
+2
+</para>
+<description>
+        The last sentence of the third bullet
+        "Operations on such types can report a failure by throwing
+        an exception unless otherwise specified" is redundant as
+        behaviour is already undefined.
+</description>
+<suggestion>
+        Strike the sentence
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="179"
+  uknum="105"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+17.6.4.8
+</section>
+<para>
+2
+</para>
+<description>
+        According to the
+        4th bullet there is a problem if "if any replacement
+        function or handler function or destructor operation throws
+        an exception". There should be no problem throwing
+        exceptions so long as they are caught within the function.
+</description>
+<suggestion>
+        Replace the word 'throws' with 'propogates'
+</suggestion>
+<notes>Agreed. Alisdair will draft an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="22"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.5.7
+</section>
+<para>
+4<sup>th</sup> <font size="2"
+        style="font-size: 11pt">para, 1<sup>st</sup>
+        line</font>
+</para>
+<description>
+        The
+        statement below describes relation among two or more
+        threads using words &#8220;between threads&#8221;:
+        [Note: This means, for example, that implementations
+        can&#8217;t use a static object for internal purposes
+        without synchronization because it could cause a data race
+        even in programs that do not explicitly share objects
+        between threads. &#8212;end note ]
+        <BR/><BR/>In
+        such case, &#8220;among&#8221; is preferred instead of
+        &#8220;between&#8221;.
+</description>
+<suggestion>
+        Change "between threads" to "among threads".
+        <BR/><BR/>
+        There are same cases in 17.6.1 paragraph 2, 17.6.5.7
+        paragraph 6, 30.1 paragraph 1, 30.3.1 paragraph 1 also.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="180"
+  uknum="107"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+17.6.5.10
+</section>
+<para>
+1, 4
+</para>
+<description>
+        It should not be
+        possible to strengthen the exception specification for
+        virtual functions as this could break user code. Note this
+        is not a problem in practice as there are no virtual
+        functions with exception specifications in the current
+        library, other than empty throw specifications which it is
+        not possible to strengthen.
+</description>
+<suggestion>
+        Add restriction that exception
+        specification of virtual functions cannot be tightened.
+</suggestion>
+<notes>NAD, the standard already has the desired restriction.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="181"
+  uknum="108"
+  type="Te"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+17.6.5.10
+</section>
+<para>
+Footnote 186
+</para>
+<description>
+        This footnote is
+        wrong. C library functions do not have any exception
+        specification, but might be treated as if they had an empty
+        throw specification
+</description>
+<suggestion>
+        Clarify that this note does not mean the
+        functions are genuinely declared with the specification,
+        but are treated as-if.
+</suggestion>
+<notes>We agree that the footnote is wrong and it will be removed. Pete will handle 
+    as editorial.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="182"
+  uknum="109"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+17.6.5.10
+</section>
+<para>
+Footnote 188
+</para>
+<description>
+        It is very
+        helpful to assume all exceptions thrown by the standard
+        library derive from std::exception. The 'encouragement' of
+        this note should be made normative.
+</description>
+<suggestion>
+        Make this footnote normative
+</suggestion>
+<notes>NAD. We cannot mandate all standard-library functions that might use some 
+    third-party library.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="184"
+  uknum="144"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18 -&gt; 30
+</section>
+<para>
+</para>
+<description>
+        The new
+        alias-declaration syntax is generally easier to read than a
+        typedef declaration. This is especially true for complex
+        types like function pointers.
+</description>
+<suggestion>
+        Replace all typedef declarations in the
+        standard library with alias-declarations, except in the
+        standard C library.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="24"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18
+</section>
+<para>
+2<sup>nd</sup> <font size="2"
+        style="font-size: 11pt">para, Table 16</font>
+</para>
+<description>
+        Subclauses are listed in Table 16 as:
+        <BR/><BR/>"18.6 Type
+        identification &#8230;"
+        <BR/><BR/>"18.8 Initializer
+        lists &#8230;"
+        <BR/><BR/>"18.7 Exception
+        handling &#8230;".
+</description>
+<suggestion>
+        Sort them in the increasing order
+        "18.6 Type identification &#8230;"
+        <BR/><BR/>"18.7 Exception
+        handling &#8230;".
+        <BR/><BR/>
+        "18.8 Initializer lists &#8230;"
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="25"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.1
+</section>
+<para>
+        6<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">para , last line, SEE ALSO</font>
+</para>
+<description>
+        max_align_t is described in 18.1, so add 3.11 Alignment as
+        the reference.
+</description>
+<suggestion>
+        Add
+        "<u>3.11, Alignment</u><font color="#000000">" to</font>
+        <font size="2" style="font-size: 11pt">SEE ALSO.</font>
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="32"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.2.1
+[Numeric
+limits]
+</section>
+<para>
+</para>
+<description>
+        The definition of
+        numeric_limits&lt;&gt; as requiring a regular type is both
+        conceptually wrong and operationally illogical. As we
+        pointed before, this mistake needs to be corrected. For
+        example, the template can be left unconstrained. In fact
+        this reflects a much more general problem with
+        concept_maps/axioms and their interpretations. It appears
+        that the current text heavily leans toward experimental
+        academic type theory.
+</description>
+<suggestion>
+        We suggest that a more pragmatic approach, in the spirit
+        of C and C++, be taken so that calls to constrained
+        function templates are interpreted as assertions on
+        *values*, not necessarily semantics assertions on the
+        carrier type.
+</suggestion>
+<notes>Alisdair and Gaby will work on a resolution.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="16"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.2.1
+</section>
+<para>
+</para>
+<description>
+        DE-16 The class
+        template numeric_limits should not specify the Regular
+        concept requirement for its template parameter, because it
+        contains functions returning NaN values for floating-point
+        types; these values violate the semantics of
+        EqualityComparable. See also library issue 902 in WG21
+        document N2794 "C++ Standard Library Active Issues List
+        (Revision R60)", available at
+        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html
+        .
+</description>
+<suggestion>
+        Specify a concept requirement with fewer constraints as
+        appropriate, for example SemiRegular.
+</suggestion>
+<notes>Alisdair and Gaby will work on a resolution.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="26"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.2.1.1
+</section>
+<para>
+</para>
+<description>
+        numeric_limits does not use concept.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class T&gt; class numeric_limits&lt;const
+        T&gt;;
+        <BR/><BR/>
+        template&lt;class T&gt; class numeric_limits&lt;volatile
+        T&gt;;
+        <BR/><BR/>
+        template&lt;class T&gt; class numeric_limits&lt;const
+        volatile T&gt;;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;<u>Regular</u> T&gt; class
+        numeric_limits&lt;const T&gt;;
+        <BR/><BR/>
+        template&lt;<u>Regular</u> T&gt; class
+        numeric_limits&lt;volatile T&gt;;
+        <BR/><BR/>
+        template&lt;<u>Regular</u> T&gt; class
+        numeric_limits&lt;const volatile T&gt;;
+</suggestion>
+<notes>Alisdair will work on a resolution.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="17"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.2.6
+</section>
+<para>
+</para>
+<description>
+        DE-17 The class
+        type_index should be removed; it provides no additional
+        functionality beyond providing appropriate concept maps.
+</description>
+<suggestion>
+        Specify concept maps for "const type_info *" as required
+        by the ordered and unordered containers and remove the
+        class type_index.
+</suggestion>
+<notes>Doug will open an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="185"
+  uknum="264"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.3.1
+</section>
+<para>
+2
+</para>
+<description>
+        There is no
+        header &lt;stdint&gt;, it should either be &lt;stdint.h&gt;
+        or &lt;cstdint&gt;
+</description>
+<suggestion>
+        Replace &lt;stdint&gt; with &lt;cstdint&gt;
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="18"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.4
+</section>
+<para>
+</para>
+<description>
+        DE-18 The
+        proposed C++ standard makes a considerable number of
+        existing programs that have well-defined behavior according
+        to ISO/IEC 14882:2003 have undefined behavior without a
+        diagnostic hint to the programmer at all. This applies to
+        the presence of threads and to pointer safety (the latter
+        was introduced to support garbage collection). In order to
+        avoid requiring a full code review for user code,
+        facilities should be present that allow the compile-time
+        detection of the advanced features of the proposed C++
+        standard. It is expected that C++ implementations will
+        provide a means (for example, a command-line switch) to
+        turn off either or both of threads and garbage collection
+        support, turning potentially undefined programs into
+        well-defined ones.
+        <i>Note:</i> This issue is contributing significantly to
+        Germany's overall &#8220;no&#8221; vote.
+</description>
+<suggestion>
+        Consider applying the changes proposed in WG21 document
+        N2693 "Requirements on programs and backwards
+        compatibility", available at
+        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html
+        .
+</suggestion>
+<notes>Straw polls: pointer safety: 9-1-10; threading: 14-2-9. Jens will open 
+    multiple issues.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="186"
+  uknum="265"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.4
+</section>
+<para>
+Footnote 221
+</para>
+<description>
+        What is the
+        purpose of this comment? The standard stream objects (cin,
+        cerr etc.) have a peculiar lifetime that extends beyond the
+        program. They may never be destroyed so will not be
+        responsible for flushing buffers at the stated time.
+</description>
+<suggestion>
+        Remove the footnote
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="187"
+  uknum="266"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.4
+</section>
+<para>
+9
+</para>
+<description>
+        The term "thread
+        safe" is not defined nor used in this context anywhere else
+        in the standard.
+</description>
+<suggestion>
+        Clarify the intended meaing of "thread
+        safe"
+</suggestion>
+<notes>Lawrence Crowl will open an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="188"
+  uknum="267"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+18.4
+</section>
+<para>
+12
+</para>
+<description>
+        The function
+        _Exit does not appear to be defined in this standard.
+        Should it be added to the table of functions
+        included-by-reference to the C standard?
+</description>
+<suggestion>
+        Depends on where _Exit comes from
+</suggestion>
+<notes>Agreed. Bill Plauger will open an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="189"
+  uknum="273"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+18.4, 18.7
+</section>
+<para>
+</para>
+<description>
+        The addition of the [[noreturn]] attribute
+        to the language will be an important aid for static
+        analysis tools.
+</description>
+<suggestion>
+        The following
+        functions should be declared in C++ with the [[noreturn]]
+        attribute: abort exit quick_exit terminate unexpected
+        rethrow_exception throw_with_nested
+</suggestion>
+<notes>Agreed. Howard will open an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="27"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.4, 18.9,
+18.7.2.2,
+18.7.3.1
+</section>
+<para>
+</para>
+<description>
+        There are Standard library functions that never return to
+        the caller. They are explained so in the Standard but not
+        declared explicitly.
+</description>
+<suggestion>
+        Consider to add the attribute [[noreturn]] to such
+        functions,
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        15.5.2 unexpected
+        18.4: abort(), exit(), quick_exit,
+        18.7.2.2: unexpected_handler,
+        18.7.3.1: terminate_handler,
+        <BR/><BR/>
+        18.7.6 rethrow_nested
+        <BR/><BR/>18.7.6
+        throw_with_nested
+        18.9: longjmp.
+</suggestion>
+<notes>See UK 180</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="190"
+  uknum="268"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+18.5.1
+</section>
+<para>
+various
+</para>
+<description>
+        It is not entirely clear how the current
+        specification acts in the presence of a garbage collected
+        implementation.
+</description>
+<suggestion>
+        All deallocation
+        functions taking a pointer parameter should have a
+        Precondition : ptr is a safely-derived pointer value.
+</suggestion>
+<notes>agreed. Alisdair will open an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="191"
+  uknum="271"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.5.1.1
+</section>
+<para>
+4
+</para>
+<description>
+        According to the second bullet, behaviour
+        becomes undefined (for lack of a specification) if the user
+        has not yet called set_new_handler.
+</description>
+<suggestion>
+        Rephrase the
+        second bullet in terms of a new handler being installed,
+        and update any definition of handler function necessary to
+        be sure the term 'installed' is defined.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="192"
+  uknum="269"
+  type="Te"
+  owner="CWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.5.1.2
+</section>
+<para>
+</para>
+<description>
+        The declared
+        signature is not compatible with the current requirement to
+        throw std::length_error. It is too late to weaken the
+        exception specification, so the only other change is to
+        preserve new (improved) behaviour is to throw
+        std::bad_alloc, or something derived from std::bad_alloc.
+</description>
+<suggestion>
+        Fix 5.3.4p7 by required std::bad_alloc
+        rather than std::length_error
+</suggestion>
+<notes>Howard will open a CWG issue referring to N2814.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="193"
+  uknum="272"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.5.2.2
+</section>
+<para>
+2
+</para>
+<description>
+        quick_exit has
+        been added as a new valid way to terminate a program in a
+        well defined way
+</description>
+<suggestion>
+        Change 3rd bullet: call either abort(),
+        exit() or quick_exit();
+</suggestion>
+<notes>change &#8220;call either abort() or exit()&#8221;
+to terminate the program. Bill 
+    Plauger will open an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="194"
+  uknum="443"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.6
+</section>
+<para>
+</para>
+<description>
+        The inclusion of
+        type_index and hash&lt;type_index&gt; in &lt;typeinfo&gt;
+        brings dependencies into &lt;typeinfo&gt; which are
+        inconsistent with the definition of freestanding C++ in
+        17.6.2.4.
+</description>
+<suggestion>
+        Move type_index and hash&lt;type_index&gt;
+        out of &lt;typeinfo&gt; and into a new header,
+        &lt;typeindex&gt;.
+</suggestion>
+<notes>already handled by the free-standing paper.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="28"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+18.6,
+18.7,
+19.1
+</section>
+<para>
+</para>
+<description>
+        Errors reported by Exception classes are of types char or
+        std::string only. For example, std::exception is declared
+        with char, std::string types, therefore types
+        wchar_t/wstring, char16_t/u16string, or char32_t/u32string
+        can not be used.
+</description>
+<suggestion>
+        Consider other types.
+</suggestion>
+<notes>NAD. There is already guidance in the CD. It is the caller's responsibility 
+    to internationalize MB character string.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="29"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.7.6
+</section>
+<para>
+</para>
+<description>
+        throw_with_nested does not use concept.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        template&lt;class T&gt; void throw_with_nested(T&amp;&amp;
+        t); // [[noreturn]]
+        <BR/><BR/>
+        
+        <BR/><BR/>should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;CopyConstructible T&gt; void
+        throw_with_nested(T&amp;&amp; t); // [[noreturn]]
+</suggestion>
+<notes>Alisdair will open an issue.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="30"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.7.6
+</section>
+<para>
+</para>
+<description>
+        To
+        handle nested exceptions strictly, error information of
+        tree structure will be required though, the
+        nested_exception does not support tree structure. It is
+        insufficient as error handling.
+</description>
+<suggestion>
+        Consider nested_exception to support tree structure.
+</suggestion>
+<notes>Howard will ping Bill Plauger to request more information.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="31"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.7.6
+</section>
+<para>
+</para>
+<description>
+        It
+        is difficult to understand in which case nested_exception
+        is applied.
+</description>
+<suggestion>
+        Consider to add
+        a sample program which rethrows exception.
+</suggestion>
+<notes>Alisdair will incorporate this in the JP29 paper.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="195"
+  uknum="451"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.8
+</section>
+<para>
+</para>
+<description>
+        The class
+        definition of std::initializer_list contains concept-maps
+        to Range which should be out of the class, and in
+        &lt;iterator_concepts&gt; instead. Otherwise, it's not
+        possible to use initializer_lists in a freestanding C++
+        implementation.
+</description>
+<suggestion>
+        Delete the two concept maps from
+        std::initializer_list.
+</suggestion>
+<notes>will be handled in connection with the free-standing paper.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="196"
+  uknum="452"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+18.8.3
+</section>
+<para>
+</para>
+<description>
+        Concept maps for initializer_list to Range
+        should not be in language support headers, but instead in
+        iterator concepts.
+</description>
+<suggestion>
+        Remove section
+        18.8.3 and put it in 24.1.8.1 instead, so that the
+        concept_maps from initializer_list to Range are specified
+        under Range instead of under initializer lists; also, so
+        that they're implemented in &lt;iterator_concepts&gt;
+        instead of &lt;initializer_list&gt;.
+</suggestion>
+<notes>will be handled in connection with the free-standing paper.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="197"
+  uknum="275"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+19
+</section>
+<para>
+</para>
+<description>
+        All the exception classes in this clause
+        take a std::string argument by const reference. They should
+        all be overloaded to accept std::string by rvalue rerefence
+        for an efficient move as well.
+</description>
+<suggestion>
+        Provide a
+        constructor for every exception class in clause 19
+        accepting a std::string by rvalue reference, with the
+        semantics that the passed string may be moved.
+</suggestion>
+<notes>NAD. Implementations are permitted to add the requested signature under the 
+    as-if rule.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="32"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+19.1
+</section>
+<para>
+</para>
+<description>
+        Messages returned by the member function what() of standard
+        exception classes seem difficult to judge.
+        <BR/><BR/>For
+        example, following messages are returned by what() of
+        std::bad_alloc of existing implementations:
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        Compiler: Message returned by what()
+        <BR/><BR/>
+        ---------------------------------------------
+        <BR/><BR/>
+        Borland C++ 5.6.4: no named exception thrown
+        <BR/><BR/>
+        Visual C++ 8.0: bad allocation
+        <BR/><BR/>
+        Code Warrior 8.0: exception
+        <BR/><BR/>g++
+        3.4.4: St9exception
+        <BR/><BR/>
+        
+        <BR/><BR/>It is difficult
+        to recognize what exception was thrown when using those
+        compilers except Visual C++.
+</description>
+<suggestion>
+        Consider to add footnote that recommends what() returns
+        message easy to recognize what exception was thrown.
+</suggestion>
+<notes>NAD. Q of I.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="64"
+  uknum=""
+  type="Ge"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+19.3
+</section>
+<para>
+1
+</para>
+<description>
+        <font color="#000000">&#8220;</font> See also: ISO C
+        7.1.4, 7.2, Amendment 1 4.3.<font color="#000000">&#8221;
+        It is unclear why this cross reference is here. Amendment 1
+        was to C89, not C99.</font>
+</description>
+<suggestion>
+        Delete this
+        cross reference. If necessary, expand the main text to
+        include the relevant referenced text
+</suggestion>
+<notes>We believe that this is editorial.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="65"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20
+</section>
+<para>
+</para>
+<description>
+        Scoped allocators and
+        allocator propagation traits add a small amount of utility
+        at the cost of a great deal of machinery. The machinery is
+        user visible, and it extends to library components that
+        don't have any obvious connection to allocators, including
+        basic concepts and simple components like pair and tuple.
+</description>
+<suggestion>
+        Sketch of proposed resolution: Eliminate scoped allocators,
+        replace allocator propagation traits with a simple uniform
+        rule (e.g. always propagate on copy and move), remove all
+        mention of allocators from components that don't explicitly
+        allocate memory (e.g. pair), and adjust container
+        interfaces to reflect this simplification.
+        <BR/><BR/>
+        Components that I propose eliminating include <font size=
+        "2" style="font-size: 11pt"><font color=
+        "#0000FF"><span style=
+        "background: #ffffce">HasAllocatorType</span></font><font color="#000080">
+        <u><a href=
+        "http://wiki.corp.google.com/twiki/bin/edit/Main/HasAllocatorType?topicparent=Main.CppStandardIssues">
+        ?</a></u></font>, is_scoped_allocator,
+        allocator_propagation_map, scoped_allocator_adaptor, and
+        <font color="#0000FF"><span style=
+        "background: #ffffce">ConstructibleAsElement</span></font><font color="#000080">
+        <u><a href=
+        "http://wiki.corp.google.com/twiki/bin/edit/Main/ConstructibleAsElement?topicparent=Main.CppStandardIssues">
+        ?</a></u></font>.</font>
+</suggestion>
+<notes>
+The statement made in the comment was already aired prior to the last vote. 
+Without further input, the committee cannot remove a feature that was voted 
+into the draft. We will look at this comment in the light of N2829, which 
+attempts to make scoped allocators less intrusive.<BR/><BR/>
+Later: US 
+65, remove scoped allocators: straw poll, 4 pro - 9 con - 3 abstain, no 
+consensus for removing scoped allocators.<BR/><BR/>
+D2840: straw 
+poll, this is the direction we want to go: 11 pro - 0 con - 5 abstain, 
+we have consensus. Straw poll, put on format motions page for this 
+meeting (pro) or review and consider at next meeting (con): 7 pro - 1 
+con - many abstain, consensus for moving as formal motion at this 
+meeting.<BR/><BR/>
+D2840 was renamed
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
+N2840</a> and was accepted into the WP in Summit.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="198"
+  uknum="126"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20
+</section>
+<para>
+</para>
+<description>
+        The organization of clause 20 could be
+        improved to better group related items, making the standard
+        easier to navigate.
+</description>
+<suggestion>
+        20.6.7, 20.6.8,
+        20.6.9 and 20.6.10 should be grouped under a section called
+        "operator wrappers" or similar. The goal of all 4
+        subsections combined is to provide a functor for every
+        operator in the language. 20.6.17 class template hash
+        should numerically appear immediately after the operator
+        wrappers, as they are functors that are used in similar
+        ways 20.6.11, 20.6.12, 20.6.13, 20.6.14, 20.6.15 are
+        strongly related to 20.6.3, and to an extent 20.6.2. These
+        should all come under a subheading of "function adapters"
+        20.7.1, 20.7.3, 20.7.4, 20.7.5, 20.7.6, 20.7.7 and 20.7.10
+        should all be grouped as subclauses under [20.7.2
+        Allocators] [20.7.12 unique_ptr] should be a sub-section of
+        [20.7.13 smart pointers] [20.7.13 smart pointers] is
+        important enough to have a high level bullet after [20.7
+        memory], suggest renumbering as [20.8 smart pointers]
+        [20.7.13.7 Pointer safety] is nothing to do with smart
+        pointers and should become its own subclause [20.7.14
+        Pointer safety] [20.9 date and time functions] should be
+        moved under [20.8 time utilities] and retitled [20.8.6 C
+        Library] (as per memory management/C Library) [20.6.18
+        reference_closure] is fundamentally a language support
+        feature and should move to clause 18, see separate comment
+        [20.6.5 reference_wrapper] should be simplified and moved
+        into [2.2 utility components], see separate comment [20.6.4
+        result_of] should be reorganised as a type trait - see
+        separate comment Tuples and pairs are closely related so
+        merge tuple and pair into the same subclause - see more
+        general comment on this
+</suggestion>
+<notes>Agree that this is editorial -- forward to project editor. (effective 
+    duplicate of US 69)</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="199"
+  uknum="127"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.1.1, 20.1.2
+</section>
+<para>
+2
+</para>
+<description>
+        The requirement
+        that programs do not supply concept_maps should probably be
+        users do not supply their own concept_map specializations.
+        THe program will almost certainly supply concept_maps - the
+        standard itself supplies a specialization for RvalueOf?
+        references. Note that the term _program_ is defined in
+        3.5p1 and makes no account of the standard library being
+        treated differently to user written code.
+</description>
+<suggestion>
+        Replace the term 'program' with 'user'.
+</suggestion>
+<notes>Agree change 'program' to 'user' in clauses 20.1.1 and 20.1.2</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="200"
+  uknum="354"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+20.1.4
+</section>
+<para>
+</para>
+<description>
+        All standard library use expects Predicates
+        to be CopyConstructible, and this should be recognised
+        easily without reatedly stating on every use-case.
+</description>
+<suggestion>
+        Either require
+        CopyConstructible&lt;F&gt; as part of Predicate, or create
+        a refined concept, StdPredicate, used throughout the
+        library that requires CopyConstructible as well as
+        Callable. Consider making (Std)Predicate SemiRegular.
+</suggestion>
+<notes>After further 
+    discussion of UK200, we do not think adding constraints to predicates is a 
+    good idea. Straw poll on UK200: status quo, 5 pro - 2 con; remove 
+    copy-constructible, 3 pro - 4 con; pred must be copy-constructible, 4 pro - 
+    3 con; no consensus for moving away from the status quo.<BR/><BR/>
+    Also see UK245.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="201"
+  uknum="290"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+20.1.5
+</section>
+<para>
+</para>
+<description>
+        The Consistency axiom for
+        LessThanComparable will not compile.
+</description>
+<suggestion>
+        Add a requires
+        clause to the Consistency axiomL requires
+        HasLessEquals&lt;T&gt; &amp;&amp;
+        HasGreaterEquals&lt;T&gt;, or split the Consistency axiom
+        into two so that 'basic' consistency can be asserted
+        regardless of the &lt;=/&gt;= requirement.
+</suggestion>
+<notes>After consultation with the submitter, we agreed that the suggestion was in 
+    error and there is nothing else to be done.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="33"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.1.5
+</section>
+<para>
+</para>
+<description>
+        LessThanComparable and EqualityComparable don't correspond
+        to NaN.
+</description>
+<suggestion>
+        Apply
+        concept_map to these concepts at FloatingPointType
+</suggestion>
+<notes>We believe that no change is necessary, but it should be reviewed by a group 
+    devoted to numeric issues. Not every possible state for a type must 
+    participate in the axioms. For example, pointers are dereferenceable even if 
+    some pointers (e.g. the null pointer) should not be dereferenced.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="66"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.1.10
+</section>
+<para>
+</para>
+<description>
+        Application of the "Regular" concept to floating-point
+        types appears to be controversial (see long discussion on
+        std-lib reflector).
+</description>
+<suggestion>
+        State that the &#8220;Regular&#8221; concept does not
+        apply to floating-point types.
+</suggestion>
+<notes>Recommend that we handle the same as JP 33.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="34"
+  uknum=""
+  type="ed"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.2
+</section>
+<para>
+        1<sup>st</sup> <font size="2" style=
+        "font-size: 11pt">para, 4<sup>th</sup> line</font>
+</para>
+<description>
+        Though N2672 pointed at adding
+        "#include&lt;initializer_list&gt;", it isn't reflected.
+</description>
+<suggestion>
+        add
+        followings
+        <BR/><BR/>
+        #include &lt;initializer_list&gt; // for concept_map
+</suggestion>
+<notes>Agree that the omission of <code>#include
+    &lt;initializer_list&gt;</code>was not agreed to in a vote
+    and that the editor should reinstate it. 
+    There is some disagreement as to whether it actually <em>should</em> be 
+    there. Some believed it did not belong because we do not guarantee that one 
+    header includes another anywhere else in the standard. However, the paper 
+    that was voted in explicitly did make that guarantee. Removing that 
+    guarantee is beyond the scope of this review.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="67"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.2.1
+</section>
+<para>
+5 first sent.
+</para>
+<description>
+        Some connective words are missing.
+</description>
+<suggestion>
+        Insert &#8220;corresponding to&#8221; before &#8220;an
+        lvalue reference type.&#8221;
+</suggestion>
+<notes>Yes. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="35"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.2.3
+</section>
+<para>
+        6<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">para, 1<sup>st</sup> line</font>
+</para>
+<description>
+        Typo,
+        <BR/><BR/>"stdforward" should be
+        "std::forward"
+</description>
+<suggestion>
+        Correct typo.
+</suggestion>
+<notes>Yes. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="202"
+  uknum="213"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.2.4
+</section>
+<para>
+</para>
+<description>
+        The references
+        to pair in the tuple-like access to pair functions qualify
+        pair with std::pair even though they are in a namespace std
+        block.
+</description>
+<suggestion>
+        Remove the std:: qualification from these
+        references to pair.
+</suggestion>
+<notes>Yes. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="68"
+  uknum=""
+  type="te/ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.1.12
+</section>
+<para>
+IntegralLike
+</para>
+<description>
+        The code defining the context is syntactically
+        incorrect.
+</description>
+<suggestion>
+        Insert a comma in two places: at the end of the third
+        line of refinements, and at the end of the fourth line of
+        refinements.
+</suggestion>
+<notes>Editorial. The correct section is 20.1.12, not 20.2.12. Forward to project 
+    editor.</notes>
+<rationale>
+Section reference corrected from 20.2.12.
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="203"
+  uknum="229"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.3.2
+</section>
+<para>
+1-4
+</para>
+<description>
+        The ratio_xyz
+        types have a misplaced '}'. For example: template &lt;class
+        R1, class R2&gt; struct ratio_add { typedef see below}
+        type; ;
+</description>
+<suggestion>
+        Move the '}' to after the typedef: template
+        &lt;class R1, class R2&gt; struct ratio_add { typedef see
+        below type; };
+</suggestion>
+<notes>Yes. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="36"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.4.2.1
+</section>
+<para>
+        19<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">para, 6<sup>th</sup> line</font>
+</para>
+<description>
+        Typo.
+        <BR/><BR/>"it
+        it" should be "it is"
+</description>
+<suggestion>
+        Correct typo.
+</suggestion>
+<notes>Yes. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="204"
+  uknum="239"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.5.7 [meta.trans.other]
+</section>
+<para>
+Table 41
+</para>
+<description>
+        It is not
+        possible to create a variant union based on a parameter
+        pack expansion, e.g. to implement a classic discriminated
+        union template.
+</description>
+<suggestion>
+        Restore aligned_union template that was
+        removed by LWG issue 856.
+</suggestion>
+<notes>Agree. The need for aligned_union is compelling enough to reinstate.</notes>
+<rationale>
+Section reference corrected from 20.5.
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="69"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.5
+</section>
+<para>
+</para>
+<description>
+        This section, dealing with tuple&lt;&gt;, should be in
+        the same section as the similar utility pair&lt;&gt;.
+</description>
+<suggestion>
+        Restructure Clause 20 so as to bring these similar
+        components together.
+</suggestion>
+<notes>Editorial (effective duplicate of UK 198).
+Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="205"
+  uknum="253"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.5.3
+</section>
+<para>
+</para>
+<description>
+        integral_constant objects should be usable in
+        integral-constant-expressions. The addition to the language
+        of literal types and the enhanced rules for constant
+        expressions make this possible.
+</description>
+<suggestion>
+        Add a constexpr conversion operator to
+        class tempalate integral_constant: constexpr operator
+        value_type() { return value; }
+</suggestion>
+<notes>Agree: Add a constexpr conversion operator to class template 
+    integral_constant:
+    <code>constexpr operator value_type() { return value; }</code></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="206"
+  uknum="255"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.5.5
+</section>
+<para>
+para 4
+</para>
+<description>
+        Currently the
+        std says: "In order to instantiate the template
+        is_convertible&lt;From, To&gt;, the following code shall be
+        well formed:" But the code shown is the requirement for the
+        result of is_convertible to be a true_type, not a
+        precondition on whether the template can be instantiated.
+</description>
+<suggestion>
+        Change: "In order to instantiate the
+        template is_convertible&lt;From, To&gt;, the following code
+        shall be well formed:" To: "The template
+        is_convertible&lt;From, To&gt; inherits either directly or
+        indirectly from true_type if the following code is well
+        formed:"
+</suggestion>
+<notes>Agree with the proposed resolution: Section 20.5.5,
+Change: &#8220;In order to 
+instantiate the template is_convertible&lt;From, To&gt;, the following code shall 
+be well formed:&#8221;
+To: &#8220;The template is_convertible&lt;From, To&gt; inherits either 
+directly or indirectly from true_type if the following code
+is well formed:&#8221;</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="207"
+  uknum="256"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.5.6.1
+</section>
+<para>
+Table 36
+</para>
+<description>
+        suffix "::type" is missing from the some of
+        the examples.
+</description>
+<suggestion>
+        Change:
+        Example:remove_const&lt;const volatile int&gt;::type
+        evaluates to volatile int, whereas remove_const&lt;const
+        int*&gt; is const int*. &#8212;end example To:
+        Example:remove_const&lt;const volatile int&gt;::type
+        evaluates to volatile int, whereas remove_const&lt;const
+        int*&gt;::type is const int*. &#8212;end example And
+        change: Example:remove_volatile&lt;const volatile
+        int&gt;::type evaluates to const int, whereas
+        remove_volatile&lt;volatile int*&gt; is volatile int*.
+        &#8212;end example To: Example:remove_volatile&lt;const
+        volatile int&gt;::type evaluates to const int, whereas
+        remove_volatile&lt;volatile int*&gt;::type is volatile
+        int*. &#8212;end example And change:
+        Example:remove_cv&lt;const volatile int&gt;::type evaluates
+        to int, whereas remove_cv&lt;const volatile int*&gt; is
+        const volatile int*. &#8212;end example To:
+        Example:remove_cv&lt;const volatile int&gt;::type evaluates
+        to int, whereas remove_cv&lt;const volatile int*&gt;::type
+        is const volatile int*. &#8212;end example
+</suggestion>
+<notes>We tend to agree. Forward to project editor. Also recommend that the word 
+&#8220;is&#8221; be replaced with &#8220;evaluates to&#8221;
+in the same text.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="37"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.5.7
+</section>
+<para>
+Table 41
+</para>
+<description>
+        Typo.
+        <BR/><BR/>There isn't a
+        period at the end of enable_if's comments.
+        <BR/><BR/>
+        
+        <BR/><BR/>If
+        B is true, the member typedef type shall equal T;
+        otherwise, there shall be no member typedef type
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>If
+        B is true, the member typedef type shall equal T;
+        otherwise, there shall be no member typedef type.
+</description>
+<suggestion>
+        Add
+        &#8221;.&#8221;
+</suggestion>
+<notes>Agree. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="70"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.5
+</section>
+<para>
+</para>
+<description>
+        Specifications now expressed via narrative text are more
+        accurately and clearly expressed via executable code.
+</description>
+<suggestion>
+        Wherever
+        concepts are available that directly match this
+        section&#8217;s type traits, express the traits in terms of
+        the concepts instead of via narrative text. Where the type
+        traits do not quite match the corresponding concepts, bring
+        the two into alignment so as to avoid two nearly-identical
+        notions.
+</suggestion>
+<notes>(The correct reference is section 20.5, not 20.6) We think that this is a 
+    good idea, but it requires a lot of work. If someone submits a paper 
+    proposing specific changes, we would be happy to review it at the next 
+    meeting.</notes>
+<rationale>
+Section reference corrected from 20.6.
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="71"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.6.7
+</section>
+<para>
+Table 51, last row, column 3
+</para>
+<description>
+        The grammar is incorrect.
+</description>
+<suggestion>
+        Change &#8220;conversion are&#8221; to &#8220;conversion
+        is&#8221;.
+</suggestion>
+<notes>(The correct reference is section 20.5.7, table 41, last row). Agree: 
+    Forward to project editor. There are several ways to fix the grammar.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="38"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.6.12.1.3
+</section>
+<para>
+</para>
+<description>
+        add the move requirement for bind's return type.
+        
+        <BR/><BR/>
+        For example, assume following th1 and th2,
+        <BR/><BR/>
+        
+        void f(vector&lt;int&gt; v) { }
+        
+        vector&lt;int&gt; v{ ... };
+        thread th1([v]{ f(v); });
+        thread th2(bind(f, v));
+        
+        When function object are set to thread, v is moved to th1's
+        lambda expression in a Move Constructor of lambda
+        expression becuase th1's lambda expression has a Move
+        Constructor. But bind of th2's return type doesn't have the
+        requirement of Move, so it may not moved but copied.
+        <BR/><BR/>Add
+        the requirement of move to get rid of this useless copy.
+        <BR/><BR/>And also, add
+        the MoveConstructible as well as CopyConstructible.
+</description>
+<suggestion>
+        Add
+        the following requirements.
+        "<font color="#000000">it has a public move constructor
+        that performs a member-wise move."</font>
+        <BR/><BR/>Add
+        the MoveConstructible.
+</suggestion>
+<notes>
+We were not clear about what the submitter really
+intended. Requiring that the result of bind be MoveConstructible
+and/or CopyConstructible might be a start, but we would like to
+communicate with the submitter.  [NOTE: We would like to see a
+clarification of the wording for Returnable that makes it clear
+that move-only types can be Returnable.]<BR/><BR/>
+Peter Dimov comments: I believe that if US 72 is 
+resolved as proposed by me above, the objects returned by bind will already 
+be required to have a move constructor, otherwise bind would be unable to 
+return them when F or a type in BoundArgs is move-only.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="39"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="modified"
+  date=""
+  extdoc=""
+>
+<section>
+20.6.16.2
+</section>
+<para>
+</para>
+<description>
+        There are no requires corresponding to F of std::function.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        template&lt;class F, Allocator A&gt;
+        function(allocator_arg_t, const A&amp;, F);
+        <BR/><BR/>
+        template&lt;class F, Allocator A&gt;
+        function(allocator_arg_t, const A&amp;, F&amp;&amp;);
+        <BR/><BR/>
+        
+        <BR/><BR/>should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class F, Allocator A&gt;
+        <BR/><BR/>
+        requires CopyConstructible&lt;F&gt; &amp;&amp;
+        Callable&lt;F, ArgTypes...&gt;
+        <BR/><BR/>
+        &amp;&amp; Convertible&lt;Callable&lt;F,
+        ArgTypes...&gt;::result_type, R&gt;
+        <BR/><BR/>
+        function(allocator_arg_t, const A&amp;, F);
+        <BR/><BR/>
+        template&lt;class F, Allocator A&gt;
+        <BR/><BR/>
+        requires CopyConstructible&lt;F&gt; &amp;&amp;
+        Callable&lt;F, ArgTypes...&gt;
+        <BR/><BR/>
+        &amp;&amp; Convertible&lt;Callable&lt;F,
+        ArgTypes...&gt;::result_type, R&gt;
+        <BR/><BR/>
+        function(allocator_arg_t, const A&amp;, F&amp;&amp;);
+</suggestion>
+<notes>
+Agree with one correction: CopyConstructible should be 
+ConstructibleWithAllocator. New proposed resolution:<BR/><BR/>
+Correct as follows.<BR/><BR/>
+<PRE>
+  template&lt;class F, Allocator A&gt;
+    function(allocator_arg_t, const A&amp;, F);
+  template&lt;class F, Allocator A&gt;
+    function(allocator_arg_t, const A&amp;, F&amp;&amp;);
+</PRE>
+<BR/><BR/>should be<BR/><BR/>
+<PRE>
+  template&lt;class F, Allocator A&gt;
+    requires ConstructibleWithAllocator&lt;F, A&gt;
+      &amp;&amp; Callable&lt;F, ArgTypes...&gt;
+      &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;
+         ::result_type, R&gt;
+      function(allocator_arg_t, const A&amp;, F);
+
+  template&lt;class F, Allocator A&gt;
+    requires ConstructibleWithAllocator&lt;F,A&gt; 
+      &amp;&amp; Callable&lt;F, ArgTypes...&gt;
+      &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;
+         ::result_type, R&gt;
+      function(allocator_arg_t, 
+       const A&amp;, F&amp;&amp;);
+</PRE>
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="40"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.6.16.2
+</section>
+<para>
+</para>
+<description>
+        Thougn it's "Allocator Aloc" at other places, it's
+        "Allocator A" only std::function constructor template
+        parameter.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        template&lt;class F, Allocator A&gt;
+        function(allocator_arg_t, const A&amp;, F);
+        <BR/><BR/>
+        template&lt;class F, Allocator A&gt;
+        function(allocator_arg_t, const A&amp;, F&amp;&amp;);
+        <BR/><BR/>
+        
+        <BR/><BR/>should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class F, Allocator <u>Alloc</u>&gt;
+        function(allocator_arg_t, const <u>Alloc</u> &amp;, F);
+        <BR/><BR/>
+        template&lt;class F, Allocator <u>Alloc</u>&gt;
+        function(allocator_arg_t, const <u>Alloc</u> &amp;,
+        F&amp;&amp;);
+</suggestion>
+<notes>Agree, though minor. Forward to project editor (who may disregard).</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="41"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+20.6.16.2
+</section>
+<para>
+</para>
+<description>
+        There are no requires corresponding to R and Args of
+        UsesAllocator.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        template &lt;class R, class... Args&gt;
+        <BR/><BR/>
+        concept_map UsesAllocator&lt;function&lt;R(Args...)&gt;,
+        Alloc&gt; {
+        <BR/><BR/>
+        typedef Alloc allocator_type;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;<u>Returnable</u> R,
+        <u>CopyConstructible</u>... Args&gt;
+        <BR/><BR/>
+        concept_map UsesAllocator&lt;function&lt;R(Args...)&gt;,
+        Alloc&gt; {
+        <BR/><BR/>
+        typedef Alloc allocator_type;
+        <BR/><BR/>}
+</suggestion>
+<notes>This change would be redundant because function&lt;&gt; is already sufficiently 
+    constrained. No actions necessary.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="42"
+  uknum=""
+  type="ed"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.6.16.2
+</section>
+<para>
+</para>
+<description>
+        The requires
+        are wrong.
+        <BR/><BR/>R
+        require Returnable, and ArgTypes requires CopyConstructible
+        by a definition of function, then it's a mistake to
+        designate followings by MoveConstructible.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;MoveConstructible R, MoveConstructible...
+        ArgTypes&gt;
+        <BR/><BR/>
+        bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;,
+        nullptr_t);
+        <BR/><BR/>
+        template &lt;MoveConstructible R, MoveConstructible...
+        ArgTypes&gt;
+        <BR/><BR/>
+        bool operator==(nullptr_t, const
+        function&lt;R(ArgTypes...)&gt;&amp;);
+        <BR/><BR/>
+        template &lt;MoveConstructible R, MoveConstructible...
+        ArgTypes&gt;
+        <BR/><BR/>
+        bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;,
+        nullptr_t);
+        <BR/><BR/>
+        template &lt;MoveConstructible R, MoveConstructible...
+        ArgTypes&gt;
+        <BR/><BR/>
+        bool operator!=(nullptr_t, const
+        function&lt;R(ArgTypes...)&gt;&amp;);
+        <BR/><BR/>
+        template &lt;MoveConstructible R, MoveConstructible...
+        ArgTypes&gt;
+        <BR/><BR/>
+        void swap(function&lt;R(ArgTypes...)&gt;&amp;,
+        function&lt;R(ArgTypes...)&gt;&amp;);
+        <BR/><BR/>
+        
+        <BR/><BR/>should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;<u>Returnable</u> R,
+        <u>CopyConstructible</u>... ArgTypes&gt;
+        <BR/><BR/>
+        bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;,
+        nullptr_t);
+        <BR/><BR/>
+        template &lt;<u>Returnable</u> R,
+        <u>CopyConstructible</u>... ArgTypes&gt;
+        <BR/><BR/>
+        bool operator==(nullptr_t, const
+        function&lt;R(ArgTypes...)&gt;&amp;);
+        <BR/><BR/>
+        template &lt;<u>Returnable</u> R,
+        <u>CopyConstructible</u>... ArgTypes&gt;
+        <BR/><BR/>
+        bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;,
+        nullptr_t);
+        <BR/><BR/>
+        template &lt;<u>Returnable</u> R,
+        <u>CopyConstructible</u>... ArgTypes&gt;
+        <BR/><BR/>
+        bool operator!=(nullptr_t, const
+        function&lt;R(ArgTypes...)&gt;&amp;);
+        <BR/><BR/>
+        template &lt;<u>Returnable</u> R,
+        <u>CopyConstructible</u>... ArgTypes&gt;
+        <BR/><BR/>void
+        swap(function&lt;R(ArgTypes...)&gt;&amp;,
+        function&lt;R(ArgTypes...)&gt;&amp;);
+</suggestion>
+<notes>As with JP 41, these constraints are redundant given that function&lt;&gt; is 
+    already constrained. So we recommend changing each occurence of &#8220;MoveConstructible&#8221; 
+    to &#8220;class&#8221;. Note: this issue is also present in func.wrap.func.nullptr.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="208"
+  uknum="338"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+20.6.17
+</section>
+<para>
+1
+</para>
+<description>
+        std::hash should
+        be implemented for much more of the standard library. In
+        particular for pair, tuple and all the standard containers.
+</description>
+<suggestion>
+        .
+</suggestion>
+<notes>Consensus is that this is an expansion of the scope of C++0X and so we 
+    recommend no action.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="209"
+  uknum="111"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.7
+</section>
+<para>
+</para>
+<description>
+        Smart pointers cannot be used in
+        constrained templates
+</description>
+<suggestion>
+        Provide
+        constraints for smart pointers
+</suggestion>
+<notes>We look forward to a paper on this topic. We recommend no action until a 
+    paper is available. We understand that a paper is forthcoming.<BR/><BR/>
+    Peter Dimov comments: shared_ptr&lt;T&gt; and weak_ptr&lt;T&gt; support all types T for 
+    which T* is valid. In other words, a possible (partial) resolution is to 
+    change class T to PointeeType T for shared_ptr, weak_ptr and possibly 
+    enable_shared_from_this.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="213"
+  uknum="357"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.7.6
+</section>
+<para>
+</para>
+<description>
+        std::allocator
+        should be constrained to simplify its use on constrained
+        contexts. This library component models allocation from
+        free store via the new operator so choose constraints to
+        match. The Allocator concept allows for a wider variety of
+        allocators that users may choose to supply if their
+        allocation model does not require operator new, without
+        impacting the requirements of this template.
+</description>
+<suggestion>
+        The primary allocator template should be
+        constrained to require ObjectType&lt;T&gt; and
+        FreeStoreAllocatable&lt;T&gt;. Further operations to be
+        constrained as required.
+</suggestion>
+<notes>[default.allocator]
+
+    Agree as stated. A future paper will address additional related issues.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="214"
+  uknum="125"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.7.8
+</section>
+<para>
+</para>
+<description>
+        raw_storage_iterator needs constraining as an iterator
+        adaptor to be safely used in constrained templates
+</description>
+<suggestion>
+        Constrain the raw_storage_iterator template
+</suggestion>
+<notes>We look forward to a paper on this topic. We recommend no action until a 
+    paper is available.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="210"
+  uknum="124"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.7.11
+</section>
+<para>
+</para>
+<description>
+        Specialized algorithms for memory
+        managenment need requirements to be easily usable in
+        constrained templates
+</description>
+<suggestion>
+        Provide
+        constraints for all algorithms in 20.7.11
+</suggestion>
+<notes>We look forward to a paper on this topic. We recommend no action until a 
+    paper is available.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="20"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.6.12
+</section>
+<para>
+</para>
+<description>
+        DE-20 The section heading and the first sentence use the
+        term "template function", which is undefined.
+</description>
+<suggestion>
+        Replace
+        "template function" by "function template".
+</suggestion>
+<notes>Agree. Forward to the project editor.
+</notes>
+<rationale>
+Section reference corrected from 20.7.12.
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="72"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.6.12.1.3 [func.bind.bind]
+</section>
+<para>
+</para>
+<description>
+        bind should support move-only functors and bound arguments.
+</description>
+<suggestion>
+</suggestion>
+<notes>We look forward to a paper on this topic. We recommend 
+no action until a paper is available. We do think that bind would 
+require further overloads to support move semantics, if indeed move 
+semantics are possible.<BR/><BR/>
+Peter Dimov comments: I believe 
+that what is meant here is that the CopyConstructible requirements on F 
+and BoundArgs must be changed to MoveConstructible. I see no need for a 
+paper.
+</notes>
+<rationale>
+Section reference corrected from 20.7.12.
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="21"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.6.12.1.3 [func.bind.bind]
+</section>
+<para>
+</para>
+<description>
+        DE-21 The specification for bind claims twice that "the
+        values and types for the bound arguments v1, v2, ..., vN
+        are determined as specified below". No such specification
+        appears to exist.
+</description>
+<suggestion>
+        Add the missing specification in the same section, or
+        add a cross-reference indicating the section where the
+        specification appears.
+</suggestion>
+<notes>Agree. There are several differences (omissions) between 
+N2691 [func.bind.bind] and N2800 [func.bind.bind]. Ask the project 
+editor to review the changes.
+</notes>
+<rationale>
+Section reference corrected from 20.7.12.1.3.
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="211"
+  uknum="428"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.6.12.2.3 [unique.ptr.single.asgn]
+</section>
+<para>
+11
+</para>
+<description>
+        The nullptr_t
+        type was introduced to resolve the null pointer literal
+        problem. It should be used for the assignemnt operator, as
+        with the constructor and elsewhere through the library.
+</description>
+<suggestion>
+        Change signature here and in the synopsis
+        to: unique_ptr&amp; operator=(nullptr_t); Strike the
+        sentance an note before the Effects clause.
+</suggestion>
+<notes>Agree.
+</notes>
+<rationale>
+Section reference corrected from 20.7.12.2.3.
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="212"
+  uknum="270"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="modified"
+  date=""
+  extdoc=""
+>
+<section>
+20.6.13.7 [util.dynamic.safety]
+</section>
+<para>
+</para>
+<description>
+        The
+        pointer-safety API is nothing to do with smart pointers, so
+        does not belong in 20.7.13. In fact it is a set of language
+        support features are really belongs in clause 18, with the
+        contents declared in a header that deals with
+        language-support of memory management.
+</description>
+<suggestion>
+        Move this specification to 18.5. Move the
+        declarations into the header &lt;new&gt;.
+</suggestion>
+<notes>Agree in principle, but not with the proposed 
+resolution. We believe it belongs either a subsection of either 20 
+[utilities] or 20.7 [memory] as part of the general reorganization of 
+20. The declaration should stay in
+[memory].
+</notes>
+<rationale>
+Section reference corrected from 20.7.13.7.
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="22"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.6.16.2 [func.wrap.func]
+</section>
+<para>
+</para>
+<description>
+        DE-22 The conditions for deriving from
+        std::unary_function and std::binary_function are unclear:
+        The condition would also be satisfied if ArgTypes were
+        std::vector&lt;T1&gt;, because it (arguably) "contains" T1.
+</description>
+<suggestion>
+        Consider stating the conditions in normative prose
+        instead of in comments in the class definition. Use
+        "consists of" instead of "contains". Consider using "if and
+        only if" instead of "iff".
+</suggestion>
+<notes>Agree. std::reference_wrapper has the same structure, 
+and we suggest that std::function be presented in the same way as 
+std::reference_wrapper.
+</notes>
+<rationale>
+Section reference corrected from 20.7.16.2.
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="73"
+  uknum=""
+  type="te"
+  owner="CWG"
+  issue=""
+  disp="accepted"
+  date="2009-03-06"
+  extdoc="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2845.html"
+>
+<section>
+20.6.18
+</section>
+<para>
+</para>
+<description>
+        The
+        std::reference_closure template is redundant with
+        std::function and should be removed.
+        <BR/><BR/>
+        <BR/><BR/>
+        std::reference_closure is a premature optimization that
+        provides a limited subset of the functionality of
+        std::function intended to improve performance in a narrow
+        use case. However, the &#8220;parallel application
+        performance&#8221; benchmark used to motivate the inclusion
+        of std::reference_closure was flawed in several ways:
+        <ol start="3">
+          <li>
+            <BR/><BR/>it failed to
+            enable a common optimization in std::function
+            (implemented by all vendors), exacting a large and
+            unrealistic penalty for copying std::function
+            instances, and</li>
+          <li>
+            <BR/><BR/>it failed to
+            account for parallel scheduler overhead or
+            realistically-sized work units, both of which would
+            dominate the costs measured by the benchmark in any
+            realistic application.</li>
+          </ol>
+</description>
+<suggestion>
+        Remove 20.7.18
+        [func.referenceclosure].
+        <BR/><BR/>
+        <BR/><BR/>Remove 5.1.1 paragraph 12.
+</suggestion>
+<notes>This requires attention from CWG and/or EWG.
+</notes>
+<rationale>
+Section reference corrected from 20.7.18.
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="74.1"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date="2009-03-06"
+  extdoc="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf"
+>
+<section>
+20.8
+</section>
+<para>
+</para>
+<description>
+        Scoped
+        allocators represent a poor trade-off for standardization,
+        since (1) scoped-allocator--aware containers can be
+        implemented outside the C++ standard library but used with
+        its algorithms, (2) scoped allocators only benefit a tiny
+        proportion of the C++ community (since few C++ programmers
+        even use today&#8217;s allocators), and (3) all C++ users,
+        especially the vast majority of the C++ community that
+        won&#8217;t ever use scoped allocators are forced to cope
+        with the interface complexity introduced by scoped
+        allocators. In essence, the larger community will suffer to
+        support a very small subset of the community who can
+        already implement their own data structures outside of the
+        standard library. Therefore, scoped allocators should be
+        removed from the working paper.
+        <BR/><BR/>Some evidence of
+        the complexity introduced by scoped allocators:
+        <BR/><BR/>20.3.3, 20.5:
+        large increase in the number of pair and tuple constructors
+        <BR/><BR/>23: confusing
+        &#8220;AllocatableElement&#8221; requirements throughout.
+</description>
+<suggestion>
+        Remove support
+        for scoped allocators from the working paper. This includes
+        at least the following changes:
+        <BR/><BR/>
+        <BR/><BR/>Remove 20.8.3
+        [allocator.element.concepts]
+        <BR/><BR/>
+        <BR/><BR/>Remove 20.8.7
+        [allocator.adaptor]
+        <BR/><BR/>
+        <BR/><BR/>Remove 20.8.10
+        [construct.element]
+        <BR/><BR/>
+        <BR/><BR/>In Clause 23:
+        replace requirements naming the AllocatableElement concept
+        with requirements naming CopyConstructible,
+        MoveConstructible, DefaultConstructible, or Constructible,
+        as appropriate.
+</suggestion>
+<notes>
+Resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
+N2840</a>, accepted in New Jersey.<BR/><BR/>
+See US 65 for detailed notes.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="74.2"
+  uknum=""
+  type="te/ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.8.2.2
+</section>
+<para>
+(a) synopsis (b) after &#182; 14
+</para>
+<description>
+        A concept name is twice misspelled.
+</description>
+<suggestion>
+        Change &#8220;Hasconstructor&#8221; to
+        &#8220;HasConstructor&#8221; (twice).
+</suggestion>
+<notes>Agree. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="75"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue="modified"
+  disp=""
+  date="2009-03-06"
+  extdoc="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf"
+>
+<section>
+20.8.2.2
+</section>
+<para>
+</para>
+<description>
+        Allocator concepts are incomplete
+</description>
+<suggestion>
+        See paper:
+        http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf
+</suggestion>
+<notes>
+    The referenced paper, N2810, was revised into
+    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
+    N2840</a> and accepted in New Jersey.<BR/><BR/>
+    Full LWG: Considered N2840 (a revision of N2829): straw poll, this is the 
+    direction we want to go: 11 pro - 0 con - 5 abstain, we have consensus. 
+    Straw poll, put on formal motions page for this meeting (pro) or review and 
+    consider at next meeting (con): 7 pro - 1 con - many abstain, consensus for 
+    moving as formal motion at this meeting. Also had strong support for 
+    proposals 1, 2 and 3 in N2834 (simplify pair). Pablo will submit a paper 
+    containing only those parts of N2834 in Frankfurt.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="43"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.8.3
+</section>
+<para>
+</para>
+<description>
+        Typo.
+        <BR/><BR/>
+        "alloc" should be "Alloc"
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        auto concept UsesAllocator&lt;typename T, typename
+        Alloc&gt; {
+        <BR/><BR/>
+        requires Allocator&lt;alloc&gt;;
+        <BR/><BR/>
+        typename allocator_type = T::allocator_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        <BR/><BR/>
+        auto concept UsesAllocator&lt;typename T, typename
+        Alloc&gt; {
+        <BR/><BR/>
+        requires Allocator&lt;<u>Alloc</u>&gt;;
+        <BR/><BR/>typename
+        allocator_type = T::allocator_type;
+</suggestion>
+<notes>Agree. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="215"
+  uknum="356"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.8.3.3
+</section>
+<para>
+6,8
+</para>
+<description>
+        Extra pair of
+        {}, presumably some formatting code gone awry :
+        duration&amp; operator-{-}();
+</description>
+<suggestion>
+        Remove the {} or fix formatting
+</suggestion>
+<notes>Agree. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="77"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.8.4
+</section>
+<para>
+</para>
+<description>
+        Allocator-specific move and copy behavior for containers
+        (N2525) complicates a little-used and already-complicated
+        portion of the standard library (allocators), and breaks
+        the conceptual model of move-constructor and
+        move-assignment operations on standard containers being
+        efficient operations. The extensions for allocator-specific
+        move and copy behavior should be removed from the working
+        paper.
+        <BR/><BR/>With the
+        introduction of rvalue references, we are teaching
+        programmers that moving from a standard container (e.g., a
+        vector&lt;string&gt;) is an efficient, constant-time
+        operation. The introduction of N2525 removed that
+        guarantee; depending on the behavior of four different
+        traits (20.8.4), the complexity of copy and move operations
+        can be constant or linear time. This level of customization
+        greatly increases the complexity of standard containers,
+        and benefits only a tiny fraction of the C++ community.
+</description>
+<suggestion>
+        Remove 20.8.4.
+        <BR/><BR/>
+        <BR/><BR/>Remove 20.8.5.
+        <BR/><BR/>
+        <BR/><BR/>Remove all references to the facilities in
+        20.8.4 and 20.8.5 from clause 23.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="78"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.8.12,
+        20.8.13.2
+</section>
+<para>
+</para>
+<description>
+        There is presently no way to
+        convert directly from a <font size="2" style=
+        "font-size: 11pt"><code>shared_ptr</code> to a
+        <code>unique_ptr</code>.</font>
+</description>
+<suggestion>
+        Add
+        an interface that performs the conversion. See the
+        attached, Issues with the C++ Standard" paper under Chapter
+        20, "Conversion from <font size="2" style=
+        "font-size: 11pt"><code>shared_ptr</code> to
+        <code>unique_ptr".</code></font>
+</suggestion>
+<notes>We look forward to 
+a paper on this topic. We recommend no action until a paper is 
+available. We believe that the shared pointer must use the default deleter for the conversion to succeed.<BR/><BR/>
+Peter Dimov comments: this is basically a request for shared_ptr&lt;&gt;::release 
+in disguise, with all the associated problems. Not a good idea.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="79"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.8.12.2.1
+</section>
+<para>
+</para>
+<description>
+        [unique.ptr.single.ctor]/5 no longer requires for D not to
+        be a pointer type. This restriction needs to be put
+        back in. Otherwise we have a run time failure that
+        could have been caught at compile time:
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        unique_ptr&lt;int, void(*)(void*)&gt;
+        p(malloc(sizeof(int))); // should not compile
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        unique_ptr&lt;int, void(*)(void*)&gt;
+        p(malloc(sizeof(int)), free); // ok
+</description>
+<suggestion>
+</suggestion>
+<notes>Agree. The unique_ptr(pointer 
+p) <em>Requires</em> clause should be the same as the unique_ptr() <em>
+Requires</em> clause. Note that unique_ptr [unique.ptr] needs concepts.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="44"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.7.13.6 [util.smartptr.shared.atomic]
+</section>
+<para>
+</para>
+<description>
+        The
+        1st parameter p and 2nd parameter v is now
+        shared_ptr&lt;T&gt; *.
+        <BR/><BR/>It
+        should be shared_ptr&lt;T&gt;&amp;, or if these are
+        shared_ptr&lt;T&gt;* then add the "p shall not be a null
+        pointer" at the requires.
+</description>
+<suggestion>
+        Change shared_ptr&lt;T&gt;&amp; or add the "p shall not be
+        a null pionter" at the requires.
+</suggestion>
+<notes>Agree. All of the 
+functions need a requirement that p (or v) is a pointer to a valid 
+object.
+</notes>
+<rationale>
+Section reference corrected from 20.8.13.6.
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="45"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.9
+</section>
+<para>
+</para>
+<description>
+        Rep, Period, Clock and Duration don't correspond to
+        concept.
+        <BR/><BR/>
+        template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
+        class duration;
+        <BR/><BR/>template
+        &lt;class Clock, class Duration = typename
+        Clock::duration&gt; class time_point;
+</description>
+<suggestion>
+        Make concept for Rep, Period, Clock and Duration, and fix
+        20.9 and wait_until and wait_for's template parameter at
+        30.
+</suggestion>
+<notes>We agree that this section needs concepts. We 
+look forward to a paper on this topic. We recommend no action until a 
+paper is available.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="80"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.8.2.1 [time.traits.is_fp]
+</section>
+<para>
+Heading
+</para>
+<description>
+        The section heading does not describe the contents.
+</description>
+<suggestion>
+        Change the
+        heading &#8220;<span lang=
+        "en-US">is_floating_point</span>&#8221; to
+        &#8220;<span lang=
+        "en-US">treat_as_floating_point</span>&#8221;. Optionally
+        adjust the section&#8217;s label similarly.
+</suggestion>
+<notes>Agree. The section name and the section label 
+    ([time.traits.is_fp]) are wrong. Forward to project editor.
+</notes>
+<rationale>
+Section reference corrected from 20.9.2.1.
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="81"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue="934"
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+20.9.3
+</section>
+<para>
+</para>
+<description>
+        chrono::duration is missing the modulous operator for both
+        member and non-member arithmetic. This operator is useful
+        for finding the position of a duration within a bounded
+        time frame. Having it be built in to duration is safer than
+        requiring the client to extract and operate directly on the
+        duration&#8217;s representation as the latter will not
+        enforce the correct units of the operation.
+        <BR/><BR/>
+        
+        <BR/><BR/>Ex:
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        milliseconds ms(...);
+        <BR/><BR/>
+        microseconds us(...);
+        <BR/><BR/>
+        
+        <BR/><BR/>ms
+        % us; // microseconds
+        <BR/><BR/>us
+        % ms; // microseconds
+        <BR/><BR/>ms
+        % 5; // milliseconds
+        <BR/><BR/>5 %
+        ms; // does not compile
+</description>
+<suggestion>
+        Add:
+        <BR/><BR/>
+        <BR/><BR/>
+        template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
+        <BR/><BR/>
+        class duration {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>...
+        <BR/><BR/>duration&amp;
+        operator%(const rep&amp;);
+        <BR/><BR/>duration&amp;
+        operator%(const duration&amp;);
+        <BR/><BR/>..
+        <BR/><BR/>};
+        <BR/><BR/>
+        <BR/><BR/>template
+        &lt;class Rep1, class Period,
+        <BR/><BR/>class Rep2&gt;
+        <BR/><BR/>
+        duration&lt;typename common_type&lt;
+        <BR/><BR/>Rep1,
+        Rep2&gt;::type, Period&gt;
+        <BR/><BR/>operator%(const
+        duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
+        <BR/><BR/>
+        <BR/><BR/>template
+        &lt;class Rep1, class Period1,
+        <BR/><BR/>class Rep2,
+        class Period2&gt;
+        <BR/><BR/>typename
+        common_type&lt;duration&lt;Rep1, Period1&gt;,
+        duration&lt;Rep2, Period2&gt;&gt;::type
+        <BR/><BR/>operator%(const
+        duration&lt;Rep1, Period1&gt;&amp; lhs, const
+        duration&lt;Rep2, Period2&gt;&amp; rhs);
+</suggestion>
+<notes>[time.duration] Agree except that there is a typo in the 
+proposed resolution. The member operators should be operator%=. This is 
+also LWG
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">
+issue 934</a>.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="82"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+20.9.5.3
+</section>
+<para>
+after &#182; 1
+</para>
+<description>
+        The code synopsis has a minor alignment error.
+</description>
+<suggestion>
+        Align &#8220;rep&#8221; with the other symbols defined
+        in this synopsis.
+</suggestion>
+<notes>[time.clock.hires] Agree. Forward to project editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="216"
+  uknum="282"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+21
+</section>
+<para>
+</para>
+<description>
+        All the containers use concepts for their
+        iterator usage, exect for basic_string. This needs fixing.
+</description>
+<suggestion>
+        Use concepts for iterator template
+        parameters throughout the chapter.
+</suggestion>
+<notes>NB comments to be handled by Dave Abrahams and Howard Hinnant with advice 
+    from PJP: UK216 (which duplicates) JP46, JP48.
+    JP46 supplies extensive 
+    proposed wording; start there.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="46"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+21.2, 21.3
+</section>
+<para>
+</para>
+<description>
+        The
+        basic_string does not use concept.
+</description>
+<suggestion>
+        The
+        "class Alloc" is changed to "Allocator Alloc".
+        <BR/><BR/>The
+        "class InputIterator" is changed to "InputIterator Iter".
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3, basic_string:
+        <BR/><BR/>
+        template&lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+        <u>Allocator</u> Alloc = allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_string;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
+        <BR/><BR/>
+        operator+(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        <BR/><BR/>
+        operator+(basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        <BR/><BR/>
+        operator+(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        <BR/><BR/>
+        operator+(basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        lhs,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
+        <BR/><BR/>
+        operator+(const charT* lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        <BR/><BR/>
+        operator+(const charT* lhs,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
+        <BR/><BR/>
+        operator+(charT lhs, const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        <BR/><BR/>
+        operator+(charT lhs,
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
+        <BR/><BR/>
+        operator+(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const charT* rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        <BR/><BR/>
+        operator+(basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        lhs,
+        <BR/><BR/>
+        const charT* rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
+        <BR/><BR/>
+        operator+(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        charT rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        <BR/><BR/>
+        operator+(basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
+        lhs, charT rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator==(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator==(const charT* lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator==(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const charT* rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator!=(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator!=(const charT* lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator!=(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const charT* rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&lt; (const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&lt; (const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const charT* rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&lt; (const charT* lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&gt; (const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&gt; (const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const charT* rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&gt; (const charT* lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&lt;=(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&lt;=(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const charT* rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&lt;=(const charT* lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&gt;=(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&gt;=(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
+        <BR/><BR/>
+        const charT* rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        bool operator&gt;=(const charT* lhs,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3.8.8: swap
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_string&lt;charT,traits,Alloc&gt;&amp; lhs,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,Alloc&gt;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_string&lt;charT,traits,Alloc&gt;&amp;&amp;
+        lhs,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,Alloc&gt;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_string&lt;charT,traits,Alloc&gt;&amp; lhs,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,Alloc&gt;&amp;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3.8.9: inserters and extractors
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_istream&lt;charT,traits&gt;&amp;
+        <BR/><BR/>
+        operator&gt;&gt;(basic_istream&lt;charT,traits&gt;&amp;&amp;
+        is,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; str);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_ostream&lt;charT, traits&gt;&amp;
+        <BR/><BR/>
+        operator&lt;&lt;(basic_ostream&lt;charT,
+        traits&gt;&amp;&amp; os,
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        str);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_istream&lt;charT,traits&gt;&amp;
+        <BR/><BR/>
+        getline(basic_istream&lt;charT,traits&gt;&amp;&amp; is,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; str,
+        <BR/><BR/>
+        charT delim);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc</u>&gt;
+        <BR/><BR/>
+        basic_istream&lt;charT,traits&gt;&amp;
+        <BR/><BR/>
+        getline(basic_istream&lt;charT,traits&gt;&amp;&amp; is,
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; str);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3 Class template basic_string
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template&lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_string {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>//
+        types:
+        <BR/><BR/>
+        typedef traits traits_type;
+        <BR/><BR/>
+        typedef typename traits::char_type value_type;
+        <BR/><BR/>
+        typedef <u>Alloc</u> allocator_type;
+        <BR/><BR/>
+        typedef typename <u>Alloc</u>::size_type size_type;
+        <BR/><BR/>
+        typedef typename <u>Alloc</u>::difference_type
+        difference_type;
+        <BR/><BR/>
+        typedef typename <u>Alloc</u>::reference reference;
+        <BR/><BR/>
+        typedef typename <u>Alloc</u>::const_reference
+        const_reference;
+        <BR/><BR/>
+        typedef typename <u>Alloc</u>::pointer pointer;
+        <BR/><BR/>
+        typedef typename <u>Alloc</u>::const_pointer const_pointer;
+        <BR/><BR/>
+        typedef implementation-defined iterator; // See 23.1
+        <BR/><BR/>
+        typedef implementation-defined const_iterator; // See 23.1
+        <BR/><BR/>
+        typedef std::reverse_iterator&lt;iterator&gt;
+        reverse_iterator;
+        <BR/><BR/>
+        typedef std::reverse_iterator&lt;const_iterator&gt;
+        const_reverse_iterator;
+        <BR/><BR/>
+        static const size_type npos = -1;
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3.2 construct/copy/destroy:
+        <BR/><BR/>
+        explicit basic_string(const <u>Alloc</u>&amp; a =
+        <u>Alloc</u>());
+        <BR/><BR/>
+        basic_string(const basic_string&amp; str);
+        <BR/><BR/>
+        basic_string(basic_string&amp;&amp; str);
+        <BR/><BR/>
+        basic_string(const basic_string&amp; str, size_type pos,
+        size_type n = npos,
+        <BR/><BR/>
+        const <u>Alloc</u>&amp; a = <u>Alloc</u>());
+        <BR/><BR/>
+        basic_string(const charT* s,
+        <BR/><BR/>
+        size_type n, const <u>Alloc</u>&amp; a = <u>Alloc</u>());
+        <BR/><BR/>
+        basic_string(const charT* s, const <u>Alloc</u>&amp; a =
+        <u>Alloc</u>());
+        <BR/><BR/>
+        basic_string(size_type n, charT c, const <u>Alloc</u>&amp;
+        a = <u>Alloc</u>());
+        <BR/><BR/>
+        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
+        <BR/><BR/>
+        basic_string(<u>Iter</u> begin, <u>Iter</u> end,
+        <BR/><BR/>
+        const <u>Alloc</u>&amp; a = <u>Alloc</u>());
+        <BR/><BR/>
+        basic_string(initializer_list&lt;charT&gt;, const
+        <u>Alloc</u>&amp; = <u>Alloc</u>());
+        <BR/><BR/>
+        basic_string(const basic_string&amp;, const
+        <u>Alloc</u>&amp;);
+        <BR/><BR/>
+        basic_string(basic_string&amp;&amp;, const
+        <u>Alloc</u>&amp;);
+        <BR/><BR/>
+        ~basic_string();
+        <BR/><BR/>
+        basic_string&amp; operator=(const basic_string&amp; str);
+        <BR/><BR/>
+        basic_string&amp; operator=(basic_string&amp;&amp; str);
+        <BR/><BR/>
+        basic_string&amp; operator=(const charT* s);
+        <BR/><BR/>
+        basic_string&amp; operator=(charT c);
+        <BR/><BR/>
+        basic_string&amp; operator=(initializer_list&lt;charT&gt;);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3.3 iterators:
+        <BR/><BR/>...
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3.4 capacity:
+        <BR/><BR/>...
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3.5 element access:
+        <BR/><BR/>...
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3.6 modifiers:
+        <BR/><BR/>...
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        basic_string&amp; append(const basic_string&amp; str);
+        <BR/><BR/>
+        basic_string&amp; append(const basic_string&amp; str,
+        size_type pos,
+        <BR/><BR/>
+        size_type n);
+        <BR/><BR/>
+        basic_string&amp; append(const charT* s, size_type n);
+        <BR/><BR/>
+        basic_string&amp; append(const charT* s);
+        <BR/><BR/>
+        basic_string&amp; append(size_type n, charT c);
+        <BR/><BR/>
+        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
+        <BR/><BR/>
+        basic_string&amp; append(<u>Iter</u> first, <u>Iter</u>
+        last);
+        <BR/><BR/>
+        basic_string&amp; append(initializer_list&lt;charT&gt;);
+        <BR/><BR/>
+        void push_back(charT c);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        basic_string&amp; assign(const basic_string&amp; str);
+        <BR/><BR/>
+        basic_string&amp; assign(basic_string&amp;&amp; str);
+        <BR/><BR/>
+        basic_string&amp; assign(const basic_string&amp; str,
+        size_type pos,
+        <BR/><BR/>
+        size_type n);
+        <BR/><BR/>
+        basic_string&amp; assign(const charT* s, size_type n);
+        <BR/><BR/>
+        basic_string&amp; assign(const charT* s);
+        <BR/><BR/>
+        basic_string&amp; assign(size_type n, charT c);
+        <BR/><BR/>
+        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
+        <BR/><BR/>
+        basic_string&amp; assign(<u>Iter</u> first, <u>Iter</u>
+        last);
+        <BR/><BR/>
+        basic_string&amp; assign(initializer_list&lt;charT&gt;);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        basic_string&amp; insert(size_type pos1, const
+        basic_string&amp; str);
+        <BR/><BR/>
+        basic_string&amp; insert(size_type pos1, const
+        basic_string&amp; str,
+        <BR/><BR/>
+        size_type pos2, size_type n);
+        <BR/><BR/>
+        basic_string&amp; insert(size_type pos, const charT* s,
+        size_type n);
+        <BR/><BR/>
+        basic_string&amp; insert(size_type pos, const charT* s);
+        <BR/><BR/>
+        basic_string&amp; insert(size_type pos, size_type n, charT
+        c);
+        <BR/><BR/>
+        iterator insert(const_iterator p, charT c);
+        <BR/><BR/>
+        void insert(const_iterator p, size_type n, charT c);
+        <BR/><BR/>
+        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
+        <BR/><BR/>
+        void insert(const_iterator p, <u>Iter</u> first,
+        <u>Iter</u> last);
+        <BR/><BR/>
+        void insert(const_iterator p,
+        initializer_list&lt;charT&gt;);
+        <BR/><BR/>
+        
+        <BR/><BR/>...
+        <BR/><BR/>
+        basic_string&amp; replace(size_type pos1, size_type n1,
+        <BR/><BR/>
+        const basic_string&amp; str);
+        <BR/><BR/>
+        basic_string&amp; replace(size_type pos1, size_type n1,
+        <BR/><BR/>
+        const basic_string&amp; str,
+        <BR/><BR/>
+        size_type pos2, size_type n2);
+        <BR/><BR/>
+        basic_string&amp; replace(size_type pos, size_type n1,
+        const charT* s,
+        <BR/><BR/>
+        size_type n2);
+        <BR/><BR/>
+        basic_string&amp; replace(size_type pos, size_type n1,
+        const charT* s);
+        <BR/><BR/>
+        basic_string&amp; replace(size_type pos, size_type n1,
+        size_type n2,
+        <BR/><BR/>
+        charT c);
+        <BR/><BR/>
+        basic_string&amp; replace(iterator i1, iterator i2,
+        <BR/><BR/>
+        const basic_string&amp; str);
+        <BR/><BR/>
+        basic_string&amp; replace(iterator i1, iterator i2, const
+        charT* s,
+        <BR/><BR/>
+        size_type n);
+        <BR/><BR/>
+        basic_string&amp; replace(iterator i1, iterator i2, const
+        charT* s);
+        <BR/><BR/>
+        basic_string&amp; replace(iterator i1, iterator i2,
+        <BR/><BR/>
+        size_type n, charT c);
+        <BR/><BR/>
+        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
+        <BR/><BR/>
+        basic_string&amp; replace(iterator i1, iterator i2,
+        <BR/><BR/>
+        <u>Iter</u> j1, <u>Iter</u> j2);
+        <BR/><BR/>
+        basic_string&amp; replace(iterator, iterator,
+        initializer_list&lt;charT&gt;);
+        <BR/><BR/>
+        
+        <BR/><BR/>...
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        21.3.7 string operations:
+        <BR/><BR/>...
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator</u>
+        <u>Alloc&gt;</u>
+        <BR/><BR/>
+        struct constructible_with_allocator_suffix&lt;
+        <BR/><BR/>
+        basic_string&lt;charT, traits, <u>Alloc</u>&gt; &gt; :
+        true_type { };
+</suggestion>
+<notes>See UK 216</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="47"
+  uknum=""
+  type="ed"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+21.3
+</section>
+<para>
+</para>
+<description>
+        Typo. Missing &#8221;&gt;&#8221;
+        <BR/><BR/>
+        template &lt;class charT, class traits, Allocator Alloc
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits, Allocator Alloc&gt;
+</description>
+<suggestion>
+        Correct typo.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="48"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+21.3
+</section>
+<para>
+</para>
+<description>
+        char_traits does not use concept.
+        <BR/><BR/>For
+        example, create CharTraits concept and change as follows:
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class charT, <u>CharTraits</u> traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+        class Allocator = allocator&lt;charT&gt; &gt;
+        <BR/><BR/>class
+        basic_string {
+</description>
+<suggestion>
+        Add
+        a concept for char_traits.
+</suggestion>
+<notes>See UK 216</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="217"
+  uknum="340"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+21.3
+</section>
+<para>
+</para>
+<description>
+        basic_string refers to
+        constructible_with_allocator_suffix, which I thought was
+        removed?
+</description>
+<suggestion>
+        Remove the
+        lines: template &lt;class charT, class traits, class Alloc
+        struct constructible_with_allocator_suffix&lt;
+        basic_string&lt;charT, traits, Alloc&gt; &gt; : true_type {
+        };
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="218"
+  uknum="228"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+21.3.1
+</section>
+<para>
+3
+</para>
+<description>
+        The identity
+        "&amp;*(s.begin() + n) == &amp;*s.begin() + n" relies on
+        operator&amp; doing the "right thing", which (AFAICS) there
+        is no requirement for. See my comment under clauses
+        "23.2.1, 23.2.6" (p1 in both cases) - this is the same
+        issue, but I've created a separate comment for basic_string
+        because it is in a different chapter.
+</description>
+<suggestion>
+        See my recommendations for "23.2.1,
+        23.2.6".
+</suggestion>
+<notes>NAD, we think. basic_string elements have to be POD and PODs may not have 
+    overloaded operator&amp;. Need to check whether this is true in light of relaxed 
+    POD constraints.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="219"
+  uknum="342"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+21.3.6.6
+        [string.replace]
+</section>
+<para>
+11
+</para>
+<description>
+        Effects refers to "whose first begin() - i1
+        elements" However i1 is greater than begin()...
+</description>
+<suggestion>
+        Effects refers to "whose first i1 - begin()
+        elements"
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="220"
+  uknum="339"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+21.3.8.9
+</section>
+<para>
+</para>
+<description>
+        The
+        operator&lt;&lt; for basic_string takes the output stream
+        by r-value reference. This is different from the same
+        operator for error_code (19.4.2.6), bitset (20.2.6.3),
+        shared_ptr (20.7.13.2.8), complex (26.3.6) and sub_match
+        (28.4)
+</description>
+<suggestion>
+        Use the same reference type for the all the
+        library types. This should be the r-value reference. There
+        are other places in the standard where TR1, and new
+        classes, did not receive an 'R-value' update.
+</suggestion>
+<notes>We did it differently for basic_string because otherwise rvalue strreaming 
+    was producing confusing results with strings, but this difference will be 
+    fixed by N2831 if it's accepted.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="33"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.1.1
+[locale]
+</section>
+<para>
+3
+</para>
+<description>
+        ios_base::iostate err = 0;
+        <BR/><BR/>
+        <BR/><BR/>iostate is a bitmask type and
+        so could be an enumeration. Probably using
+        goodbit is the solution.
+</description>
+<suggestion>
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="49"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.1.3.2.2
+</section>
+<para>
+</para>
+<description>
+        codecvt does not use concept. For example, create
+        CodeConvert concept and change as follows.
+        <BR/><BR/>
+        template&lt;<u>CodeConvert</u> Codecvt, class Elem =
+        wchar_t&gt; class wstring_convert {
+</description>
+<suggestion>
+        Add
+        a concept for codecvt.
+</suggestion>
+<notes>to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="50"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.1.3.2.2
+</section>
+<para>
+</para>
+<description>
+        Add
+        custom allocator parameter to wstring_convert, since we
+        cannot allocate memory for strings from a custom allocator.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        template&lt;class Codecvt, class Elem = wchar_t&gt; class
+        wstring_convert {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef std::basic_string&lt;char&gt; byte_string;
+        <BR/><BR/>
+        typedef std::basic_string&lt;Elem&gt; wide_string;
+        <BR/><BR/>
+        
+        <BR/><BR/>should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class Codecvt, class Elem = wchar_t<u>,</u>
+        <BR/><BR/>
+        <u>Allocator WideAllocator = allocator&lt;Elem&gt;,</u>
+        <BR/><BR/>
+        <u>Allocator ByteAllocator = allocator&lt;char&gt;</u>&gt;
+        <BR/><BR/>
+        class wstring_convert {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef std::basic_string&lt;char,
+        <u>char_traits&lt;char&gt;, ByteAllocator</u>&gt;
+        byte_string;
+        <BR/><BR/>typedef
+        std::basic_string&lt;Elem, <u>char_traits&lt;Elem&gt;,
+        WideAllocator</u>&gt; wide_string;
+</suggestion>
+<notes>to be handled by PJ Plauger</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FI"
+  num="4"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.2.1.4.1
+        22.2.1.4.2
+</section>
+<para>
+</para>
+<description>
+        <tt>to_end and to_limit are both used. Only one is
+        needed.</tt>
+</description>
+<suggestion>
+        Change to_limit to to_end.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FI"
+  num="5"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.2.1.4.2
+</section>
+<para>
+#3
+</para>
+<description>
+        <tt>[ Note: As
+        a result of operations on state, it can return ok or
+        partial and set next == from and to_next != to. &#8212;end
+        note ]</tt>
+        
+        
+        <BR/><BR/><tt>"next"
+        should be "from_next."</tt>
+        <BR/><BR/><tt>Also, the
+        sentence applies to all the examples, including do_in and
+        do_out.</tt>
+        <BR/><BR/><tt>Reasoning: When reading one element of multibyte
+        source data such as UTF-8, it is possible that from_next is
+        incremented, to_next is unaltered, state is altered and
+        return value is partial.
+        When reading one element of wide character data, the output
+        can be several multibyte characters, so it is possible that
+        from_next is unaltered, to_next is advanced, state is
+        altered and return value is partial.</tt>
+</description>
+<suggestion>
+        <tt>[ Note: As a result of operations on state, do_in
+        and do_out can return</tt>
+        <tt>ok or partial and set from_next == from and/or to_next
+        != to. &#8212;end</tt>
+        <tt>note ]</tt>
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FI"
+  num="6"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.2.1.5
+        <BR/><BR/>See also
+22.2.1.4
+(1,2,3)
+</section>
+<para>
+</para>
+<description>
+        <tt>codecvt_byname is only specified to work with locale
+        names. There is no built-in means to find a codecvt with a
+        character set's name. A locale and a character set are not
+        the same. If the user has data which is encoded in a
+        certain character set and she wants to create a codecvt
+        which can convert from that character set to another one,
+        she must iterate through locales to find one, or use
+        external means (iconv, ICU's uconv). Specifying a locale
+        with the character set is not a suitable solution, since
+        there is no built-in mapping from character sets to
+        locales. It is only possible to inquire the character set
+        once the locale is known.</tt>
+</description>
+<suggestion>
+        <tt>There should be a built-in means to find a codecvt
+        with a pair of character set names.</tt>
+</suggestion>
+<notes>Martin Sebor interested in solving this problem (also POSIX group), but 
+    addressing it controversial because it's probably too late in the process 
+    for what looks like a new feature.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FI"
+  num="7"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.2.1.4
+</section>
+<para>
+1,2,3
+</para>
+<description>
+        The word
+        "codeset" is used, whereas the word "character set" is used
+        elsewhere in the text. The words are intended to convey the
+        same concept, so only one should be used (or always both
+        together).
+</description>
+<suggestion>
+        Change "codeset" to "character set."
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="51"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.2.5.1.1
+</section>
+<para>
+7<sup>th</sup> <font size="2"
+        style="font-size: 11pt">para, 1<sup>st</sup>
+        line</font>
+</para>
+<description>
+        A
+        parameter `end&#8217; should be `fmtend&#8217;.
+        get() function had two `end&#8217; parameters at N2321.
+        <BR/><BR/>
+        iter_type get (iter_type s, iter_type end, ios_base&amp; f,
+        ios_base::iostate&amp; err, tm* t, const char_type* fmt,
+        const char_type *end) const;
+        <BR/><BR/>The function
+        prototype of get() has been corrected at N2800, but a
+        Requires statement still refers `end&#8217; parameter.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        Requires: [fmt,end) shall be a valid range.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        Requires: [fmt,fmtend) shall be a valid range.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="52"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.2.5.1,
+        22.2.5.2,
+        22.2.6.1
+</section>
+<para>
+</para>
+<description>
+        InputIterator does not use concept.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        22.2.5.1
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class InputIterator =
+        istreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class time_get : public locale::facet, public time_base {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef InputIterator iter_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, <u>InputIterator InputIter</u> =
+        istreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class time_get : public locale::facet, public time_base {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef <u>InputIter</u> iter_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        22.2.5.2
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class InputIterator =
+        istreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class time_get_byname : public time_get&lt;charT,
+        InputIterator&gt; {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef time_base::dateorder dateorder;
+        <BR/><BR/>
+        typedef InputIterator iter_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, <u>InputIterator InputIter</u> =
+        istreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class time_get_byname : public time_get&lt;charT,
+        InputIter&gt; {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef time_base::dateorder dateorder;
+        <BR/><BR/>
+        typedef <u>InputIter</u> iter_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        22.2.6.1
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT,
+        <BR/><BR/>
+        class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class money_get : public locale::facet {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef InputIterator iter_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT,
+        <BR/><BR/>
+        <u>InputIterator InputIter</u> =
+        istreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class money_get : public locale::facet {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef <u>InputIter</u> iter_type;
+</suggestion>
+<notes>to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="53"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+22.2.5.3 ,
+        22.2.5.4
+</section>
+<para>
+</para>
+<description>
+        OutputIterator does not use concept.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        22.2.5.3
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class OutputIterator =
+        ostreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class time_put : public locale::facet {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef OutputIterator iter_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        <span lang="zxx">&#12288;</span>should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, <u>OutputIterator OutputIter</u>
+        = ostreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class time_put : public locale::facet {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef <u>OutputIter</u> iter_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        22.2.5.4
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class OutputIterator =
+        ostreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class time_put_byname : public time_put&lt;charT,
+        OutputIterator&gt;
+        <BR/><BR/>{
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef OutputIterator iter_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, <u>OutputIterator OutputIter</u>
+        = ostreambuf_iterator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class time_put_byname : public time_put&lt;charT,
+        OutputIter&gt;
+        <BR/><BR/>{
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>typedef <u>OutputIter</u>
+        iter_type;
+</suggestion>
+<notes>to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="54"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23
+</section>
+<para>
+        2<sup>nd</sup> <font size="2" style=
+        "font-size: 11pt">para, Table 79</font>
+</para>
+<description>
+        There is not &lt;forward_list&gt; in Table 79.
+</description>
+<suggestion>
+        Add
+        &lt;forward_list&gt; between &lt;deque&gt; and
+        &lt;list&gt;.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="221"
+  uknum="287"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23
+</section>
+<para>
+Table 79
+</para>
+<description>
+        The table is missing the new
+        &lt;forward_list&gt; header.
+</description>
+<suggestion>
+        Add
+        &lt;forward_list&gt; to the table for sequence containers.
+        Alternative (technical) solution might be to merge
+        &lt;forward_list&gt; into &lt;list&gt;.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="222"
+  uknum="295"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23
+</section>
+<para>
+</para>
+<description>
+        It is not clear
+        what purpose the Requirement tables serve in the Containers
+        clause. Are they the definition of a library Container? Or
+        simply a conventient shorthand to factor common semantics
+        into a single place, simplifying the description of each
+        subsequent container? This becomes an issue for
+        'containers' like array, which does not meet the
+        default-construct-to-empty requirement, or forward_list
+        which does not support the size operation. Are these
+        components no longer containers? Does that mean the
+        remaining requirements don't apply? Or are these
+        contradictions that need fixing, despite being a clear
+        design decision?
+</description>
+<suggestion>
+        Clarify all the tables in 23.1 are there as
+        a convenience for documentation, rather than a strict set
+        of requirements. Containers should be allowed to relax
+        specific requirements if they call attention to them in
+        their documentation. The introductory text for array should
+        be expanded to mention a default constructed array is not
+        empty, and forward_list introduction should mention it does
+        not provide the required size operation as it cannot be
+        implemented efficiently.
+</suggestion>
+<notes>Agree in principle. We suggest proposed wording:</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="55"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.1
+</section>
+<para>
+        3<sup>rd</sup> <font size="2" style=
+        "font-size: 11pt">para, 4<sup>th</sup> line</font>
+</para>
+<description>
+        It
+        seems that &#8220;the MinimalAllocator concep&#8221; is the
+        typo of &#8220;the MinimalAllocator concept&#8221;.
+</description>
+<suggestion>
+        Change to &#8230; models the MinimalAllocator
+        concep<font color="#339966">t</font><font size="2" style=
+        "font-size: 11pt">.</font>
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="223"
+  uknum="285"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date="2009-03-06"
+  extdoc="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf"
+>
+<section>
+23.1.1
+</section>
+<para>
+3
+</para>
+<description>
+        The library does
+        not define the MinimalAllocator or ScopedAllocator
+        concepts, these were part of an earlier Allocators proposal
+        that was rejected.
+</description>
+<suggestion>
+        Remove the references to MinimalAllocator
+        and ScopedAllocator, or add definitions for these concepts
+        to clause 20.7.
+</suggestion>
+<notes>Agree. Proposed wording will be presented 
+    in N2829 or D2840.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="224"
+  uknum="298"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="modified"
+  date="2009-03-06"
+  extdoc="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf"
+>
+<section>
+23.1.1
+</section>
+<para>
+8
+</para>
+<description>
+        This paragraph implicitly requires all
+        containers in clause 23 to support allocators, which
+        std::array does not.
+</description>
+<suggestion>
+        Add an 'unless
+        otherwise specified' rider somewhere in p8, or move the
+        whole array container from clause 23 [containers] to clause
+        20 [utilies] to accompany bitset, pair and tuple.
+</suggestion>
+<notes>Agree except with moving array to clause 
+    20. Proposed wording will be presented in D2840.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="225"
+  uknum="299"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.1
+</section>
+<para>
+Table 81
+</para>
+<description>
+        Inconsistent
+        words used to say the same thing. Table 80 describes
+        iterator/const_iterator typedef as returning an "iterator
+        type whose value type is T". Table 81 expresses the same
+        idea as an "iterator type pointing to T". Express identical
+        ideas with the same words to avoid accidentally introducing
+        subtlety and confusion
+</description>
+<suggestion>
+        Change return types for
+        X::(const)_reverse_iterator to say "iterator type whose
+        value type is (const) T".
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="226"
+  uknum="336"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.1
+</section>
+<para>
+10
+</para>
+<description>
+        &lt;array&gt;
+        must be added to this list. In particular it doesn't
+        satisfy: - no swap() function invalidates any references,
+        pointers, or iterators referring to the elements of the
+        containers being swapped. and probably doesn't satisfy:
+        &#8212; no swap() function throws an exception.
+</description>
+<suggestion>
+        If &lt;array&gt; remains a container, this
+        will have to also reference array, which will then have to
+        say which of these points it satisfies.
+</suggestion>
+<notes>Agree. The proposed resolution is 
+    incomplete. Further work required.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="227"
+  uknum="146"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.1
+</section>
+<para>
+Table 80
+</para>
+<description>
+        The post-condition for a = rv uses the word
+        &#8220;construction&#8221; when it means
+        &#8220;assignment&#8221;
+</description>
+<suggestion>
+        Replace the word
+        &#8220;construction&#8221; with the word
+        &#8220;assignment&#8221;
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="228"
+  uknum="283"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.1
+</section>
+<para>
+3
+</para>
+<description>
+        Line 4 contains
+        a spelling mistake in the fragment "MinimalAllocator
+        concep."
+</description>
+<suggestion>
+        Replace "concep" with "concept"
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="229"
+  uknum="284"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.1
+</section>
+<para>
+3
+</para>
+<description>
+        The fragment "A container may directly call
+        constructors" is not technically correct as constructors
+        are not callable.
+</description>
+<suggestion>
+        Replace "A
+        container may directly call constructors and destructors
+        for its stored objects" with something similar to "A
+        container may directly construct its stored objects and
+        call destructors for its stored objects"
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="230"
+  uknum="147"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+23.1.2
+</section>
+<para>
+1
+</para>
+<description>
+        &#8220;implementations shall consider the following
+        functions to be const&#8221; - what does this mean? I don't
+        understand what it means by implementations considering the
+        functions to be const &#8211; surely they are either
+        declared const or not?
+</description>
+<suggestion>
+        Clarify what is meant and what requirements
+        an implementation must satisfy.
+</suggestion>
+<notes>After considerable discussion and 
+    consideration, we do not feel this is a defect given the reference to [res.on.data.races].</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="56"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.3
+</section>
+<para>
+12<sup>th</sup> <font size="2"
+        style="font-size: 11pt">para, Table 84</font>
+</para>
+<description>
+        `array&#8217; is unstated in Table 84 - Optional sequence
+        container operations.
+</description>
+<suggestion>
+        Add
+        `array&#8217; to Container field for the following
+        Expression.
+        <BR/><BR/>a.front()
+        <BR/><BR/>a.back()
+        <BR/><BR/>a[n]
+        <BR/><BR/>a.at(n)
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="231"
+  uknum="300"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.3
+</section>
+<para>
+9-11
+</para>
+<description>
+        These paragraphs
+        are redundant now that Concepts define what it means to be
+        an Iterator and guide overload resolution accordingly.
+</description>
+<suggestion>
+        Strike 23.1.3p9-11. Make sure
+        std::basic_string has constraints similar to std::vector to
+        meet this old guarantee.
+</suggestion>
+<notes>Agree with issue and change to [sequence.reqmts]. The changes required to 
+    [strings] will be part of the general concept support for that clause.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="232"
+  uknum="301"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+23.1.3
+</section>
+<para>
+Table 84
+</para>
+<description>
+        match_results
+        may follow the requirements but is not listed a general
+        purpose library container.
+</description>
+<suggestion>
+        Remove reference to match_results against
+        a[n] operation
+</suggestion>
+<notes>Agree. <code>operator[]</code> is defined elsewhere.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="233"
+  uknum="302"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+23.1.3
+</section>
+<para>
+Table 84
+</para>
+<description>
+        Add references to the new containers.
+</description>
+<suggestion>
+        Add reference to
+        array to the rows for: a.front(), a. back(), a[n] a.at(n).
+        Add reference to forward_list to the rows for: a.front(),
+        a.emplace_front(args), a.push_front(t), a.push_front(rv),
+        a.pop_front(). Add reference to basic_string to the row
+        for: a.at(n).
+</suggestion>
+<notes>Agree.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="234"
+  uknum="346"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+23.1.3
+</section>
+<para>
+Table 84
+</para>
+<description>
+        Ther reference
+        to iterator in semantics for back should also allow for
+        const_iterator when called on a const-qualified container.
+        This would be ugly to specify in the 03 standard, but is
+        quite easy with the addition of auto in this new standard.
+</description>
+<suggestion>
+        Replace iterator with auto in semantics for
+        back: { auto tmp = a.end(); --tmp; return *tmp; }
+</suggestion>
+<notes>Agree.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="235"
+  uknum="148"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.3
+</section>
+<para>
+1
+</para>
+<description>
+        &#8220;The library provides three basic
+        kinds of sequence containers: vector, list, and
+        deque&#8221; - text appears to be out of date re addition
+        of array and forward_list
+</description>
+<suggestion>
+        Change the text
+        to read: &#8220;The library provides five basic kinds of
+        sequence containers: array, deque, forward_list, list and
+        vector&#8221;.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="236"
+  uknum="150"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.3
+</section>
+<para>
+2
+</para>
+<description>
+        [ I've moved (1)
+        into a separate comment because I believe it is editorial
+        in the simple sense, whereas (2) and (3) are not so
+        straight forward ] (2) &#8220;vector is the type of
+        sequence container that should be used by default&#8221; --
+        As I understand it vector was considered first port of call
+        because the things it has in common with the native array
+        make programmers (especially those new to the container
+        library) feel like they are on familiar territory. However,
+        we now have the array container, so I think this should be
+        recommended as the first port of call. (3) This paragraph
+        is actually giving guidance on the use of the containers
+        and should not be normative text
+</description>
+<suggestion>
+        Remove this paragraph
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="237"
+  uknum="334"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.3
+</section>
+<para>
+2
+</para>
+<description>
+        vector, list, and deque offer the
+        programmer different complexity trade-offs and should be
+        used accordingly - this ignores array and forward_list
+</description>
+<suggestion>
+        Modify the text
+        to read: "array, deque, forward_list, list and vector offer
+        the programmer different complexity trade-offs and should
+        be used accordingly"
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="238"
+  uknum="347"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="modified"
+  date=""
+  extdoc=""
+>
+<section>
+23.1.4
+</section>
+<para>
+6
+</para>
+<description>
+        Leaving it
+        unspecified whether or not iterator and const_iterator are
+        the same type is dangerous, as user code may or may not
+        violate the One Definition Rule by providing overloads for
+        both types. It is probably too late to specify a single
+        behaviour, but implementors should document what to expect.
+        Observing that problems can be avoided by users restricting
+        themselves to using const_iterator, add a note to that
+        effect.
+</description>
+<suggestion>
+        Change 'unspecified' to 'implementation
+        defined'. Add "[Note: As itererator and const_iterator have
+        identical semantics in this case, and iterator is
+        convertible to const_iterator, users can avoid violating
+        the One Definition Rule by always using const_iterator in
+        their function parameter lists -- end note]
+</suggestion>
+<notes>Agree with issue. Agree with adding the note but not with changing the 
+    normative text. We believe the note provides sufficient guidance.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="239"
+  uknum="447"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.4
+</section>
+<para>
+85
+</para>
+<description>
+        It is not possible to take a move-only key
+        out of an unordered container, such as (multi)set or
+        (multi)map, or the new hashed containers.
+</description>
+<suggestion>
+        Add below
+        a.erase(q), a.extract(q), with the following notation:
+        a.extract(q), Return type pair&lt;key, iterator&gt;
+        Extracts the element pointed to by q and erases it from the
+        set. Returns a pair containing the value pointed to by q
+        and an iterator pointing to the element immediately
+        following q prior to the element being erased. If no such
+        element exists,returns a.end().
+</suggestion>
+<notes>We look forward to a paper on this topic. We recommend no action until a 
+    paper is available. The paper would need to address exception safety.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="240"
+  uknum="427"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.6.1
+</section>
+<para>
+12
+</para>
+<description>
+        The axiom
+        EmplacePushEquivalence should be asserting the stronger
+        contract that emplace and insert return the same iterator
+        value, not just iterators that dereference to the same
+        value. This is a similar statement that is easier to
+        express and should be equivalent - the idea that insert and
+        emplace might return iterator values that do not compare
+        equal but point to the same element should fail somewhere
+        in the iterator concepts. Also, this axiom should be
+        renamed to reflect its connection with insert, rather than
+        push_front/push_back,
+</description>
+<suggestion>
+        Remove the * to deference the returned
+        iterator either side of the == in the
+        EmplacePushEquivalence axiom, rename the axiom
+        EmplacementInsertionEquivalence : requires
+        InsertionContainer&lt;C&gt; &amp;&amp;
+        Constructible&lt;value_type, Args...&gt; axiom
+        EmplacementInsertionEquivalence(C c, const_iterator
+        position, Args... args) { emplace(c, position, args...) ==
+        insert(c, position, value_type(args...)); }
+</suggestion>
+<notes>We look forward to a paper on this topic. We recommend no action until a 
+    paper is available. We suspect that there are other similar issues in this 
+    sub-clause (9, 10).</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="57"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.1.6.3
+</section>
+<para>
+        1<sup>st</sup> <font size="2" style=
+        "font-size: 11pt">para, 4<sup>th</sup> line</font>
+</para>
+<description>
+        Typo, duplicated "to"
+        <BR/><BR/>
+        "<u>to to</u> model insertion container concepts."
+</description>
+<suggestion>
+        Remove one.
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="241"
+  uknum="286"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.2.1
+</section>
+<para>
+</para>
+<description>
+        std::array does
+        not have an allocator, so need to document an exception to
+        the requirements of 23.1.1p3
+</description>
+<suggestion>
+        add exception to 23.1.1p3
+</suggestion>
+<notes>Duplicate of UK 224.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="242"
+  uknum="355"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.2.1
+</section>
+<para>
+3
+</para>
+<description>
+        std:: qualification no longer needed for
+        reverse_iterator.
+</description>
+<suggestion>
+        remove std::
+        qualification from std::reverse_iterator&lt;iterator&gt;
+        and std::reverse_iterator&lt;const_iterator&gt;
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="243"
+  uknum="337"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+23.2.1
+</section>
+<para>
+3
+</para>
+<description>
+        Most containers,
+        and types in general have 3 swaps: swap(T&amp;, T&amp;)
+        swap(T&amp;&amp;, T&amp;) swap(T&amp;, T&amp;&amp;) But
+        array only has swap(T&amp;, T&amp;).
+</description>
+<suggestion>
+        add the other two swaps.
+</suggestion>
+<notes>Agree. The proposed wording is forthcoming from Martin. We feel that these 
+    overloads of swap are more important for array than other containers because 
+    swap is not O(1) for array.<BR/><BR/>
+    <strong>HOWEVER</strong> in a later session discussing D2844, it was decided 
+    to remove all the r-value-ref <code>swap</code> overloads from containers. 
+    Therefore adding them to <code>array</code> has no benefit. So the final 
+    disposition is NAD.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="244"
+  uknum="153"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.2.1,
+23.2.6
+</section>
+<para>
+1
+</para>
+<description>
+        The validity of
+        the expression &amp;a[n] == &amp;a[0] + n is contingent on
+        operator&amp; doing the &#8220;right thing&#8221; (as
+        captured by the CopyConstructible requirements in table 30
+        in C++2003). However this constraint has been lost in the
+        Concepts of C++0x. This applies to vector and array (it
+        actually applies to string also, but that's a different
+        chapter, so I'll file a separate comment there and
+        cross-reference).
+</description>
+<suggestion>
+        Define a ContiguousStrorage and apply it to
+        vector,array and string. The Concept (supplied by Alisdair
+        M) looks like this: Concept&lt; typename C &gt;
+        ContiguousStrorage { requires Container&lt;C&gt;; typename
+        value_type = C::value_type; value_type * data( C ); axiom
+        Contiguous { C c; true = equal_ranges( data( c), data(c) +
+        size(c), begin(c)); } };
+</suggestion>
+<notes>Agree with the issue but not the details of the proposed solution. Walter to 
+    provide wording for the new concept.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="245"
+  uknum="358"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+23.2.3
+</section>
+<para>
+2
+</para>
+<description>
+        The predicate types used in special member
+        function of forward_list should be CopyConstructible, as
+        per the algorithms of the same name. Note: an alternate
+        solution would be to require these callable concepts to be
+        CopyConstructible in clause 20, which would simplify the
+        library specification in general. See earlier comment for
+        details, that would render this one redundant.
+</description>
+<suggestion>
+        Add
+        CopyConstructible requirement to the following signatures:
+        template &lt;Predicate&lt;auto, T&gt; Pred&gt; requires
+        CopyConstructible&lt;Pred&gt; void remove_if(Pred pred);
+        template &lt;EquivalenceRelation&lt;auto, T&gt;
+        BinaryPredicate&gt; requires
+        CopyConstructible&lt;BinaryPredicate&gt; void
+        unique(BinaryPredicate binary_pred); template
+        &lt;StrictWeakOrder&lt;auto, T&gt; Compare&gt; requires
+        CopyConstructible&lt;Compare&gt; void
+        merge(forward_list&lt;T,Alloc&gt;&amp;&amp; x, Compare
+        comp); template &lt;StrictWeakOrder&lt;auto, T&gt;
+        Compare&gt; requires CopyConstructible&lt;Compare&gt; void
+        sort(Compare comp);
+</suggestion>
+<notes>UK245 with additional comments on UK200 in clause 20: After further 
+    discussion of UK200, we do not think adding constraints to predicates is a 
+    good idea. Straw poll on 
+    UK245: status quo, 5 pro - 0 con; add copy-constructible, 1 pro - 3 con; no 
+    consensus for moving away from the status quo.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="58"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.2.3.2
+</section>
+<para>
+        1<sup>st</sup> <font size="2" style="font-size: 11pt">line
+        before 1<sup>st</sup> para</font>
+</para>
+<description>
+        Unnecessary "{" exists before a word iterator like
+        "{iterator before_begin()".
+</description>
+<suggestion>
+        Remove "{"
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="59"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.2.4.4
+</section>
+<para>
+</para>
+<description>
+        Types of the third and forth parameter of splice() are
+        iterator at 23.2.4.4, though types of them are
+        const_iterator at 23.2.4. (They are both const_iterator on
+        N2350)
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        void splice(const_iterator position,
+        list&lt;T,Allocator&gt;&amp;&amp; x, iterator i);
+        <BR/><BR/>
+        void splice(const_iterator position,
+        list&lt;T,Allocator&gt;&amp;&amp; x,
+        <BR/><BR/>
+        iterator first, iterator last);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        void splice(const_iterator position,
+        list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
+        <BR/><BR/>
+        void splice(const_iterator position,
+        list&lt;T,Allocator&gt;&amp;&amp; x,
+        <BR/><BR/>const_iterator
+        first, const_iterator last);
+</suggestion>
+<notes>[Being reviewed by Editor]</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="83"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.2.6.2
+</section>
+<para>
+7
+</para>
+<description>
+        "shrink_to_fint" should be "shrink_to_fit".
+</description>
+<suggestion>
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="246"
+  uknum="350"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+23.3.2.2
+</section>
+<para>
+</para>
+<description>
+        The content of
+        this sub-clause is purely trying to describe in words the
+        effect of the requires clauses on these operations, now
+        that we have Concepts. As such, the desctiption is more
+        confusing than the signature itself. The semantic for these
+        functions is adequately covered in the requirements tables
+        in 23.1.4.
+</description>
+<suggestion>
+        Strike 23.3.2.2 entirely. (but do NOT
+        strike these signatures from the class template
+        definition!)
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="247"
+  uknum="46"
+  type="Ge"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.1
+</section>
+<para>
+</para>
+<description>
+        Iterator
+        concepts are not extensive enough to merit a whole new
+        header, and should be merged into &lt;concpts&gt;. This is
+        particularly important for supporting the new for loop
+        syntax which requires access to the Range concept. The
+        required header to enable this syntax shoud have a simple
+        name, like &lt;concepts&gt;, rather than something awkward
+        to type like &lt;iterator_concepts&gt;.
+</description>
+<suggestion>
+        Move the concepts of
+        &lt;iterator_concepts&gt; into the &lt;concepts&gt; header.
+        We take no position on moving the text from Clause 24 to
+        Clause 20 though.
+</suggestion>
+<notes>NAD. We believe the separate header to have value.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="248"
+  uknum="47"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1
+</section>
+<para>
+6
+</para>
+<description>
+        The text "so for
+        any iterator type there is an iterator value that points
+        past the last element of a corresponding container" is
+        slightly misleading. Iterators can refer into generalised
+        ranges and sequences, not just containers. A broader term
+        than 'container' should be used.
+</description>
+<suggestion>
+        Replace the reference to container with a
+        more appropriate concept
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="250"
+  uknum="50"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.1
+</section>
+<para>
+</para>
+<description>
+        A default implementation should be supplied
+        for the post-increment operator to simplify implementation
+        of iterators by users.
+</description>
+<suggestion>
+        Copy the Effects clause into the concept
+        description as the default implementation. Assumes a
+        default value for postincrement_result
+</suggestion>
+<notes>Howard will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="251"
+  uknum="51"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.1
+</section>
+<para>
+3
+</para>
+<description>
+        The
+        post-increment operator is dangerous for a general
+        InputIterator. The multi-pass guarantees that make it
+        meaningful are defined as part of the ForwardIterator
+        refinement. Any change will affect only constrained
+        templates that have not yet been written, so should not
+        break existing user iterators which remain free to add
+        these operations. This change will also affect the
+        generalised OutputIterator, although there is no percieved
+        need for the post-increment operator in this case either.
+</description>
+<suggestion>
+        Move declaration of postincrement operator
+        and postincrement_result type from Interator concept to the
+        ForwardIterator concept
+</suggestion>
+<notes>Alisdair will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="252"
+  uknum="53"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.2
+</section>
+<para>
+3
+</para>
+<description>
+        istream_iterator is not a class, but a
+        class template
+</description>
+<suggestion>
+        Change 'class' to 'class template' in the
+        note.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="253"
+  uknum="54"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.3
+</section>
+<para>
+1
+</para>
+<description>
+        First sentance
+        does not make gramatical sense, Seems to be missing the
+        words 'if it' by comparison with similar sentance in other
+        subsections
+</description>
+<suggestion>
+        Add the words 'if it' : "X satisfies the
+        requirements of an output iterator IF IT meets the
+        syntactic and semantic requirements"
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="254"
+  uknum="55"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.3
+</section>
+<para>
+5
+</para>
+<description>
+        This
+        postcondition for pre-increment operator should be written
+        as an axiom
+</description>
+<suggestion>
+        Move the postcondition into the concept
+        definition as an axiom
+</suggestion>
+<notes>deferred until we know whether we have axioms.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="255"
+  uknum="56"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.4
+</section>
+<para>
+4
+</para>
+<description>
+        This
+        postcondition for pre-increment operator should be written
+        as an axiom
+</description>
+<suggestion>
+        Move the postcondition into the concept
+        definition as an axiom
+</suggestion>
+<notes>deferred until we know whether we have axioms.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="256"
+  uknum="57"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.5
+</section>
+<para>
+3, 4, 5
+</para>
+<description>
+        The relationship between pre- and post-
+        decrement should be expressed as an axiom.
+</description>
+<suggestion>
+        Move the text
+        specification of pre/post-conditions and behaviour into an
+        axiom within the BidirectionalIterator concept
+</suggestion>
+<notes>deferred until we know whether we have axioms.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="257"
+  uknum="58"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.1.5
+</section>
+<para>
+</para>
+<description>
+        There is a
+        reasonable default for postdecrement_result type, which is
+        X. X is required to be regular, therefore CopyConstructible
+        and a valid ResultType. Together with the next comment this
+        simplifies user defined iterator implentations
+</description>
+<suggestion>
+        Add the default : typename
+        postincrement_result = X;
+</suggestion>
+<notes>NAD, postdecrement_result is deduced.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="258"
+  uknum="50"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.5
+</section>
+<para>
+</para>
+<description>
+        A default
+        implementation should be supplied for the post-decrement
+        operator to simplify implementation of iterators by users.
+</description>
+<suggestion>
+        Copy the Effects clause into the concept
+        description as the default implementation. Assumes a
+        default value for postincrement_result
+</suggestion>
+<notes>Howard will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="259"
+  uknum="60"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.1.5
+</section>
+<para>
+</para>
+<description>
+        postdecrement_result is effectively returning a copy of the
+        original iterator value, so should have similar
+        constraints, rather than just HasDereference. If Concepts
+        do not support this circularity of definition suggest that
+        concepts feature may want a little more work
+</description>
+<suggestion>
+        Add the requirement: requires Iterator&lt;
+        postdecrement_result &gt;;
+</suggestion>
+<notes>NAD unless Alisdair comes back with more motivation.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="260"
+  uknum="61"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.5
+</section>
+<para>
+6
+</para>
+<description>
+        The effects clause for post-decrement
+        iterator should be available as an axiom and a default
+        implementation, where the compiler can make better use of
+        it.
+</description>
+<suggestion>
+        Move the Effects
+        clause into the BidirectionalIterator concept definition as
+        an axiom, and as the default implementation for the
+        operation.
+</suggestion>
+<notes>deferred for axiom decision.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="249"
+  uknum="64"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+2
+</para>
+<description>
+        The semantic for
+        operator+= should also be provided as a default
+        implementation to simplify implementation of user-defined
+        iterators
+</description>
+<suggestion>
+        Copy the text from the effects clause into
+        the RandomAccessIterator concept as the default
+        implementaiton.
+</suggestion>
+<notes>NAD, violates complexity requirements.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="261"
+  uknum="62"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+</para>
+<description>
+        To simplify user
+        defined random access iterator types, the
+        subscript_reference type should default to reference
+</description>
+<suggestion>
+        typename subscript_reference = reference;
+</suggestion>
+<notes>
+NAD, subscript reference isn't used.<BR/><BR/>
+In c++std-lib-23104, Daniel Kr&#252;gler commented, &#8220;this
+[proposed change] would disable "auto-deduction" of the return
+type of any operator[] as described by
+[concept.map.assoc]/4+5.&#8221;
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="262"
+  uknum="65"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+3, 4
+</para>
+<description>
+        Effects and post-conditions for operator+
+        are more useful if expressed as axioms, and supplied as
+        default implementations.
+</description>
+<suggestion>
+        Move the effects
+        and Postcondition definitions into the RandomAccessIterator
+        concept and copy the code in the specification as the
+        default implementation of these operations.
+</suggestion>
+<notes>default implementation already in Standard; axiom part 
+deferred.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="263"
+  uknum="66"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+5
+</para>
+<description>
+        This requirement on operator-= would be
+        better expressed as a default implementation in the
+        concept, with a matching axiom
+</description>
+<suggestion>
+        Move the
+        specification for operator-= from the returns clause into
+        an axiom and default implementation within the
+        RandomAccessIterator concept
+</suggestion>
+<notes>Alisdair will open an issue, axiom part deferred.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="264"
+  uknum="67"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+6
+</para>
+<description>
+        Effects clauses are better expressed as
+        axioms where possible.
+</description>
+<suggestion>
+        Move code in
+        operator- effects clause into RandomAccessIterator concept
+        as both a default implementation and an axiom
+</suggestion>
+<notes>deferred/axiom.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="265"
+  uknum="68"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+8
+</para>
+<description>
+        This effects
+        clause is nonesense. It looks more like an axiom stating
+        equivalence, and certainly an effects clause cannot change
+        the state of two arguments passed by const reference
+</description>
+<suggestion>
+        Strike the Effects clause
+</suggestion>
+<notes>Doug will open issueÂ…strike effect, returns n.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="266"
+  uknum="69"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+9
+</para>
+<description>
+        This sentance should be provided as a
+        default definition, along with a matching axiom
+</description>
+<suggestion>
+        Move the Returns
+        clause into the spefication for RandomAccessIterator
+        operator- as a default implementation. Move the Effects
+        clause as the matching axiom.
+</suggestion>
+<notes>default definition is not implementable; axiom part 
+deferred.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="267"
+  uknum="70"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+24.1.6
+</para>
+<description>
+        The code in the
+        Requires clause for RandomAccessIterator operator[] would
+        be better expressed as an axiom.
+</description>
+<suggestion>
+        Rewrite the Requires clause as an axiom in
+        the RandomAccessIterator concept
+</suggestion>
+<notes>deferred/axiom.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="268"
+  uknum="71"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.1.6
+</section>
+<para>
+12
+</para>
+<description>
+        This note is
+        potentialy confusing as __far enters the syntax as a clear
+        language extension, but the note treats it as a regular
+        part of the grammar. It might be better expressed using
+        attributes in the current wording.
+</description>
+<suggestion>
+        Clean up the note to either avoid using
+        language extension, or spell out this is a constraint to
+        support extensions.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="60"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.1.8
+</section>
+<para>
+1<sup>st</sup> <font size="2"
+        style="font-size: 11pt">para</font>
+</para>
+<description>
+        Capability of an iterator is too much restricted by
+        concept.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        Concept of std::Range is defined as:
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        concept Range&lt;typename T&gt; {
+        <BR/><BR/>
+        InputIterator iterator;
+        <BR/><BR/>
+        iterator begin(T&amp;);
+        <BR/><BR/>
+        iterator end(T&amp;);
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>So
+        the following code generates an error.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;std::Range Rng&gt;
+        <BR/><BR/>
+        void sort(Rng&amp; r)
+        <BR/><BR/>{
+        <BR/><BR/>
+        // error! Rng::iterator does not satisfy requirements of a
+        random
+        <BR/><BR/>
+        // access iterator.
+        <BR/><BR/>
+        std::sort(begin(r), end(r));
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        std::vector&lt;int&gt; v; // vector::iterator is a random
+        access iterator.
+        <BR/><BR/>
+        sort(v);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        This is because the concept of an iterator of std::Range is
+        InputIterator. For this reason, a random access iterator
+        loses its capability when passed to a std::Range parameter.
+        <BR/><BR/>
+        
+        <BR/><BR/>To
+        be able to work the above code, we need to write as
+        follows:
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;std::Range T&gt;
+        <BR/><BR/>
+        requires std::RandomAccessIterator&lt;T::iterator&gt;
+        &amp;&amp;
+        <BR/><BR/>
+        std::ShuffleIterator&lt;T::iterator&gt; &amp;&amp;
+        <BR/><BR/>
+        std::LessThanComparable&lt;T::iterator::value_type&gt;
+        <BR/><BR/>
+        void sort(T&amp; r)
+        <BR/><BR/>{
+        <BR/><BR/>
+        sort(begin(r), end(r));
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        std::vector&lt;int&gt; v;
+        <BR/><BR/>
+        sort(v);
+        <BR/><BR/>
+        
+        <BR/><BR/>It
+        needs quiet a few amount of codes like this only to recover
+        random access capability from InputIterator concept.
+        <BR/><BR/>
+        
+        <BR/><BR/>We
+        can write the following valid code with Boost.Range, which
+        is implemented with using C++03 SFINAE.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class Range&gt;
+        <BR/><BR/>
+        void sort(Range&amp; r)
+        <BR/><BR/>{
+        <BR/><BR/>
+        std::sort(boost::begin(r), boost::end(r));
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        std::vector&lt;int&gt; v;
+        <BR/><BR/>
+        sort(v); // OK
+        <BR/><BR/>
+        
+        <BR/><BR/>One of the
+        motivation to introduce concepts are supporting template
+        programming techniques by language directly to eliminate
+        hacky techniques such as tag-dispatch, SFINAE and Type
+        Traints. But SFINAE will be kept using because it needs
+        quite a few amount of codes without using SFAINAE.
+</description>
+<suggestion>
+        Add
+        InputRange, OutputRange, ForwardRange, BidirectionalRange
+        and RandomAccessRange.
+</suggestion>
+<notes>NAD, beyond the scope of the Standard because we are not 
+supplying range-based algorithms.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="269"
+  uknum="16"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.3
+</section>
+<para>
+3
+</para>
+<description>
+        'decrements for
+        negative n' seems to imply a negative number of decrement
+        operations, which is odd.
+</description>
+<suggestion>
+        Need simple, clearer wording
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="270"
+  uknum="17"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.3
+</section>
+<para>
+4
+</para>
+<description>
+        The reachability
+        constraint in p5 means that a negavite result, implying
+        decrements operations in p4, is not possible
+</description>
+<suggestion>
+        Split the two overloads into separate
+        descriptions, where reachability is permitted to be in
+        either direction for RandomAccessIterator
+</suggestion>
+<notes>Howard will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="271"
+  uknum="145"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.3
+</section>
+<para>
+6,7
+</para>
+<description>
+        next/prev return
+        an incremented iterator without changing the value of the
+        original iterator. However, even this may invalidate an
+        InputIterator. A ForwardIterator is required to guarantee
+        the 'multipass' property.
+</description>
+<suggestion>
+        Replace InputIterator constraint with
+        FOrwardIterator in next and prev function templates.
+</suggestion>
+<notes>Alisdair will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="272"
+  uknum="159"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.4
+</section>
+<para>
+</para>
+<description>
+        reverse_iterator
+        and move_iterator use different formulations for their
+        comparison operations. move_iterator merely requires the
+        minimal set of operations, &lt; and ==, from its underlying
+        iterator and synthesizes all oprations from these two.
+        reverse_iterator relies on the undelying iterator to
+        support all comparision operations directly. In practice,
+        move_iterator can only be implemented this way as it must
+        support iterator types that are merely InputIterators, and
+        so SemiRegular and not Regular. However, reserse_iterator
+        has an existing specification and any change of semantic
+        could change behaviour of conforming programs today -
+        although an iterator that yields different results for (a
+        &gt; b) than (b &lt; a) may fall foul of some semantic
+        consistency requirements, even if the syntax is met.
+</description>
+<suggestion>
+        Rephrase the reverse_iterator comparison
+        operations using only operators &lt; and ==, as per the
+        move_iterator specification.
+</suggestion>
+<notes>NAD, no consensus.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="274"
+  uknum="119"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.4, 24.5
+</section>
+<para>
+</para>
+<description>
+        The subclauses
+        for standard iterator adaptors could be better organised.
+        There are essentially 3 kinds of iterator wrappers
+        provided, stream iterators adapt streams and get their own
+        subsection. insert iterators adapt containers, and get
+        their own subsection but it is inserted into the middle of
+        24.4 Predifined iterators. reverse_iterator and
+        move_iterator adpat other iterators, but their presentation
+        is split by insert iterators
+</description>
+<suggestion>
+        Promote 24.4.2 [insert.iterators] up one
+        level to 24.6. Emphasize that insert iterators adapt
+        containers Retarget 24.4 [predef.iterators] as iterator
+        adapters for iterator templates that wrap other iterators.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="275"
+  uknum="18"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.4.1.1
+</section>
+<para>
+</para>
+<description>
+        The constructor
+        template taking a single Iterator argument will be selected
+        for Copy Initialization instead of the non-template
+        constructor taking a single Iterator argument selected by
+        Direct Initialization.
+</description>
+<suggestion>
+        The reverse_iterator template constructor
+        taking a single Iterator argument should be explicit.
+</suggestion>
+<notes>NAD, withdrawn by submitter.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="276"
+  uknum="19"
+  type="Ed"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.4.1.1
+</section>
+<para>
+</para>
+<description>
+        It is odd to
+        have a mix of declaration stlyes for operator+ overloads.
+        Prefer if either all are member functions, or all are
+        'free' functions.
+</description>
+<suggestion>
+        Make the member operators taking a
+        difference_type argument non-member operators
+</suggestion>
+<notes>NAD, not editorial, withdrawn by submitter.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="277"
+  uknum="20"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.4.1.2.1
+</section>
+<para>
+1
+</para>
+<description>
+        The default
+        constructor default-initializes current, rather than
+        value-initializes. This means that when Iterator
+        corresponds to a trivial type, the current member is left
+        un-initialized, even when the user explictly requests value
+        intialization! At this point, it is not safe to perform any
+        operations on the reverse_iterator other than assign it a
+        new value or destroy it. Note that this does correspond to
+        the basic definition of a singular iterator.
+</description>
+<suggestion>
+        i/ Specify value initialization rather than
+        default intialization or ii/ specify = default; rather than
+        spell out the semantic. This will at least allow users to
+        select value initialization and copy the iterator value. or
+        iii/ Add a note to the description emphasizing the singular
+        nature of a value-initialized reserve iterator.
+</suggestion>
+<notes>agree with option i, Alisdair will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="278"
+  uknum="21"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.4.1.2.1
+</section>
+<para>
+3
+</para>
+<description>
+        There is an
+        inconsistency between the constructor taking an iterator
+        and the constructor template taking a reverse_iterator
+        where one passes by value, and the other by const
+        reference. The by-value form is preferred as it allows for
+        efficient moving when copy elision fails to kick in.
+</description>
+<suggestion>
+        Change the const reverse_iterator&lt;U&gt;
+        &amp; parameter to pass-by-value
+</suggestion>
+<notes>NAD, we don't believe that copy elision is a 
+sufficiently high priority for iterator types.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="279"
+  uknum="24"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.4.1.2.12,
+        24.4.3.2.12
+</section>
+<para>
+</para>
+<description>
+        The reason the
+        return type became unspecified is LWG issue 386. This
+        reasoning no longer applies as there are at least two ways
+        to get the right return type with the new language
+        facilities added since the previous standard.
+</description>
+<suggestion>
+        Specify the return type using either
+        decltype or the Iter concept map
+</suggestion>
+<notes>under discussion. This is a general question about all 
+iterator adapters.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="280"
+  uknum="22"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.4.1.2.4
+</section>
+<para>
+</para>
+<description>
+        The presence of
+        the second iterator value is surprising for many readers
+        who underestimate the size of a reverse_iterator object.
+        Adding the exposition only member that is required by the
+        semantic will reduce confusion.
+</description>
+<suggestion>
+        Add reverse_iterator expsoition only member
+        tmp as a comment to class declaration, as a private member
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="281"
+  uknum="23"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.4.1.2.5
+</section>
+<para>
+</para>
+<description>
+        The current
+        specification for return value will always be a true
+        pointer type, but reverse_iterator supports proxy iterators
+        where the pointer type may be some kind of 'smart pointer'
+</description>
+<suggestion>
+        Replace the existing returns specification
+        with a copy of the operator* specification that returns
+        this-&gt;tmp.operator-&gt;
+</suggestion>
+<notes>study group formed to come up with a suggested 
+resolution.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="282"
+  uknum="5"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.4.2.1,
+        24.4.2.2.2,
+        24.4.2.3,
+        24.4.2.4.2,
+        24.4.2.5,
+        24.4.2.6.2
+</section>
+<para>
+n/a
+</para>
+<description>
+        Insert iterators of move-only types will
+        move from lvalues
+</description>
+<suggestion>
+        Add an additional constrained overload for
+        operator= that requires
+        !CopyConstructible&lt;Cont::value_type&gt; and mark it
+        =delete.
+</suggestion>
+<notes>deferred to discussion of N2831.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="283"
+  uknum="156"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.4.2.5,
+        24.4.2.6.4
+</section>
+<para>
+</para>
+<description>
+        postincrement operator overloads
+        traditionally return by value - insert_iterator is declared
+        as return by reference. The change is harmless in this
+        case, but either front/back_insert_iterator should take the
+        matching change for consistency, or this function should
+        return-by-value
+</description>
+<suggestion>
+        change operator++(int) overload to return
+        by value, not reference. Affects both class summary and
+        operator definition in p
+</suggestion>
+<notes>NAD. This is compatible with C++03; and we lack a 
+consensus for change.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="61"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.4.3.2.1
+</section>
+<para>
+2<sup>nd</sup> <font size="2"
+        style="font-size: 11pt">para, 1<sup>st</sup>
+        line</font>
+</para>
+<description>
+        Typo.
+        <BR/><BR/>
+        "intializing" should be "in<u>i</u>tializing"
+</description>
+<suggestion>
+        Add
+        "i"
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="284"
+  uknum="26"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+24.5
+</section>
+<para>
+</para>
+<description>
+        The stream
+        iterators need constraining with concepts/requrires
+        clauses.
+</description>
+<suggestion>
+        Provide constraints
+</suggestion>
+<notes>We agree. To be handled by Howard, Martin and PJ.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="285"
+  uknum="27"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.1
+</section>
+<para>
+1,2
+</para>
+<description>
+        Much of the
+        content of p1 and the whole of p2 is a redundant
+        redefinition of InputIterator. It should be simplified
+</description>
+<suggestion>
+        Strike p2. Simplify p1 and add a
+        cross-reference to the definition of InputIterator concept.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="286"
+  uknum="28"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.1
+</section>
+<para>
+3
+</para>
+<description>
+        To the casual
+        reader it is not clear if it is intended to be able to
+        assign to istream_iterator objects. Specifying the copy
+        constructor but relying on the implicit copy-assign
+        operator is confusing.
+</description>
+<suggestion>
+        Either provide a similar definition to the
+        copy-assign operator as for the copy constructor, or strike
+        the copy constructor
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="287"
+  uknum="25"
+  type="Te"
+  owner="LWG"
+  issue="788"
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.1.1
+</section>
+<para>
+2
+</para>
+<description>
+        It is not clear
+        what the intial state of an istream_iterator should be. Is
+        _value_ initialized by reading the stream, or default/value
+        initialized? If it is initialized by reading the stream,
+        what happens if the initialization is deferred until first
+        dereference, when ideally the iterator value should have
+        been that of an end-of-stream iterator which is not safely
+        dereferencable?
+</description>
+<suggestion>
+        Specify _value_ is initialized by reading
+        the stream, or the iterator takes on the end-of-stream
+        value if the stream is empty
+</suggestion>
+<notes>Martin will address with existing LWG
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">
+issue 788</a>.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="288"
+  uknum="29"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.1.1
+</section>
+<para>
+3
+</para>
+<description>
+        The provided specification is vacuous,
+        offering no useful information.
+</description>
+<suggestion>
+        Either strike
+        the specification of the copy constructor, or simply
+        replace it with an = default definition.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="289"
+  uknum="30"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.1.2
+</section>
+<para>
+6
+</para>
+<description>
+        It is very hard
+        to pick up the correct specification for
+        istream_iterator::operator== as the complete specification
+        requires reading two quite disconnected paragraphs,
+        24.5.1p3, and 24.5.1.2p6. Reading just the specifaction of
+        the operation itself suggests that end-of-stream iterators
+        are indistinguishable from 'valid' stream iterators, which
+        is a very dangerous misreading.
+</description>
+<suggestion>
+        Merge 24.5.1p3, equality comparison of
+        end-of-stream-iterators, into 24.5.1.2p6, the specification
+        of the equality operator for istream_iterator.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="290"
+  uknum="160"
+  type="Te"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.2
+</section>
+<para>
+1
+</para>
+<description>
+        The character
+        type of a string delimiter for an ostream_iterator should
+        be const charT *, the type of the elements, not char *, a
+        narrow character string.
+</description>
+<suggestion>
+        Replace char * with const charT *
+</suggestion>
+<notes>We agree and believe it to be editorial.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="291"
+  uknum="161"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.5.2.2
+</section>
+<para>
+2
+</para>
+<description>
+        ostream_iterator
+        postincrement operator returns by reference rather than by
+        value. This may be a small efficiency gain, but it is
+        otherwise unconventional. Prefer return-by-value.
+</description>
+<suggestion>
+        ostream_iterator operator++(int);
+</suggestion>
+<notes>NAD. This is compatible with C++03; and we lack a 
+consensus for change.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="34"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.3
+        [istreambuf.
+        iterator]
+</section>
+<para>
+</para>
+<description>
+        There are two public
+        sections, and the content of the second one is indented
+        with respect to the first. I don't it should be.
+</description>
+<suggestion>
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="292"
+  uknum="163"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.3
+</section>
+<para>
+1
+</para>
+<description>
+        Prefer the use
+        of the new nullptr constant to the zero literal when using
+        a null pointer in text.
+</description>
+<suggestion>
+        Change istreambuf_iterator(0) to
+        istreambuf_iterator(nullptr)
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="293"
+  uknum="164"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+24.5.3
+</section>
+<para>
+2,3,4
+</para>
+<description>
+        The listed paragraphs redundantly redefine
+        an input iterator, and redundancy can be a dangerous thing
+        in a specification. Suggest a simpler phrasing below.
+</description>
+<suggestion>
+        2. The result of
+        operator*() on an end of stream is undefined. For any other
+        iterator value a char_type value is returned. 3. Two end of
+        stream iterators are always equal. An end of stream
+        iterator is not equal to a non-end of stream iterator. 4.
+        As istreambuf_iterator() is an InputIterator but not a
+        ForwardIterator, istreambuf_iterators object can be used
+        only for one-pass algorithms. It is not possible to assign
+        a character via an input iterator.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="294"
+  uknum="166"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+24.5.3.2
+</section>
+<para>
+2
+</para>
+<description>
+        Implicit converting constructors can be
+        invoked at surprising times, so there should always be a
+        good reason for declaring one.
+</description>
+<suggestion>
+        Mark the two
+        single-argument constructors take a stream or stream buffer
+        as explicit. The proxy constructor should remain implicit.
+        explicit
+        istreambuf_iterator(basic_istream&lt;charT,traits&gt;&amp;
+        s) throw(); explicit
+        istreambuf_iterator(basic_streambuf&lt;charT,traits&gt;* s)
+        throw();
+</suggestion>
+<notes>NAD. This could potentially [break] C++03-conforming 
+programs.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="295"
+  uknum="173"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+25
+</section>
+<para>
+</para>
+<description>
+        THere is a level
+        of redundancy in the library specification for many
+        algorithms that can be eliminated with the combination of
+        concepts and default parameters for function templates.
+        Eliminating redundancy simplified specification and reduces
+        the risk of inttroducing accidental inconsistencies.
+</description>
+<suggestion>
+        Adopt n2743, or an update of that paper.
+</suggestion>
+<notes>NAD, this change would break code that takes the address 
+of an algorithm.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="62"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+25, 25.3.1.5,
+        26.3.6.5
+</section>
+<para>
+</para>
+<description>
+        The return types of is_sorted_until function and
+        is_heap_until function are iterator. But basically, the
+        return type of is_xxx function is bool. And the return type
+        of lower_bound function and upper_bound is iterator.
+        <BR/><BR/>
+        So we think that it is reasonable to change those two
+        functions.
+</description>
+<suggestion>
+        Change "is_sorted_until" to "sorted_bound"
+        <BR/><BR/>
+        Change "is_heap" to "heap_bound"
+</suggestion>
+<notes>no consensus to make the change.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="296"
+  uknum="183"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+25.1.8
+</section>
+<para>
+1
+</para>
+<description>
+        The 'Returns' of
+        adjacent_find requires only HasEqualTo, or a Predicate.
+        Requiring EqualityComparable or EquivalenceRelation seems
+        too strong and not useful.
+</description>
+<suggestion>
+        Change EqualityComparable to HasEqualTo and
+        EquivalnceRelation to Predicate
+</suggestion>
+<notes>no consensus to make the change.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="297"
+  uknum="185"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+25.2.11
+</section>
+<para>
+6
+</para>
+<description>
+        The definition
+        of rotate_copy is very complicated. It is equivalent to:
+        return copy(first, middle, copy(middle, last, result));
+</description>
+<suggestion>
+        Change 'effects' to, returns, requires,
+        complexity to: effects: equivalent to: return copy(first,
+        middle, copy(middle, last, result));
+</suggestion>
+<notes>Editor requests guidance: we agree that it is editorial.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="298"
+  uknum="186"
+  type="Te"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+25.2.13
+</section>
+<para>
+13
+</para>
+<description>
+        partition_point requires a partitioned
+        array
+</description>
+<suggestion>
+        requires: is_partitioned(first, last, pred)
+        != false;
+</suggestion>
+<notes>We agree with the suggested change and believe that it 
+is editorial.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="299"
+  uknum="352"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+25.2.2
+</section>
+<para>
+</para>
+<description>
+        Should be consistent in style use of
+        concepts in template parameter lists. The
+        auto-OutputIterator sytle used in std::copy is probably
+        preferred.
+</description>
+<suggestion>
+        Change way signature is declared:
+        template&lt;InputIterator InIter, OutputIterator&lt;auto,
+        RvalueOf&lt;InIter::reference&gt;::type&gt; OutIter&gt;
+        OutIter move(InIter first, InIter last, OutIter result);
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="300"
+  uknum="351"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+25.2.3
+</section>
+<para>
+</para>
+<description>
+        Since publishing
+        the original standard, we have learned that swap is a
+        fundamental operation, and several common idioms rely on it
+        - especially those related to exception safety. As such it
+        belongs in the common &lt;utility&gt; header rather than
+        the broader &lt;algorithm&gt; header, and likewise should
+        move to clause 20. For backwards compatiblility the
+        algorithm header should be required to #include
+        &lt;utility&gt;, which would be covered in the resolution
+        of LWG issue 343. There are already dependencies in
+        &lt;algorithm&gt; on types declared in this header, so this
+        comment does not create a new dependency.
+</description>
+<suggestion>
+        Move primary swap template from
+        &lt;algorithm&gt; into &lt;utility&gt;. Move 25.2.3 to
+        somewhere under 20.2. Require &lt;algorithm&gt; to #include
+        &lt;utility&gt; to access pair and provide legacy support
+        for finding swap.
+</suggestion>
+<notes>no consensus to make the change.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="301"
+  uknum="184"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+25.2.5
+</section>
+<para>
+</para>
+<description>
+        replace and
+        replace_if have the requirement: OutputIterator&lt;Iter,
+        Iter::reference&gt; Which implies they need to copy some
+        values in the range the algorithm is iterating over. This
+        is not however the case, the only thing that happens is
+        const T&amp;s might be copied over existing elements (hence
+        the OutputIterator&lt;Iter, const T&amp;&gt;
+</description>
+<suggestion>
+        Remove OutputIterator&lt;Iter,
+        Iter::reference&gt; from replace and replace_if
+</suggestion>
+<notes>agreed. Howard will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="302"
+  uknum="187"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+25.3
+</section>
+<para>
+4
+</para>
+<description>
+        the concept
+        StrictWeakOrder covers the definition of a strict weak
+        ordering, described in paragraph 4.
+</description>
+<suggestion>
+        Remove 4, and mention StrictWeakOrder in
+        paragraph 1.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="303"
+  uknum="188"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+25.3
+</section>
+<para>
+6
+</para>
+<description>
+        This paragraph just describes
+        is_partitioned
+</description>
+<suggestion>
+        6 A sequence
+        [start,finish) is partitioned with respect to an expression
+        f(e) if is_partitioned(start, finish, e) != false
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="304"
+  uknum="189"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+25.3.6
+</section>
+<para>
+</para>
+<description>
+        The requires
+        clauses of push_heap, pop_heap and make_heap are
+        inconsistently formatted, dispite being identical
+</description>
+<suggestion>
+        Format them identically.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="305"
+  uknum="335"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+25.3.7
+</section>
+<para>
+1, 9, 17
+</para>
+<description>
+        The negative requirement on IsSameType is a
+        hold-over from an earlier draught with a variadic template
+        form of min/max algorith. It is no longer necessary.
+</description>
+<suggestion>
+        Strike the !IsSameType&lt;T, Compare&gt;
+        constraint on min/max/minmax algorithms
+</suggestion>
+<notes>agreed. We request that someone from the UK open an 
+issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="84"
+  uknum=""
+  type="ge"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+26
+</section>
+<para>
+</para>
+<description>
+        Parts of the numerics chapter are not concept enabled.
+</description>
+<suggestion>
+</suggestion>
+<notes>The portions of this comment dealing 
+with random numbers are resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
+N2836</a>, which was accepted in New Jersey.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="35"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+26.3
+        [Complex
+numbers]
+</section>
+<para>
+</para>
+<description>
+        Instantiations of the class
+        template complex&lt;&gt; have to be allowed for integral
+        types, to reflect existing practice and ISO standards
+        (LIA-III).
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="306"
+  uknum="113"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date="2009-03-06"
+  extdoc="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf"
+>
+<section>
+26.4
+</section>
+<para>
+</para>
+<description>
+        Random number
+        library component cannot be used in constrained templates
+</description>
+<suggestion>
+        Provide constraints for the random number
+        library
+</suggestion>
+<notes>Resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
+N2836</a>, which was accepted in New Jersey.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="63"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue="874"
+  disp="accepted"
+  date="2009-03-06"
+  extdoc="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf"
+>
+<section>
+26.4.8.5.1
+</section>
+<para>
+</para>
+<description>
+        No
+        constructor of discrete_distribution that accepts
+        initializer_list.
+        <BR/><BR/>
+        discrete_distribution initialize distribution by a given
+        range (iterators), but temporary variable of a container or
+        an array is needed in the following case.
+        <BR/><BR/>
+        
+        <BR/><BR/>int
+        ar[] = {1, 2, 3};
+        <BR/><BR/>
+        discrete_distribution&lt;&gt; dist(ar, ar+3);
+        <BR/><BR/>
+        
+        <BR/><BR/>Other libraries
+        also accept initializer_list, so change
+        discrete_distribution library to accept initializer_list
+        too.
+        <BR/><BR/>
+</description>
+<suggestion>
+        Add
+        the following constructer.
+        <BR/><BR/>
+        <u>discrete_distribution(initializer_list&lt;result_type&gt;);</u>
+</suggestion>
+<notes>Resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
+N2836</a>, which was accepted in New Jersey.<BR/><BR/>
+This comment is also covered by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">
+issue 874</a>. [Suggested by Daniel Kr&#252;gler and confirmed by the
+submitter.]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="64"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+26.5.2
+</section>
+<para>
+</para>
+<description>
+        &#8220;valarray&lt;T&gt;&amp; operator+=
+        (initializer_list&lt;T&gt;);&#8221; is not defined.
+</description>
+<suggestion>
+        Add
+        valarray&lt;T&gt;&amp; operator+=
+        (initializer_list&lt;T&gt;);
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="307"
+  uknum="394"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+26.7
+</section>
+<para>
+Footnote 288
+</para>
+<description>
+        The footnote
+        refers to TR1, which is not a defined term in this
+        standard. Drop the reference to TR1, those templates are a
+        regular part of the standard now and how they were
+        introduced is no longer relevant.
+</description>
+<suggestion>
+        Drop the reference to TR1.
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="85"
+  uknum=""
+  type="ge"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27
+</section>
+<para>
+</para>
+<description>
+        The
+        input/output chapter is not concept enabled.
+</description>
+<suggestion>
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="308"
+  uknum="114"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27
+</section>
+<para>
+</para>
+<description>
+        <span lang="en-US">iostreams library cannot be used from
+        constrained templates</span>
+</description>
+<suggestion>
+        Provide constraints for the iostreams
+        library, clause 27
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="65"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.4.4
+</section>
+<para>
+</para>
+<description>
+        Switch from
+        &#8220;unspecified-bool-type&#8221; to<span lang=
+        "zxx">&#12288;&#8220;</span>explicit operator bool()
+        const&#8221;.
+</description>
+<suggestion>
+        Replace "operator <i>unspecified-bool-type</i>() const;"
+        with "explicit operator bool() const;"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="66"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.4.4.3
+</section>
+<para>
+1<sup>st</sup> <font size="2"
+        style="font-size: 11pt">para</font>
+</para>
+<description>
+        Switch from
+        &#8220;unspecified-bool-type&#8221; to<span lang=
+        "zxx">&#12288;&#8220;</span>explicit operator bool()
+        const&#8221;
+</description>
+<suggestion>
+        Replace "operator <i>unspecified-bool-type</i>() const;"
+        with "explicit operator bool() const;"
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="36"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.6.1.2.2
+[istream.
+        formatted.
+        arithmetic]
+</section>
+<para>
+1, 2, and 3
+</para>
+<description>
+        iostate err = 0;
+        <BR/><BR/>
+        <BR/><BR/>iostate is a bitmask type and
+        so could be an enumeration. Probably using
+        <BR/><BR/>goodbit is the solution.
+</description>
+<suggestion>
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="37"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.6.1.2.2
+[istream.
+        formatted.
+        arithmetic]
+</section>
+<para>
+3
+</para>
+<description>
+        else if (lval &lt;
+        numeric_limits&lt;int&gt;::min()
+        <BR/><BR/>||
+        numeric_limits&lt;int&gt;::max() &lt; lval))
+        <BR/><BR/>
+        <BR/><BR/>The parentheses aren't
+        balanced.
+</description>
+<suggestion>
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="67"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.7.1
+</section>
+<para>
+</para>
+<description>
+        basic_stringbuf dose not use concept.
+</description>
+<suggestion>
+        Replace &#8220;class Allocator&#8221; to &#8220;Allocator
+        Alloc&#8221;.
+        <BR/><BR/>
+         Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_stringbuf : public
+        basic_streambuf&lt;charT,traits&gt; {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>...
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.1.1 Constructors:
+        <BR/><BR/>
+        explicit basic_stringbuf(ios_base::openmode which
+        <BR/><BR/>=
+        ios_base::in | ios_base::out);
+        <BR/><BR/>
+        explicit basic_stringbuf
+        <BR/><BR/>
+        (const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        str,
+        <BR/><BR/>
+        ios_base::openmode which = ios_base::in | ios_base::out);
+        <BR/><BR/>
+        basic_stringbuf(basic_stringbuf&amp;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>...
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.1.3 Get and set:
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt; str() const;
+        <BR/><BR/>
+        void str(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; s);
+        <BR/><BR/>
+        
+        <BR/><BR/>...
+        <BR/><BR/>};
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator
+        Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_stringbuf&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp; x,
+        <BR/><BR/>
+        basic_stringbuf&lt;charT, traits, <u>Alloc</u>&gt;&amp; y);
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator
+        Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_stringbuf&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp;&amp; x,
+        <BR/><BR/>
+        basic_stringbuf&lt;charT, traits, <u>Alloc</u>&gt;&amp; y);
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator
+        Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_stringbuf&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp; x,
+        <BR/><BR/>
+        basic_stringbuf&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp;&amp; y);
+        <BR/><BR/>}
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="68"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.7.2
+</section>
+<para>
+</para>
+<description>
+        basic_istringstream dose not use concept.
+</description>
+<suggestion>
+        Replace &#8220;class Allocator&#8221; to &#8220;Allocator
+        Alloc&#8221;.
+        <BR/><BR/>
+         Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_istringstream : public
+        basic_istream&lt;charT,traits&gt; {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef typename traits::int_type int_type;
+        <BR/><BR/>
+        typedef typename traits::pos_type pos_type;
+        <BR/><BR/>
+        typedef typename traits::off_type off_type;
+        <BR/><BR/>
+        typedef traits traits_type;
+        <BR/><BR/>
+        typedef <u>Alloc</u> allocator_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.2.1 Constructors:
+        <BR/><BR/>
+        explicit basic_istringstream(ios_base::openmode which =
+        ios_base::in);
+        <BR/><BR/>
+        explicit basic_istringstream(
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        str,
+        <BR/><BR/>
+        ios_base::openmode which = ios_base::in);
+        <BR/><BR/>
+        basic_istringstream(basic_istringstream&amp;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.2.2 Assign and swap:
+        <BR/><BR/>
+        basic_istringstream&amp;
+        operator=(basic_istringstream&amp;&amp; rhs);
+        <BR/><BR/>
+        void swap(basic_istringstream&amp;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.2.3 Members:
+        <BR/><BR/>
+        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt;* rdbuf()
+        const;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt; str() const;
+        <BR/><BR/>
+        void str(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; s);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        private:
+        <BR/><BR/>//
+        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt; sb;
+        exposition only
+        <BR/><BR/>};
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator
+        Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_istringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp; x,
+        <BR/><BR/>
+        basic_istringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
+        y);
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator
+        Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_istringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp;&amp; x,
+        <BR/><BR/>
+        basic_istringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
+        y);
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator
+        Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_istringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp; x,
+        <BR/><BR/>
+        basic_istringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp;&amp; y);
+        <BR/><BR/>}
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="69"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.7.3
+</section>
+<para>
+</para>
+<description>
+        basic_ostringstream dose not use concept.
+</description>
+<suggestion>
+        Replace &#8220;class Allocator&#8221; to &#8220;Allocator
+        Alloc&#8221;.
+        <BR/><BR/>
+         Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_ostringstream : public
+        basic_ostream&lt;charT,traits&gt; {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>//
+        types:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef typename traits::int_type int_type;
+        <BR/><BR/>
+        typedef typename traits::pos_type pos_type;
+        <BR/><BR/>
+        typedef typename traits::off_type off_type;
+        <BR/><BR/>
+        typedef traits traits_type;
+        <BR/><BR/>
+        typedef <u>Alloc</u> allocator_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.3.1 Constructors/destructor:
+        <BR/><BR/>
+        explicit basic_ostringstream(ios_base::openmode which =
+        ios_base::out);
+        <BR/><BR/>
+        explicit basic_ostringstream(
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        str,
+        <BR/><BR/>
+        ios_base::openmode which = ios_base::out);
+        <BR/><BR/>
+        basic_ostringstream(basic_ostringstream&amp;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.3.2 Assign/swap:
+        <BR/><BR/>
+        basic_ostringstream&amp;
+        operator=(basic_ostringstream&amp;&amp; rhs);
+        <BR/><BR/>
+        void swap(basic_ostringstream&amp;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.3.3 Members:
+        <BR/><BR/>
+        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt;* rdbuf()
+        const;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt; str() const;
+        <BR/><BR/>
+        void str(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; s);
+        <BR/><BR/>
+        private:
+        <BR/><BR/>//
+        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt; sb;
+        exposition only
+        <BR/><BR/>};
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator</u>
+        <font size="2" style=
+        "font-size: 11pt"><u>Alloc</u>&gt;</font>
+        <BR/><BR/>
+        void swap(basic_ostringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp; x,
+        <BR/><BR/>
+        basic_ostringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
+        y);
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator</u>
+        <font size="2" style=
+        "font-size: 11pt"><u>Alloc</u>&gt;</font>
+        <BR/><BR/>
+        void swap(basic_ostringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp;&amp; x,
+        <BR/><BR/>
+        basic_ostringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
+        y);
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator
+        Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_ostringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp; x,
+        <BR/><BR/>
+        basic_ostringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp;&amp; y);
+        <BR/><BR/>}
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="71"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.7.3
+</section>
+<para>
+</para>
+<description>
+        Typo.
+        <BR/><BR/>"template" is missing in
+        "class basic_ostringstream" of the title of the chapter.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        27.7.3 Class basic_ostringstream
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>27.7.3 Class <u>template</u>
+        basic_ostringstream
+</suggestion>
+<notes>[Being reviewed by Editor]
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="72"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.7.4
+</section>
+<para>
+</para>
+<description>
+        basic_stringstream dose not use concept.
+</description>
+<suggestion>
+        Replace "class Allocator" to "Allocator Alloc".
+        <BR/><BR/>
+         Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        template &lt;class charT, class traits =
+        char_traits&lt;charT&gt;,
+        <BR/><BR/>
+        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
+        <BR/><BR/>
+        class basic_stringstream
+        <BR/><BR/>:
+        public basic_iostream&lt;charT,traits&gt; {
+        <BR/><BR/>
+        public:
+        <BR/><BR/>//
+        types:
+        <BR/><BR/>
+        typedef charT char_type;
+        <BR/><BR/>
+        typedef typename traits::int_type int_type;
+        <BR/><BR/>
+        typedef typename traits::pos_type pos_type;
+        <BR/><BR/>
+        typedef typename traits::off_type off_type;
+        <BR/><BR/>
+        typedef traits traits_type;
+        <BR/><BR/>
+        typedef <u>Alloc</u> allocator_type;
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        constructors/destructor
+        <BR/><BR/>
+        explicit basic_stringstream(
+        <BR/><BR/>
+        ios_base::openmode which = ios_base::out|ios_base::in);
+        <BR/><BR/>
+        explicit basic_stringstream(
+        <BR/><BR/>
+        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
+        str,
+        <BR/><BR/>
+        ios_base::openmode which = ios_base::out|ios_base::in);
+        <BR/><BR/>
+        basic_stringstream(basic_stringstream&amp;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        27.7.5.1 Assign/swap:
+        <BR/><BR/>
+        void swap(basic_stringstream&amp;&amp; rhs);
+        <BR/><BR/>
+        
+        <BR/><BR/>//
+        Members:
+        <BR/><BR/>
+        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt;* rdbuf()
+        const;
+        <BR/><BR/>
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt; str() const;
+        <BR/><BR/>
+        void str(const
+        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; str);
+        <BR/><BR/>
+        private:
+        <BR/><BR/>//
+        basic_stringbuf&lt;charT, traits&gt; sb; exposition only
+        <BR/><BR/>};
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator
+        Alloc</u>&gt;
+        <BR/><BR/>
+        void swap(basic_stringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp; x,
+        <BR/><BR/>
+        basic_stringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
+        y);
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator</u>
+        <font size="2" style=
+        "font-size: 11pt"><u>Alloc</u>&gt;</font>
+        <BR/><BR/>
+        void swap(basic_stringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp;&amp; x,
+        <BR/><BR/>
+        basic_stringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
+        y);
+        <BR/><BR/>
+        template &lt;class charT, class traits, <u>Allocator</u>
+        <font size="2" style=
+        "font-size: 11pt"><u>Alloc</u>&gt;</font>
+        <BR/><BR/>
+        void swap(basic_stringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp; x,
+        <BR/><BR/>
+        basic_stringstream&lt;charT, traits,
+        <u>Alloc</u>&gt;&amp;&amp; y);
+        <BR/><BR/>}
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="73"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+27.8.1.14
+</section>
+<para>
+</para>
+<description>
+        It is a problem
+        from C++98, fstream cannot appoint a filename of wide
+        character string(const wchar_t and const wstring&amp;).
+</description>
+<suggestion>
+        Add
+        interface corresponding to wchar_t, char16_t and char32_t.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="86"
+  uknum=""
+  type="ge"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28
+</section>
+<para>
+</para>
+<description>
+        The
+        regular expressions chapter is not concept enabled.
+</description>
+<suggestion>
+</suggestion>
+<notes>US86, UK309, UK310: We believe that an issue can be 
+opened and we await a volunteer.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="309"
+  uknum="115"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28
+</section>
+<para>
+</para>
+<description>
+        Regular
+        expressions cannot be used in constrained templates
+</description>
+<suggestion>
+        Provide constraints for the regular
+        expression library, clause 28
+</suggestion>
+<notes>US86, UK309, UK310: We believe that an issue can be 
+opened and we await a volunteer.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="310"
+  uknum="281"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28
+</section>
+<para>
+</para>
+<description>
+        The regex chapter uses iterators in the old
+        pre-concept style, it should be changed to use concepts
+        instead.
+</description>
+<suggestion>
+        Use concepts for iterator template
+        arguments throughout.
+</suggestion>
+<notes>US86, UK309, UK310: We believe that an issue can be 
+opened and we await a volunteer.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="314"
+  uknum="343"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28.4
+</section>
+<para>
+</para>
+<description>
+        The swap
+        overloads for regex classes are only supplied for l-value
+        references. Other sections of the library (eg 21 strings or
+        23 containers) provide two extra overloads taking an
+        r-value reference as the first and second argument
+        respectively.
+</description>
+<suggestion>
+        Add the missing overloads to 28.4 and the
+        corresponding later sections in 28 for each swap function.
+        We want to accept AMs paper which proposes a single
+        overload with two r-value references
+</suggestion>
+<notes>deferred to discussion of N2831.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="315"
+  uknum="344"
+  type="Te"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28.4
+</section>
+<para>
+p6
+</para>
+<description>
+        6 Effects:
+        string_type str(first, last); return
+        use_facet&lt;collate&lt;charT&gt; &gt;(
+        getloc()).transform(&amp;*str.begin(), &amp;*str.end()); Is
+        it legal to dereference str.end() ?
+</description>
+<suggestion>
+        Reword to effect clause to use legal
+        iterator dereferences
+</suggestion>
+<notes>We believe that this is editorial.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="316"
+  uknum="345"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+28.4 ff
+</section>
+<para>
+</para>
+<description>
+        The constructors
+        for regex classes do not have an r-value overload.
+</description>
+<suggestion>
+        Add the missing r-value constructors to
+        regex classes.
+</suggestion>
+<notes>We agree and await assistance from the UK.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="317"
+  uknum="278"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28.8
+</section>
+<para>
+</para>
+<description>
+        basic_string has both a constructor and an
+        assignment operator that accepts an initializer list,
+        basic_regex should have the same.
+</description>
+<suggestion>
+        In the
+        basic_regex synopsis, after: basic_regex&amp;
+        operator=(const charT* ptr); add: basic_regex&amp;
+        operator=(initializer_list&lt;charT&gt; il); And after
+        paragraph 20 add: basic_regex&amp;
+        operator=(initializer_list&lt;charT&gt; il); Effects:
+        returns assign(il.begin(), il.end());
+</suggestion>
+<notes>UK317, JP74: Alisdair will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="74"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28.8
+</section>
+<para>
+</para>
+<description>
+        &#8220;basic_regx &amp; operator=
+        (initializer_list&lt;T&gt;);&#8221; is not defined.
+</description>
+<suggestion>
+        Add
+        basic_regx &amp; operator= (initializer_list&lt;T&gt;);
+</suggestion>
+<notes>UK317, JP74: Alisdair will open an issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="318"
+  uknum="279"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28.8.2
+</section>
+<para>
+para 22
+</para>
+<description>
+        Constructor
+        definition should appear with the other constructors not
+        after assignment ops.
+</description>
+<suggestion>
+        Move para 22 to just after para 17.
+</suggestion>
+<notes></notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="319"
+  uknum="280"
+  type="Te"
+  owner="LWG"
+  issue="909"
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+28.12.2
+</section>
+<para>
+</para>
+<description>
+        It was always expected that
+        regex_token_iterator would be constructible from an array
+        literal: indeed ideally this is the prefered method of
+        initializing such an object. However, the best we could do
+        in C++0x was: template &lt;std::size_t N&gt;
+        regex_token_iterator(BidirectionalIterator a,
+        BidirectionalIterator b, const regex_type&amp; re, const
+        int (&amp;submatches)[N], regex_constants::match_flag_type
+        m = regex_constants::match_default); Now that we have
+        initializer_lists we should use them to remove this
+        particular wart.
+</description>
+<suggestion>
+        To the synopsis
+        for regex_token_iterator, after template &lt;std::size_t
+        N&gt; regex_token_iterator(BidirectionalIterator a,
+        BidirectionalIterator b, const regex_type&amp; re, const
+        int (&amp;submatches)[N], regex_constants::match_flag_type
+        m = regex_constants::match_default); add
+        regex_token_iterator(BidirectionalIterator a,
+        BidirectionalIterator b, const regex_type&amp; re,
+        initializer_list&lt;int&gt; submatches,
+        regex_constants::match_flag_type m =
+        regex_constants::match_default); In 28.12.2.1 add the
+        declaration: regex_token_iterator(BidirectionalIterator a,
+        BidirectionalIterator b, const regex_type&amp; re,
+        initializer_list&lt;int&gt; submatches,
+        regex_constants::match_flag_type m =
+        regex_constants::match_default); And to the end of para 3
+        add: The forth constructor initializes the member subs to
+        hold a copy of the sequence of integer values in the range
+        [submatches.begin(), submatches.end()).
+</suggestion>
+<notes>We agree. Alisdair will open an issue.<BR/><BR/>
+In c++std-lib-23130, Daniel Kr&#252;gler pointed out that this comment
+is already covered by issue 909.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="87"
+  uknum=""
+  type="ge"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+29
+</section>
+<para>
+</para>
+<description>
+        The
+        atomics chapter is not concept enabled. The adopted paper,
+        N2427, did have those concepts.
+</description>
+<suggestion>
+</suggestion>
+<notes>Create an issue for concepts in the atomics chapter. See 
+N2427. Needs to also consider issues 
+923 and 
+924.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="311"
+  uknum="116"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+29
+</section>
+<para>
+</para>
+<description>
+        Atomic types
+        cannot be used generically in a constrained template
+</description>
+<suggestion>
+        Provide constraints for the atomics
+        library, clause 29
+</suggestion>
+<notes>Duplicate of US 87.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="312"
+  uknum="157"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+29
+</section>
+<para>
+</para>
+<description>
+        The contents of the &lt;stdatomic.h&gt;
+        header are not listed anywhere, and &lt;cstdatomic&gt; is
+        listed as a C99 header in chapter 17. If we intend to use
+        these for compatibility with a future C standard, we should
+        not use them now.
+</description>
+<suggestion>
+        Remove &lt;cstdatomic&gt; from the C99
+        headers in table 14. Add a new header &lt;atomic&gt; to the
+        headers in table 13. Update chapter 29 to remove reference
+        to &lt;stdatomic.h&gt; and replace the use of
+        &lt;cstdatomic&gt; with &lt;atomic&gt;. If and when WG14
+        adds atomic operations to C we can add corresponding
+        headers to table 14 with a TR.
+</suggestion>
+<notes>Create an issue. Assigned to Lawrence Crowl. May be 
+resolvable with a footnote for clarity stating that the header is 
+defined where it exists.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="75"
+  uknum=""
+  type="ed"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+29
+</section>
+<para>
+</para>
+<description>
+        A
+        definition of enum or struct is the style of C using
+        typedef.
+</description>
+<suggestion>
+        Change to a style of C++.
+        <BR/><BR/>
+        Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        29.1
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        <u>typedef</u> enum memory_order {
+        <BR/><BR/>
+        memory_order_relaxed, memory_order_consume,
+        memory_order_acquire,
+        <BR/><BR/>
+        memory_order_release, memory_order_acq_rel,
+        memory_order_seq_cst
+        <BR/><BR/>}
+        memory_order;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        enum memory_order {
+        <BR/><BR/>
+        memory_order_relaxed, memory_order_consume,
+        memory_order_acquire,
+        <BR/><BR/>
+        memory_order_release, memory_order_acq_rel,
+        memory_order_seq_cst
+        <BR/><BR/>};
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        29.3.1
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        <u>typedef</u> struct atomic_bool {
+        <BR/><BR/>...
+        <BR/><BR/>}
+        atomic_bool;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        struct atomic_bool {
+        <BR/><BR/>...
+        <BR/><BR/>};
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        <u>typedef</u> struct atomic_<i>itype</i> {
+        <BR/><BR/>...
+        <BR/><BR/>}
+        atomic_<i>itype</i>;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        struct atomic_<i>itype</i> {
+        <BR/><BR/>...
+        <BR/><BR/>};
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        29.3.2
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        <u>typedef</u> struct atomic_address {
+        <BR/><BR/>...
+        <BR/><BR/>}
+        atomic_address;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        struct atomic_address {
+        <BR/><BR/>...
+        <BR/><BR/>};
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        29.5
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        <u>typedef</u> struct atomic_flag {
+        <BR/><BR/>...
+        <BR/><BR/>}
+        atomic_flag;
+        <BR/><BR/>}
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        namespace std {
+        <BR/><BR/>
+        struct atomic_flag {
+        <BR/><BR/>...
+        <BR/><BR/>};
+        <BR/><BR/>}
+</suggestion>
+<notes>Recommend to reject the comment: We believe the current 
+syntax is most appropriate for an interface that is intended to be 
+highly compatible with C.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="313"
+  uknum="220"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+29.1
+</section>
+<para>
+</para>
+<description>
+        seq_cst fences don't necessarily guarantee
+        ordering
+        http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926
+</description>
+<suggestion>
+        Add a new
+        paragraph after 29.1 [atomics.order]p5 that says For atomic
+        operations A and B on an atomic object M, where A and B
+        modify M, if there are memory_order_seq_cst fences X and Y
+        such that A is sequenced before X, Y is sequenced before B,
+        and X precedes Y in S, then B occurs later than A in the
+        modifiction order of M.
+</suggestion>
+<notes>Hans to make proposal. See LWG
+Issue 926.<BR/><BR/>
+UK 313 Update and LWG
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">
+926</a>: Accept proposed resolution, correcting 
+spelling. Move to review state. Hans to ask additional review from cpp-threads.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="88"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+29.2
+</section>
+<para>
+</para>
+<description>
+        The "lockfree" facilities do
+        not tell the programmer enough.
+</description>
+<suggestion>
+        Expand the "lockfree" facilities. See the attached paper
+        "Issues with the C++ Standard" under Chapter 29,
+        "atomics.lockfree doesn't tell the programmer enough"
+</suggestion>
+<notes>Create an issue, will require more discussion. Assigned 
+to Lawrence. Description of issue should be based on what is in the 
+additional notes for US 88.<BR/><BR/>
+See wiki for further comments.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="89"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue="937"
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+29.3.1
+</section>
+<para>
+Table 122
+</para>
+<description>
+        The
+        types in the table "Atomics for standard typedef types"
+        should be typedefs, not classes. These semantics are
+        necessary for compatibility with C.
+</description>
+<suggestion>
+        Change the classes to
+        typedefs.
+</suggestion>
+<notes>LWG
+Issue 937. Direct the editor to turn the types into typedefs as proposed in the comment. Paper approved by committee used 
+typedefs, this appears to have been introduced as an editorial change. 
+Rationale: for compatibility with C.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="90"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+29.4
+</section>
+<para>
+</para>
+<description>
+        Are atomic functions allowed
+        to have non-volatile overloads?
+</description>
+<suggestion>
+        Allow non-volatile overloads. See the attached paper
+        "Issues with the C++ Standard, under Chapter 29, "Are
+        atomic functions allowed to have non-volatile overloads?"
+</suggestion>
+<notes>Create an issue. Assigned to Lawrence Crowl. Should 
+explicitly consider the process shared issue.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="91"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+29.4
+</section>
+<para>
+</para>
+<description>
+        Whether or not a failed
+        compare_exchange is a RMW operation (as used in 1.10
+        [intro.multithread]) is unclear.
+</description>
+<suggestion>
+        Make failing compare_exchange operations <font size="2"
+        style="font-size: 11pt"><strong>not</strong> be RMW. See
+        the attached paper under "atomic RMW status of failed
+        compare_exchange"</font>
+</suggestion>
+<notes>Create an issue, goes to review. Attention: Howard. 
+Group agrees with the resolution as proposed by Anthony Williams in the 
+attached note.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="92"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+29.4
+</section>
+<para>
+</para>
+<description>
+        The effect of
+        memory_order_consume with atomic RMW operations is unclear.
+</description>
+<suggestion>
+        Follow the lead of fences [atomics.fences], and promote
+        memory_order_consume to memory_order_acquire with RMW
+        operations.
+</suggestion>
+<notes>Create an issue. Assigned to Lawrence. Resolution 
+requires proposed wording.<BR/><BR/>
+Later: Mark as Not A Defect. 
+We can not see the issue being suggested by the comment.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="76"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30
+</section>
+<para>
+</para>
+<description>
+        A
+        description for "<i>Throws:</i> Nothing." are not unified.
+        <BR/><BR/>At
+        the part without throw, "<i>Throws:</i> Nothing." should be
+        described.
+</description>
+<suggestion>
+        Add
+        "<i>Throws:</i> Nothing." to the following.
+        <BR/><BR/>
+        30.2.1.6 , 1<sup>st</sup> <font size="2" style=
+        "font-size: 11pt">paragraph</font>
+        <BR/><BR/>
+        30.3.3.1 , 4<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">paragraph</font>
+        <BR/><BR/>
+        30.3.3.2.1 , 6<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">paragraph</font>
+        <BR/><BR/>
+        30.4.1 , 7<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">and 8<sup>th</sup> paragraph</font>
+        <BR/><BR/>30.4.2 ,
+        6<sup>th</sup><font size="2" style="font-size: 11pt">,
+        7<sup>th</sup>,19<sup>th</sup>,21th and 25<sup>th</sup>
+        paragraph</font>
+</suggestion>
+<notes>Pass on to editor.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="93"
+  uknum=""
+  type="ge"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30
+</section>
+<para>
+</para>
+<description>
+        The
+        thread chapter is not concept enabled.
+</description>
+<suggestion>
+</suggestion>
+<notes>Create an issue. Need to find volunteers to work on 
+this.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="320"
+  uknum="117"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30
+</section>
+<para>
+</para>
+<description>
+        Threads library cannot be used in
+        constrained templates
+</description>
+<suggestion>
+        Provide constraints for the threads
+        library, clause 30
+</suggestion>
+<notes>Duplicate of US 93.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="321"
+  uknum="172"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30
+</section>
+<para>
+</para>
+<description>
+        Throughout this
+        clause, the term Requires: is used to introduce compile
+        time requirements, which we expect to be replaced with
+        concepts and requires in code. Run-time preconditions are
+        introduced with the term "Preconditions:" which is not a
+        defined part of the library documentation structure
+        (17.5.2.4). However, this is exactly the direction that BSI
+        would like to see the organisation move, replacing
+        Requires: clauses with Preconditions: clasues throught the
+        library. See comment against clause 17 for more details.
+</description>
+<suggestion>
+        Decument Preconditions: paragraphs in
+        17.5.2.4, and use consistently through rest of the library.
+</suggestion>
+<notes>Pass on to editor.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="94"
+  uknum=""
+  type="te"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.1.2
+</section>
+<para>
+1
+</para>
+<description>
+        The first sentence of para 1 suggests that no other
+        library function is permitted to call operating system or
+        low level APIs.
+</description>
+<suggestion>
+        Rewrite para 1
+        as: &#8220; <font color="#000000">Some functions described
+        in this Clause are specified to throw exceptions of type
+        system_error (</font><font color="#0000FF">19.4.5</font>
+        <font color="#000000">). Such exceptions shall be thrown if
+        a call to an operating system or underlying API results in
+        an error that prevents the library function from satisfying
+        its postconditions or from returning a meaningful
+        value.&#8221;</font>
+</suggestion>
+<notes>Reclassify as editorial. Pass on to editor, wording roughly as proposed.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="95"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+30.1.3
+</section>
+<para>
+1
+</para>
+<description>
+        &#8220;native_handle_type&#8221; is a typedef, not a
+        class member.
+</description>
+<suggestion>
+        Several classes
+        described in this Clause have a member native_handle (of
+        type native_handle_type) . The
+        <BR/><BR/>
+        presence of this member and its semantics is implementation
+        defined. [ Note: This member allows implementations to
+        provide access to implementation details. The name of the
+        member and the type are specified to facilitate portable
+        compile-time detection. Actual use of this member or the
+        corresponding type is inherently non-portable. &#8212;end
+        note ]
+</suggestion>
+<notes>Not a defect. native_handle_type is a typedef, but it is also a member of 
+    the classes in question.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="96"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+30.1.4
+</section>
+<para>
+2
+</para>
+<description>
+        There is no definition here for monotonic clock.
+</description>
+<suggestion>
+        Implementations
+        should use a <i>monotonic clock</i> to measure time for
+        these functions. A monotonic clock measures real time, but
+        cannot be set, and is guaranteed to have no negative clock
+        jumps.
+</suggestion>
+<notes>There is a good definition. NAD. There are other problems here (see issue 
+    859). Create an issue, together with UK 322. Detlef will write the issue, 
+    but not proposed wording. Refer also to sections [time.clock.req] and [time.clock.monotonic].</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="322"
+  uknum="168"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.1.4
+</section>
+<para>
+2
+</para>
+<description>
+        Not all systms
+        can provide a monotonic clock. How are they expected to
+        treat a _for function?
+</description>
+<suggestion>
+        Add at least a note explaining the intent
+        for systems that do not support a monotonic clock.
+</suggestion>
+<notes>Create an issue, together with UK 96. Note that the specification as is 
+    already allows a non-monotonic clock due to the word &#8220;should&#8221; rather than 
+    &#8220;shall&#8221;. If this wording is kept, a footnote should be added to make the 
+    meaning clear.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="323"
+  uknum="171"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+30.2.1
+</section>
+<para>
+1
+</para>
+<description>
+        The presence of
+        a non-explicit variadic template constructor alongside an
+        explicit single-argument constructor can lead to behaviour
+        that is not intended: the variadic constructor will be
+        selected for implicit conversions, defeating the purpose of
+        the explicit single-argument constructor. Additionally the
+        single-argument constructor is redundant; the variadic
+        constructor can provide identical functionality with one
+        *fewer* copies if the supplied func is an lvalue.
+</description>
+<suggestion>
+        Mark constructor template &lt;class F,
+        class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;...
+        args); as explicit and remove the single-argument
+        constructor.
+</suggestion>
+<notes>Create an issue, goes to review. Attention: Howard. Group agrees with the 
+    proposed resolution.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="324"
+  uknum="169"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+30.2.1.1
+</section>
+<para>
+</para>
+<description>
+        thread::id
+        objects should be as useable in hashing containers as they
+        are in ordered associative containers.
+</description>
+<suggestion>
+        Add thread::id
+        support for std::hash
+</suggestion>
+<notes>Not a defect. See [unord.hash], where std::thread:id is already listed as a 
+    required specialization for std::hash().</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="77"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.2.1.2
+</section>
+<para>
+</para>
+<description>
+        "CopyConstructible" and "MoveConstructible" in
+        "<i>Requires:</i> F and each Ti in Args shall be
+        CopyConstructible if an lvalue and otherwise
+        MoveConstructible." are reflected by interface.
+</description>
+<suggestion>
+        Add
+        a concept for constructor of thread.
+</suggestion>
+<notes>Subset of US 93. Should be addressed under the issue corresponding to US 93.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="78"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.2.1.2
+</section>
+<para>
+        4<sup>th</sup> <font size="2" style=
+        "font-size: 11pt">para, 1<sup>st</sup> line</font>
+</para>
+<description>
+        In
+        "F and each Ti in Args", 'Ti' is not clear.
+</description>
+<suggestion>
+        Replace "Ti" with "args"
+</suggestion>
+<notes>Pass on to editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="97"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date="2009-03-06"
+  extdoc="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2802.html"
+>
+<section>
+30.2.1.3
+</section>
+<para>
+1
+</para>
+<description>
+        detach-on-destruction may result in
+        &#8220;escaped&#8221; threads accessing objects with
+        bounded lifetime after the end of their lifetime.
+</description>
+<suggestion>
+        See document WG21 N2802=08-0312 written by Hans Boehm.
+</suggestion>
+<notes>Create an issue. To be discussed in full library group.<BR/><BR/>
+    Later: straw poll 10-0, put N2802 Alternative 2 on formal motions page.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="US"
+  num="98"
+  uknum=""
+  type=""
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.2.1.3,
+        30.2.1.4
+</section>
+<para>
+</para>
+<description>
+        The current defined behavior
+        for the std::thread destructor is to detach the thread.
+        Unfortunately, this behavior exposes programmers to tricky,
+        hard-to-diagnose, undefined behavior.
+</description>
+<suggestion>
+        Change destruction behavior to undefined behavior, with a
+        note strongly encouraging termination. See the attached
+        paper "Issues with the C++ Standard" under Chapter 30,
+        "Implicit thread detach is harmful".
+</suggestion>
+<notes>Duplicate of US 97.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="325"
+  uknum="174"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.3.3
+</section>
+<para>
+2
+</para>
+<description>
+        We believe constexpr literal values should
+        be a more natural expression of empty tag types than extern
+        objects as it should improve the compilers ability to
+        optimize the empty object away completely.
+</description>
+<suggestion>
+        Replace the
+        extern declarations: extern const defer_lock_t defer_lock;
+        extern const try_to_lock_t try_to_lock; extern const
+        adopt_lock_t adopt_lock; with constexpr values constexpr
+        defer_lock_t defer_lock{}; constexpr try_to_lock_t
+        try_to_lock{}; constexpr adopt_lock_t adopt_lock{};
+</suggestion>
+<notes>Create an issue. Move to review, attention: Howard. The current 
+    specification is a &#8220;hack&#8221;, and the proposed specification is a better 
+    &#8220;hack&#8221;.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="326"
+  uknum="176"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+30.3.3.2.1
+</section>
+<para>
+7
+</para>
+<description>
+        The precondition
+        that the mutex is not owned by this thread offers
+        introduces the risk of un-necessary undefined behaviour
+        into the program. The only time it matters whether the
+        current thread owns the mutex is in the lock operation, and
+        that will happen subsequent to construction in this case.
+        The lock operation has the identical pre-condition, so
+        there is nothing gained by asserting that precondition
+        earlier and denying the program the right to get into a
+        valid state before calling lock.
+</description>
+<suggestion>
+        Strike 30.3.3.2.1p7
+</suggestion>
+<notes>Create an issue. Move to review, attention: Howard. Proposed resolution is 
+    fine.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="327"
+  uknum="179"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.3.3.2.2
+</section>
+<para>
+4, 9, 14, 19
+</para>
+<description>
+        Not clear what
+        the specification for error condition
+        resource_deadlock_would_occur means. It is perfectly
+        possible for this thread to own the mutex without setting
+        owns to true on this specific lock object. It is also
+        possible for lock operations to succeed even if the thread
+        does own the mutex, if the mutex is recursive. Likewise, if
+        the mutex is not recursive and the mutex has been locked
+        externally, it is not always possible to know that this
+        error condition should be raised, depending on the host
+        operating system facilities. It is possible that 'i.e.' was
+        supposed to be 'e.g.' and that suggests that recursive
+        locks are not allowed. That makes sense, as the
+        exposition-only member owns is boolean and not a integer to
+        count recursive locks.
+</description>
+<suggestion>
+        Add a precondition !owns. Change the 'i.e.'
+        in the error condition to be 'e.g.' to allow for this
+        condition to propogate deadlock detection by the host OS.
+</suggestion>
+<notes>Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock 
+    means for recursive locks when you are the owner. POSIX has language on 
+    this, which should ideally be followed. Proposed fix is not quite right, for 
+    example, try_lock should have different wording from lock.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="328"
+  uknum="182"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.3.3.2.2
+</section>
+<para>
+20
+</para>
+<description>
+        There is a missing precondition that owns
+        is true, or an if(owns) test is missing from the effect
+        clause
+</description>
+<suggestion>
+        Add a
+        precondition that owns == true. Add an error condition to
+        detect a violation, rather than yield undefined behaviour.
+</suggestion>
+<notes>Handle in same issue as UK 327. Also uncertain that the proposed resolution 
+    is the correct one.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="329"
+  uknum="203"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5
+</section>
+<para>
+</para>
+<description>
+        future, promise and packaged_task provide a
+        framework for creating future values, but a simple function
+        to tie all three components together is missing. Note that
+        we only need a *simple* facility for C++0x. Advanced thread
+        pools are to be left for TR2.
+</description>
+<suggestion>
+        Provide a simple
+        function along the lines of: template&lt; typename F,
+        typename ... Args &gt; requires Callable&lt; F, Args...
+        &gt; future&lt; Callable::result_type &gt; async(
+        F&amp;&amp; f, Args &amp;&amp; ... ); Semantics are similar
+        to creating a thread object with a packaged_task invoking f
+        with forward&lt;Args&gt;(args...) but details are left
+        unspecified to allow different scheduling and thread
+        spawning implementations. It is unspecified whether a task
+        submitted to async is run on its own thread or a thread
+        previously used for another async task. If a call to async
+        succeeds, it shall be safe to wait for it from any thread.
+        The state of thread_local variables shall be preserved
+        during async calls. No two incomplete async tasks shall see
+        the same value of this_thread::get_id(). [Note: this
+        effectively forces new tasks to be run on a new thread, or
+        a fixed-size pool with no queue. If the library is unable
+        to spawn a new thread or there are no free worker threads
+        then the async call should fail.]
+</suggestion>
+<notes>
+
+The concurrency subgroup has revisited this issue and decided
+that it could be considered a defect according to the Kona
+compromise. A task group was formed led by Lawrence Crowl
+(crowl_at_[hidden]) and Bjarne Stroustrup (bs_at_[hidden]) to
+write a paper for Frankfurt proposing a simple asynchronous
+launch facility returning a future. It was agreed that the
+callable must be run on a separate thread from the caller, but
+not necessarily a brand-new thread. The proposal might or might
+not allow for an implementation that uses fixed-size or unlimited
+thread pools.<BR/><BR/>
+Bjarne in c++std-lib-23121: I think that what we agreed was that
+to avoid deadlock async() would almost certainly be specified to
+launch in a different thread from the thread that executed
+async(), but I don't think it was a specific design constraint.
+</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="330"
+  uknum="424"
+  type="Ed"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.1
+</section>
+<para>
+</para>
+<description>
+        30.5.1 (and then 30.5.7) refer to a
+        specialisation of
+        constructible_with_allocator_prefix&lt;&gt; However this
+        trait is not in the CD, so references to it should be
+        removed.
+</description>
+<suggestion>
+        Remove the
+        reference to constructible_with_allocator_prefix in 30.5.1
+        Remove paragraph 30.5.7
+</suggestion>
+<notes>Related to JP 79 and therefore subset of US 93. Should be addressed under 
+    the issue corresponding to US 93.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="79"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.1
+</section>
+<para>
+</para>
+<description>
+        The
+        concept of UsesAllocator and Allocator should be used.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class R, class Alloc&gt;
+        <BR/><BR/>
+        struct uses_allocator&lt;promise&lt;R&gt;, Alloc&gt;;
+        <BR/><BR/>
+        template &lt;class R&gt;
+        <BR/><BR/>
+        struct
+        constructible_with_allocator_prefix&lt;promise&lt;R&gt;
+        &gt;;
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template&lt;class R, Allocator Alloc&gt;
+        <BR/><BR/>concept_map
+        UsesAllocator&lt;promise&lt;R&gt;, Alloc&gt;;
+</suggestion>
+<notes>Subset of US 93. Should be addressed under the issue corresponding to US 93.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="331"
+  uknum="192"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.3
+</section>
+<para>
+</para>
+<description>
+        Not clear what
+        it means for a public constructor to be 'exposition only'.
+        If the intent is purely to support the library calling this
+        constructor then it can be made private and accessed
+        through friendship. Otherwise it should be documented for
+        public consumption.
+</description>
+<suggestion>
+        Declare the constructor as private with a
+        note about intended friendship, or remove the
+        exposition-only comment and document the semantics.
+</suggestion>
+<notes>Create an issue. Assigned to Detlef. Suggested resolution probably makes 
+    sense.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="332"
+  uknum="194"
+  type="Ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.4
+</section>
+<para>
+</para>
+<description>
+        It is not clear
+        without reference to the original proposal how to use a
+        future. In particular, the only way for the user to
+        construct a future is via the promise API which is
+        documented after the presentation of future. Most library
+        clauses feature a small description of their components and
+        intended use, it would be most useful in this case.
+</description>
+<suggestion>
+        Provide a small introductory paragraph,
+        docuenting intended purpose of the future class template
+        and the way futures can only be created via the promise
+        API.
+</suggestion>
+<notes>Pass on to editor. Detlef has volunteered to provide some wording.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="333"
+  uknum="195"
+  type="Ge"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.4
+</section>
+<para>
+5
+</para>
+<description>
+        We expect the complicated 3-signature
+        specifcation for future::get() to be simplified to a single
+        signature with a requires clause by the application of
+        concepts.
+</description>
+<suggestion>
+        Requires fully baked concepts for clause 30
+</suggestion>
+<notes>Subset of US 93. Should be addressed under the issue corresponding to US 93.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="334"
+  uknum="196"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+30.5.4
+</section>
+<para>
+5
+</para>
+<description>
+        Behaviour of
+        get() is undefined if calling get() while not is_ready().
+        The intent is that get() is a blocking call, and will wait
+        for the future to become ready.
+</description>
+<suggestion>
+        Effects: If is_ready() would return false,
+        block on the asynchronous result associated with *this.
+</suggestion>
+<notes>Create an issue. Move to review, attention: Howard. Proposed resolution is 
+    fine.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="335"
+  uknum="436"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.4
+</section>
+<para>
+</para>
+<description>
+        std::unique_future is MoveConstructible, so you can
+        transfer the association with an asynchronous result from
+        one instance to another. However, there is no way to
+        determine whether or not an instance has been moved from,
+        and therefore whether or not it is safe to wait for it.
+        std::promise&lt;int&gt; p; std::unique_future&lt;int&gt;
+        uf(p.get_future()); std::unique_future&lt;int&gt;
+        uf2(std::move(uf)); uf.wait(); // oops, uf has no result to
+        wait for.
+</description>
+<suggestion>
+        Add a "waitable()" function to
+        unique_future (and shared_future) akin to
+        std::thread::joinable(), which returns true if there is an
+        associated result to wait for (whether or not it is ready).
+        Then we can say: if(uf.waitable()) uf.wait();
+</suggestion>
+<notes>Create an issue. Requires input from Howard. Probably NAD.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="336"
+  uknum="437"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.4
+</section>
+<para>
+</para>
+<description>
+        It is possible
+        to transfer ownership of the asynchronous result from one
+        unique_future instance to another via the move-constructor.
+        However, it is not possible to transfer it back, and nor is
+        it possible to create a default-constructed unique_future
+        instance to use as a later move target. This unduly limits
+        the use of unique_future in code. Also, the lack of a
+        move-assignment operator restricts the use of unique_future
+        in containers such as std::vector - vector::insert requires
+        move-assignable for example.
+</description>
+<suggestion>
+        Add a default constructor with the
+        semantics that it creates a unique_future with no
+        associated asynchronous result. Add a move-assignment
+        operator which transfers ownership.
+</suggestion>
+<notes>Create an issue. Detlef will look into it.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="80"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.4,
+        30.5.5
+</section>
+<para>
+</para>
+<description>
+        Typo, duplicated "&gt;"
+        <BR/><BR/>"class
+        Period&gt;&gt;"
+</description>
+<suggestion>
+        Remove one
+</suggestion>
+<notes>Pass on to editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="337"
+  uknum="198"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.5
+</section>
+<para>
+</para>
+<description>
+        shared_future
+        should support an efficient move constructor that can avoid
+        unnecessary manipulation of a reference count, much like
+        shared_ptr
+</description>
+<suggestion>
+        Add a move constructor
+</suggestion>
+<notes>Create an issue. Detlef will look into it.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="338"
+  uknum="223"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.5
+</section>
+<para>
+</para>
+<description>
+        shared_future is currently
+        CopyConstructible, but not CopyAssignable. This is
+        inconsistent with shared_ptr, and will surprise users.
+        Users will then write work-arounds to provide this
+        behaviour. We should provide it simply and efficiently as
+        part of shared_future. Note that since the shared_future
+        member functions for accessing the state are all declared
+        const, the original usage of an immutable shared_future
+        value that can be freely copied by multiple threads can be
+        retained by declaring such an instance as "const
+        shared_future".
+</description>
+<suggestion>
+        Remove "=delete"
+        from the copy-assignment operator of shared_future. Add a
+        move-constructor shared_future(shared_future&amp;&amp;
+        rhs), and a move-assignment operator shared_future&amp;
+        operator=(shared_future&amp;&amp; rhs). The postcondition
+        for the copy-assignment operator is that *this has the same
+        associated state as rhs. The postcondition for the
+        move-constructor and move assignment is that *this has the
+        same associated as rhs had before the
+        constructor/assignment call and that rhs has no associated
+        state.
+</suggestion>
+<notes>Create an issue. Detlef will look into it.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="339"
+  uknum="200"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+30.5.6
+</section>
+<para>
+6, 7
+</para>
+<description>
+        Move assignment is goiing in the wrong
+        direction, assigning from *this to the passed rvalue, and
+        then returning a reference to an unusable *this
+</description>
+<suggestion>
+        Strike 6. 7
+        Postcondition: associated state of *this is the same as the
+        associated state of rhs before the call. rhs has no
+        associated state.
+</suggestion>
+<notes>Create an issue. Move to review, attention: Howard. Proposed resolution is 
+    fine.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="340"
+  uknum="201"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp="accepted"
+  date=""
+  extdoc=""
+>
+<section>
+30.5.6
+</section>
+<para>
+11, 12, 13
+</para>
+<description>
+        There is an
+        implied postcondition that the state of the promise is
+        transferred into the future leaving the promise with no
+        associated state. It should be spelled out.
+</description>
+<suggestion>
+        Postcondition: *this has no associated
+        state.
+</suggestion>
+<notes>Create an issue. Move to review, attention: Howard. Proposed resolution is 
+    fine.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="341"
+  uknum="122"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.6
+</section>
+<para>
+</para>
+<description>
+        promise::swap accepts its parameter by
+        lvalue reference. This is inconsistent with other types
+        that provide a swap member function, where those swap
+        functions accept an rvalue reference
+</description>
+<suggestion>
+        Change promise::swap to take an rvalue
+        reference.
+</suggestion>
+<notes>Create an issue. Detlef will look into it. Probably ready as it.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="342"
+  uknum="123"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.6
+</section>
+<para>
+</para>
+<description>
+        std::promise is
+        missing a non-member overload of swap. This is inconsistent
+        with other types that provide a swap member function
+</description>
+<suggestion>
+        Add a non-member overload void
+        swap(promise&amp;&amp; x,promise&amp;&amp; y){ x.swap(y); }
+</suggestion>
+<notes>Create an issue. Move to review, attention: Howard. Detlef will also look 
+    into it.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="343"
+  uknum="439"
+  type="Te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.6
+</section>
+<para>
+3
+</para>
+<description>
+        The move constructor of a std::promise
+        object does not need to allocate any memory, so the
+        move-construct-with-allocator overload of the constructor
+        is superfluous.
+</description>
+<suggestion>
+        Remove the
+        constructor with the signature template &lt;class
+        Allocator&gt; promise(allocator_arg_t, const Allocator&amp;
+        a, promise&amp; rhs);
+</suggestion>
+<notes>Create an issue. Detlef will look into it. Will solicit feedback from Pablo. 
+    Note that &#8220;rhs&#8221; argument should also be an rvalue reference in any case.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="JP"
+  num="81"
+  uknum=""
+  type="ed"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+30.5.8
+</section>
+<para>
+</para>
+<description>
+        There are not requirements for F and a concept of Allocator
+        dose not use.
+</description>
+<suggestion>
+        Correct as follows.
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class F&gt;
+        <BR/><BR/>
+        explicit packaged_task(F f);
+        <BR/><BR/>
+        template &lt;class F, class Allocator&gt;
+        <BR/><BR/>
+        explicit packaged_task(allocator_arg_t, const
+        Allocator&amp; a, F f);
+        <BR/><BR/>
+        template &lt;class F&gt;
+        <BR/><BR/>
+        explicit packaged_task(F&amp;&amp; f);
+        <BR/><BR/>
+        template &lt;class F, class Allocator&gt;
+        <BR/><BR/>
+        explicit packaged_task(allocator_arg_t, const
+        Allocator&amp; a, F&amp;&amp; f);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        should be
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class F&gt;
+        <BR/><BR/>
+        <u>requires CopyConstructible&lt;F&gt; &amp;&amp;
+        Callable&lt;F, ArgTypes...&gt;</u>
+        <BR/><BR/>
+        &amp;&amp; Convertible&lt;Callable&lt;F,
+        ArgTypes...&gt;::result_type, R&gt;
+        <BR/><BR/>
+        explicit packaged_task(F f);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class F, <u>Allocator Alloc</u>&gt;
+        <BR/><BR/>
+        <u>requires CopyConstructible&lt;F&gt; &amp;&amp;
+        Callable&lt;F, ArgTypes...&gt;</u>
+        <BR/><BR/>
+        &amp;&amp; Convertible&lt;Callable&lt;F,
+        ArgTypes...&gt;::result_type, R&gt;
+        <BR/><BR/>
+        explicit packaged_task(allocator_arg_t, const
+        <u>Alloc</u>&amp; a, F f);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class F&gt;
+        <BR/><BR/>
+        <u>requires CopyConstructible&lt;F&gt; &amp;&amp;
+        Callable&lt;F, ArgTypes...&gt;</u>
+        <BR/><BR/>
+        &amp;&amp; Convertible&lt;Callable&lt;F,
+        ArgTypes...&gt;::result_type, R&gt;
+        <BR/><BR/>
+        explicit packaged_task(F&amp;&amp; f);
+        <BR/><BR/>
+        
+        <BR/><BR/>
+        template &lt;class F, <u>Allocator Alloc</u>&gt;
+        <BR/><BR/>
+        <u>requires CopyConstructible&lt;F&gt; &amp;&amp;
+        Callable&lt;F, ArgTypes...&gt;</u>
+        <BR/><BR/>
+        &amp;&amp; Convertible&lt;Callable&lt;F,
+        ArgTypes...&gt;::result_type, R&gt;
+        <BR/><BR/>explicit
+        packaged_task(allocator_arg_t, const <u>Alloc</u>&amp; a,
+        F&amp;&amp; f);
+</suggestion>
+<notes>Subset of US 93. Should be addressed under the issue corresponding to US 93. 
+    We do not consider this to be an editorial change.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="23"
+  uknum=""
+  type="te"
+  owner="CWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+Annex B
+</section>
+<para>
+p2
+</para>
+<description>
+        DE-23 Recursive
+        use of constexpr functions appears to be permitted. Since
+        such functions may be required to be evaluated at
+        compile-time, Annex B "implementation quantities" should
+        specify a maximum depth of recursion.
+</description>
+<suggestion>
+        In Annex B, specify a recursion depth of 256 or a larger
+        value.
+</suggestion>
+<notes>Create issue, share with DE 25. See 
+    N2826. Attention: core group.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="24"
+  uknum=""
+  type="te"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+Annex B
+</section>
+<para>
+p2
+</para>
+<description>
+        DE-24 The
+        number of placeholders for "bind" is implementation-defined
+        in 20.7.12.1.4, but no minimum is suggested in Annex B.
+</description>
+<suggestion>
+        Add a miminum of 10 placeholders to Annex B.
+</suggestion>
+<notes>Create issue, proposed resolution as in comment. Attention: LWG subgroup 2. 
+    Note the section in N2800 is actually 20.6.12.1.4 [func.bind.place].</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="DE"
+  num="25"
+  uknum=""
+  type="te"
+  owner="CWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+Annex B
+</section>
+<para>
+p2
+</para>
+<description>
+        DE-25
+        Specifying a minimum of 17 recursively nested template
+        instantiations is too small for practical purposes. The
+        limit is too high to effectively limit compiler resource
+        usage, see
+        http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf
+        . The conclusion is that the metric "number of recursively
+        nested template instantiations" is inapposite.
+</description>
+<suggestion>
+        Remove the bullet "Recursively nested template
+        instantiations [17]".
+</suggestion>
+<notes>Create issue, share with DE 23. Attention: core group.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="38"
+  uknum=""
+  type="ed"
+  owner="LWG"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+C.2
+        [diffs.library]
+</section>
+<para>
+1
+</para>
+<description>
+        What is ISO/IEC 1990:9899/DAM
+        1? My guess is that's a typo for ISO/IEC
+        <BR/><BR/>9899/Amd.1:1995 which I'd
+        have expected to be referenced here (the tables
+        <BR/><BR/>make reference to things
+        which were introduced by Amd.1).
+</description>
+<suggestion>
+        One need probably a reference
+        to the document which introduce char16_t and
+        <BR/><BR/>char32_t in C (ISO/IEC TR 19769:2004?).
+</suggestion>
+<notes>Create issue. Document in question should be C99, not C90+amendment1. The 
+    rest of the section requires careful review for completeness. Example &lt;cstdint&gt; 
+    18.3.1 [csdtint.sym]. Assign to C liasons.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="UK"
+  num="344"
+  uknum="136"
+  type="Ge"
+  owner="CWG"
+  issue=""
+  disp="rejected"
+  date=""
+  extdoc=""
+>
+<section>
+Appendix D
+</section>
+<para>
+</para>
+<description>
+        It is desirable to allow some mechanism to
+        support phasing out of deprecated features in the future.
+        Allowing compilers to implement a mode where deprecated
+        features are not available is a good first step.
+</description>
+<suggestion>
+        Add to the definition of deprecated
+        features permission for compilers to maintain a
+        conditionally supported mode where deprecated features can
+        be disabled, so long as they also default to a mode where
+        all deprecated features are supported.
+</suggestion>
+<notes>Deals with deprecation, needs to be discussed in general group. Attention: 
+    Bill Plauger<BR/><BR/>
+    Update 2009-03-04: Mark as NAD. Compiler switches are outside the domain of 
+    the standard.</notes>
+<rationale>
+</rationale>
+</comment>
+
+<comment
+  nb="FR"
+  num="39"
+  uknum=""
+  type="ed"
+  owner="editor"
+  issue=""
+  disp=""
+  date=""
+  extdoc=""
+>
+<section>
+Index
+</section>
+<para>
+</para>
+<description>
+        Some definitions seem not
+        indexed (such as <I>trivially copyable</I> or
+        <I>sequenced before</I>), indexing
+        them would be useful (and marking specially the page -- say
+        bold or italic -- which reference to the definition would
+        increase the usefulness; having a separate index of all
+        definitions is something which could also be considered).
+</description>
+<suggestion>
+</suggestion>
+<notes>  Pass to the editor.</notes>
+<rationale>
+</rationale>
+</comment>
+
+</document>