<HTML>
<STYLE>
 ins {text-decoration:none;font-weight:bold;background-color:#A0FFA0}
 del {text-decoration:line-through;background-color:#FFA0A0}
</STYLE>
<HEAD>
<TITLE>
Additional Core Language Issue Resolutions for Madrid
</TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
 <TR><TD ALIGN="RIGHT" VALIGN="TOP"><B>Document:&#160;&#160;</B></TD><TD>PL22.16/11-0032 = WG21 N3262</TD></TR>
 <TR><TD ALIGN="RIGHT" VALIGN="TOP"><B>Author:&#160;&#160;&#160;</B></TD>
 <TD>William M. (Mike) Miller<BR/>Edison Design Group, Inc.</TD></TR>
 <TR><TD ALIGN="RIGHT"><B>Date:&#160;&#160;&#160;</B></TD><TD>2011-03-25</TD></TR>
</TABLE>

<BR/><BR/><BR/><BR/><BR/>

<P><H2>Additional Core Language Issue Resolutions for Madrid</H2></P>

<P>The following issue resolutions, in addition to those in "ready"
and "tentatively ready" status in document PL22.16/11-0006 = N3236,
have been approved by the Core Language Working Group to be applied to
the FDIS.</P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#531">531</A>. Defining members of explicit specializations</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.7.3 paragraphs 4-6 as follows:</P>

<BLOCKQUOTE>

<P>A member function, <ins>a member function template,</ins> a member
class<ins>, a member class template,</ins> or a static data member of
a class template may be explicitly specialized for a class
specialization that is implicitly instantiated; in this case, the
definition of the class template shall precede the explicit
specialization...</P>

<P>A member of an explicitly specialized class is not implicitly
instantiated from the member declaration of the class template;
instead, the member of the class template specialization shall itself
be explicitly defined <ins>if its definition is required</ins>.  In
this case, the definition of the class template explicit
specialization shall be in scope at the point <del>of declaration of
the explicit specialization of</del> <ins>at which</ins> the member
<ins>is defined</ins>.  The definition of an explicitly specialized
class... <del>Definitions of members</del> <ins>Members</ins> of an
explicitly specialized class <ins>template</ins> are defined in the
same manner as members of normal classes, and not using the
<ins><TT>template&lt;&gt;</TT></ins> syntax <del>for explicit
specialization</del>. <ins>The same is true when defining a member of
an explicitly specialized member class.  However,
<TT>template&lt;&gt;</TT> is used in defining a member of an
explicitly specialized member class template that is specialized as a
class template.</ins> [<I>Example:</I></P>

<PRE>
  template&lt;class T&gt; struct A {
<del>    void f(T) { /* ... */ }</del>
<ins>    struct B { };
    template&lt;class U&gt; struct C { };</ins>
   };

  template&lt;&gt; struct A&lt;int&gt; {
    void f(int);
  };

  void h() {
    A&lt;int&gt; a;
    a.f(16);     //<SPAN style="font-family:Times;font-style:italic"> </SPAN>A&lt;int&gt;::f<SPAN style="font-family:Times;font-style:italic"> must be defined somewhere</SPAN>
  }

  //<SPAN style="font-family:Times;font-style:italic"> <del>explicit specialization syntax</del> </SPAN><ins>template&lt;&gt;</ins><SPAN style="font-family:Times;font-style:italic"> not used for a member of <ins>an</ins></SPAN>
  //<SPAN style="font-family:Times;font-style:italic"> explicitly specialized class template <del>specialization</del></SPAN>
  void A&lt;int&gt;::f(int) { /* ... */ }

<ins>  template&lt;&gt; struct A&lt;char&gt;::B {
    void f();
  };  
  //<SPAN style="font-family:Times;font-style:italic"> </SPAN>template&lt;&gt;<SPAN style="font-family:Times;font-style:italic"> also not used when defining a member of</SPAN>
  //<SPAN style="font-family:Times;font-style:italic"> an explicitly-specialized member class</SPAN>
  void A&lt;char&gt;::B::f() { /* ... */ }

  template&lt;&gt; template&lt;class U&gt; struct A&lt;char&gt;::C {
    void f();
  };
  //<SPAN style="font-family:Times;font-style:italic"> </SPAN>template&lt;&gt;<SPAN style="font-family:Times;font-style:italic"> is used when defining a member of an explicitly</SPAN>
  //<SPAN style="font-family:Times;font-style:italic"> specialized member class template specialized as a class template</SPAN>
  template&lt;&gt;
  template&lt;class U&gt; void A&lt;char&gt;::C&lt;U&gt;::f() { /* ... */ }

  template&lt;&gt; struct A&lt;short&gt;::B {
    void f();
  };  
  template&lt;&gt; void A&lt;short&gt;::B::f() { /* ... */ }  //<SPAN style="font-family:Times;font-style:italic"> error: </SPAN>template&lt;&gt;<SPAN style="font-family:Times;font-style:italic"> not permitted</SPAN>

  template&lt;&gt; template&lt;class U&gt; struct A&lt;short&gt;::C {
    void f();
  };
  template&lt;class U&gt; void A&lt;short&gt;::C&lt;U&gt;::f() { /* ... */ }  //<SPAN style="font-family:Times;font-style:italic"> error: requires </SPAN>template&lt;&gt;</ins>
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P>If a template, a member template or <del>the</del> <ins>a</ins>
member of a class template is explicitly specialized then that
specialization shall be declared before the first use of that
specialization that would cause an implicit instantiation to take
place...</P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#547">547</A>. Partial specialization on member function types</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 8.3.5 paragraph 6 as follows:</P>

<BLOCKQUOTE>

A <I>cv-qualifier-seq</I> <ins>or a <I>ref-qualifier</I></ins>
shall only be part of<ins>:</ins>
<UL><LI><P>the function type for
a non-static member function,</P></LI>

<LI><P>the function type to which a pointer to
member refers,</P></LI>

<LI><P><del>or </del>the top-level function type of a function typedef
declaration<del>.</del> <ins>or <I>alias-declaration</I>,</ins></P></LI>

<LI><P><ins>the <I>type-id</I> in the default argument of a
<I>type-parameter</I> (14.1 [temp.param]), or</ins></P></LI>

<LI><P><ins>the <I>type-id</I> of a <I>template-argument</I> for a
<I>type-parameter</I> (14.2 [temp.names]).</ins></P></LI>

</UL>

<del>[<I>Note:</I> A function type that has a
<I>cv-qualifier-seq</I> is not a cv-qualified type; there are no
cv-qualified function types. &#8212;<I>end note</I>]</del> The effect of a
<I>cv-qualifier-seq</I> in a function declarator is not the same as
adding cv-qualification on top of the function type. In the latter
case, the cv-qualifiers are ignored. <ins>[<I>Note:</I> A function
type that has a <I>cv-qualifier-seq</I> is not a cv-qualified type;
there are no cv-qualified function types. &#8212;<I>end
note</I>]</ins> [<I>Example:</I>...  &#8212;<I>end example</I>] <del>A
<I>ref-qualifier</I> shall only be part of the function type for a
non-static member function, the function type to which a pointer to
member refers, or the top-level function type of a function typedef
declaration.</del> The return type...

</BLOCKQUOTE>

<I>[Drafting note: this resolution transforms the running text of
the first sentence of 8.3.5 paragraph 6 into a bulleted list.]</I>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#580">580</A>. Access in <I>template-parameter</I>s of member and friend definitions</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 11 [class.access] paragraphs 6-7 as follows:</P>

<BLOCKQUOTE>

<P>All access controls in Clause 11 [class.access] affect the ability
to access a class member name from <ins>the declaration of</ins> a
particular <del>scope</del> <ins>entity, including parts of the
declaration preceding the name of the entity being declared and, if
the entity is a class, the definitions of members of the class
appearing outside the class's <I>member-specification</I></ins>.
<ins>[<I>Note:</I> this access also applies to implicit references to
constructors, conversion functions, and destructors.  &#8212;<I>end
note</I>]</ins> <del>For purposes of access control, the
<I>base-specifier</I>s of a class and the definitions of class members
that appear outside of the class definition are considered to be
within the scope of that class.  In particular, access controls apply
as usual to member names accessed as part of a function return type,
even though it is not possible to determine the access privileges of
that use without first parsing the rest of the function declarator.
Similarly, access control for implicit calls to the constructors, the
conversion functions, or the destructor called to create and destroy a
static data member is performed as if these calls appeared in the
scope of the member's class.</del> [<I>Example:</I></P>

<PRE>
  class A {
    typedef int I;    //<SPAN style="font-family:Times;font-style:italic"> private member</SPAN>
    I f();
    friend I g(I);
    static I x;
<ins>    template&lt;int&gt; struct Q;
    template&lt;int&gt; friend struct R;</ins>
  protected:
    struct B { };
  };

  A::I A::f() { return 0; }
  A::I g(A::I p = A::x);
  A::I g(A::I p) { return 0; }
  A::I A::x = 0;
<ins>  template&lt;A::I&gt; struct A::Q { };
  template&lt;A::I&gt; struct R { };
</ins>
  struct D: A::B, A { };
</PRE>

<P>Here, all the uses of <TT>A::I</TT> are well-formed because
<TT>A::f</TT><del> and</del><ins>,</ins> <TT>A::x</TT><ins>, and
<TT>A::Q</TT></ins> are members of class <TT>A</TT> and
<TT>g</TT> <del>is a friend</del> <ins>and <TT>R</TT> are
friends</ins> of class <TT>A</TT>. This implies, for example,
that access checking on the first use of <TT>A::I</TT> must be
deferred until it is determined that this use of <TT>A::I</TT> is
as the return type of a member of class <TT>A</TT>. Similarly,
the use of <TT>A::B</TT> as a <I>base-specifier</I> is
well-formed because <TT>D</TT> is derived from <TT>A</TT>, so
checking of <I>base-specifier</I>s must be deferred until the
entire <I>base-specifier-list</I> has been seen.  &#8212;<I>end
example</I>]</P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#758">758</A>. Missing cases of declarations that are not definitions </B></P>

<P><B>Proposed Resolution:</B></P>

<P>Change 3.1 [basic.def] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A declaration is a <I>definition</I> unless it declares a function
without specifying the function's body (8.4 [dcl.fct.def]), it
contains the <TT>extern</TT> specifier (7.1.1 [dcl.stc]) or a
<I>linkage-specification</I><SUP>25</SUP> (7.5 [dcl.link]) and neither
an <I>initializer</I> nor a <I>function-body</I>, it declares a static
data member in a class definition (<ins>9.2 [class.mem],</ins> 9.4
[class.static]), it is a class name declaration (9.1 [class.name]), it
is an <I>opaque-enum-declaration</I> (7.2 [dcl.enum]), <ins>it
is a <I>template-parameter</I> (14.1 [temp.param]), it is a
<I>parameter-declaration</I> (8.3.5 [dcl.fct]) in a
function declarator that is not the <I>declarator</I> of a
<I>function-definition</I>,</ins> or it is a
<TT>typedef</TT> declaration (7.1.3 [dcl.typedef]), <ins>an
<I>alias-declaration</I> (7.1.3 [dcl.typedef]),</ins> a
<I>using-declaration</I> (7.3.3 [namespace.udecl]), a
<I>static_assert-declaration</I> (Clause 7 [dcl.dcl]), an
<I>attribute-declaration</I> (Clause 7 [dcl.dcl]), an
<I>empty-declaration</I> (Clause 7 [dcl.dcl]), or a
<I>using-directive</I> (7.3.4 [namespace.udir]).

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#798">798</A>. Overloaded subscript operator described in clause 5</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 5.2.1 [expr.sub] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

<P>A <I>braced-init-list</I> <del>may appear as a subscript for a
user-defined <TT>operator[]</TT>. In that case, the initializer list
is treated as the initializer for the subscript argument of the
<TT>operator[]</TT>.  An initializer list</del> shall not be used with the
built-in subscript operator.</P>

<P><del>[<I>Example:</I></del></P>

<PRE>
<del>  struct X {
    Z operator[](std::initializer_list&lt;int&gt;);
  };
  X x;
  x[{1,2,3}] = 7; //<SPAN style="font-family:Times;font-style:italic"> OK: meaning </SPAN>x.operator[]({1,2,3})
  int a[10];
  a[{1,2,3}] = 7; //<SPAN style="font-family:Times;font-style:italic"> error: built-in subscript operator</SPAN></del>
</PRE>

<P><del>&#8212;<I>end example</I>]</del></P>

</BLOCKQUOTE>

<LI><P>Change 13.5.5 [over.sub] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P><TT>operator[]</TT> shall be a non-static member function with
exactly one parameter. It implements the subscripting syntax</P>

<UL><I>posfix-expression</I> <TT>[</TT> <I>expression</I> <TT>]</TT></UL>

<P><ins>or</ins></P>

<UL><ins><I>postfix-expression</I> <TT>[</TT> <I>braced-init-list</I> <TT>]</TT></ins></UL>

<P>Thus, a subscripting expression <TT>x[y]</TT> is interpreted as
<TT>x.operator[](y)</TT> for a class object <TT>x</TT> of type
<TT>T</TT> if <TT>T::operator[](T1)</TT> exists and if the operator is
selected as the best match function by the overload resolution
mechanism (13.3.3 [over.match.best]). <ins>[<I>Example:</I></ins></P>

<PRE>
<ins>  struct X {
    Z operator[](std::initializer_list&lt;int&gt;);
  };
  X x;
  x[{1,2,3}] = 7;               //<SPAN style="font-family:Times;font-style:italic"> OK: meaning </SPAN>x.operator[]({1,2,3})
  int a[10];
  a[{1,2,3}] = 7;               //<SPAN style="font-family:Times;font-style:italic"> error: built-in subscript operator</SPAN></ins>
</PRE>

<P><ins>&#8212;<I>end example</I>]</ins></P>

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#996">996</A>. Ambiguous partial specializations of member class templates</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.7.1 [temp.local] paragraph 1 as follows, creating a new
paragraph from the existing text following the new example:</P>

<BLOCKQUOTE>

<P>Unless a class template specialization has been explicitly
instantiated (14.7.2 [temp.explicit]) or explicitly specialized
(14.7.3 [temp.expl.spec]), the class template specialization is
implicitly instantiated when the specialization is referenced in a
context that requires a completely-defined object type or when the
completeness of the class type affects the semantics of the program.
The implicit instantiation of a class template specialization causes
the implicit instantiation of the declarations, but not of the
definitions or default arguments, of the class member functions,
member classes, static data members and member templates; and it
causes the implicit instantiation of the definitions of member
anonymous unions. <ins>However, for the purpose of determining whether
an instantiated redeclaration of a member is valid according to 9.2
[class.mem], a declaration that corresponds to a definition in the
template is considered to be a definition. [<I>Example:</I></ins></P>

<PRE>
<ins>  template&lt;typename T, typename U&gt;
    struct Outer {
      template&lt;typename X, typename Y&gt; struct Inner;
      template&lt;typename Y&gt; struct Inner&lt;T, Y&gt;;    //<SPAN style="font-family:Times;font-style:italic"> #1a</SPAN>
      template&lt;typename Y&gt; struct Inner&lt;T, Y&gt; {}; //<SPAN style="font-family:Times;font-style:italic"> #1b: Ok; valid redeclaration of #1a</SPAN>
      template&lt;typename Y&gt; struct Inner&lt;U, Y&gt; {}; //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
    };

    Outer&lt;int, int&gt; outer;                        //<SPAN style="font-family:Times;font-style:italic"> Error at #2.</SPAN></ins>
</PRE>

<P><ins><TT>Outer&lt;int,int&gt;::Inner&lt;int,Y&gt;</TT> is
redeclared at #1b.  (It is not defined but noted as being associated
with a definition in <TT>Outer&lt;T,U&gt;</TT>.) #2 is also a
redeclaration of #1a.  It is also noted as associated with a
definition, so it is an invalid redeclaration of the same partial
specialization. &#8212;<I>end example</I>]</ins></P>

<P>Unless a member of a class template or a member template has been
explicitly instantiated...</P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#997">997</A>. Argument-dependent lookup and dependent function template parameter types</B></P>

<P><B>Proposed resolution</B></P>

<P>Change 3.4.2 [basic.lookup.argdep] paragraph 2 as follows:</P>

<BLOCKQUOTE>

...In addition, if the argument is the name or address of a set of
overloaded functions and/or function templates, its associated classes
and namespaces are the union of those associated with each of the
members of the set, i.e., the classes and namespaces associated with
its <del>(non-dependent)</del> parameter types and return type.
<ins>Additionally, if the aforementioned set of overloaded functions
is named with a <I>template-id</I>, its associated classes
and namespaces also include those of its type
<I>template-argument</I>s and its template
<I>template-argument</I>s.</ins>

</BLOCKQUOTE>

<P>(This resolution also resolves issue 1015.)</P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1004">1004</A>. Injected-class-names as arguments for template template parameters </B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.6.1 [temp.local] paragraphs 1-5 as follows:</P>

<BLOCKQUOTE>

<P>Like normal (non-template) classes, class templates have an
injected-class-name (Clause 9 [class]).  The
injected-class-name can be used <del>with or without a
<I>template-argument-list</I></del> <ins>as a <I>template-name</I>
or a <I>type-name</I></ins>. <del>When it is used without a
<I>template-argument-list</I>, it is equivalent to the
injected-class-name followed by the <I>template-parameter</I>s of the
class template enclosed in <TT>&lt;&gt;</TT>.</del> When it is used
with a <I>template-argument-list</I>, <ins>as a
<I>template-argument</I> for a template <I>template-parameter</I>, or
as the final identifier in the <I>elaborated-type-specifier</I> of a
friend class template declaration,</ins> it refers to the <del>specified
class template specialization, which could be the current
specialization or another specialization.</del> <ins>class template
itself.  Otherwise, it is equivalent to the <I>template-name</I>
followed by the <I>template-parameter</I>s of the class template
enclosed in <TT>&lt;&gt;</TT>.</ins></P>

<P>Within the scope of a class template specialization or partial
specialization, when the injected-class-name is <del>not followed by a
<TT>&lt;</TT></del> <ins>used as a <I>type-name</I></ins>, it is
equivalent to the <del>injected-class-name</del>
<ins><I>template-name</I></ins> followed by the
<I>template-argument</I>s of the class template specialization or
partial specialization enclosed in
<TT>&lt;&gt;</TT>. [<I>Example:</I></P>

<PRE>
<ins>  template&lt;template&lt;class&gt; class T&gt; class A { };</ins>
  template&lt;class T&gt; class Y;
  template&lt;&gt; class Y&lt;int&gt; {
    Y* p;           //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>Y&lt;int&gt;
    Y&lt;char&gt;* q;     //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>Y&lt;char&gt;
<ins>    A&lt;Y&gt;* a;        //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>A&lt;::Y&gt;
    class B {
      template&lt;class&gt; friend class Y;  //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>::Y
    };</ins>
  };
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P>The injected-class-name of a class template or class template
specialization can be used either <del>with or without a
<I>template-argument-list</I></del> <ins>as a <I>template-name</I> or
a <I>type-name</I></ins> wherever it is in scope. [<I>Example:</I></P>

<PRE>
  template &lt;class T&gt; struct Base {
    Base* p;
  };

  template &lt;class T&gt; struct Derived: public Base&lt;T&gt; {
    typename Derived::Base* p;    //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>Derived::Base&lt;T&gt;
  };

<ins>  template&lt;class T, template&lt;class&gt; class U = T::template Base&gt; struct Third { };
  Third&lt;Base&lt;int&gt;&gt; t; //<SPAN style="font-family:Times;font-style:italic"> OK, default argument uses injected-class-name as a template</SPAN></ins>
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P>A lookup that finds an injected-class-name (10.2 [class.member.lookup]) can result in an ambiguity in certain cases (for
example, if it is found in more than one base class). If all of the
injected-class-names that are found refer to specializations of the
same class template, and if the name is <del>followed by a
<I>template-argument-list</I></del> <ins>used as a
<I>template-name</I></ins>, the reference refers to the class template
itself and not a specialization thereof, and is not
ambiguous. [<I>Example:</I></P>

<PRE>
  template &lt;class T&gt; struct Base { };
  template &lt;class T&gt; struct Derived: Base&lt;int&gt;, Base&lt;char&gt; {
    typename Derived::Base b;             //<SPAN style="font-family:Times;font-style:italic"> error: ambiguous</SPAN>
    typename Derived::Base&lt;double&gt; d;     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  };
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P>When the normal name of the template (i.e., the name from the
enclosing scope, not the injected-class-name) is used <del>without a
<I>template-argument-list</I></del>, it <ins>always</ins> refers to
the class template itself and not a specialization of the
template. [<I>Example:...</I></P>

</BLOCKQUOTE>

<P>(This resolution also resolves issue 602).</P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1018">1018</A>. Ambiguity between <I>simple-declaration</I> and <I>attribute-declaration</I></B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 7 [dcl.dcl] paragraph 1 as follows:</P>

<UL><I>simple-declaration:</I>
<UL><I><del>attribute-specifier-seq<SUB>opt</SUB></del> decl-specifier-seq<SUB>opt</SUB> init-declarator-list<SUB>opt</SUB></I> <TT>;</TT><BR/>
<ins><I>attribute-specifier-seq decl-specifier-seq<SUB>opt</SUB> init-declarator-list</I> <TT>;</TT></ins>
</UL>

</UL>

<BLOCKQUOTE>

...The <del>optional</del> <I>attribute-specifier-seq</I> in a
<I>simple-declaration</I> appertains to each of the entities declared
by the <I>declarator</I>s<del>; it shall not appear if the optional</del>
<ins>of the</ins> <I>init-declarator-list</I> <del>is omitted</del>...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1031">1031</A>. Optional elements in attributes</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change the grammar of 7.6.1 [dcl.attr.grammar] paragraph 1 as
follows:</P>

<UL><I>balanced-token-seq:</I>
<UL><I>balanced-token<ins><SUB>opt</SUB></ins></I><BR/>
<I>balanced-token-seq balanced-token</I>
</UL>
</UL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1032">1032</A>. Empty pack expansions</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.5.3 [temp.variadic] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<P>...All of the <TT>E</TT><SUB><I>i</I></SUB> become elements in the
enclosing list.  [<I>Note:</I> The variety of list varies with the
context: <I>expression-list</I>, <I>base-specifier-list</I>,
<I>template-argument-list</I>, etc. &#8212;<I>end note</I>] <ins>When
<I>N</I> is zero, the instantiation of the expansion produces an empty
list. Such an instantiation does not alter the syntactic
interpretation of the enclosing construct, even in cases where
omitting the list entirely would otherwise be ill-formed or would
result in an ambiguity in the grammar. [<I>Example:</I></ins></P>

<PRE>
<ins>  template&lt;typename ...T&gt; struct X : T... { };
  template&lt;typename ...T&gt; void f(T ...values) {
    X&lt;T...&gt; x(values...);
  }

  template void f&lt;&gt;(); //<SPAN style="font-family:Times;font-style:italic"> okay: </SPAN>X&lt;&gt;<SPAN style="font-family:Times;font-style:italic"> has no base classes</SPAN>
                       //<SPAN style="font-family:Times;font-style:italic"> </SPAN>x<SPAN style="font-family:Times;font-style:italic"> is a variable of type </SPAN>X&lt;&gt;<SPAN style="font-family:Times;font-style:italic"> that is value-initialized</SPAN></ins>
</PRE>

<P><ins>&#8212;<I>end example</I>]</ins></P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1033">1033</A>. Restrictions on alignment attributes</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 7.6.2 [dcl.align] paragraph 5 as follows:</P>

<BLOCKQUOTE>

The combined effect of all <I>alignment-specifier</I>s in a
declaration shall not specify an alignment that is less strict than
the alignment that would <del>otherwise</del> be required for the
entity being declared <ins>if all <I>alignment-specifier</I>s were
omitted (including those in other declarations)</ins>.

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1035"/>1035</A>. Omitted and required <I>decl-specifier</I>s</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 9.2 [class.mem] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

The <I>decl-specifier-seq</I> <del>is</del> <ins>may be</ins> omitted
in constructor, destructor, and conversion function declarations
only<ins>; when declaring another kind of member the
<I>decl-specifier-seq</I> shall contain a <I>type-specifier</I> that
is not a <I>cv-qualifier</I></ins>.  The <I>member-declarator-list</I>
can be omitted...

</BLOCKQUOTE>

<LI><P>Change C.1.5 [diff.dcl], &#8220;Banning implicit
int,&#8221; as follows:</P></LI>

<BLOCKQUOTE>

In C++ a <I>decl-specifier-seq</I> must contain a
<I>type-specifier</I><ins>, unless it is followed by a declarator for
a constructor, a destructor, or a conversion function</ins>.  In the
following example...

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1042">1042</A>. Attributes in <I>alias-declaration</I>s</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change the grammar in 7 [dcl.dcl] paragraph 1 as
follows:</P></LI>

<UL><I>alias-declaration:</I>
<UL><TT>using</TT> <I>identifier <ins>attribute-specifier-seq<SUB>opt</SUB></ins></I> <TT>=</TT> <I>type-id</I> <TT>;</TT></UL>
</UL>

<LI><P>Change 7.1.3 [dcl.typedef] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

A <I>typedef-name</I> can also be introduced by an
<I>alias-declaration</I>. The <I>identifier</I> following the
<TT>using</TT> keyword becomes a <I>typedef-name</I> <ins>and the
optional <I>attribute-specifier-seq</I> following the <I>identifier</I>
appertains to that <I>typedef-name</I></ins>.  It has the same
semantics...

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1055"/>1055</A>. Permissible uses of <TT>void</TT></B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 3.9.1 [basic.fundamental] paragraph 9 as follows:</P></LI>

<BLOCKQUOTE>

...Any expression can be explicitly converted to type <I>cv</I>
<TT>void</TT> (5.4 [expr.cast]). An expression of type
<TT>void</TT> shall be used only as an expression statement
(6.2 [stmt.expr]), as an operand of a comma expression
(5.18 [expr.comma]), as a second or third operand of
<TT>?:</TT> (5.16 [expr.cond]), as the operand of
<TT>typeid</TT> <ins>or <TT>decltype</TT></ins>, <del>or</del> as the
expression in a return statement (6.6.3 [stmt.return]) for a
function with the return type <TT>void</TT><ins>, or as the operand
of an explicit conversion to type <I>cv</I> <TT>void</TT></ins>.

</BLOCKQUOTE>

<LI><P>Change 5.16 [expr.cond] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

If either the second or the third operand has type <del>(possibly
cv-qualified)</del> <TT>void</TT>, then...

</BLOCKQUOTE>

<LI><P>Change 6.6.3 [stmt.return] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

A return statement with an expression of type
<del>&#8220;<I>cv</I></del> <TT>void</TT><del>&#8221;</del> can be
used only in functions with a return type of <I>cv</I> <TT>void</TT>;
the expression is evaluated just before the function returns to its
caller.

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1056">1056</A>. Template aliases, member definitions, and the current instantiation</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.6.2.1 [temp.dep.type] paragraph 1 as
follows:</P>

<BLOCKQUOTE>

<P>In the definition of a class template, a nested class of a class
template, a member of a class template, or a member of a nested class
of a class template, a name refers to the <I>current instantiation</I>
if it is</P>

<UL><LI><P>the injected-class-name (Clause [class]) of
the class template or nested class,</P></LI>

<LI><P>in the definition of a primary class template, the name of the
class template followed by the template argument list of the primary
template (as described below) enclosed in <TT>&lt;&gt;</TT> <ins>(or
an equivalent template alias specialization)</ins>,</P></LI>

<LI><P>in the definition of a nested class of a class template, the
name of the nested class referenced as a member of the current
instantiation, or</P></LI>

<LI><P>in the definition of a partial specialization, the name of the
class template followed by the template argument list of the partial
specialization enclosed in <TT>&lt;&gt;</TT> <ins>(or an equivalent
template alias specialization)</ins>. If the <I>n</I>th template
parameter is a parameter pack, the <I>n</I>th template argument is a
pack expansion (14.5.3 [temp.variadic]) whose pattern is the name
of the parameter pack.</P></LI>

</UL>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1057">1057</A>. <TT>decltype</TT> and the current instantiation</B></P>

<P><B>Proposed resolution:</B></P>

<P>Add the following as a new paragraph following 14.4 [temp.type]
paragraph 1:</P>

<BLOCKQUOTE>

<ins>If an expression <TT>e</TT> involves a template parameter,
<TT>decltype(e)</TT> denotes a unique dependent type. Two such
<I>decltype-specifier</I>s refer to the same type only if their
<I>expression</I>s are equivalent (14.5.6.1
[temp.over.link]). [<I>Note:</I> However, it may be aliased, e.g., by a
<I>typedef-name</I> &#8212;<I>end note</I>].</ins>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1074">1074</A>. Value-dependent <I>noexcept-expression</I>s</B></P>

<P><B>Proposed resolution:</B></P>

<P>Delete &#8220;<TT>noexcept(</TT> <I>expression</I> <TT>)</TT>&#8221;
from the list in 14.6.2.3 [temp.dep.constexpr] paragraph 3.</P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1079">1079</A>. Overload resolution involving aggregate initialization</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 13.3.3.2 [over.ics.rank]
paragraph 3 bullet 2 as follows:</P>

<UL><LI><P>User-defined conversion sequence <TT>U1</TT> is a better
conversion sequence than another user-defined conversion sequence
<TT>U2</TT> if they contain the same user-defined conversion function
or constructor <ins>or aggregate initialization,</ins> and if the
second standard conversion sequence of <TT>U1</TT> is better than the
second standard conversion sequence of <TT>U2</TT>.</P></LI></UL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1082">1082</A>. Implicit copy function if subobject has none?</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 12.8 [class.copy] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

If the class definition does not explicitly declare a copy
constructor, <del>there is no user-declared move constructor, and
there is no user-declared move assignment operator, a copy constructor
is implicitly declared as defaulted (8.4.2
[dcl.fct.def.default])</del> <ins>one is declared
<I>implicitly</I>. If the class definition declares a move constructor
or move assignment operator, the implicitly declared copy constructor
is defined as deleted; otherwise, it is defined as defaulted (8.4
[dcl.fct.def])</ins>. <del>Such an implicit declaration</del> <ins>The
latter case</ins> is deprecated if the class has a user-declared copy
assignment operator or a user-declared destructor. Thus, for the class
definition...

</BLOCKQUOTE>

<LI><P>Change 12.8 [class.copy] paragraph 19 as follows:</P></LI>

<BLOCKQUOTE>

If the class definition does not explicitly declare a copy assignment
operator, <del>there is no user-declared move constructor, and there
is no user-declared move assignment operator, a copy assignment
operator is implicitly declared as defaulted (8.4.2
[dcl.fct.def.default])</del> <ins>one is declared
<I>implicitly</I>. If the class definition declares a move constructor
or move assignment operator, the implicitly declared copy assignment
operator is defined as deleted; otherwise, it is defined as defaulted
(8.4 [dcl.fct.def])</ins>.  <del>Such implicit declaration</del>
<ins>The latter case</ins> is deprecated if the class has a
user-declared copy constructor or a user-declared destructor.  The
implicitly-declared copy assignment operator for a class <TT>X</TT>
will have the form...

</BLOCKQUOTE>

<LI><P>Change D.3 [depr.impldec] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

The implicit <del>declaration</del> <ins>definition</ins> of a copy
constructor <ins>as defaulted</ins> is deprecated if the class has a
user-declared copy assignment operator or a user-declared
destructor. The implicit <del>declaration</del> <ins>definition</ins>
of a copy assignment operator <ins>as defaulted</ins> is deprecated if
the class has a user-declared copy constructor or a user-declared
destructor (12.4 [class.dtor], 12.8 [class.copy]). <ins>In a future
revision of the Standard, these implicit definitions could become
deleted (8.4 [dcl.fct.def]).</ins>

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1088">1088</A>. Dependent non-type template arguments</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Add a new paragraph at the end of
14.6.2.3 [temp.dep.constexpr]:</P></LI>

<BLOCKQUOTE>

<ins>An <I>id-expression</I> is value-dependent if it names a member
of an unknown specialization.</ins>

</BLOCKQUOTE>

<LI><P>Change 14.6.2.4 [temp.dep.temp] paragraphs 2-3 as follows:</P></LI>

<BLOCKQUOTE>

<P><del>An integral</del> <ins>A</ins> non-type
<I>template-argument</I> is dependent if <ins>its type is dependent
or</ins> the constant expression it specifies is value-dependent.</P>

<P><del>A non-integral</del> <ins>Furthermore, a</ins> non-type
<I>template-argument</I> is dependent if <del>its type is dependent or it
has either of the following forms</del></P>

<UL><del><I>qualified-id</I></del></UL>
<UL><del><TT>&amp;</TT> <I>qualified-id</I></del></UL>

<P><del>and contains a <I>nested-name-specifier</I> which specifies a
<I>class-name</I> that names a dependent type</del> <ins>the
corresponding non-type <I>template-parameter</I> is of reference or
pointer type and the <I>template-argument</I> designates or points to
a member of the current instantiation or a member of a dependent
type</ins>.</P>

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1090">1090</A>. Alignment of subobjects</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 3.11 [basic.align] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A <I>fundamental alignment</I> is represented by an alignment less
than or equal to the greatest alignment supported by the
implementation in all contexts, which is equal to
<TT>alignof(std::max_align_t)</TT> (18.2 [support.types]).  <ins>The
alignment required for a type might be different when it is used as
the type of a complete object and when it is used as the type of a
subobject.  [<I>Example:</I></ins>

<PRE>
<ins>  struct B { long double d; };
  struct D: virtual B { char c; };</ins>
</PRE>

<P><ins>When <TT>D</TT> is the type of a complete object, it will have a
subobject of type <TT>B</TT>, so it must be aligned appropriately for
a <TT>long double</TT>.  If <TT>D</TT> appears as a subobject of
another object that also has <TT>B</TT> as a virtual base class, the
<TT>B</TT> subobject might be part of a different subobject, reducing
the alignment requirement on the <TT>D</TT> subobject.
&#8212;<I>end example</I>] The result of the <TT>alignof</TT>
operator reflects the alignment requirement of the type in the
complete-object case.</ins></P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1095">1095</A>. List-initialization of references</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 8.5 [dcl.init] paragraph 16 bullet 1
as follows:</P></LI>

<UL><LI><P>If the initializer is a <I>braced-init-list</I>, the object
<ins>or reference</ins> is list-initialized (8.5.4 [dcl.init.list]).</P></LI></UL>

<LI><P>Change 8.5.4 [dcl.init.list] paragraph 3 bullet 7 as
follows:</P></LI>

<UL><LI><P>Otherwise, if the initializer list has a single element,
the object <ins>or reference</ins> is initialized from that element;
if a narrowing conversion (see below) is required to convert the
element to <TT>T</TT>, the program is ill-formed.</P></LI></UL>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1101">1101</A>. Non-integral initialized static data members</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 9.4.2 [class.static.data] paragraph 3 as follows:</P>

<BLOCKQUOTE>

If a <ins>non-volatile <TT>const</TT></ins> <TT>static</TT> data
member is of <del><TT>const</TT> literal</del> <ins>integral or
enumeration</ins> type, its declaration in the class definition can
specify a
<I>brace-or-equal-initializer</I> in which every
<I>initializer-clause</I> that is an <I>assignment-expression</I> is a
constant expression <ins>(5.19 [expr.const])</ins>. A
<TT>static</TT> data member of literal type can be declared in the
class definition with the <TT>constexpr</TT> specifier...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1166">1166</A>. <I>exception-declaration</I>s that do not declare objects</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 15.3 [except.handle] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

The <I>exception-declaration</I> in a <I>handler</I> describes the
type(s) of exceptions that can cause that <I>handler</I> to be
entered. The <I>exception-declaration</I> shall not denote an
incomplete type<ins>, an abstract class type,</ins> or an rvalue
reference type. The <I>exception-declaration</I> shall not denote a
pointer or reference to an incomplete type, other than <TT>void*</TT>,
<TT>const void*</TT>, <TT>volatile void*</TT>, or <TT>const volatile
void*</TT>.

</BLOCKQUOTE>

<LI><P>Change 15.3 [except.handle] paragraph 16 as follows:</P></LI>

<BLOCKQUOTE>

<del>The object declared in an <I>exception-declaration</I> or, if the
<I>exception-declaration</I></del> <ins>If the
<I>exception-declaration</I> specifies a name, it declares a variable
which is copy-initialized (8.5 [dcl.init]) from the exception
object. If the <I>exception-declaration</I> denotes an object type,
but</ins> does not specify a name, a temporary (12.2
[class.temporary]) is copy-initialized (8.5 [class.temporary]) from
the exception object.  <del>The object shall not have an abstract
class type.</del> The <del>object is destroyed</del> <ins>lifetime of
the variable or temporary ends</ins> when the handler exits, after the
destruction of any automatic objects initialized within the handler.

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1174">1174</A>. When is a pure virtual function &#8220;used?&#8221;</B></P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 3.2 [basic.def.odr] paragraph 2 as follows:</P>

<BLOCKQUOTE>

...A variable <del>or non-overloaded function</del> whose name appears
as a potentially-evaluated expression is odr-used unless it is an
object that satisfies the requirements for appearing in a constant
expression (5.19 [expr.const]) and the lvalue-to-rvalue
conversion (4.1 [conv.lval]) is immediately applied...  A
virtual member function is odr-used if it is not pure.  A
<ins>non-overloaded function whose name appears as a
potentially-evaluated expression or a</ins> member of a set of
candidate functions <del>is odr-used</del> if <del>it is</del>
selected by overload resolution when referred to from a
potentially-evaluated expression<ins>, are odr-used, unless it is a
pure virtual function and its name is not explicitly
qualified</ins>. [<I>Note:</I>...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1175">1175</A>. Disambiguating user-defined literals</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 2.14.8 [lex.ext] paragraph 1 as follows:</P>

<BLOCKQUOTE>

If a token matches both <I>user-defined-literal</I> and another
literal kind, it is treated as the latter.  [<I>Example:</I>
<TT>123_km</TT>, <TT>1.2LL</TT>, <TT>"Hello"s</TT> are all
<I>user-defined-literal</I>s, but <TT>12LL</TT> is an
<I>integer-literal</I>.  &#8212;<I>end example</I>] <ins>The syntactic
nonterminal preceding the <I>ud-suffix</I> in a
<I>user-defined-literal</I> is taken to be the longest sequence of
characters that could match that nonterminal.</ins>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1178">1178</A>. Deduction failure matching placement new</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.8.2.6 [temp.deduct.decl] paragraphs 1-2 as follows:</P>

<BLOCKQUOTE>

<P>In a declaration whose <I>declarator-id</I> refers to a
specialization of a function template, template argument deduction is
performed to identify the specialization to which the declaration
refers. Specifically, this is done for explicit instantiations
(14.7.2 [temp.explicit]), explicit specializations (14.7.3
[temp.expl.spec]), and certain friend declarations (14.5.4
[temp.friend]).  This is also done to determine whether a
<ins>deallocation</ins> function template specialization matches a
placement <TT>operator new</TT> (3.7.4.2
[basic.stc.dynamic.deallocation], 5.3.4 [expr.new]).  In all these
cases, <TT>P</TT> is the type of the function template being
considered as a potential match and <TT>A</TT> is <ins>either</ins>
the function type from the declaration <ins>or the type of the
deallocation function that would match the placement <TT>operator
new</TT> as described in 5.3.4 [expr.new]</ins>. The deduction is done
as described in 14.8.2.5 [temp.deduct.type].</P>

<P>If, for the set of function templates so considered, there is
either no match or more than one match after partial ordering has been
considered (14.5.6.2 [temp.func.order]), deduction fails and<ins>,
in the declaration cases,</ins> the <del>declaration</del>
<ins>program</ins> is ill-formed.</P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1180">1180</A>. Over-aligned class types</B></P>

<P><U>Proposed resolution:</U></P>

<P>Change 3.11 [basic.align] paragraph 3 as follows:</P>

<BLOCKQUOTE>

[<I>Note:</I> every over-aligned type is or contains a
class type <del>with a non-static data member to which an
extended alignment has been applied</del> <ins>to which extended
alignment applies (possibly through a non-static data
member)</ins>. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1184">1184</A>. Argument conversions to nondeduced parameter types</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.8.2.1 [temp.deduct.call] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>In general, the deduction process attempts to find template
argument values that will make the deduced <TT>A</TT> identical to
<TT>A</TT> (after the type <TT>A</TT> is transformed as described
above). However, there are three cases that allow a difference:</P>

<UL><LI><P>If the original <TT>P</TT> is a reference type...</P></LI>

<LI><P>The transformed <TT>A</TT> can be another pointer...</P></LI>

<LI><P>If <TT>P</TT> is a class...</TT></P></LI>

</UL>

<P><ins>[<I>Note:</I> as specified in 14.8.1 [temp.arg.explicit],
implicit conversions will be performed on a function argument to
convert it to the type of the corresponding function parameter if the
parameter contains no <I>template-parameter</I>s that participate in
template argument deduction.  Such conversions are also allowed, in
addition to the ones described in the preceding list. &#8212;<I>end
note</I>] </ins></P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1185">1185</A>. Misleading description of language linkage and member function types</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 7.5 [dcl.link] paragraph 4 as follows:</P>

<BLOCKQUOTE>

...A C language linkage is ignored <del>for</del> <ins>in determining
the language linkage of</ins> the names of class members and the
<del>member</del> function type of class member functions...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1186">1186</A>. Non-dependent <TT>constexpr</TT> violations in function templates</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 7.1.5 [dcl.constexpr] paragraph 6 as follows:</P>

<BLOCKQUOTE>

If the instantiated template specialization of a constexpr function
template or member function of a class template would fail to satisfy
the requirements for a <TT>constexpr</TT> function or
<TT>constexpr</TT> constructor, that specialization is not a
<TT>constexpr</TT> function or <TT>constexpr</TT> constructor.
[<I>Note:</I> if the function is a member function it will still be
<TT>const</TT> as described below.  <del>Implementations are
encouraged to issue a warning if a function is rendered not
<TT>constexpr</TT> by a non-dependent construct.</del> &#8212;<I>end
note</I>] <ins>If no specialization of the template would yield a
<TT>constexpr</TT> function or <TT>constexpr</TT> constructor, the
program is ill-formed; no diagnostic required.</ins>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1188">1188</A>. Type punning in constant expressions</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 5.19 [expr.const] paragraph 2 as follows:</P>

<UL><LI><P>an lvalue-to-rvalue conversion...</P></LI>

<LI><P><ins>an lvalue-to-rvalue conversion (4.1 [conv.lval])
that is applied to a glvalue that refers to a non-active member of a
union or a subobject thereof;</ins></P></LI>

<LI><P>...</P></LI>

<LI><P><del>a type conversion from a pointer or pointer-to-member type to a
literal type [<I>Note:</I> a user-defined conversion invokes a function
&#8212;<I>end note</I>]</del> <ins>a <TT>reinterpret_cast</TT>
(5.2.10 [expr.reinterpret.cast])</ins>;</P></LI>

</UL>

<P>(This resolution also resolves issue 1098.)</P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1189">1189</A>. Address of distinct base class subobjects</B></P>

<P><B>Proposed resolution:</B></P>

<P><B>Change 1.8 [intro.object] paragraph 6 as follows:</B></P>

<BLOCKQUOTE>

Unless an object is a bit-field or a base class subobject of zero
size, the address of that object is the address of the first byte it
occupies. Two <del>distinct</del> objects that are <del>neither</del>
<ins>not</ins> bit-fields <del>nor base class subobjects of zero size
shall have distinct addresses</del> <ins>may have the same address if
one is a subobject of the other, or if at least one is a base class
subobject of zero size and they are of different types; otherwise,
they shall have distinct addresses</ins>.<SUP>4</SUP>...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1190">1190</A>. Operations on non-safely-derived pointers</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 3.7.4.3 [basic.stc.dynamic.safety] paragraph 4 as follows:</P>

<BLOCKQUOTE>

...Alternatively, an implementation may have <I>strict pointer
safety</I>, in which case<del>, if</del> a pointer value that is not a
safely-derived pointer value is <del>dereferenced or deallocated,
and</del> <ins>an invalid pointer value, unless</ins> the referenced
complete object is of dynamic storage duration and has <del>not</del>
previously been declared reachable (20.9.10 [util.smartptr])<del>, the behavior is undefined</del>. [<I>Note:</I>
<del>this</del> <ins>The effect of using an invalid pointer value
(including passing it to a deallocation function) is undefined, see
3.7.4.2 [basic.stc.dynamic.deallocation]. This</ins> is true even if the
unsafely-derived pointer value might compare equal to some
safely-derived pointer value. &#8212;<I>end note</I>] It is
implementation defined...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1192">1192</A>. Inadvertent change to ODR and templates</B></P>

<P><B>Proposed resolution</B></P>

<P>Change 3.2 [basic.def.odr] paragraph 5 as follows:</P>

<BLOCKQUOTE>

...If <TT>D</TT> is a template and is defined in more than one
translation unit, then the <del>last four</del> <ins>preceding</ins>
requirements <del>from the list above</del> shall apply
<ins>both</ins> to names from the template's enclosing scope used in
the template definition (14.6.3 [temp.nondep]), and also to
dependent names at the point of instantiation (14.6.2 [temp.dep])...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1196">1196</A>. Definition required for explicit instantiation after explicit specialization?</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.7.2 [temp.explicit] paragraphs 3-4 as follows:</P>

<BLOCKQUOTE>

<P><del>A declaration of a function template shall be in scope at the
point of the explicit instantiation of the function template. A
definition of the class or class template containing a member function
template shall be in scope at the point of the explicit instantiation
of the member function template. A definition of a class template or
class member template shall be in scope at the point of the explicit
instantiation of the class template or class member template.  A
definition of a class template shall be in scope at the point of an
explicit instantiation of a member function or a static data member of
the class template. A definition of a member class of a class template
shall be in scope at the point of an explicit instantiation of the
member class.</del> <ins>A declaration of a function template, a
member function or static data member of a class template, or a member
function template of a class or class template shall precede an
explicit instantiation of that entity. A definition of a class
template, a member class of a class template, or a member class
template of a class or class template shall precede an explicit
instantiation of that entity, unless the explicit instantiation is
preceded by an explicit specialization of the entity with the same
template arguments.</ins> If the declaration of the explicit
instantiation names an implicitly-declared special member function
(Clause 12 [special]), the program is ill-formed.</P>

<P>For a given set of template <del>parameters</del>
<ins>arguments</ins>, if an explicit instantiation of a template
appears after a declaration of an explicit specialization for that
template, the explicit instantiation has no effect.  Otherwise...</P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1202">1202</A>. Calling virtual functions during destruction</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 12.7 [class.cdtor] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Member functions, including virtual functions (10.3 [class.virtual]),
can be called during construction or destruction (12.6.2
[class.base.init]).  When a
virtual function is called directly or indirectly from a constructor
<del>(including the <I>mem-initializer</I> or
<I>brace-or-equal-initializer</I> for a non-static data member)</del>
or from a destructor, <ins>including during the construction or
destruction of the class's non-static data members,</ins> and the
object to which the call applies is the object <ins>(call it
<TT>x</TT>)</ins> under construction or destruction, the function
called is the <del>one defined in the constructor or destructor's own
class or in one of its bases, but not a function overriding it in a
class derived from the constructor or destructor's class, or
overriding it in one of the other base classes of the most derived
object (1.8 [intro.object])</del> <ins>final overrider in the
constructor or destructor's class and not one overriding it in a
more-derived class</ins>. If the virtual function call uses an
explicit class member access (5.2.5 [expr.ref]) and the
object-expression refers to <del>the object under construction or
destruction but its type is neither the constructor or destructor's
own class or one of its bases, the result of the call</del> <ins>the
complete object of <TT>x</TT> or one of that object's base class
subobjects but not <TT>x</TT> or one of its base class subobjects, the
behavior</ins> is undefined. [<I>Example:</I>...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1204">1204</A>. Specifiers in a <I>for-range-declaration</I></B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change the grammar 6.5 [stmt.iter] paragraph 1 as
follows:</P></LI>

<UL><I>for-range-declaration:</I>
<UL><I>attribute-specifier<SUB>opt</SUB> <del>type-specifier-seq</del> <ins>decl-specifier-seq</ins> declarator</I></UL>

</UL>

<LI><P>Add the following as a new paragraph at the end of 6.5.4 [stmt.ranged]:</P></LI>

<BLOCKQUOTE>

<ins>In the <I>decl-specifier-seq</I> of a <I>for-range-declaration</I>,
each <I>decl-specifier</I> shall be either a <I>type-specifier</I> or
<TT>constexpr</TT>.</ins>

</BLOCKQUOTE>

</OL>

<BR/><HR/<BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1206">1206</A>. Defining opaque enumeration members of class templates</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 14 [temp] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>...The <I>declaration</I> in a <I>template-declaration</I> shall</P>

<UL><LI><P>declare or define a function or class, or</P></LI>

<LI><P>define a member function, a member class<ins>, a member
enumeration,</ins> or a static data member of a class template or of a
class nested within a class template, or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 14.5.1 [temp.class] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

When a member function, a member class, <ins>a member
enumeration,</ins> a static data member or a member template of a
class template is defined outside of the class template definition...

</BLOCKQUOTE>

<LI><P>Add a new section following 14.5.1.3 [temp.static]:</P></LI>

<BLOCKQUOTE>

<P><B><ins>14.5.1.4 Enumeration members of class templates
[temp.mem.enum]</ins></B></P>

<P><ins>An enumeration member of a class template may be defined outside
the class template definition. [<I>Example:</I></ins></P>

<PRE>
<ins>  template&lt;class T&gt; struct A {
    enum E: T;
  };
  A&lt;int&gt; a;
  template&lt;class T&gt; enum A&lt;T&gt;::E: T { e1, e2 };
  A&lt;int&gt;::E e = A&lt;int&gt;::e1;</ins>
</PRE>

<P><ins>&#8212;<I>end example</I>]</ins></P>

</BLOCKQUOTE>

<LI><P>Change 14.7 [temp.spec] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

A function instantiated from a function template is called an
instantiated function. A class instantiated from a class template is
called an instantiated class. A member function, a member class,
<ins>a member enumeration,</ins> or a static data member of a class
template instantiated from the member definition of the class template
is called, respectively, an instantiated member function, member
class<ins>, member enumeration,</ins> or static data member.  A member
function...

</BLOCKQUOTE>

<LI><P>Change 14.7.1 [temp.inst] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...The implicit instantiation of a class template specialization
causes the implicit instantiation of the declarations, but not of the
definitions or default arguments, of the class member functions,
member classes, <ins>scoped member enumerations,</ins> static data
members and member templates; and it causes the implicit instantiation
of the definitions of <ins>unscoped member enumerations and</ins> member
anonymous unions. Unless a member...

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>An explicit specialization of any of the following:</P>

<UL><LI><P>function template</P></LI>

<LI><P>class template</P></LI>

<LI><P>member function of a class template</P></LI>

<LI><P>static data member of a class template</P></LI>

<LI><P>member class of a class template</P></LI>

<LI><P><ins>member enumeration of a class template</ins></P></LI>

<LI><P>member class template of a class or class template</P></LI>

<LI><P>member function template of a class or class template</P></LI>

<P>can be declared by a declaration introduced by
<TT>template&lt;&gt;</TT>...</P>

</UL>

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

A member function, a member class<ins>, a member enumeration,</ins> or
a static data member of a class template may be explicitly specialized
for a class specialization that is implicitly instantiated...

</BLOCKQUOTE>

<LI><P>Add the indicated text to the example in 14.7.3 [temp.expl.spec]
paragraph 6:</P></LI>

<PRE>
  template&lt;&gt; void sort&lt;&gt;(Array&lt;char*&gt;&amp; v);        //<cmnt> OK: </cmnt>sort&lt;char*&gt;<cmnt> not yet used</cmnt>
<ins>  template&lt;class T&gt; struct A {
    enum E: T;
    enum class S: T;
  };
  template&lt;&gt; enum A&lt;int&gt;::E: int { eint };         //<cmnt> OK</cmnt>
  template&lt;&gt; enum class A&lt;int&gt;::S: int { sint };   //<cmnt> OK</cmnt>
  template&lt;class T&gt; enum A&lt;T&gt;::E: T { eT };
  template&lt;class T&gt; enum class A&lt;T&gt;::S: T { sT };
  template&lt;&gt; enum A&lt;char&gt;::E: int { echar };       //<cmnt> ill-formed, </cmnt>A&lt;char&gt;::E<cmnt> was instantiated when </cmnt>A&lt;char&gt;<cmnt> was instantiated</cmnt>
  template&lt;&gt; enum class A&lt;char&gt;::S: int { schar }; //<cmnt> OK</cmnt></ins>
</PRE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

The placement of explicit specialization declarations for function
templates, class templates, member functions of class templates,
static data members of class templates, member classes of class
templates, <ins>member enumerations of class templates,</ins> member
class templates of class templates, member function templates...

</BLOCKQUOTE>

</OL>

<BR/><HR/<BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1210">1210</A>. Injection of <I>elaborated-type-specifier</I> in enumeration scope</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 3.3.2 [basic.scope.pdelc] paragraph 6 bullet 2 as follows:</P>

<BLOCKQUOTE>

...otherwise, except as a friend declaration, the <I>identifier</I> is
declared in the smallest <del>non-class, non-function-prototype</del>
<ins>namespace or block</ins> scope that contains the
declaration. [<I>Note:</I>...

</BLOCKQUOTE>

<BR/><HR/<BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1212">1212</A>. Non-function-call xvalues and <TT>decltype</TT></B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 7.1.6.2 [dcl.type.simple] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>The type denoted by <TT>decltype(e)</TT> is defined as follows:</P>

<UL><LI><P>if <TT>e</TT> is an unparenthesized <I>id-expression</I> or
a class member access (5.2.5 [expr.ref]),
<TT>decltype(e)</TT> is the type of the entity named by <TT>e</TT>.
If there is no such entity, or if <TT>e</TT> names a set of overloaded
functions, the program is ill-formed;</P></LI>

<LI><P>otherwise, if <TT>e</TT> is <del>a function call (5.2.2 [expr.call]) or an invocation of an overloaded operator (parentheses
around <TT>e</TT> are ignored), <TT>decltype(e)</TT> is the return
type of the statically chosen function</del> <ins>an xvalue,
<TT>decltype(e)</TT> is <TT>T&amp;&amp;</TT>, where <TT>T</TT> is the
type of <TT>e</TT></ins>;</P></LI>

<LI><P>otherwise, if <TT>e</TT> is an lvalue, <TT>decltype(e)</TT> is
<TT>T&amp;</TT>, where <TT>T</TT> is the type of <TT>e</TT>;</P></LI>

<LI><P>otherwise, <TT>decltype(e)</TT> is the type of
<TT>e</TT>.</P></LI>

</UL>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1214">1214</A>. Kinds of initializers</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 8.5 [dcl.init] paragraph 13 as follows:</P></LI>

<BLOCKQUOTE>

The form of initialization (using parentheses or <TT>=</TT>) is
generally insignificant, but does matter when the initializer or the
entity being initialized has a class type; see below. <del>A</del>
<ins>If the entity being initialized does not have class type, the
<I>expression-list</I> in a</ins> parenthesized initializer
<del>can</del> <ins>shall</ins> be a <del>list of expressions only
when the entity being initialized has a class type</del> <ins>single
expression</ins>.

</BLOCKQUOTE>

<LI><P>Change 8.5 [dcl.init] paragraph 16 as follows:</P></LI>

<BLOCKQUOTE>

<P>The semantics of initializers are as follows. The <I>destination
type</I> is the type of the object or reference being initialized and
the <I>source type</I> is the type of the initializer
expression. <del>The</del> <ins>If the initializer is not a single
(possibly parenthesized) expression, the</ins> source type is not
defined <del>when the initializer is a <I>braced-init-list</I> or when
it is a parenthesized list of expressions</del>.</P>

<UL><LI><P>If the initializer is a <ins>(non-parenthesized)</ins>
<I>braced-init-list</I>, the object <ins>or reference</ins> is
list-initialized (8.5.4 [dcl.init.list]).</P></LI>

<LI><P>...</P></LI>

<LI><P>If the destination type is a (possibly cv-qualified) class
type:</P></LI>

<UL><LI><P>If the initialization is direct-initialization, or if it is
copy-initialization where the cv-unqualified version of the source
type is the same class as, or a derived class of, the class of the
destination, constructors are considered. The applicable constructors
are enumerated (13.3.1.3 [over.match.ctor]), and the best one is
chosen through overload resolution (13.3 [over.match]). The
constructor so selected is called to initialize the object, with the
initializer expression<del>(s)</del> <ins>or
<I>expression-list</I></ins> as its argument(s). If no constructor
applies, or the overload resolution is ambiguous, the initialization
is ill-formed.</P></LI>

<LI><P>Otherwise...</P></LI>

</UL>

</UL>

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1215">1215</A>. Definition of POD struct</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 9 [class] paragraph 10 as follows:</P>

<BLOCKQUOTE>

A <I>POD struct</I><SUP>111</SUP> is a <ins>non-union</ins> class that
is both a trivial class and a standard-layout class...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1216">1216</A>. Exceptions &#8220;allowed&#8221; by a <I>noexcept-specification</I></B></P>

<P><B>Proposed resolution</B></P>

<P>Change 15.4 [except.spec] paragraph 8 as follows:</P>

<BLOCKQUOTE>

A function is said to <I>allow</I> an exception of type <TT>E</TT> if
<ins>the <I>constant-expression</I> in its
<I>noexcept-specification</I> evaluates to <TT>false</TT> or</ins> its
<I>dynamic-exception-specification</I> contains a type <TT>T</TT> for
which a handler of type <TT>T</TT> would be a match (15.3 [except.handle]) for an exception of type <TT>E</TT>.

</BLOCKQUOTE>

<BR/<HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1219">1219</A>. Non-static data member initializers in constant expressions</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 3.6.2 [basic.start.init] paragraph 2 as follows:</P></LI>

<UL><LI><P>if an object with static or thread storage duration is
initialized by a constructor call, if the constructor is a
<TT>constexpr</TT> constructor, if all constructor arguments are
constant expressions (including conversions), and if, after function
invocation substitution (7.1.5 [dcl.constexpr]), every constructor call
and full-expression in the <I>mem-initializer</I>s <ins>and in the
<I>brace-or-equal-initializer</I>s for non-static data members</ins>
is a constant expression </P></LI></UL>

<LI><P>Change 3.9 [basic.types] paragraph 10 as follows (wording
assumes the proposed resolution of <issue_ref text="issue "
num="981"/>)</P></LI>

<BLOCKQUOTE>

<P>A type is a <I>literal type</I> if it is:</P>

<UL><LI><P>a scalar type; or</P></LI>

<LI><P>a class type (clause 9 [class]) that
<ins>has all of the following properties:</ins></P></LI>

<UL><LI><P><ins>it</ins> has a trivial destructor,</P></LI>

<LI><P><ins>every constructor call and full-expression in the
<I>brace-or-equal-initializer</I>s for non-static data members (if
any) is a constant expression (5.19 [expr.const]),</ins></P></LI>

<LI><P><ins>it</ins> is an aggregate type (8.5.1 [dcl.init.aggr]) or
has at least one <TT>constexpr</TT> constructor or constructor
template that is not a copy or move constructor, and</P></LI>

<LI><P><ins>it</ins> has all non-static data members and base
classes of literal types; or</P></LI>

</UL>

<LI><P>an array of literal type.</P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<BR/<HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1220">1220</A>. Looking up <I>conversion-type-id</I>s</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 3.4.5 [basic.lookup.classref] paragraph 7 of the proposed
resolution of issue 1111 as follows:</P>

<BLOCKQUOTE>

If the <I>id-expression</I> is a <I>conversion-function-id</I>, its
<I>conversion-type-id</I> is first looked up in the class of the
object expression and the name, if found <del>and denotes a
type</del>, is used. Otherwise it is looked up in the context of the
entire <I>postfix-expression</I> <del>and the name shall denote a
type</del>. <ins>In each of these lookups, only names that denote
types or templates whose specializations are types are considered.</ins>

</BLOCKQUOTE>

<BR/<HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1224">1224</A>. <TT>constexpr</TT> defaulted copy constructors</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 12.8 [class.copy] paragraph 14 as follows:</P>

<BLOCKQUOTE>

A copy/move constructor that is defaulted and not defined as deleted
is <I>implicitly defined</I> if it is odr-used (3.2 [basic.def.odr])
to initialize an object of its class type from a copy of an object of
its class type or of a class type derived from its class
type<SUP>123</SUP> or when it is explicitly defaulted after its first
declaration.  [<I>Note:</I> the copy/move constructor is implicitly
defined even if the implementation elided its odr-use (3.2
[basic.def.odr], 12.2 [class.temporary]). &#8212;<I>end note</I>]
<ins>If the implicitly-defined constructor would satisfy the
requirements of a <TT>constexpr</TT> constructor (7.1.5
[dcl.constexpr]), the implicitly-defined constructor is
<TT>constexpr</TT>.</ins>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1225"/>1225</A>. <TT>constexpr</TT> constructors and virtual bases</B></P>

<P><B>Proposed resolution:</B></P>

<P>Add the following bullet to the list in 7.1.5 [dcl.constexpr]
paragraph 4:</P>

<UL><LI><P><ins>the class shall not have any virtual base
class;</ins></P></LI></UL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1229">1229</A>. Overload resolution with empty <I>braced-init-list</I> argument</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 8.5.4 [dcl.init.list] paragraph 3 bullet 5
as follows:</P></LI>

<UL><LI><P>Otherwise, if <TT>T</TT> is a class type,
constructors are considered. <del>If <TT>T</TT> has an
initializer-list constructor, the argument list consists of
the initializer list as a single argument; otherwise, the
argument list consists of the elements of the initializer
list.</del> The applicable constructors are enumerated
<del>(13.3.1.7 [over.match.list])</del> and the best one
is chosen through overload resolution (<ins>13.3.1.7 [over.match.list],</ins> 13.3 [over.match]). If a
narrowing conversion (see below) is required to convert any
of the arguments, the program is ill-formed.
[<I>Example:</I>...</P></LI></UL>

<LI><P>Change 13.3.1.7 [over.match.list] as follows:</P></LI>

<BLOCKQUOTE>

<P>When objects of non-aggregate class type
<ins><TT>T</TT></ins> are list-initialized (8.5.4 [dcl.init.list]), overload resolution selects the constructor
<ins>in two phases</ins>
<del>as follows, where <TT>T</TT> is the cv-unqualified class
type of the object being initialized</del>:</P>

<UL><LI><P><del>If <TT>T</TT> has an initializer-list
constructor (8.5.4 [dcl.init.list]),</del>
<ins>Initially, the candidate functions are the
initializer-list constructors (8.5.4 [dcl.init.list])
of the class <TT>T</TT> and</ins> the argument list consists
of the initializer list as a single argument<ins>.</ins></P></LI>

<LI><P><del>; otherwise,</del> <ins>If no viable
initializer-list constructor is found, overload resolution is
performed again, where the candidate functions are all the
constructors of the class <TT>T</TT> and</ins> the
argument list consists of the elements of the initializer
list.</P></LI>

<LI><P><del>For direct-list-initialization, the candidate
functions are all the constructors of the class
<TT>T</TT>.</del></P></LI>

</UL>

<P><ins>If the initializer list has no elements and <TT>T</TT> has a
default constructor, the first phase is omitted.</ins>
<del>For</del> <ins>In</ins> copy-list-initialization, <del>the
candidate functions are all the constructors of <TT>T</TT>.
However,</del> if an <TT>explicit</TT> constructor is chosen, the
initialization is ill-formed. [<I>Note:</I> <ins>This differs from
other situations (13.3.1.3 [over.match.ctor], 13.3.1.4
[over.match.copy]), where only converting constructors are considered
for copy-initialization.</ins> This restriction only applies if this
initialization is part of the final result of overload
resolution<ins>.</ins> &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

</OL>

<P>(This resolution also resolves issue 1151.)</P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1231">1231</A>. Variadic templates requiring an empty pack expansion</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.6 [temp.res] paragraph 8 as follows:</P>

<BLOCKQUOTE>

Knowing which names are type names allows the syntax of every template
definition to be checked.  No diagnostic shall be issued for a
template definition for which a valid specialization can be generated.
If no valid specialization can be generated for a template definition,
and that template is not instantiated, the template definition is
ill-formed, no diagnostic required.  <ins>If every valid
specialization of a variadic template requires an empty template
parameter pack, the template definition is ill-formed, no diagnostic
required.</ins> If a type used in a non-dependent name...
[<I>Example:</I>

<PRE>
  int j;
  template&lt;class T&gt; class X {
</PRE>

<P>...</P>

<PRE>
  };
<ins>
  template&lt;typename ... T&gt; struct A {
    void operator++(int, T... t);                     //<SPAN style="font-family:Times;font-style:italic"> error: too many parameters</SPAN>
  };
  template&lt;typename ... T&gt; union X: T... { };         //<SPAN style="font-family:Times;font-style:italic"> error: union with base class</SPAN>
  template&lt;typename ... T&gt; struct A: T..., T... { };  //<SPAN style="font-family:Times;font-style:italic"> error: duplicate base class</SPAN></ins>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1232">1232</A>. Creation of array temporaries using a <I>braced-init-list</I></B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 8.5.4 [dcl.init.list] paragraph 3 bullet 5 as
follows:</P></LI>

<UL><LI><P>Otherwise, if <TT>T</TT> is a reference <del>to class</del>
type <del>or if <TT>T</TT> is any reference type and the initializer
list has no elements</del>, a prvalue temporary of the type referenced
by <TT>T</TT> is list-initialized, and the reference is bound to that
temporary. [<I>Note:</I> As usual, the binding will fail and the
program is ill-formed if the reference type is an lvalue reference to
a non-const type. &#8212;<I>end note</I>]</P>

<P>[<I>Example:</I></P>

<PRE>
  struct S {
    S(std::initializer_list&lt;double&gt;); //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    S(const std::string&amp;);            //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
    // ...
  };
  const S&amp; r1 = { 1, 2, 3.0 };        //<SPAN style="font-family:Times;font-style:italic"> OK: invoke #1</SPAN>
  const S&amp; r2 { "Spinach" };          //<SPAN style="font-family:Times;font-style:italic"> OK: invoke #2</SPAN>
  S&amp; r3 = { 1, 2, 3 };                //<SPAN style="font-family:Times;font-style:italic"> error: initializer is not an lvalue</SPAN>
<ins>  const int&amp; i1 = { 1 };              //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  const int&amp; i2 = { 1.1 };            //<SPAN style="font-family:Times;font-style:italic"> error: narrowing</SPAN>
  const int (&amp;iar)[2] = { 1, 2 };     //<SPAN style="font-family:Times;font-style:italic"> OK, </SPAN>iar<SPAN style="font-family:Times;font-style:italic"> bound to temporary array</SPAN></ins>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</LI>

</UL>

<LI><P>Change 13.3.3.1.5 [over.ics.list] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

<P>If the parameter type is <TT>std::initializer_list&lt;X&gt;</TT>
<ins>or &#8220;array of <TT>X</TT>&#8221; [<I>Footnote:</I> since
there are no parameters of array type, this will only occur as the
underlying type of a reference parameter. &#8212;<I>end
footnote</I>]</ins> and all the elements of the initializer list can
be implicitly converted to <TT>X</TT>, the implicit conversion
sequence is the worst conversion necessary to convert an element of
the list to <TT>X</TT>. This conversion can be a user-defined
conversion even in the context of a call to an initializer-list
constructor. [<I>Example:</I></P>

<PRE>
  void f(std::initializer_list&lt;int&gt;);
  f( {1,2,3} );        //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>f(initializer_list&lt;int&gt;)<SPAN style="font-family:Times;font-style:italic"> identity conversion</SPAN>
  f( {'a','b'} );      //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>f(initializer_list&lt;int&gt;)<SPAN style="font-family:Times;font-style:italic"> integral promotion</SPAN>
  f( {1.0} );          //<SPAN style="font-family:Times;font-style:italic"> error: narrowing</SPAN>

  struct A {
    A(std::initializer_list&lt;double&gt;);          //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    A(std::initializer_list&lt;complex&lt;double&gt;&gt;); //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
    A(std::initializer_list&lt;std::string&gt;);     //<SPAN style="font-family:Times;font-style:italic"> #3</SPAN>
  };
  A a{ 1.0,2.0 };      //<SPAN style="font-family:Times;font-style:italic"> OK, uses #1</SPAN>

  void g(A);
  g({ "foo", "bar" }); //<SPAN style="font-family:Times;font-style:italic"> OK, uses #3</SPAN>
<ins>
  typedef int IA[3];
  void h(const IA&amp;);
  h({1,2,3});          //<SPAN style="font-family:Times;font-style:italic"> OK: identity conversion</SPAN></ins>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1233">1233</A>. Pack expansions and dependent calls</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.6.2 [temp.dep] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<P>Inside a template... the <I>id-expression</I> denotes a dependent
name if</P>

<UL><LI><P><ins>any of the expressions in the <I>expression-list</I>
is a pack expansion (14.5.3 [temp.variadic]),</ins></P></LI>

<LI><P>any of the expressions in the <I>expression-list</I> is a
type-dependent expression (14.6.2.2 [temp.dep.expr])<ins>,</ins>
or</P></LI>

<LI><P>the <I>unqualified-id</I> of the <I>id-expression</I> is a
<I>template-id</I> in which any of the template arguments depends on a
template parameter.</P></LI>

</UL>

<P>If an operand of an operator...</P>

</BLOCKQUOTE>

<P><I>[Drafting note: this resolution changes some running text in
the current wording into a bulleted list, adding one item.</I></P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1234">1234</A>. <I>abstract-declarator</I> does not permit <TT>...</TT> after <I>ptr-operator</I></B></P>

<P><B>Proposed resolution:</B></P>

<P>Change the grammar in 8.1 [dcl.name] paragraph 1 as follows:</P>

<UL><I>type-id:</I>
<UL><I>type-specifier-seq abstract-declarator<SUB>opt</SUB></I></UL>
<BR/>
<I>abstract-declarator:</I>
<UL><I>ptr-abstract-declarator</I><BR/
<I>noptr-abstract-declarator<SUB>opt</SUB> parameters-and-qualifiers trailing-return-type</I><BR/>
<del><TT>...</TT></del> <ins><I>abstract-pack-declarator</I></ins></UL>
<BR/>
<I>ptr-abstract-declarator:</I>
<UL><I>noptr-abstract-declarator</I><BR/>
<I>ptr-operator ptr-abstract-declarator<SUB>opt</SUB></I></UL>
<BR/>
<I>noptr-abstract-declarator:</I>
<UL><I>noptr-abstract-declarator<SUB>opt</SUB> parameters-and-qualifiers</I><BR/>
<I>noptr-abstract-declarator<SUB>opt</SUB></I> <TT>[</TT> <I>constant-expression<ins><SUB>opt</SUB></I></ins> <TT>]</TT> <I>attribute-specifier-seq<SUB>opt</SUB></I><BR/>
<TT>(</TT> <I>ptr-abstract-declarator</I> <TT>)</TT></UL>
<BR/>
<ins><I>abstract-pack-declarator:</I></ins>
<UL><ins><I>noptr-abstract-pack-declarator</I><BR/>
<I>ptr-operator abstract-pack-declarator</I></ins></UL>
<BR/>
<ins><I>noptr-abstract-pack-declarator:</I></ins>
<UL><ins><I>noptr-abstract-pack-declarator parameters-and-qualifiers</I><BR/>
<I>noptr-abstract-pack-declarator</I> <TT>[</TT> <I>constant-expression<SUB>opt</SUB></I> <TT>]</TT> <I>attribute-specifier-seq<SUB>opt</SUB></I><BR/>
<TT>...</TT></ins></UL>

</UL>

<P>(This resolution also resolves NB FCD comment CH 8.)</P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1236">1236</A>. Inconsistently-interrelated examples</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change the examples in 8.5.3 [dcl.init.ref] as follows:</P>

<PRE>
  struct A { };
  struct B : A { } b;
  extern B f();
  const A&amp; rca<ins>2</ins> = f();                //<SPAN style="font-family:Times;font-style:italic"> bound to the </SPAN>A<SPAN style="font-family:Times;font-style:italic"> subobject of the </SPAN>B<SPAN style="font-family:Times;font-style:italic"> rvalue.</SPAN>
  A&amp;&amp; rra = f();                      //<SPAN style="font-family:Times;font-style:italic"> same as above</SPAN>
  struct X {
    operator B();
    operator int&amp;();
  } x;
  const A&amp; r = x;                     //<SPAN style="font-family:Times;font-style:italic"> bound to the </SPAN>A<SPAN style="font-family:Times;font-style:italic"> subobject of the result of the conversion</SPAN>
<ins>  int i2 = 42;</ins>
  int&amp;&amp; rri = static_cast&lt;int&amp;&amp;&gt;(i<ins>2</ins>); //<SPAN style="font-family:Times;font-style:italic"> bound directly to </SPAN>i<ins>2</ins>
  B&amp;&amp; rrb = x;                        //<SPAN style="font-family:Times;font-style:italic"> bound directly to the result of </SPAN>operator B
  int&amp;&amp; rri2 = X();                   //<SPAN style="font-family:Times;font-style:italic"> error: lvalue-to-rvalue conversion applied to the</SPAN>
                                      //<SPAN style="font-family:Times;font-style:italic"> result of </SPAN>operator int&amp;
</PRE>

<P>and</P>

<PRE>
  const double&amp; rcd2 = 2;             //<SPAN style="font-family:Times;font-style:italic"> </SPAN>rcd2<SPAN style="font-family:Times;font-style:italic"> refers to temporary with value </SPAN>2.0
  double&amp;&amp; rrd = 2;                   //<SPAN style="font-family:Times;font-style:italic"> </SPAN>rrd<SPAN style="font-family:Times;font-style:italic"> refers to temporary with value </SPAN>2.0
  const volatile int cvi = 1;
  const int&amp; r<ins>2</ins> = cvi;                //<SPAN style="font-family:Times;font-style:italic"> error: type qualifiers dropped</SPAN>
<ins>  double d2 = 1.0;</ins>
  double&amp;&amp; rrd2 = d<ins>2</ins>;                 //<SPAN style="font-family:Times;font-style:italic"> error: copying lvalue of related type</SPAN>
<ins>  int i3 = 2;</ins>
  double&amp;&amp; rrd3 = i<ins>3</ins>;                 //<SPAN style="font-family:Times;font-style:italic"> </SPAN>rrd3<SPAN style="font-family:Times;font-style:italic"> refers to temporary with value <del>2.0</del> </SPAN><ins>2.0</ins>
</PRE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1237">1237</A>. Deprecated implicit copy assignment in example</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change the example in 12.2 [class.temporary] paragraph 2 as follows:</P>

<PRE>
  class X {
  public:
    X(int);
    X(const X&amp;);
<ins>    X&amp; operator=(const X&amp;);</ins>
    ~X();
  };
...
</PRE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1238">1238</A>. Overloading ambiguity binding reference to function</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Add a new bullet 13.3.3.2 [over.ics.rank] paragraph 3,
bullet 1, sub-bullet 4</P></LI>

<UL><LI><P>...</P></LI>

<LI><P><TT>S1</TT> and <TT>S2</TT> are reference bindings (8.5.3
[dcl.init.ref]) and neither refers to an implicit object
parameter...</P></LI>

<LI><P><ins><TT>S1</TT> and <TT>S2</TT> are reference bindings (8.5.3
[dcl.init.ref]), and <TT>S1</TT> binds an lvalue reference to a
function lvalue and <TT>S2</TT> binds an rvalue reference to a function
lvalue. [<I>Example:</I></ins></P></LI>

<PRE>
<ins>  template &lt;class T&gt; int f(T &amp;);
  template &lt;class T&gt; int f(T &amp;&amp;);
  void g();
  int ii = f(g);   //<SPAN style="font-family:Times;font-style:italic"> Calls </SPAN>f(T &amp;)</ins>
</PRE>

<LI><P><TT>S1</TT> and <TT>S2</TT> are reference bindings (8.5.3
[dcl.init.ref]), and the types to which the references refer are the
same...</P></LI>

</UL>

<LI><P>Change 13.3.3.1.4 [over.ics.ref] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

Except for an implicit object parameter, for which see 13.3.1
[over.match.funcs], a standard conversion sequence cannot be formed if
it requires binding an lvalue reference other than a reference to a
non-volatile <TT>const</TT> type to an rvalue or binding an rvalue
reference to an lvalue <ins>other than a function
lvalue</ins>. [<I>Note:</I>...

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1239">1239</A>. Hexadecimal floating-point literals vs user-defined literals</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 2.14.8 [lext.ext] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

If a token matches both <I>user-defined-literal</I> and another
literal kind, it is treated as the latter.  [<I>Example:</I>
<TT>123_km</TT><del>, 1.2LL, "Hello"s are all
user-defined-literals</del> <ins>is a
<I>user-defined-literal</I></ins>, but 12LL is an <I>integer-literal</I>.
&#8212;<I>end example</I>]

</BLOCKQUOTE>

<LI><P>Change 2.14.8 [lex.ext] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

<P>[<I>Example:</I></P>

<PRE>
  long double operator "" <ins>_</ins>w(long double);
  std::string operator "" <ins>_</ins>w(const char16_t*, size_t);
  unsigned operator "" <ins>_</ins>w(const char*);
  int main() {
    1.2<ins>_</ins>w;       //<SPAN style="font-family:Times;font-style:italic"> calls </SPAN>operator "" <ins>_</ins>w(1.2L)
    u"one"<ins>_</ins>w;    //<SPAN style="font-family:Times;font-style:italic"> calls </SPAN>operator "" <ins>_</ins>w(u"one", 3)
    12<ins>_</ins>w;        //<SPAN style="font-family:Times;font-style:italic"> calls </SPAN>operator "" <ins>_</ins>w("12")
    "two"<ins>_</ins>w;     //<SPAN style="font-family:Times;font-style:italic"> error: no applicable literal operator</SPAN>
}
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<LI><P>Change 2.14.8 [lex.ext] paragraph 9 as follows:</P></LI>

<BLOCKQUOTE>

<P>[<I>Example:</I></P>

<PRE>
  int main() {
    L"A" "B" "C"<ins>_</ins>x;   //<SPAN style="font-family:Times;font-style:italic"> OK: same as </SPAN>L"ABC"<ins>_</ins>x
    "P"<ins>_</ins>x "Q" "R"<ins>_</ins>y;  //<SPAN style="font-family:Times;font-style:italic"> error: two different ud-suffixes</SPAN>
  }
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<LI><P>Insert the following as a new paragraph after
2.14.8 [lex.ext] paragraph 9:</P></LI>

<BLOCKQUOTE>

<ins>Some <I>identifier</I>s appearing as <I>ud-suffix</I>es are
reserved for future standardization (17.6.4.3.5 [usrlit.suffix]). A
program containing such a <I>ud-suffix</I> is ill-formed, no
diagnostic required.</ins>

</BLOCKQUOTE>

<LI><P>Change 13.5.8 [over.literal] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

The <I>identifier</I> in a <I>literal-operator-id</I> is called a
<I>literal suffix identifier</I>. <ins>[<I>Note:</I> some literal
suffix identifiers are reserved for future standardization; see
17.6.4.3.5 [usrlit.suffix]. &#8212;<I>end note</I>]</ins>

</BLOCKQUOTE>

</OL>

<P><I>[Note: CWG decided not to require a diagnostic for such
ud-suffixes because libraries may wish to use them, which would
be more difficult with a mandatory diagnostic.]</I></P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1241">1241</A>. Which members does a destructor destroy?</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 12.4 [class.dtor] paragraph 7 as follows:</P>

<BLOCKQUOTE>

After executing the body of the destructor and destroying any
automatic objects allocated within the body, a destructor for class
<TT>X</TT> calls the destructors for <TT>X</TT>'s direct non-variant
<ins>non-static data</ins> members, the destructors for <TT>X</TT>'s
direct base classes and...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1242">1242</A>. Initializing variant class members</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 12.6.2 [class.base.init paragraph 5 as follows:</P>

<BLOCKQUOTE>

A <I>ctor-initializer</I> may initialize <del>the member of an
anonymous union that is a</del> <ins>a variant</ins> member of the
constructor's class...

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1243">1243</A>. Misleading footnote regarding multiple-declarator declarations</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change the footnote in 8 [dcl.dcl] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P>A declaration with several declarators is usually equivalent to the
corresponding sequence of declarations each with a single
declarator. That is</P>

<PRE>
  T D1, D2, ... Dn;
</PRE>

<P>is usually <del>equvalent</del> <ins>equivalent</ins> to</P>

<PRE>
  T D1; T D2; ... T Dn;
</PRE>

<P>where <TT>T</TT> is a <I>decl-specifier-seq</I> and each
<TT>Di</TT> is an <I>init-declarator</I>.  <del>The</del>
<ins>An</ins> exception occurs when a name introduced by one of the
<I>declarator</I>s hides a type name used by the
<I>decl-specifier</I>s, so that when the same <I>decl-specifier</I>s
are used in a subsequent declaration, they do not have the same
meaning, as in</P>

<PRE>
  struct S ... ;
  S S, T; //<SPAN style="font-family:Times"> declare two instances of </SPAN>struct S
</PRE>

<P>which is not equivalent to</P>

<PRE>
  struct S ... ;
  S S;
  S T; //<SPAN style="font-family:Times"> error</SPAN>
</PRE>

<P><ins>Another exception occurs when <TT>T</TT> is <TT>auto</TT>
(7.1.6.4 [dcl.spec.auto]), for example:</ins></P>

<PRE>
<ins>  auto i = 1, j = 2.0;   //<SPAN style="font-family:Times;font-style:italic"> error: deduced types for </SPAN>i<SPAN style="font-family:Times;font-style:italic"> and </SPAN>j<SPAN style="font-family:Times;font-style:italic"> don't match</SPAN></ins>
</PRE>

<P><ins>as opposed to</ins></P>

<PRE>
<ins>  auto i = 1;            //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>i<SPAN style="font-family:Times;font-style:italic"> deduced to have type </SPAN>int
  auto j = 2.0;          //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>j<SPAN style="font-family:Times;font-style:italic"> deduced to have type </SPAN>double</ins>
</PRE>

<PRE>

</PRE>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1244">1244</A>. Equivalence of alias templates and class templates</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change the example in 14.4 [temp.type] paragraph 1 as follows:</P>

<PRE>
  template&lt;<del>template&lt;class&gt; class TT</del> <ins>class T</ins>&gt; struct X { };
  template&lt;class&gt; struct Y { };
  template&lt;class T&gt; using Z = Y&lt;T&gt;;
  X&lt;Y<ins>&lt;int&gt;</ins>&gt; y;
  X&lt;Z<ins>&lt;int&gt;</ins>&gt; z;
</PRE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#1246">1246</A>. Non-deduced non-final parameter packs </B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 14.1 [temp.param] paragraph 11 as follows:</P>

<BLOCKQUOTE>

<P>If a <I>template-parameter</I> of a class template has a default
<I>template-argument</I>, each subsequent <I>template-parameter</I>
shall either have a default <I>template-argument</I> supplied or be a
template parameter pack.  If a <I>template-parameter</I> of a primary
class template is a template parameter pack, it shall be the last
<I>template-parameter</I>. <del>[<I>Note:</I> These are not
requirements for function templates or class template partial
specializations because template arguments can be deduced</del> <ins>A
template parameter pack of a function template shall not be followed
by another template parameter unless that template parameter can be
deduced or has a default argument</ins> (14.8.2
[temp.deduct]). [<I>Example:</I></P>

<PRE>
  template&lt;class T1 = int, class T2&gt; class B;   //<SPAN style="font-family:Times;font-style:italic"> error</SPAN>
<ins>
  //<SPAN style="font-family:Times;font-style:italic"> </SPAN>U<SPAN style="font-family:Times;font-style:italic"> cannot be deduced or specified</SPAN>
  template&lt;typename... T, typename... U&gt; void f() { }
  template&lt;typename... T, typename U&gt; void g() { }</ins>
</PRE>

<P>&#8212;<I>end example</I>] <del>&#8212;<I>end note</I>]</del></P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

</BODY>
</HTML>
