<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core "tentatively ready" Issues
   </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
       &#160;P0263R1</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2016-03-04</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Project:
     </TD>
<TD>
      &#160;Programming Language C++
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reference:
     </TD>
<TD>
      &#160;ISO/IEC IS 14882:2014
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD>
<TD>
      &#160;William M. Miller
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;Edison Design Group, Inc.
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;<A HREF="mailto://wmm@edg.com">wmm@edg.com</A></TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Audience:
     </TD>
<TD>
      &#160;WG21
     </TD>
</TR>
</TABLE><BR CLEAR="ALL"><BR><CENTER>
<H2>
     Core Language Working Group "tentatively ready" Issues
      the
     February, 2016 (Jacksonville) meeting
    </H2>
</CENTER><BR><P>
    Section references in this document reflect the section numbering
    of document
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4567.pdf">WG21 N4567</A>.
   </P>
<HR><A NAME="212"></A><H4>212.
  
Implicit instantiation is not described clearly enough
</H4><B>Section: </B>14.7.1&#160; [temp.inst]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Christophe de Dinechin
 &#160;&#160;&#160;

 <B>Date: </B>7 Mar 2000




<P>Three points have been raised where the wording in
14.7.1 [temp.inst] may not be sufficiently clear.</P>

<OL>

<LI>

In paragraph 4, the statement is made that

<BLOCKQUOTE>

A class template specialization is implicitly instantiated...  if the
completeness of the class type affects the semantics of the program...

</BLOCKQUOTE>

<P>It is not clear what it means for the "completeness... [to affect]
the semantics."  Consider the following example:</P>

<PRE>
        template&lt;class T&gt; struct A;
        extern A&lt;int&gt; a;

        void *foo() { return &amp;a; }

        template&lt;class T&gt; struct A
        {
        #ifdef OPTION
                void *operator &amp;() { return 0; }
        #endif
        };
</PRE>

<P>The question here is whether it is necessary for template class
<TT>A</TT> to declare an <TT>operator &amp;</TT> for the semantics of the
program to be affected.  If it does not do so, the meaning of
<TT>&amp;a</TT> will be the same whether the class is complete or
not and thus arguably the semantics of the program are not
affected.</P>

<P>Presumably what was intended is whether the presence or absence of
certain member declarations in the template class might be relevant in
determining the meaning of the program.  A clearer statement may be
desirable.</P>

</LI>

<LI>

Paragraph 5 says,

<BLOCKQUOTE>

If the overload resolution process can determine the correct function
to call without instantiating a class template definition, it is
unspecified whether that instantiation actually takes place.

</BLOCKQUOTE>

<P>The intent of this wording, as illustrated in the example in that
paragraph, is to allow a "smart" implementation not to instantiate
class templates if it can determine that such an instantiation will
not affect the result of overload resolution, even though the
algorithm described in clause 13 [over] requires that
all the viable functions be enumerated, including functions that might
be found as members of specializations.</P>

<P>Unfortunately, the looseness of the wording allowing this latitude
for implementations makes it unclear what "the overload resolution
process" is &#8212; is it the algorithm in 13 [over] or
something else? &#8212; and what "the correct function" is.</P>

</LI>

<LI>

According to paragraph 6,

<BLOCKQUOTE>

If an implicit instantiation of a class template specialization is
required and the template is declared but not defined, the program is
ill-formed.

</BLOCKQUOTE>

<P>Here, it is not clear what conditions "require" an implicit
instantiation.  From the context, it would appear that the intent is
to refer to the conditions in paragraph 4 that cause a specialization
to be instantiated.</P>

<P>This interpretation, however, leads to different treatment of
template and non-template incomplete classes.  For example, by this
interpretation,</P>

<PRE>
    class A;
    template &lt;class T&gt; struct TA;
    extern A a;
    extern TA&lt;int&gt; ta;

    void f(A*);
    void f(TA&lt;int&gt;*);

    int main()
    {
        f(&amp;a);    // well-formed; undefined if A
                  // has operator &amp;() member
        f(&amp;ta);   // ill-formed: cannot instantiate
    }
</PRE>

<P>A different approach would be to understand "required" in paragraph
6 to mean that a complete type is required in the expression.  In this
interpretation, if an incomplete type is acceptable in the context and
the class template definition is not visible, the instantiation is not
attempted and the program is well-formed.</P>

<P>The meaning of "required" in paragraph 6 must be clarified.</P>

</LI>

</OL>

<P>(See also issues 204 and
63.)</P>

<P><B>Notes on 10/01 meeting:</B></P>

<P>It was felt that item 1 is solved by addition of the word "might"
in the resolution for issue 63; item 2
is not much of a problem; and item 3 could be solved by changing
"required" to "required to be complete".</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<OL><LI><P>Change 14.7.1 [temp.inst] paragraph 1 as
follows, moving the note and example from paragraph 6 and
breaking it into two paragraphs:</P></LI>

<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. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> In particular, if the semantics
of an expression depend on the member or base class lists of
a class template specialization, the class template
specialization is implicitly generated.  For instance,
deleting a pointer to class type depends on whether or not
the class declares a destructor, and a conversion between
pointers to class type depends on the inheritance
relationship between the two classes involved.
&#8212;<I>end note</I>] [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;class T&gt; class B { /* ... */ };
  template&lt;class T&gt; class D : public B&lt;T&gt; { /* ... */ };

  void f(void*);
  void f(B&lt;int&gt;*);

  void g(D&lt;int&gt;* p, D&lt;char&gt;* pp, D&lt;double&gt;* ppp) {
    f(p);            //<SPAN style="font-family:Times;font-style:italic"> instantiation of </SPAN>D&lt;int&gt;<SPAN style="font-family:Times;font-style:italic"> required: call </SPAN>f(B&lt;int&gt;*)
    B&lt;char&gt;* q = pp; //<SPAN style="font-family:Times;font-style:italic"> instantiation of </SPAN>D&lt;char&gt;<SPAN style="font-family:Times;font-style:italic"> required:</SPAN>
                     //<SPAN style="font-family:Times;font-style:italic"> convert </SPAN>D&lt;char&gt;*<SPAN style="font-family:Times;font-style:italic"> to </SPAN>B&lt;char&gt;*
    delete ppp;      //<SPAN style="font-family:Times;font-style:italic"> instantiation of </SPAN>D&lt;double&gt;<SPAN style="font-family:Times;font-style:italic"> required</SPAN>
}</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>] If a class template has been
declared, but not defined, at the point of instantiation
(14.6.4.1 [temp.point]), the instantiation yields
an incomplete class type (3.9 [basic.types]).
[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;class T&gt; class X;

  X&lt;char&gt; ch;      //<SPAN style="font-family:Times;font-style:italic"> error: incomplete type </SPAN>X&lt;char&gt;</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN> [<I>Note:</I>
Within a template declaration, a local
class <SPAN style="font-weight:bold;background-color:#A0FFA0">(9.8 [class.local])</SPAN> or enumeration
and the members of a local class are never considered to be
entities that can be separately instantiated (this includes
their default arguments, <I>exception-specification</I>s,
and non-static data member initializers, if any). As a
result, the dependent names are looked up, the semantic
constraints are checked, and any templates used are
instantiated as part of the instantiation of the entity
within which the local class or enumeration is
declared. &#8212;<I>end note</I>]</P>

<P>The implicit instantiation of a class template
specialization causes the implicit instantiation of the
declarations, but not...</P>

</BLOCKQUOTE>

<LI><P>Delete 14.7.1 [temp.inst] paragraph 6, moving the
note and example to paragraph 1 as shown above:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A class template specialization is implicitly instantiated
if the class type is used in a context that requires a
completely-defined object type or if the completeness of the
class type might affect the semantics of the
program. [<I>Note:</I> In particular, if the semantics of an
expression depend on the member or base class lists of a
class template specialization, the class template
specialization is implicitly generated. For instance,
deleting a pointer to class type depends on whether or not
the class declares a destructor, and conversion between
pointer to class types depends on the inheritance
relationship between the two classes involved.
&#8212;<I>end note</I>] [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  template&lt;class T&gt; class B { /* ... */ };
  template&lt;class T&gt; class D : public B&lt;T&gt; { /* ... */ };

  void f(void*);
  void f(B&lt;int&gt;*);

  void g(D&lt;int&gt;* p, D&lt;char&gt;* pp, D&lt;double&gt;* ppp) {
    f(p);            //<SPAN style="font-family:Times;font-style:italic"> instantiation of </SPAN>D&lt;int&gt;<SPAN style="font-family:Times;font-style:italic"> required: call </SPAN>f(B&lt;int&gt;*)
    B&lt;char&gt;* q = pp; //<SPAN style="font-family:Times;font-style:italic"> instantiation of </SPAN>D&lt;char&gt;<SPAN style="font-family:Times;font-style:italic"> required:</SPAN>
                     //<SPAN style="font-family:Times;font-style:italic"> convert </SPAN>D&lt;char&gt;*<SPAN style="font-family:Times;font-style:italic"> to </SPAN>B&lt;char&gt;*
    delete ppp;      //<SPAN style="font-family:Times;font-style:italic"> instantiation of </SPAN>D&lt;double&gt;<SPAN style="font-family:Times;font-style:italic"> required</SPAN>
}</SPAN>
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

If the <SPAN style="font-weight:bold;background-color:#A0FFA0">function selected by</SPAN> overload
resolution <SPAN style="text-decoration:line-through;background-color:#FFA0A0">process</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">(13.3 [over.match])</SPAN>
can <SPAN style="text-decoration:line-through;background-color:#FFA0A0">determine the correct function to
call</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">be determined</SPAN> without instantiating a
class template definition, it is unspecified whether that
instantiation actually takes place. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Delete 14.7.1 [temp.inst] paragraphs 8-9:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If an implicit instantiation of a class template
specialization is required and the template is declared but
not defined, the program is ill-formed. [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  template&lt;class T&gt; class X;

  X&lt;char&gt; ch; //<SPAN style="font-family:Times;font-style:italic"> error: definition of </SPAN>X<SPAN style="font-family:Times;font-style:italic"> required</SPAN></SPAN>
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8212;<I>end example</I>]</SPAN></P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The implicit instantiation of a class template does not
cause any static data members of that class to be implicitly
instantiated.</SPAN></P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="238"></A><H4>238.
  
Precision and accuracy constraints on floating point
</H4><B>Section: </B>5&#160; [expr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Christophe de Dinechin
 &#160;&#160;&#160;

 <B>Date: </B>31 Jul 2000




<P>It is not clear what constraints are placed on a floating point
implementation by the wording of the Standard.  For instance, is
an implementation permitted to generate a "fused multiply-add"
instruction if the result would be different from what would
be obtained by performing the operations separately?  To what
extent does the "as-if" rule allow the kinds of optimizations
(e.g., loop unrolling) performed by FORTRAN compilers?</P>



<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 3.9.1 [basic.fundamental] paragraph 8 as follows:</P>

<BLOCKQUOTE>

There are three <I>floating point</I>
types: <TT>float</TT>, <TT>double</TT>, and <TT>long double</TT>. The type
<TT>double</TT> provides at least as much precision as <TT>float</TT>, and
the type <TT>long double</TT> provides at least as much precision
as <TT>double</TT>.  The set of values of the type <TT>float</TT> is a
subset of the set of values of the type <TT>double</TT>; the set of values
of the type <TT>double</TT> is a subset of the set of values of the type
<TT>long double</TT>. The value representation of floating-point types is
implementation-defined. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> This International Standard
imposes no requirements on the accuracy of floating-point operations; see
also 18.3.2 [limits]. &#8212;<I>end
note</I>]</SPAN> <I>Integral</I> and <I>floating</I> types are collectively
called <I>arithmetic</I> types. Specializations of the
standard <SPAN style="font-weight:bold;background-color:#A0FFA0">library</SPAN> template <TT>std::numeric_limits</TT>
(18.3 [support.limits]) shall specify the maximum and minimum values of
each arithmetic type for an implementation.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="242"></A><H4>242.
  
Interpretation of old-style casts
</H4><B>Section: </B>5.4&#160; [expr.cast]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>30 Aug 2000




<P>The meaning of an old-style cast is described in terms of
<TT>const_cast</TT>, <TT>static_cast</TT>, and
<TT>reinterpret_cast</TT> in 5.4 [expr.cast] paragraph 5.
Ignoring <TT>const_cast</TT> for the moment, it basically says that if
the conversion performed by a given old-style cast is one of those
performed by <TT>static_cast</TT>, the conversion is interpreted as if
it were a <TT>static_cast</TT>; otherwise, it's interpreted as if it
were a <TT>reinterpret_cast</TT>, if possible.  The following example
is given in illustration:</P>

<PRE>
    struct A {};
    struct I1 : A {};
    struct I2 : A {};
    struct D : I1, I2 {};
    A *foo( D *p ) {
	return (A*)( p ); // ill-formed static_cast interpretation
    }
</PRE>

<P>The obvious intent here is that a derived-to-base pointer
conversion is one of the conversions that can be performed using
<TT>static_cast</TT>, so <TT>(A*)(p)</TT> is equivalent to
<TT>static_cast&lt;A*&gt;(p)</TT>, which is ill-formed because of the
ambiguity.</P>

<P>Unfortunately, the description of <TT>static_cast</TT> in
5.2.9 [expr.static.cast] does NOT support this interpretation.
The problem is in the way 5.2.9 [expr.static.cast] lists the
kinds of casts that can be performed using <TT>static_cast</TT>.
Rather than saying something like "All standard conversions can be
performed using <TT>static_cast</TT>," it says</P>

<BLOCKQUOTE>
An expression e can be explicitly converted to a type <TT>T</TT> using
a <TT>static_cast</TT> of the form <TT>static_cast&lt;T&gt;(e)</TT> if
the declaration "<TT>T t(e);</TT>" is well-formed, for some invented
temporary variable <TT>t</TT>.
</BLOCKQUOTE>

<P>Given the declarations above, the hypothetical declaration</P>

<PRE>
    A* t(p);
</PRE>

<P>is NOT well-formed, because of the ambiguity.  Therefore the old-style
cast <TT>(A*)(p)</TT> is NOT one of the conversions that can be performed
using <TT>static_cast</TT>, and <TT>(A*)(p)</TT> is equivalent to
<TT>reinterpret_cast&lt;A*&gt;(p)</TT>, which is well-formed under
5.2.10 [expr.reinterpret.cast] paragraph 7.</P>

<P>Other situations besides ambiguity which might raise similar
questions include access violations, casting from virtual base
to derived, and casting pointers-to-members when virtual
inheritance is involved.</P>



<P><B>Proposed resolution (October, 2015):</B></P>

<OL><LI><P>Change 5.2.9 [expr.static.cast] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

An lvalue of type &#8220;<I>cv1</I> <TT>B</TT>&#8221;,
where <TT>B</TT> is a class type, can be cast to type
&#8220;reference to <I>cv2</I> <TT>D</TT>&#8221;,
where <TT>D</TT> is a class derived (Clause
10 [class.derived]) from <TT>B</TT>, if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a valid
standard conversion from &#8220;pointer to <TT>D</TT>&#8221;
to &#8220;pointer to <TT>B</TT>&#8221; exists
(4.10 [conv.ptr]),</SPAN> <I>cv2</I> is the same
cv-qualification as, or greater cv-qualification
than, <I>cv1</I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">, and</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">. If</SPAN> <TT>B</TT>
is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">neither</SPAN> a virtual base class
of <TT>D</TT> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">nor</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">or</SPAN> a base class of a
virtual base class of <TT>D</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">, or if no valid
standard conversion from &#8220;pointer to <TT>D</TT>&#8221;
to &#8220;pointer to <TT>B</TT>&#8221; exists
(4.10 [conv.ptr]), the program is ill-formed</SPAN>.
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The result has type
&#8220;<I>cv2</I> <TT>D</TT>&#8221;.</SPAN> An xvalue of type
&#8220;<I>cv1</I> <TT>B</TT>&#8221; <SPAN style="text-decoration:line-through;background-color:#FFA0A0">may</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">can</SPAN>
be cast to type &#8220;rvalue reference
to <I>cv2</I> <TT>D</TT>&#8221; with the same constraints as
for an lvalue of type &#8220;<I>cv1</I>
<TT>B</TT>&#8221;.  If the object of type
&#8220;<I>cv1</I> <TT>B</TT>&#8221; is actually a subobject
of an object of type <TT>D</TT>, the result refers to the enclosing
object of type <TT>D</TT>. Otherwise, the behavior is
undefined. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 5.2.9 [expr.static.cast] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<P>An expression <TT>e</TT> can be explicitly converted to a
type <TT>T</TT> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">using a <TT>static_cast</TT> of the form
<TT>static_cast&lt;T&gt;(e)</TT></SPAN> if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the
declaration <TT>T t(e);</TT> is well-formed, for some
invented temporary variable <TT>t</TT>
(8.5 [dcl.init])</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">there is an implicit
conversion sequence (13.3.3.1 [over.best.ics]) from
<TT>e</TT> to <TT>T</TT>, or if overload resolution for a
direct-initialization (8.5 [dcl.init]) of an
object or reference of type <TT>T</TT> from <TT>e</TT> would
find at least one viable function
(13.3.2 [over.match.viable])</SPAN>. The effect of such an
explicit conversion is the same as performing the
declaration and initialization</P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  T t(e);</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">for some invented temporary variable <TT>t</TT>
(8.5 [dcl.init])</SPAN> and then using the
temporary variable as the result of the conversion.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> The conversion is ill-formed when
attempting to convert an expression of class type to an
inaccessible or ambiguous base class. &#8212;<I>end
note</I>]</SPAN> The expression <TT>e</TT> is used as a
glvalue if and only if the initialization uses it as a
glvalue.</P>

</BLOCKQUOTE>

<LI><P>Change 5.2.9 [expr.static.cast] paragraph 11 as follows:</P></LI>

<BLOCKQUOTE>

A prvalue of type &#8220;pointer
to <I>cv1</I> <TT>B</TT>&#8221;, where <TT>B</TT> is a class
type, can be converted to a prvalue of type &#8220;pointer
to <I>cv2</I> <TT>D</TT>&#8221;, where <TT>D</TT> is a class
derived (Clause 10 [class.derived]) from B, if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a
valid standard conversion from &#8220;pointer
to <TT>D</TT>&#8221; to &#8220;pointer to <TT>B</TT>&#8221;
exists (4.10 [conv.ptr]),</SPAN> <I>cv2</I> is the
same cv-qualification as, or greater cv-qualification
than, <I>cv1</I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">, and</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">. If</SPAN> <TT>B</TT>
is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">neither</SPAN> a virtual base class
of <TT>D</TT> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">nor</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">or</SPAN> a base class of a
virtual base class of <TT>D</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">, or if no valid
standard conversion from &#8220;pointer to <TT>D</TT>&#8221;
to &#8220;pointer to <TT>B</TT>&#8221; exists
(4.10 [conv.ptr]), the program is
ill-formed</SPAN>. The null pointer value
(4.10 [conv.ptr]) is converted to the null pointer
value of the destination type. If the prvalue of type
&#8220;pointer to <I>cv1</I> <TT>B</TT>&#8221; points to
a <TT>B</TT> that is actually a subobject of an object of
type <TT>D</TT>, the resulting pointer points to the
enclosing object of type <TT>D</TT>. Otherwise, the behavior
is undefined.

</BLOCKQUOTE>

<LI><P>Change 5.2.9 [expr.static.cast] paragraph 12 as follows:</P></LI>

<BLOCKQUOTE>

A prvalue of type &#8220;pointer to member of <TT>D</TT> of
type <I>cv1</I> <TT>T</TT>&#8221; can be converted to a
prvalue of type &#8220;pointer to member
of <TT>B</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8221;</SPAN> of
type <I>cv2</I> <TT>T</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8221;</SPAN>,
where <TT>B</TT> is a base class (Clause
10 [class.derived]) of <TT>D</TT>, if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a valid
standard conversion from &#8220;pointer to member
of <TT>B</TT> of type
<TT>T</TT>&#8221; to &#8220;pointer to member of <TT>D</TT>
of type <TT>T</TT>&#8221; exists
(4.11 [conv.mem]), and</SPAN> <I>cv2</I> is the same
cv-qualification as, or greater cv-qualification than,
<I>cv1</I>.<SUP>70</SUP> <SPAN style="font-weight:bold;background-color:#A0FFA0">If no valid standard conversion
from &#8220;pointer to member of <TT>B</TT> of type
<TT>T</TT>&#8221; to &#8220;pointer to member of <TT>D</TT>
of type <TT>T</TT>&#8221; exists (4.11 [conv.mem]),
the program is ill-formed.</SPAN> The null member pointer value
(4.11 [conv.mem]) is converted to the null member
pointer value of the destination type. If class <TT>B</TT>
contains the original member, or is a base or derived class
of the class containing the original member, the resulting
pointer to member points to the original member. Otherwise,
the behavior is undefined. [<I>Note:</I> although
class <TT>B</TT> need not contain the original member, the
dynamic type of the object with which indirection through
the pointer to member is performed must contain the original
member; see 5.5 [expr.mptr.oper]. &#8212;<I>end
note</I>]

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1284"></A><H4>1284.
  
Should the lifetime of an array be independent of that of its elements?
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-02




<P>The note in 3.8 [basic.life] paragraph 2 reads,</P>

<BLOCKQUOTE>

[<I>Note:</I> The lifetime of an array object starts as soon as
storage with proper size and alignment is obtained, and its lifetime
ends when the storage which the array occupies is reused or released.
12.6.2 [class.base.init] describes the lifetime of base and member
subobjects.  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>This wording reflects an earlier version of paragraph 1 that
deferred the start of an object's lifetime only for initialization of
objects of class type. The note simply emphasized the implication that
that the lifetime of a POD type or an array began immediately, even if
lifetime of an array's elements began later.</P>

<P>The decomposition of POD types removed the mention of PODs, leaving
only the array types, and when the normative text was changed to
include aggregates whose members have non-trivial initialization, the
note was overlooked.</P>

<P>It is not clear whether it would be better to update the note to
emphasize the distinction between aggregates with non-trivial
initialization and those without or to delete it entirely.</P>

<P>A possible related normative change to consider is whether the
specification of paragraph 1 is sufficiently clear with respect to
multidimensional arrays.  The current definition of &#8220;non-trivial
initialization&#8221; is:</P>

<BLOCKQUOTE>

An object is said to have non-trivial initialization if it is of a
class or aggregate type and it or one of its members is initialized by
a constructor other than a trivial default constructor.

</BLOCKQUOTE>

<P>Presumably the top-level array of an N-dimensional array whose
ultimate element type is a class type with non-trivial initialization
would also have non-trivial initialization, but it's not clear that
this wording says that.</P>

<P>A more radical change that came up in the discussion was whether the
undefined behavior resulting from an lvalue-to-rvalue conversion of an
uninitialized object in 4.1 [conv.lval] paragraph 1 would be
better dealt with as a lifetime violation instead.</P>

<P><B>Proposed resolution (October, 2015):</B></P>

<P>Change 3.8 [basic.life] paragraphs 1 and 2 as follows:</P>

<BLOCKQUOTE>

<P>The <I>lifetime</I> of an object is a runtime property of
the object. An object is said to have <I>non-vacuous</I>
initialization if it is of a class or aggregate type and it
or one of its <SPAN style="text-decoration:line-through;background-color:#FFA0A0">members</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">subobjects</SPAN> is
initialized by a constructor other than a trivial default
constructor. [<I>Note:</I> initialization...</P>

<P>[<I>Note:</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The lifetime of an array object starts
as soon as storage with proper size and alignment is
obtained, and its lifetime ends when the storage which the
array occupies is reused or released.</SPAN>
12.6.2 [class.base.init] describes the lifetime of base
and member subobjects. &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1315"></A><H4>1315.
  
Restrictions on non-type template arguments in partial specializations
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-05-12




<P>The rationale for the restriction in 14.5.5 [temp.class.spec]
paragraph 8, first bullet is not clear:</P>

<UL><LI><P>A partially specialized non-type argument expression shall
not involve a template parameter of the partial specialization except
when the argument expression is a simple
<I>identifier</I>. [<I>Example:</I></P></LI>

<PRE>
  template &lt;int I, int J&gt; struct A {};
  template &lt;int I&gt; struct A&lt;I+5, I*2&gt; {}; //<SPAN style="font-family:Times;font-style:italic"> error</SPAN>
  template &lt;int I, int J&gt; struct B {};
  template &lt;int I&gt; struct B&lt;I, I&gt; {};     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
</PRE>

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

</UL>

<P>In the example, it's clear that <TT>I</TT> is non-deducible, but
this rule prevents plausible uses like:</P>

<PRE>
  template &lt;int I, int J&gt; struct A {};
  template &lt;int I&gt; struct A&lt;I, I*2&gt; {};
</PRE>

<P>(See also issues 1647,
2033, and
2127.)</P>



<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 14.5.5 [temp.class.spec] bullet 8.1 as follows:</P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A partially specialized non-type argument expression shall
not involve a template parameter of the partial specialization except when
the argument expression is a
simple <I>identifier</I>.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Each <I>template-parameter</I> shall
appear at least once in the <I>template-id</I> outside a non-deduced
context.</SPAN> [<I>Example:</I></P></LI>

<PRE>
  template &lt;int I, int J&gt; struct A {};
  template &lt;int I&gt; struct A&lt;I+5, I*2&gt; {};   //<SPAN style="font-family:Times;font-style:italic"> error</SPAN>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">
  template &lt;int I, int J&gt; struct B {};</SPAN>
  template &lt;int I&gt; struct <SPAN style="text-decoration:line-through;background-color:#FFA0A0">B</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A</SPAN>&lt;I, I&gt; {};     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">
  template &lt;int I, int J, int K&gt; struct B {};
  template &lt;int I&gt; struct B&lt;I, I*2, 2&gt; {};  //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN></SPAN>
</PRE>

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

</UL>

<BR><BR><HR><A NAME="1496"></A><H4>1496.
  
Triviality with deleted and missing default constructors
</H4><B>Section: </B>9.1&#160; [class.name]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-04-25




<P>A default constructor that is defined as deleted is trivial, according
to 12.1 [class.ctor] paragraph 5. This means that, according
to 9 [class] paragraph 6, such a class can be trivial.
If, however, the class has no default constructor because it has a
user-declared constructor, the class is not trivial.  Since both cases
prevent default construction of the class, it is not clear why there is
a difference in triviality between the cases.</P>

<P>(See also issue 1928.)</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>It was observed that this issue was related to issue 1344, as the current specification allows adding
a default constructor by adding default arguments to the definition of
a constructor.  The resolution of that issue should also resolve this
one.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>It was decided to resolve issue 1344
separately from this issue, so this issue now requires its own
resolution.</P>

<P><B>Proposed resolution (October, 2015):</B></P>

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

<BLOCKQUOTE>

A <I>trivial class</I> is a class that <SPAN style="text-decoration:line-through;background-color:#FFA0A0">has a default
constructor (12.1 [class.ctor]), has no non-trivial
default constructors, and</SPAN> is trivially copyable <SPAN style="font-weight:bold;background-color:#A0FFA0">
and has one or more default constructors
(12.1 [class.ctor]), all of which are either trivial
or deleted and at least one of which is not
deleted</SPAN>. [<I>Note:</I> In particular, a trivially
copyable or trivial class does not have virtual functions or
virtual base classes. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1638"></A><H4>1638.
  
Declaring an explicit specialization of a scoped enumeration
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-12




<P>There is no syntax currently for declaring an explicit specialization of
a member scoped enumeration.  A declaration (not a definition) of such an
explicit specialization most resembles an <I>opaque-enum-declaration</I>,
but the grammar for that requires that the name be a simple identifier,
which will not be the case for an explicit specialization of a member
enumeration.  This could be remedied by adding
a <I>nested-name-specifier</I> to the grammar with a restriction that
a <I>nested-name-specifier</I> only appear in an explicit
specialization.</P>

<P><B>Proposed resolution (October, 2015):</B></P>

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

<UL><I>opaque-enum-declaration:</I>
<UL><I>enum-key attribute-specifier-seq<SUB>opt</SUB> <SPAN style="font-weight:bold;background-color:#A0FFA0">nested-name-specifier<SUB>opt</SUB></SPAN> identifier enum-base<SUB>opt</SUB></I> <TT>;</TT>
</UL>
</UL>

<LI><P>Add the following at the end of 7.2 [dcl.enum]
paragraph 1:</P></LI>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">If an <I>opaque-enum-declaration</I> contains a
<I>nested-name-specifier</I>, the declaration shall be an
explicit specialization (14.7.3 [temp.expl.spec]).</SPAN>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1872"></A><H4>1872.
  
Instantiations of <TT>constexpr</TT> templates that cannot appear in constant expressions
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-02-17




<P>According to 7.1.5 [dcl.constexpr] paragraph 6,</P>

<BLOCKQUOTE>

If the instantiated template specialization of a <TT>constexpr</TT>
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 still
a <TT>constexpr</TT> function or <TT>constexpr</TT> constructor, even
though a call to such a function cannot appear in a constant expression.

</BLOCKQUOTE>

<P>The restriction on appearing in a constant expression assumes the
previous wording that made such a specialization non-<TT>constexpr</TT>,
and a call to a non-<TT>constexpr</TT> function cannot appear in a
constant expression.  With the current wording, however, there is no
normative restriction against calls to such specializations.
5.20 [expr.const] should be updated to include such a
prohibition.</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<P>Add the following bullet following 5.20 [expr.const]
bulllet 2.3:</P>

<BLOCKQUOTE>

<P>A <I>conditional-expression</I> e is a <I>core constant
expression</I> unless the evaluation of <TT>e</TT>, following the
rules of the abstract machine (1.9 [intro.execution]),
would evaluate one of the following expressions:</P>

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

<LI><P>an invocation of an undefined <TT>constexpr</TT> function or an
undefined <TT>constexpr</TT> constructor;</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">an invocation of an instantiated <TT>constexpr</TT>
function or <TT>constexpr</TT> constructor that fails to
satisfy the requirements for a <TT>constexpr</TT> function or
<TT>constexpr</TT> constructor
(7.1.5 [dcl.constexpr]);</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1992"></A><H4>1992.
  
<TT>new (std::nothrow) int[N]</TT> can throw
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Sebor
 &#160;&#160;&#160;

 <B>Date: </B>2014-08-27




<P>According to 5.3.4 [expr.new] paragraph 7,</P>

<BLOCKQUOTE>

If the expression, after converting to <TT>std::size_t</TT>, is a
core constant expression and the expression is erroneous,
the program is ill-formed. Otherwise,
a <I>new-expression</I> with an erroneous expression does
not call an allocation function and terminates by throwing
an exception of a type that would match a handler
(15.3 [except.handle]) of type
<TT>std::bad_array_new_length</TT> (18.6.2.2 [new.badlength]).

<P>This wording makes no provision for an expression like</P>

<PRE>
  new (std::nothrow) int[N]
</PRE>

<P>which most programmers would intuitively expect not to throw
an exception under any condition.</P>

</BLOCKQUOTE>

<P><B>Proposed resolution (May, 2015) [SUPERSEDED]:</B></P>

<P>Change the last part of
5.3.4 [expr.new] paragraph 7 as follows,
converting the running text into bullets, and making the
last sentence into a paragraph 8:</P>

<BLOCKQUOTE>

<P>...If the expression<SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is erroneous</SPAN>
after converting to <TT>std::size_t</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the <I>expression</I></SPAN> is a core constant
expression<SPAN style="text-decoration:line-through;background-color:#FFA0A0"> and the expression is erroneous</SPAN>, the program is
ill-formed<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">;</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Otherwise</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise</SPAN>,
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">a <I>new-expression</I> with an erroneous expression does
not call</SPAN> an allocation function <SPAN style="font-weight:bold;background-color:#A0FFA0">is not called;
instead</SPAN></P></LI>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the allocation function that would have been
called is non-throwing (15.4 [except.spec]), the value
of the <I>new-expression</I> is the null pointer value of the
required result type;</SPAN></P></LI>


<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, the
<I>new-expression</I></SPAN> terminates by throwing an
exception of a type that would match a handler
(15.3 [except.handle]) of type
<TT>std::bad_array_new_length</TT>
(18.6.2.2 [new.badlength]).</P></LI>

</UL>

</UL>

<P>When the value of the <I>expression</I> is zero, the
allocation function is called to allocate an array with no
elements.</P>

</BLOCKQUOTE>

<P><B>Notes from the October, 2015 meeting:</B></P>

<P>The text in 15.4 paragraph 15 should also be changed.</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<OL><LI><P>Change 5.3.4 [expr.new] paragraph 7 as
follows, dividing the running text into bullets and making
the last sentence into a new paragraph:</P></LI>

<BLOCKQUOTE>

<P>The expression in a <I>noptr-new-declarator</I> is erroneous
if:</P>

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

<P>If the <I>expression</I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is
erroneous</SPAN> after converting
to <TT>std::size_t</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the <I>expression</I></SPAN> is a core
constant expression <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and the expression is
erroneous</SPAN>, the program is
ill-formed<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">;</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Otherwise</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise</SPAN>,
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">a <I>new-expression</I> with an erroneous expression does
not call</SPAN> an allocation function <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">is not called; instead</SPAN></P></LI>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the allocation function that would have been
called has a non-throwing exception specification
(15.4 [except.spec]), the value of the
<I>new-expression</I> is the null pointer value of the required
result type;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, the <I>new-expression</I></SPAN>
terminates by throwing an exception of a type that would
match a handler (15.3 [except.handle]) of type
<TT>std::bad_array_new_length</TT>
(18.6.2.2 [new.badlength]).</P></LI>

</UL>

</UL>

<P>When the value of the expression is zero, the allocation
function is called to allocate an array with no
elements.</P>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<P>The <I>set of potential exceptions of an
expression</I> <TT>e</TT> is empty if e is a core constant
expression (5.20 [expr.const]). Otherwise, it is the
union of the sets of potential exceptions of the immediate
subexpressions of <TT>e</TT>, including default argument expressions
used in a function call, combined with a set <I>S</I> defined by
the form of e, as follows:</P>

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

<LI>

<P>If <TT>e</TT> implicitly invokes <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">one or
more</SPAN> function<SPAN style="font-weight:bold;background-color:#A0FFA0">s</SPAN> (such as an overloaded
operator, an allocation function in a <I>new-expression</I>,
or a destructor if <TT>e</TT> is a full-expression
(1.9 [intro.execution])), <I>S</I> is the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">set of
potential exceptions of the function.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">union
of:</SPAN></P></LI>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">the sets of potential exceptions of all such
functions, and</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if <TT>e</TT> is a <I>new-expression</I> with a
non-constant <I>expression</I> in the
<I>noptr-new-declarator</I> (5.3.4 [expr.new]) and
the allocation function selected for <TT>e</TT> has a
non-empty set of potential exceptions, the set containing
<TT>std::bad_array_new_length</TT>.</SPAN></P></LI>

</UL>

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

<LI>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If <TT>e</TT> is a <I>new-expression</I> with a non-constant
<I>expression</I> in the <I>noptr-new-declarator</I>
(5.3.4 [expr.new]), <I>S</I> consists of the type
<TT>std::bad_array_new_length</TT>.</SPAN></P></LI>

</UL>

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

</BLOCKQUOTE>

<LI><P>Change the example in 15.4 [except.spec]
bullet 17.2 as follows:</P></LI>

<PRE>
  struct A {
    A(int = (A(5), 0)) noexcept;
    A(const A&amp;) throw();
    A(A&amp;&amp;) throw();
    ~A() throw(X);
  };
  struct B {
    B() throw();
    B(const B&amp;) = default; //<SPAN style="font-family:Times;font-style:italic"> exception specification contains no types</SPAN>
    B(B&amp;&amp;, int = (throw Y(), 0)) noexcept;
    ~B() throw(Y);
  };
  int n = 7;
  struct D : public A, public B {
    int * p = new (std::nothrow) int[n];
  //<SPAN style="font-family:Times;font-style:italic"> exception specification of </SPAN>D::D()<SPAN style="font-family:Times;font-style:italic"> contains </SPAN>X<SPAN style="font-family:Times;font-style:italic"> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and </SPAN></SPAN><SPAN style="text-decoration:line-through;background-color:#FFA0A0">std::bad_array_new_length</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> exception specification of </SPAN>D::D(const D&amp;)<SPAN style="font-family:Times;font-style:italic"> contains no types</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> exception specification of </SPAN>D::D(D&amp;&amp;)<SPAN style="font-family:Times;font-style:italic"> contains </SPAN>Y
    //<SPAN style="font-family:Times;font-style:italic"> exception specification of </SPAN>D::~D()<SPAN style="font-family:Times;font-style:italic"> contains </SPAN>X<SPAN style="font-family:Times;font-style:italic"> and </SPAN>Y
  };
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct exp : std::bad_alloc {};
  void *operator new[](size_t) throws(exp);
  struct E : public A {
    int * p = new int[n];
    //<SPAN style="font-family:Times;font-style:italic"> exception specification of </SPAN>E::E()<SPAN style="font-family:Times;font-style:italic"> contains </SPAN>X<SPAN style="font-family:Times;font-style:italic">, </SPAN>exp<SPAN style="font-family:Times;font-style:italic">, and </SPAN>std::bad_array_new_length
};</SPAN>
</PRE>

</OL>

<BR><BR><HR><A NAME="2012"></A><H4>2012.
  
Lifetime of references
</H4><B>Section: </B>3.7&#160; [basic.stc]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2014-09-29




<P>According to 3.7 [basic.stc] paragraph 3,</P>

<BLOCKQUOTE>

The storage duration categories apply to references as
well. The lifetime of a reference is its storage duration.

</BLOCKQUOTE>

<P>This is clearly not correct; references can have static
storage duration but be dynamically initialized.  Consider an
example like:</P>

<PRE>
  extern int&amp; r1;
  int&amp; f();
  int&amp; r2 = r1;  //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
  int&amp; r1 = f();
  int i = r2;    //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
</PRE>

<P><TT>r1</TT> is not initialized until after its use at #1, so
the initialization of <TT>r2</TT> should produce undefined
behavior, as should the use of <TT>r2</TT> at #2.</P>

<P>The description of the lifetime of a reference should be
deleted from 3.7 [basic.stc] and it should be described
properly in 3.8 [basic.life].</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<OL><LI><P>Change 3.7 [basic.stc] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

The storage duration categories apply to references as well. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The lifetime
of a reference is its storage duration.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 3.8 [basic.life] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

The <I>lifetime</I> of an object <SPAN style="font-weight:bold;background-color:#A0FFA0">or reference</SPAN> is a runtime
property of the object <SPAN style="font-weight:bold;background-color:#A0FFA0">or reference</SPAN>. An object is said to
have...

</BLOCKQUOTE>

<LI><P>Add the following as a new paragraph following
3.7 [basic.stc] paragraph 2:</P></LI>

<BLOCKQUOTE>

<P>[<I>Note:</I> The lifetime of an array object starts as soon as storage
with proper size and alignment is obtained, and its lifetime ends when the
storage which the array occupies is reused or
released. 12.6.2 [class.base.init] describes the lifetime of base and
member subobjects. &#8212;<I>end note</I>]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The lifetime of a reference begins when its initialization is
complete. The lifetime of a reference ends as if it were a scalar
object.</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 3.8 [basic.life] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

The properties ascribed to objects <SPAN style="font-weight:bold;background-color:#A0FFA0">and references</SPAN> throughout
this International Standard apply for a given object <SPAN style="font-weight:bold;background-color:#A0FFA0">or
reference</SPAN> only during its lifetime. [<I>Note:</I>...

</BLOCKQUOTE>

<PLI><P>Change 5 [expr] paragraph 5 as follows:</P></PLI>

<BLOCKQUOTE>

If an expression initially has the type &#8220;reference
to <TT>T</TT>&#8221; (8.3.2 [dcl.ref],
8.5.3 [dcl.init.ref]), the type is adjusted to <TT>T</TT> prior to
any further analysis. The expression designates the object or function
denoted by the reference, and the expression is an lvalue or an xvalue,
depending on the expression. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> Before the lifetime of
the reference has started or after it has ended, the behavior is
undefined (see 3.8 [basic.life]). &#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

</OL>

<P><I>Drafting note:</I> there is no change to 3.8 [basic.life]
 paragraph 4:</P>

<BLOCKQUOTE>

A program may end the lifetime of any object by reusing the storage which
the object occupies or by explicitly calling the destructor for an object
of a class type with a non-trivial destructor. For an object of a class
type...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2032"></A><H4>2032.
  
Default <I>template-argument</I>s of variable templates
</H4><B>Section: </B>14.1&#160; [temp.param]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>CWG
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-03


<P>According to 14.1 [temp.param] paragraph11,</P>

<BLOCKQUOTE>

If a <I>template-parameter</I> of a class template or alias
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 or alias template is a template parameter
pack, it shall be the last <I>template-parameter</I>.

</BLOCKQUOTE>

<P>These requirements should apply to variable templates as well.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

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

<BLOCKQUOTE>

If a <I>template-parameter</I> of a class template<SPAN style="font-weight:bold;background-color:#A0FFA0">, variable
template,</SPAN> or alias 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<SPAN style="font-weight:bold;background-color:#A0FFA0">,
primary variable template,</SPAN> or alias template is a template parameter
pack, it shall be the last <I>template-parameter</I>. A template parameter
pack...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2033"></A><H4>2033.
  
Redundant restriction on partial specialization argument
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>CWG
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-04


<P>Bullets 8.3 and 8.4 of 14.5.5 [temp.class.spec] say,</P>

<BLOCKQUOTE>

<P>Within the argument list of a class template partial
specialization, the following restrictions apply:</P>

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

<LI><P>The argument list of the specialization shall not be
identical to the implicit argument list of the primary
template.</P></LI>

<LI><P>The specialization shall be more specialized than the
primary template (14.5.5.2 [temp.class.order]).</P></LI>

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

</UL>

</BLOCKQUOTE>

<P>The former is implied by the latter and should be
omitted.</P>

<P>(See also issues 1315,
1647, and
2127.)</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Delete bullet 8.3 of 14.5.5 [temp.class.spec]:</P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The argument list of the specialization shall not be
identical to the implicit argument list of the primary
template.</SPAN></P></LI></UL>

<BR><BR><HR><A NAME="2038"></A><H4>2038.
  
Document C++14 incompatibility of new braced deduction rule
</H4><B>Section: </B>C.4&#160; [diff.cpp14]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Caves
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-08


<P>The adoption of document N3922 at the November, 2014 meeting
introduces a new incompatibility that should be documented in Annex
C [diff]:</P>

<PRE>
  int x1 = 1;
  auto x2{x1};    //<SPAN style="font-family:Times;font-style:italic"> Is now </SPAN>int<SPAN style="font-family:Times;font-style:italic"> before was </SPAN>std::initializer&lt;int&gt;
</PRE>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Insert the following as a new section following
C.4.1 [diff.cpp14.lex]:</P>

<BLOCKQUOTE>

<TABLE STYLE="WIDTH:100%">
<TR><TD><H2><SPAN style="font-weight:bold;background-color:#A0FFA0">C.4.2 Clause 7: Declarations</SPAN></H2></TD>
<TD ALIGN="RIGHT"><H2><SPAN style="font-weight:bold;background-color:#A0FFA0">[diff.cpp14.dcl]</SPAN></H2></TD></TR></TABLE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">7.1.6.4 [dcl.spec.auto]<BR>
<B>Change:</B> <TT>auto</TT> deduction from <I>braced-init-list</I><BR>
<B>Rationale:</B> More intuitive deduction behavior<BR>
<B>Effect on original feature:</B> Valid C++14 code may fail to compile
or may change meaning in this International Standard. For example:</SPAN>
</P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  auto x1{1};    //<SPAN style="font-family:Times;font-style:italic"> Was </SPAN>std::initializer_list&lt;int&gt;<SPAN style="font-family:Times;font-style:italic">, now </SPAN>int
  auto x2{1, 2}; //<SPAN style="font-family:Times;font-style:italic"> Was </SPAN>std::initializer_list&lt;int&gt;<SPAN style="font-family:Times;font-style:italic">, now ill-formed</SPAN></SPAN>
</PRE>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2039"></A><H4>2039.
  
Constant conversions to <TT>bool</TT>
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-09




<P>According to 15.4 [except.spec] paragraph 1,</P>

<BLOCKQUOTE>

In a <I>noexcept-specification</I>,
the <I>constant-expression</I>, if supplied, shall be a
constant expression (5.20 [expr.const]) that is
contextually converted to bool (Clause
4 [conv]).

</BLOCKQUOTE>

<P>This allows the expression to have any type that can be converted
to <TT>bool</TT>, which is too lenient; it should instead say something
like &#8220;a converted constant expression of type <TT>bool</TT>
(5.20 [expr.const]).&#8221;  This would include the
conversion to <TT>bool</TT> in the determination of whether the
expression is constant or not and would also disallow narrowing
conversions.</P>

<P>A similar consideration applies to <TT>static_assert</TT>
(7 [dcl.dcl] paragraph 6), which should probably be
recast to something like, &#8220;an expression that is a constant
expression (5.20 [expr.const]) after contextual conversion
to <TT>bool</TT> (Clause 4 [conv]).&#8221;</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<OL><LI><P>Change 5.20 [expr.const] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

...binds directly. [<I>Note:</I> such expressions may be used in new
expressions (5.3.4 [expr.new]), as case expressions
(6.4.2 [stmt.switch]), as enumerator initializers if the underlying
type is fixed (7.2 [dcl.enum]), as array bounds
(8.3.4 [dcl.array]), and as non-type template arguments
(14.3 [temp.arg]). &#8212;<I>end note</I>] <SPAN style="font-weight:bold;background-color:#A0FFA0">A <I>contextually
converted constant expression of type <TT>bool</TT></I> is an expression,
contextually converted to <TT>bool</TT> (Clause 4 [conv]),
where the converted expression is a constant expression and the conversion
sequence contains only the conversions above.</SPAN>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

In a <I>static_assert-declaration</I><SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN>
the <I>constant-expression</I> shall be a <SPAN style="font-weight:bold;background-color:#A0FFA0">contextually converted</SPAN>
constant expression <SPAN style="font-weight:bold;background-color:#A0FFA0">of type <TT>bool</TT></SPAN>
(5.20 [expr.const]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">that can be contextually converted
to <TT>bool</TT> (Clause 4 [conv])</SPAN>. If the value of the
expression when so converted is <TT>true</TT>...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

In a <I>noexcept-specification</I>, the <I>constant-expression</I>, if
supplied, shall be a <SPAN style="font-weight:bold;background-color:#A0FFA0">contextually converted</SPAN> constant expression
<SPAN style="font-weight:bold;background-color:#A0FFA0">of type <TT>bool</TT></SPAN> (5.20 [expr.const]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">that is
contextually converted to <TT>bool</TT> (Clause
4 [conv])</SPAN>. A <TT>(</TT> token that
follows <TT>noexcept</TT>...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2040"></A><H4>2040.
  
<I>trailing-return-type</I> no longer ambiguous
</H4><B>Section: </B>8&#160; [dcl.decl]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-09


<P>According to 8 [dcl.decl] paragraph 5,</P>

<BLOCKQUOTE>

<P>The <I>type-id</I> in a <I>trailing-return-type</I> includes the longest
possible sequence of <I>abstract-declarator</I>s. [<I>Note:</I> This
resolves the ambiguous binding of array and function
declarators. [<I>Example:</I></P>

<PRE>
  auto f()-&gt;int(*)[4]; //<SPAN style="font-family:Times;font-style:italic"> function returning a pointer to array[4] of </SPAN>int
                       //<SPAN style="font-family:Times;font-style:italic"> not function returning array[4] of pointer to </SPAN>int
</PRE>

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

</BLOCKQUOTE>

<P>However, the grammar has changed since that rule and example were
added; because <I>trailing-return-type</I> can only appear at the top
level, there is no longer any potential ambiguity.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Delete 8 [dcl.decl] paragraph 5:</P>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The optional <I>attribute-specifier-seq</I> in
a <I>trailing-return-type</I> appertains to the indicated return
type. The <I>type-id</I> in a <I>trailing-return-type</I> includes the
longest possible sequence of <I>abstract-declarator</I>s. [<I>Note:</I>
This resolves the ambiguous binding of array and function
declarators. [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  auto f()-&gt;int(*)[4]; //<SPAN style="font-family:Times;font-style:italic"> function returning a pointer to array[4] of </SPAN>int
                       //<SPAN style="font-family:Times;font-style:italic"> not function returning array[4] of pointer to </SPAN>int</SPAN>
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8212;<I>end example</I>] &#8212;<I>end note</I>]</SPAN></P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2041"></A><H4>2041.
  
Namespace for explicit class template specialization
</H4><B>Section: </B>14.7.3&#160; [temp.expl.spec]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-11




<P>14.7.3 [temp.expl.spec] paragraph 2 says,</P>

<BLOCKQUOTE>

An explicit specialization shall be declared in a namespace
enclosing the specialized template. An explicit
specialization whose <I>declarator-id</I> is not qualified
shall be declared in the nearest enclosing namespace of the
template, or, if the namespace is inline
(7.3.1 [namespace.def]), any namespace from its
enclosing namespace set.

</BLOCKQUOTE>

<P>However, an explicit specialization of a class template
does not have a <I>declarator-id</I>.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

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

<BLOCKQUOTE>

An explicit specialization shall be declared in a namespace enclosing the
specialized template. An explicit specialization whose <I>declarator-id</I>
<SPAN style="font-weight:bold;background-color:#A0FFA0">or <I>class-head-name</I></SPAN> is not qualified shall be declared in
the nearest enclosing namespace of the template, or, if the namespace is
inline (7.3.1 [namespace.def]), any namespace from its enclosing
namespace set. Such a declaration...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2044"></A><H4>2044.
  
<TT>decltype(auto)</TT> and <TT>void</TT>
</H4><B>Section: </B>7.1.6.4&#160; [dcl.spec.auto]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-14




<P>The resolution of issue 1877
does not correctly
handle <TT>decltype(auto)</TT> return types with <TT>void</TT> return
expressions:</P>

<PRE>
  T f();
  decltype(auto) g() { return f(); }
</PRE>

<P>fails when <TT>T</TT> is <TT>void</TT>.</P>

<P><U>Suggested resolution:</U></P>

<P>Change 7.1.6.4 [dcl.spec.auto] paragraph 7 as follows:</P>

<BLOCKQUOTE>

...In the case of a <TT>return</TT> with no operand or with an
operand of type <TT>void</TT>, the declared return type
shall be <TT>auto</TT> <SPAN style="font-weight:bold;background-color:#A0FFA0">or <TT>decltype(auto)</TT></SPAN>
and the deduced return type is <TT>void</TT>. Otherwise...

</BLOCKQUOTE>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 7.1.6.4 [dcl.spec.auto] paragraph 7 as follows:</P>

<BLOCKQUOTE>

<P>When a variable declared using a placeholder type is initialized, or a
<TT>return</TT> statement occurs in a function declared with a return type
that contains a placeholder type, the deduced return type or variable type
is determined from the type of its initializer. In the case of
a <TT>return</TT> with no operand or with an operand of type <TT>void</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the declared return type is <TT>decltype(auto)</TT>, then the
deduced return type is <TT>void</TT>;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, </SPAN>the declared return type shall
be <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>auto</TT> and the deduced return type is
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void</TT>.</P></LI>

</UL>

<P>Otherwise, let <TT>T</TT> be...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2047"></A><H4>2047.
  
Coordinating &#8220;throws anything&#8221; specifications
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-18




<P>The resolutions of issues 330 and
1351 use different terminology for an
exception specification that can throw anything: the former
refers to a &#8220;(conceptual) set of all types,&#8221; while the
latter uses a &#8220;pseudo-type, denoted by 'any'.&#8221;  These
should be unified.</P>

<P><B>Proposed resolution (October, 2015) [SUPERSEDED]:</B></P>

<OL><LI><P>Change 15.4 [except.spec] paragraph 13 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">A</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The <I>set of</I></SPAN> <I>potential
exception<SPAN style="font-weight:bold;background-color:#A0FFA0">s</SPAN></I> of a given context is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">either
a type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a set of types</SPAN> that might be thrown
as an exception<SPAN style="text-decoration:line-through;background-color:#FFA0A0"> or a pseudo-type, denoted by
&#8220;any&#8221;, that represents the situation where an
exception of an arbitrary type might be thrown</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">; the
(conceptual) set of all types is used to denote that an
exception of arbitrary type might be thrown</SPAN>. A
subexpression <TT>e1</TT> of an expression <TT>e</TT> is
an <I>immediate subexpression</I> if there is no
subexpression <TT>e2</TT> of <TT>e</TT> such that
<TT>e1</TT> is a subexpression of <TT>e2</TT>.

</BLOCKQUOTE>

<LI><P>Delete 15.4 [except.spec] paragraph 14:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The <I>set of potential exceptions of a function,
function pointer, or member function pointer</I> <TT>f</TT>
is defined as follows:</SPAN></P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the exception specification of <TT>f</TT> is the set of
all types, the set consists of the pseudo-type
&#8220;any&#8221;.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Otherwise, the set consists of every type in the exception
specification of <TT>f</TT>.</SPAN></P></LI>

</UL>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<P>The <I>set of potential exceptions of an
expression</I> <TT>e</TT> is empty if <TT>e</TT> is a core
constant expression (5.20 [expr.const]). Otherwise,
it is the union of the sets of potential exceptions of the
immediate subexpressions of <TT>e</TT>, including default
argument expressions used in a function call, combined with
a set <I>S</I> defined by the form of <TT>e</TT>, as
follows:</P>

<UL><LI><P>If e is a function call
(5.2.2 [expr.call]):</P></LI>

<UL><LI><P>If its <I>postfix-expression</I> is a (possibly
parenthesized) <I>id-expression</I>
(5.1.1 [expr.prim.general]), class member access
(5.2.5 [expr.ref]), or pointer-to-member operation
(5.5 [expr.mptr.oper]) whose <I>cast-expression</I> is
an <I>id-expression</I>, <I>S</I> is the set
of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">potential exceptions</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">types in the
exception specification</SPAN> of the entity selected by the
contained <I>id-expression</I> (after overload resolution,
if applicable).</P></LI>

<LI><P>Otherwise, <I>S</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">contains the pseudo-type
&#8220;any&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is the set of all
types</SPAN>.</P></LI>

</UL>

<LI><P>If <TT>e</TT> implicitly invokes a function (such as
an overloaded operator, an allocation function in
a <I>new-expression</I>, or a destructor if <TT>e</TT> is a
full-expression (1.9 [intro.execution])), <I>S</I> is the
set of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">potential exceptions</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">types in the
exception specification</SPAN> of the function.</P></LI>

<LI><P>if <TT>e</TT> is a <I>throw-expression</I>
(5.17 [expr.throw]), <I>S</I> consists of the type
of the exception object that would be initialized by the
operand, if present, or <SPAN style="font-weight:bold;background-color:#A0FFA0">is</SPAN> the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pseudo-type
&#8220;any&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">set of all types</SPAN>
otherwise.</P></LI>

<LI><P>if <TT>e</TT> is a <TT>dynamic_cast</TT> expression
that casts to a reference type and requires a run-time check
(5.2.7 [expr.dynamic.cast]), <I>S</I> consists of the type
<TT>std::bad_cast</TT>.</P></LI>

<LI><P>if <TT>e</TT> is a <TT>typeid</TT> expression applied
to a glvalue expression whose type is a polymorphic class
type (5.2.8 [expr.typeid]), <I>S</I> consists of the type
<TT>std::bad_typeid</TT>.</P></LI>

<LI><P>if <TT>e</TT> is a <I>new-expression</I> with a non-constant
expression in the <I>noptr-new-declarator</I>
(5.3.4 [expr.new]), <I>S</I> consists of the type
<TT>std::bad_array_new_length</TT>.</P></LI>

</UL><P>[<I>Example:</I> Given the following declarations</P>

<PRE>
  void f() throw(int);
  void g();
  struct A { A(); };
  struct B { B() noexcept; };
  struct D<SPAN style="text-decoration:line-through;background-color:#FFA0A0">()</SPAN> { D() throw (double); };
</PRE>

<P>the set of potential exceptions for some sample expressions
is:</P>

<UL><LI><P>for <TT>f()</TT>, the set consists
of <TT>int</TT>;</P></LI>

<LI><P>for <TT>g()</TT>, the set <SPAN style="text-decoration:line-through;background-color:#FFA0A0">consists of
&#8220;any&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is the set of all types</SPAN>;</P></LI>

<LI><P>for <TT>new A</TT>, the set <SPAN style="text-decoration:line-through;background-color:#FFA0A0">consists of
&#8220;any&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is the set of all types</SPAN>;</P></LI>

<LI><P>for <TT>B()</TT>, the set is empty;</P></LI>

<LI><P>for <TT>new D</TT>, the set <SPAN style="text-decoration:line-through;background-color:#FFA0A0">consists of
&#8220;any&#8221; and <TT>double</TT></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">is the set of all types</SPAN>. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> This set
conceptually includes the type <TT>double</TT>.
&#8212;<I>end note</I>]</SPAN></P></LI>

</UL>

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

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Given a</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A</SPAN> member function <TT>f</TT> of
some class <TT>X</TT>, where <TT>f</TT> is an inheriting
constructor (_N4527_.12.9 [class.inhctor]) or an
implicitly-declared special member function, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the <I>set
of potential exceptions of the implicitly-declared member
function</I> <TT>f</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is considered to have an
implicit exception specification that</SPAN> consists of all
the members from the following sets...

</BLOCKQUOTE>

<LI><P>Delete the normative portion of 15.4 [except.spec]
paragraph 17 and merge the note and example into the preceding
paragraph, as follows:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">An inheriting constructor (_N4527_.12.9 [class.inhctor]) and an
implicitly-declared special member function (Clause
12 [special]) are considered to have an implicit
exception specification, as follows, where <I>S</I> is the set of
potential exceptions of the implicitly-declared member
function:</SPAN></P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if <I>S</I> contains the pseudo-type &#8220;any&#8221;, the
implicit exception specification is the set of all types;</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">otherwise, the implicit exception specification contains all
the types in <I>S</I>.</SPAN></P></LI>

</UL>

<P>[<I>Note:</I> An instantiation of an inheriting constructor
template...</P>

</BLOCKQUOTE>

</OL>

<P><B>Additional note (November, 2015):</B></P>

<P>The base text underlying the preceding proposed resolution was
changed at the October, 2015 meeting by the adoption of paper
P0136R1. As a result, this issue has been returned to "drafting"
status to allow reconciliation of the two sets of changes.</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<OL><LI><P>Change 15.4 [except.spec] paragraph 12 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">A</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The <I>set of</I></SPAN> <I>potential
exception<SPAN style="font-weight:bold;background-color:#A0FFA0">s</SPAN></I> of a given context is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">either
a type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a set of types</SPAN> that might be thrown
as an exception <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or a pseudo-type, denoted by
&#8220;any&#8221;, that represents the situation where an
exception of an arbitrary type might be thrown</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">;
the (conceptual) set of all types is used to denote that an
exception of arbitrary type might be thrown</SPAN>. A
subexpression <TT>e1</TT> of an expression <TT>e</TT> is
an <I>immediate subexpression</I> if there is no
subexpression <TT>e2</TT> of <TT>e</TT> such that
<TT>e1</TT> is a subexpression of <TT>e2</TT>.

</BLOCKQUOTE>

<LI><P>Delete 15.4 [except.spec] paragraph 13:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The set of potential exceptions of a function,
function pointer, or member function pointer <TT>f</TT> is defined as
follows:</SPAN></P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the exception specification of <TT>f</TT> is the
set of all types, the set consists of the pseudo-type
&#8220;any&#8221;.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Otherwise, the set consists of every type in the exception
specification of <TT>f</TT>.</SPAN></P></LI>

</UL>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<P>The <I>set of potential exceptions of an
expression</I> <TT>e</TT> is empty if <TT>e</TT> is a core constant
expression (5.20 [expr.const]). Otherwise, it is the
union of the sets of potential exceptions of the immediate
subexpressions of <TT>e</TT>, including default argument expressions
used in a function call, combined with a set <I>S</I> defined by
the form of <TT>e</TT>, as follows:</P>

<UL><LI><P>If <TT>e</TT> is a function call
(5.2.2 [expr.call]):</P></LI>

<UL><LI><P>If its <I>postfix-expression</I> is a (possibly
parenthesized) <I>id-expression</I>
(5.1.1 [expr.prim.general]), class member access
(5.2.5 [expr.ref]), or pointer-to-member operation
(5.5 [expr.mptr.oper]) whose <I>cast-expression</I> is
an <I>id-expression</I>, <I>S</I> is the set
of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">potential exceptions</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">types in the
exception specification</SPAN> of the entity selected by the
contained <I>id-expression</I> (after overload resolution,
if applicable).</P></LI>

<LI><P>Otherwise, if the <I>postfix-expression</I> has type
&#8220;<TT>noexcept</TT> function&#8221; or &#8220;pointer to
<TT>noexcept</TT> function&#8221;, <I>S</I> is the empty set.</P></LI>

<LI><P>Otherwise, <I>S</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">contains the pseudo-type
&#8220;any&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is the set of all
types</SPAN>.</P></LI>

</UL>

<LI><P>If <TT>e</TT> implicitly invokes a function (such as
an overloaded operator, an allocation function in
a <I>new-expression</I>, or a destructor if <TT>e</TT> is a
full-expression (1.9 [intro.execution])), <I>S</I> is the
set of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">potential exceptions</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">types in the
exception specification</SPAN> of the function.</P></LI>

<LI><P>If <TT>e</TT> initializes an object of
type <TT>D</TT> using an inherited constructor for a class
of type <TT>B</TT> (12.6.3 [class.inhctor.init]), <I>S</I>
also contains the sets of potential exceptions of the
implied constructor invocations for subobjects of <TT>D</TT>
that are not subobjects of <TT>B</TT> (including default
argument expressions used in such invocations) as selected
by overload resolution, and the sets of potential exceptions
of the initialization of non-static data members
from <I>brace-or-equal-initializer</I>s
(12.6.2 [class.base.init]).</P></LI>

<LI><P>If <TT>e</TT> is a <I>throw-expression</I>
(5.17 [expr.throw]), <I>S</I> consists of the type
of the exception object that would be initialized by the
operand, if present, or <SPAN style="font-weight:bold;background-color:#A0FFA0">is</SPAN> the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pseudo-type
&#8220;any&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">set of all types</SPAN>
otherwise.</P></LI>

<LI><P>If <TT>e</TT> is a <TT>dynamic_cast</TT> expression
that casts to a reference type and requires a run-time check
(5.2.7 [expr.dynamic.cast]), <I>S</I> consists of the type
<TT>std::bad_cast</TT>.</P></LI>

<LI><P>If <TT>e</TT> is a <TT>typeid</TT> expression applied
to a glvalue expression whose type is a polymorphic class
type (5.2.8 [expr.typeid]), <I>S</I> consists of the type
<TT>std::bad_typeid</TT>.</P></LI>

<LI><P>If <TT>e</TT> is a <I>new-expression</I> with a non-constant
expression in the <I>noptr-new-declarator</I>
(5.3.4 [expr.new]), <I>S</I> consists of the type
<TT>std::bad_array_new_length</TT>.</P></LI>

</UL>

<P>[<I>Example:</I> Given the following declarations</P>

<PRE>
  void f() throw(int);
  void g();
  struct A { A(); };
  struct B { B() noexcept; };
  struct D { D() throw (double); };
</PRE>

<P>the set of potential exceptions for some sample expressions
is:</P>

<UL><LI><P>for <TT>f()</TT>, the set consists of <TT>int</TT>;</P></LI>

<LI><P>for <TT>g()</TT>, the set <SPAN style="text-decoration:line-through;background-color:#FFA0A0">consists of &#8220;any&#8221;</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">is the set of all types</SPAN>;</P></LI>

<LI><P>for <TT>new A</TT>, the set <SPAN style="text-decoration:line-through;background-color:#FFA0A0">consists of &#8220;any&#8221;</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">is the set of all types</SPAN>;</P></LI>

<LI><P>for <TT>B()</TT>, the set is empty;</P></LI>

<LI><P>for <TT>new D</TT>, the set <SPAN style="text-decoration:line-through;background-color:#FFA0A0">consists of
&#8220;any&#8221; and <TT>double</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is the set
of all types</SPAN>.</P></LI>

</UL>

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

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Given an</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">An</SPAN> implicitly-declared
special member function <TT>f</TT> of some class <TT>X</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">,
the <I>set of potential exceptions of the
implicitly-declared special member function</I> <TT>f</TT></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">is considered to have an implicit exception
specification that</SPAN> consists of all the members from
the following sets:...

</BLOCKQUOTE>

<LI><P>Delete the normative text of 15.4 [except.spec]
paragraph 17 and merge the example with the preceding paragraph:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">An implicitly-declared special member function (Clause
12 [special]) is considered to have an implicit
exception specification, as follows, where <I>S</I> is the set of
potential exceptions of the implicitly-declared special
member function:</SPAN></P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if <I>S</I> contains the pseudo-type &#8220;any&#8221;, the
implicit exception specification is the set of all types;</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">otherwise, the implicit exception specification contains all
the types in <I>S</I>.</SPAN></P></LI>

</UL>

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

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2061"></A><H4>2061.
  
Inline namespace after simplifications
</H4><B>Section: </B>7.3.1&#160; [namespace.def]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-12-18


<P>After the resolution of issue 1795,
7.3.1 [namespace.def] paragraph 3 now says:</P>

<BLOCKQUOTE>

In a <I>named-namespace-definition</I>, the <I>identifier</I> is
the name of the namespace. If the <I>identifier</I>, when looked up
(3.4.1 [basic.lookup.unqual]), refers to
a <I>namespace-name</I> (but not a <I>namespace-alias</I>)
introduced in the declarative region in which
the <I>named-namespace-definition</I> appears,
the <I>namespace-definition</I> <I>extends</I> the
previously-declared namespace. Otherwise, the <I>identifier</I> is
introduced as a <I>namespace-name</I> into the declarative
region in which the <I>named-namespace-definition</I>
appears.

</BLOCKQUOTE>

<P>This appears to break code like the following:</P>

<PRE>
  namespace A {
    inline namespace b {
      namespace C {
        template&lt;typename T&gt; void f();
      }
    }
  }

  namespace A {
    namespace C {
      template&lt;&gt; void f&lt;int&gt;() { }
    }
  }
</PRE>

<P>because (by definition of &#8220;declarative region&#8221;)
<TT>C</TT> cannot be used as an unqualified name to refer to
<TT>A::b::C</TT> within <TT>A</TT> if its declarative region is
<TT>A::b</TT>.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 7.3.1 [namespace.def] paragraph 3 as follows:</P>

<BLOCKQUOTE>

In a <I>named-namespace-definition</I>, the <I>identifier</I> is the name
of the namespace. If the <I>identifier</I>, when looked up
(3.4.1 [basic.lookup.unqual]), refers to a <I>namespace-name</I> (but not
a <I>namespace-alias</I>) <SPAN style="font-weight:bold;background-color:#A0FFA0">that was</SPAN> introduced in
the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">declarative region</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">namespace</SPAN> in which
the <I>named-namespace-definition</I> appears <SPAN style="font-weight:bold;background-color:#A0FFA0">or that was introduced
in a member of the inline namespace set of that namespace</SPAN>,
the <I>namespace-definition</I> extends the previously-declared
namespace. Otherwise, the <I>identifier</I> is introduced as
a <I>namespace-name</I> into the declarative region in which
the <I>named-namespace-definition</I> appears.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2063"></A><H4>2063.
  
Type/nontype hiding in class scope
</H4><B>Section: </B>3.3.1&#160; [basic.scope.declarative]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2014-12-20




<P>The type/nontype hiding rules (&#8220;<TT>struct stat</TT>
hack&#8221;) do not apply in class scope.  This is a C
compatibility issue:</P>

<PRE>
  struct A {
    struct B { int x; } b;
    int B;    // Permitted in C
  };
</PRE>

<P>Since the type/nontype hiding rules exist for C compatibility,
should this example be supported?</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 3.3.1 [basic.scope.declarative] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>Given a set of declarations in a single declarative region, each of which
specifies the same unqualified name,</P>

<UL><LI><P>they shall all refer to the same entity, or all refer to
functions and function templates; or</P></LI>

<LI>

<P>exactly one declaration shall declare a class name or enumeration name
that is not a typedef name and the other declarations shall all refer to
the same variable<SPAN style="font-weight:bold;background-color:#A0FFA0">, non-static data member,</SPAN> or enumerator, or all
refer to functions and function templates; in this case the class name or
enumeration name is hidden (3.3.10 [basic.scope.hiding]). [<I>Note:</I> A
namespace name or a class template name must be unique in its declarative
region (7.3.2 [namespace.alias], Clause 14 [temp]).
&#8212;<I>end note</I>]</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2064"></A><H4>2064.
  
Conflicting specifications for dependent <I>decltype-specifier</I>s
</H4><B>Section: </B>14.4&#160; [temp.type]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-12-27




<P>According to 14.6.2.1 [temp.dep.type] paragraph 9, a type is
dependent if it is</P>

<BLOCKQUOTE>

denoted by <TT>decltype(</TT><I>expression</I><TT>)</TT>,
where <I>expression</I> is
type-dependent (14.6.2.2 [temp.dep.expr]).

</BLOCKQUOTE>

<P>However, 14.4 [temp.type] paragraph 2 says,</P>

<BLOCKQUOTE>

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 expressions 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>]

</BLOCKQUOTE>

<P>These seem to be in need of reconciliation.</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<P>Change 14.4 [temp.type] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If an expression <TT>e</TT> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">involves a template parameter</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">is type-dependent (14.6.2.2 [temp.dep.expr])</SPAN>,
<TT>decltype(e)</TT> denotes a unique dependent type. Two
such <I>decltype-specifier</I>s refer to the same type only
if their expressions are equivalent
(14.5.6.1 [temp.over.link]). [<I>Note:</I> however, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">it</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">such a type</SPAN> may be aliased, e.g., by
a <I>typedef-name</I>. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2066"></A><H4>2066.
  
Does type-dependent imply value-dependent?
</H4><B>Section: </B>14.6.2.3&#160; [temp.dep.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-01-09




<P>Consider the following example:</P>

<PRE>
  template&lt;int&gt; struct X { typedef int type; };
  template&lt;typename T&gt; struct Y {
    void f() { X&lt;false ? this - this : 0&gt;::type x; } //<SPAN style="font-family:Times;font-style:italic"> missing </SPAN>typename<SPAN style="font-family:Times;font-style:italic">?</SPAN>
  };
  void g() { Y&lt;void&gt;().f(); }
</PRE>

<P>This appears to be valid because the template argument expression is
not value-dependent.</P>


<P>Until I discovered this, I had been assuming that any
type-dependent expression is also value-dependent. The only
exception to that appears to be the expression <TT>this</TT>, which
may be type-dependent but is never value-dependent.</P>



<P>Now, <TT>this</TT> need not ever be value-dependent, because
evaluation of it will never succeed when it appears as a
subexpression of an expression that we're checking for
constant-expression-ness. But if that's really what we want
here, then the same applies to function parameters with
dependent types, and probably a few other cases.</P>

<P><B>Proposed resolution (September, 2015) [SUPERSEDED]:</B></P>

<P>Change 14.6.2.3 [temp.dep.constexpr] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>Expressions of the following form are value-dependent:</P>

<UL>
<TT>sizeof ... (</TT> <I>identifuer</I> <TT>)</TT><BR>
<TT><SPAN style="font-weight:bold;background-color:#A0FFA0">this</SPAN></TT><BR>
<I>fold-expression</I>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (March, 2016):</B></P>

<P>This issue is resolved by the resolution of
issue 2109.</P>

<BR><BR><HR><A NAME="2068"></A><H4>2068.
  
When can/must a defaulted virtual destructor be defined?
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-01-12




<P>The rules in 3.2 [basic.def.odr] and 12.4 [class.dtor]
do not specify when the destructor for <TT>B</TT> can/must be defined:</P>

<PRE>
   struct A { virtual ~A(); };
   struct B : A {};
   int main() {
     A *p = new B;
     delete p;
   }
</PRE>

<P>An implementation should be allowed, but not required, to
implicitly define a virtual special member function at any point
where it has been desclared, as well as being required to define
it as described in 12.4 [class.dtor] paragraph 6, etc.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

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

<BLOCKQUOTE>

A destructor that is defaulted and not defined as deleted is implicitly
defined when it is odr-used (3.2 [basic.def.odr]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">to destroy an
object of its class type (3.7 [basic.stc])</SPAN> or when it is
explicitly defaulted after its first declaration.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2069"></A><H4>2069.
  
Do destructors have names?
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-01-13


<P>According to 7.3.3 [namespace.udecl] paragraph 4,</P>

<BLOCKQUOTE>

[<I>Note:</I> Since destructors do not have names,
a <I>using-declaration</I> cannot refer to a destructor for
a base class....

</BLOCKQUOTE>

<P>However, 12.4 [class.dtor] paragraph 13 says,</P>

<BLOCKQUOTE>

In an explicit destructor call, the destructor name appears
as a <TT>~</TT> followed by a <I>type-name</I>
or <I>decltype-specifier</I> that denotes the destructor's
class type...

</BLOCKQUOTE>

<P>See also 3.4.3.1 [class.qual] bullet 1.1:</P>

<BLOCKQUOTE>

a destructor name is looked up as specified in
3.4.3 [basic.lookup.qual];

</BLOCKQUOTE>

<P><B>Proposed resolution (September, 2015):</B></P>

<OL><LI><P>Change 3.4.3.1 [class.qual] bullet 1.1 as follows:</P></LI>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a destructor name is looked up</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">the lookup for a destructor is</SPAN> as specified in 3.4.3 [basic.lookup.qual];</P></LI>

</UL>

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

<BLOCKQUOTE>

In an explicit destructor call, the destructor <SPAN style="text-decoration:line-through;background-color:#FFA0A0">name appears
as</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is specified by</SPAN> a <TT>~</TT> followed by
a <I>type-name</I> or <I>decltype-specifier</I> that denotes the
destructor's class type. The invocation...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2071"></A><H4>2071.
  
<TT>typedef</TT> with no declarator
</H4><B>Section: </B>7.1.3&#160; [dcl.typedef]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-01-16




<P>There should be a rule to prohibit the almost certainly
erroneous declaration</P>

<PRE>
  typedef struct X { };    //<SPAN style="font-family:Times;font-style:italic"> Missing declarator</SPAN>
</PRE>

<P><B>Proposed resolution (September, 2015):</B></P>

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

<BLOCKQUOTE>

Declarations containing the <I>decl-specifier</I> <TT>typedef</TT> declare
identifiers that can be used later for naming fundamental
(3.9.1 [basic.fundamental]) or compound (3.9.2 [basic.compound])
types. The <TT>typedef</TT> specifier shall not be combined in
a <I>decl-specifier-seq</I> with any other kind of specifier except
a <I>type-specifier</I>, and it shall not be used in
the <I>decl-specifier-seq</I> of a <I>parameter-declaration</I>
(8.3.5 [dcl.fct]) nor in the <I>decl-specifier-seq</I> of
a <I>function-definition</I> (8.4 [dcl.fct.def]). <SPAN style="font-weight:bold;background-color:#A0FFA0">If
a <TT>typedef</TT> specifier appears in a declaration without
a <I>declarator</I>, the program is ill-formed.</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2079"></A><H4>2079.
  
<TT>[[</TT> appearing in a <I>balanced-token-seq</I>
</H4><B>Section: </B>7.6.1&#160; [dcl.attr.grammar]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Caves
 &#160;&#160;&#160;

 <B>Date: </B>2015-02-03




<P>According to 7.6.1 [dcl.attr.grammar] paragraph 6,</P>

<BLOCKQUOTE>

Two consecutive left square bracket tokens shall appear only
when introducing
an <I>attribute-specifier</I>. [<I>Note:</I> If two
consecutive left square brackets appear where
an <I>attribute-specifier</I> is not allowed, the program is
ill-formed even if the brackets match an alternative grammar
production. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>In order to allow program fragments to appeae within
attributes, this restriction should not apply within the
<I>balanced-token-seq</I> of an attribute.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

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

<BLOCKQUOTE>

<P>Two consecutive left square bracket tokens shall appear only when
introducing an <I>attribute-specifier</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">or within
the <I>balanced-token-seq</I> of
an <I>attribute-argument-clause</I></SPAN>. [<I>Note:</I> If two consecutive
left square brackets appear where an <I>attribute-specifier</I> is not
allowed, the program is ill-formed even if the brackets match an
alternative grammar production. &#8212;<I>end note</I>]
[<I>Example:</I></P>

<PRE>
  int p[10];
  void f() {
    int x = 42, y[5];
    int(p[[x] { return x; }()]);  //<SPAN style="font-family:Times;font-style:italic"> error: invalid attribute on a nested</SPAN>
                                  //<SPAN style="font-family:Times;font-style:italic"> declarator-id and not a function-style cast of</SPAN>
                                  //<SPAN style="font-family:Times;font-style:italic"> an element of </SPAN>p<SPAN style="font-family:Times;font-style:italic">.</SPAN>
    y[[] { return 2; }()] = 2;    //<SPAN style="font-family:Times;font-style:italic"> error even though attributes are not allowed</SPAN>
                                  //<SPAN style="font-family:Times;font-style:italic"> in this context.</SPAN>

<SPAN style="font-weight:bold;background-color:#A0FFA0">    int i [[vendor::attr([[]])]]; //<SPAN style="font-family:Times;font-style:italic"> well-formed implementation-defined attribute.</SPAN></SPAN>
  }
</PRE>

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

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2085"></A><H4>2085.
  
Invalid example of adding special member function via default argument
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-02-13




<P>The example in 3.2 [basic.def.odr] bullet 6.6 reads,</P>

<PRE>
  //<SPAN style="font-family:Times;font-style:italic">translation unit 1:</SPAN>
  struct X {
    X(int);
    X(int, int);
  };
  X::X(int = 0) { }
  class D: public X { };
  D d2;     //<SPAN style="font-family:Times;font-style:italic"> </SPAN>X(int)<SPAN style="font-family:Times;font-style:italic"> called by </SPAN>D()

  //<SPAN style="font-family:Times;font-style:italic">translation unit 2:</SPAN>
  struct X {
    X(int);
    X(int, int);
  };
  X::X(int = 0, int = 0) { }
  class D: public X { };   //<SPAN style="font-family:Times;font-style:italic"> </SPAN>X(int, int)<SPAN style="font-family:Times;font-style:italic"> called by </SPAN>D()<SPAN style="font-family:Times;font-style:italic">;</SPAN>
                           //<SPAN style="font-family:Times;font-style:italic"> </SPAN>D()<SPAN style="font-family:Times;font-style:italic">'s implicit definition</SPAN>
                           //<SPAN style="font-family:Times;font-style:italic"> violates the ODR</SPAN>
</PRE>

<P>Creating a special member function via default arguments added
in an out-of-class definition, as is done here, is no longer
permitted, so at a minimum the example should be removed.  It is
not clear whether there remain any cases to which the normative
wording of bullet 6.6 would apply:</P>

<UL><LI><P>if <TT>D</TT> is a class with an implicitly-declared constructor
(12.1 [class.ctor]), it is as if the constructor was
implicitly defined in every translation unit where it is
odr-used, and the implicit definition in every translation
unit shall call the same constructor for a base class or a
class member of <TT>D</TT>.</P></LI></UL>

<P>If not, the entire bullet should be removed.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 3.2 [basic.def.odr] bullet 6.6 as follows:</P>

<UL><LI>

<P>if <TT>D</TT> is a class with an implicitly-declared constructor
(12.1 [class.ctor]), it is as if the constructor was implicitly
defined in every translation unit where it is odr-used, and the implicit
definition in every translation unit shall call the same constructor for a
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">base class or a class member</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">subobject</SPAN>
of <TT>D</TT>. [<I>Example:</I></P></LI>

<PRE>
  //<SPAN style="font-family:Times;font-style:italic">translation unit 1:</SPAN>
  struct X {
    X(int<SPAN style="font-weight:bold;background-color:#A0FFA0">, int</SPAN>);
    X(int, int<SPAN style="font-weight:bold;background-color:#A0FFA0">, int</SPAN>);
  };
  X::X(<SPAN style="font-weight:bold;background-color:#A0FFA0">int,</SPAN> int = 0) { }
  class D<SPAN style="text-decoration:line-through;background-color:#FFA0A0">: public X</SPAN> {
    <SPAN style="font-weight:bold;background-color:#A0FFA0">X x = 0;</SPAN>
  };
  D d2;            //<SPAN style="font-family:Times;font-style:italic"> </SPAN>X(<SPAN style="font-weight:bold;background-color:#A0FFA0">int,</SPAN> int)<SPAN style="font-family:Times;font-style:italic"> called by </SPAN>D()

  //<SPAN style="font-family:Times;font-style:italic">translation unit 2:</SPAN>
  struct X {
    X(int<SPAN style="font-weight:bold;background-color:#A0FFA0">, int</SPAN>);
    X(int, int<SPAN style="font-weight:bold;background-color:#A0FFA0">, int</SPAN>);
  };
  X::X(<SPAN style="font-weight:bold;background-color:#A0FFA0">int,</SPAN> int = 0, int = 0) { }
  class D<SPAN style="text-decoration:line-through;background-color:#FFA0A0">: public X</SPAN> {
    <SPAN style="font-weight:bold;background-color:#A0FFA0">X x = 0;</SPAN>
  };
                   //<SPAN style="font-family:Times;font-style:italic"> </SPAN>X(<SPAN style="font-weight:bold;background-color:#A0FFA0">int,</SPAN> int, int)<SPAN style="font-family:Times;font-style:italic"> called by </SPAN>D()<SPAN style="font-family:Times;font-style:italic">;</SPAN>
                   //<SPAN style="font-family:Times;font-style:italic"> </SPAN>D()<SPAN style="font-family:Times;font-style:italic">'s implicit definition</SPAN>
                   //<SPAN style="font-family:Times;font-style:italic"> violates the ODR</SPAN>
</PRE>

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

</UL>

<BR><BR><HR><A NAME="2095"></A><H4>2095.
  
Capturing rvalue references to functions by copy
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-07




<P>According to 5.1.2 [expr.prim.lambda] paragraph 15,</P>

<BLOCKQUOTE>

An entity is captured by copy if it is implicitly captured
and the <I>capture-default</I> is <TT>=</TT> or if it is explicitly
captured with a capture that is not of the form &amp;
<I>identifier</I> or
&amp; <I>identifier</I> <I>initializer</I>. For each entity
captured by copy, an unnamed non-static data member is
declared in the closure type. The declaration order of these
members is unspecified. The type of such a data member is
the type of the corresponding captured entity if the entity
is not a reference to an object, or the referenced type
otherwise.

</BLOCKQUOTE>

<P>It's not clear how to handle capture by copy when the
entity is an rvalue reference to function.  In particular,
this appears to be a contradiction with 5.1.2 [expr.prim.lambda]
paragraph 3,</P>

<BLOCKQUOTE>

An implementation shall not add members of rvalue reference
type to the closure type.

</BLOCKQUOTE>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 5.1.2 [expr.prim.lambda] paragraph 15 as follows:</P>

<BLOCKQUOTE>

An entity is <I>captured by copy</I> if it is implicitly captured and
the <I>capture-default</I> is <TT>=</TT> or if it is explicitly captured
with a capture that is not of the form <TT>&amp;</TT> <I>identifier</I> or
<TT>&amp;</TT> <I>identifier initializer</I>. For each entity captured by
copy, an unnamed non-static data member is declared in the closure
type. The declaration order of these members is unspecified. The type of
such a data member is <SPAN style="font-weight:bold;background-color:#A0FFA0">the referenced type if the entity is a reference
to an object, an lvalue reference to the referenced function type if the
entity is a reference to a function, or</SPAN> the type of the corresponding
captured entity <SPAN style="text-decoration:line-through;background-color:#FFA0A0">if the entity is not a reference to an object, or the
referenced type</SPAN> otherwise. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">[<I>Note:</I> If the captured entity
is a reference to a function, the corresponding data member is also a
reference to a function.  &#8212;<I>end note</I>]</SPAN> A member of an
anonymous union shall not be captured by copy.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2096"></A><H4>2096.
  
Constraints on literal unions
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Agust&#237;n K-ballo Berg&#233;
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-11




<P>According to 3.9 [basic.types] bullet 10.5.3, all the
members of a class type must be of non-volatile literal types.
This seems overly constraining for unions; it would seem to be
sufficient if at least one of its non-static members were of a
literal type.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 3.9 [basic.types] bullet 10.5 as follows:</P>

<BLOCKQUOTE>

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

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

<LI>

<P>a possibly cv-qualified class type (Clause 9 [class]) that has
all of the following properties:</P></LI>

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

<LI><P>it is an aggregate type (8.5.1 [dcl.init.aggr]) or has at least
one constexpr constructor or constructor template that is not a copy or
move constructor, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if it is a union, at least one of its non-static data members
is of non-volatile literal type, and</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if it is not a union,</SPAN> all of its non-static data members
and base classes are of non-volatile literal types.</P></LI>

</UL>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2098"></A><H4>2098.
  
Is <TT>uncaught_exceptions()</TT> per-thread?
</H4><B>Section: </B>15.5.3&#160; [except.uncaught]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Ville Voutilainen
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-14




<P>The current specification of <TT>std::uncaught_exceptions()</TT>
(15.5.3 [except.uncaught] paragraph 1) does not, but should, state
that it is the number of uncaught exceptions in the current thread.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 15.5.3 [except.uncaught] paragraph 1 as follows:</P>

<BLOCKQUOTE>

...The function <TT>std::uncaught_exceptions()</TT>
(18.8.4 [uncaught.exceptions]) returns the number of uncaught exceptions
<SPAN style="font-weight:bold;background-color:#A0FFA0">in the current thread</SPAN>.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2104"></A><H4>2104.
  
Internal-linkage <TT>constexpr</TT> references and ODR requirements
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-17




<P>In an example like:</P>

<PRE>
  extern int i;
  namespace {
    constexpr int&amp; r = i;
  }
  inline int f() { return r; }
</PRE>

<P>use of <TT>f()</TT> in multiple translation units results in an
ODR violation because of use of the internal-linkage reference
<TT>r</TT>.  It would be helpful if 3.2 [basic.def.odr]
paragraph 6 could be amended to &#8220;look through&#8221; a
<TT>constexpr</TT> reference in determining whether an inline
function violates the ODR or not.</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<P>Change 3.2 [basic.def.odr] bullet 6.2 as follows,
dividing the running text into a bulleted list:</P>

<BLOCKQUOTE>

<P>...Given such an entity named <TT>D</TT> defined in more than one
translation unit, then</P>

<UL><LI><P>each definition of <TT>D</TT> shall consist of
the same sequence of tokens; and</P></LI>

<LI><P>in each definition of <TT>D</TT>, corresponding
names, looked up according to 3.4 [basic.lookup],
shall refer to an entity defined within the definition
of <TT>D</TT>, or shall refer to the same entity, after
overload resolution (13.3 [over.match]) and after
matching of partial template specialization
(14.8.3 [temp.over]), except that a name can refer
to</P></LI>

<UL><LI><P>a non-volatile const object with internal or no
linkage if the object</P></LI>

<UL><LI><P>has the same literal type in all definitions of
<TT>D</TT>, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">the object</SPAN> is initialized with a constant
expression (5.20 [expr.const]), <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">the object</SPAN> is not odr-used, and</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">the object</SPAN> has the same value in all
definitions of <TT>D</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN></P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">or</SPAN></P>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">a reference with internal or no linkage
initialized with a constant expression such that the reference
refers to the same entity in all definitions of <TT>D</TT></SPAN>;</P></LI>

</UL>

<P>and</P>

<LI><P>in each definition of <TT>D</TT>, corresponding
entities...</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2106"></A><H4>2106.
  
Unclear restrictions on use of function-type template arguments
</H4><B>Section: </B>14.3.1&#160; [temp.arg.type]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-17


<P>According to 14.3.1 [temp.arg.type] paragraph 3,</P>

<BLOCKQUOTE>

If a declaration acquires a function type through a type
dependent on a <I>template-parameter</I> and this causes a
declaration that does not use the syntactic form of a
function declarator to have function type, the program is
ill-formed.

</BLOCKQUOTE>

<P>This is not clear enough regarding which declarations are in
view.  For example, does it apply to a <TT>typedef</TT>
declaration?  Does it apply to a parameter declaration, where
normal function-to-pointer decay would apply?  There is implementation
variance at block scope.</P>

<P>Also, since this applies a restriction to the usage of
dependent types, not template type arguments per se, the
paragraph presumably should appear in 14.6.2.1 [temp.dep.type]
and not its current location.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<OL><LI><P>Delete 14.3.1 [temp.arg.type] paragraph 3:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If a declaration acquires a function type through a type dependent
on a <I>template-parameter</I> and this causes a declaration that does not
use the syntactic form of a function declarator to have function type, the
program is ill-formed. [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  template&lt;class T&gt; struct A {
    static T t;
  };
  typedef int function();
  A&lt;function&gt; a; //<SPAN style="font-family:Times;font-style:italic"> ill-formed: would declare </SPAN>A&lt;function&gt;::t
                 //<SPAN style="font-family:Times;font-style:italic"> as a static member function</SPAN></SPAN>
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<LI>Add the following as a new paragraph following 14.7 [temp.spec]
paragraph 6:</LI>

<BLOCKQUOTE>

<P>...<TT>X&lt;int&gt;</TT> has a static member <TT>s</TT> of
type <TT>int</TT> and <TT>X&lt;char*&gt;</TT> has a static member <TT>s</TT> of type
<TT>char*</TT>. &#8212;<I>end example</I>]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If a function declaration acquired its function type through
a dependent type (14.6.2.1 [temp.dep.type]) without using the
syntactic form of a function declaator, the program is ill-formed.
[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">   template&lt;class T&gt; struct A {
     static T t;
   };
   typedef int function();
   A&lt;function&gt; a;   //<SPAN style="font-family:Times;font-style:italic"> ill-formed: would declare </SPAN>A&lt;function&gt;::t
                    //<SPAN style="font-family:Times;font-style:italic"> as a static member function</SPAN></SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2107"></A><H4>2107.
  
Lifetime of temporaries for default arguments in array copying
</H4><B>Section: </B>12.2&#160; [class.temporary]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-19




<P>The lifetime of temporaries introduced for default
arguments in array copying is not specified clearly.
Presumably it should be treated like default arguments in
default constructors (12.2 [class.temporary] paragraph
4), which deletes each element's set of default argument
temporaries before construction of the next element.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 12.2 [class.temporary] paragraphs 4-5 as follows:</P>

<BLOCKQUOTE>

<P>There are <SPAN style="text-decoration:line-through;background-color:#FFA0A0">two</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">three</SPAN> contexts in which temporaries
are destroyed at a different point than the end of the full-expression. The
first context is when a default constructor is called to initialize an
element of an array <SPAN style="font-weight:bold;background-color:#A0FFA0">with no corresponding initializer
(8.5 [dcl.init]). The second context is when a copy constructor
is called to copy an element of an array while the entire array is copied
(5.1.2 [expr.prim.lambda],
12.8 [class.copy])</SPAN>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">In either case,
if</SPAN> the constructor has one or more default arguments, the destruction
of every temporary created in a default argument is sequenced before the
construction of the next array element, if any.</P>

<P>The <SPAN style="text-decoration:line-through;background-color:#FFA0A0">second</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">third</SPAN> context is when a reference is
bound to a temporary.<SUP>117</SUP> The temporary to which the reference is
bound...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2109"></A><H4>2109.
  
Value dependence underspecified
</H4><B>Section: </B>14.6.2.3&#160; [temp.dep.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Maxim Kartashev
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-26




<P>In the following example,</P>

<PRE>
  struct A {};

  struct X {
     template &lt;typename Q&gt;
     int memfunc();
  };

  template &lt;int (X::* P) ()&gt; int foo(...);

  template&lt;class T&gt; struct B {
     static int bar() {
       A a;
       return foo&lt;&amp;X::memfunc&lt;T&gt; &gt;(a);
     }
  };

  template &lt;int (X::* P) ()&gt;  int foo(A a) { return 0; }

  int main()  {
     return B&lt;int&gt;::bar();
  }
</PRE>

<P>the call <TT>foo&lt;&amp;X::memfunc&lt;T&gt; &gt;(a);</TT> is
dependent only if the template argument is dependent, which is
only true because of the use of the template parameter <TT>T</TT>.
Implementations generally agree that this is dependent, but there
does not appear to be wording to support this determination.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 14.6.2.3 [temp.dep.constexpr] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P>An <I>id-expression</I> is value-dependent if:</P>

<UL><LI><P>it is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a name declared with a dependent type</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">type-dependent</SPAN>,</P></LI>

<LI><P>it is the name of a non-type template parameter,</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">it names a member of an unknown specialization,</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

<P>This resolution also resolves issue 2066.</P>

<BR><BR><HR><A NAME="2113"></A><H4>2113.
  
Incompete specification of types for declarators
</H4><B>Section: </B>8.3&#160; [dcl.meaning]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-04-08




<P>According to 8.3 [dcl.meaning]</P>

<BLOCKQUOTE>

A <TT>static</TT>, <TT>thread_local</TT>, <TT>extern</TT>, <TT>register</TT>, <TT>mutable</TT>, <TT>friend</TT>,
<TT>inline</TT>, <TT>virtual</TT>, or <TT>typedef</TT>
specifier applies directly to each <I>declarator-id</I> in
an <I>init-declarator-list</I>; the type specified for
each <I>declarator-id</I> depends on both
the <I>decl-specifier-seq</I> and its <I>declarator</I>.

</BLOCKQUOTE>

<P>This list is missing <TT>constexpr</TT> and
<TT>explicit</TT>.  Also, this should apply, but doesn't, to
<I>member-declarator-list</I>s.</P>

<P><B>Proposed resolution (September, 2015):</B></P>

<P>Change 8.3 [dcl.meaning] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A <TT>static</TT>, <TT>thread_local</TT>, <TT>extern</TT>, <TT>register</TT>,
<TT>mutable</TT>, <TT>friend</TT>, <TT>inline</TT>, <TT>virtual</TT>,
<SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>constexpr</TT>, <TT>explicit</TT>,</SPAN> or <TT>typedef</TT>
specifier applies directly to each <I>declarator-id</I> in
an <I>init-declarator-list</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">or <I>member-declarator-list</I></SPAN>;
the type specified for each <I>declarator-id</I> depends on both
the <I>decl-specifier-seq</I> and its <I>declarator</I>.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2122"></A><H4>2122.
  
Glvalues of <TT>void</TT> type
</H4><B>Section: </B>3.10&#160; [basic.lval]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>CWG
 &#160;&#160;&#160;

 <B>Date: </B>2015-05-05


<P>According to 3.10 [basic.lval] paragraph 4,</P>

<BLOCKQUOTE>

Unless otherwise indicated (5.2.2 [expr.call]),
prvalues shall always have complete types or
the <TT>void</TT> type; in addition to these types, glvalues
can also have incomplete types.

</BLOCKQUOTE>

<P>This wording inadvertently implies that glvalues can have
type <TT>void</TT>, which is not correct.</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<P>Change 3.10 [basic.lval] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Unless otherwise indicated (5.2.2 [expr.call]),
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">prvalues</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a prvalue</SPAN> shall always have
complete <SPAN style="text-decoration:line-through;background-color:#FFA0A0">types</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">type</SPAN> or
the <TT>void</TT> type<SPAN style="text-decoration:line-through;background-color:#FFA0A0">; in addition to these types, glvalues
can also have incomplete types</SPAN>. <SPAN style="font-weight:bold;background-color:#A0FFA0">A glvalue shall not
have type <I>cv</I> <TT>void</TT>.</SPAN> [<I>Note:</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">class</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">A glvalue may have complete or incomplete
non-<TT>void</TT> type.  Class</SPAN> and array prvalues can
have cv-qualified types; other prvalues always have
cv-unqualified types. See Clause
5 [expr]. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2129"></A><H4>2129.
  
Non-object prvalues and constant expressions
</H4><B>Section: </B>5.20&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Faisal Vali
 &#160;&#160;&#160;

 <B>Date: </B>2015-05-20




<P>According to 5.20 [expr.const] paragraph 5,</P>

<BLOCKQUOTE>

A constant expression is either a glvalue core constant
expression whose value... or a prvalue core constant
expression whose value is an object where...

</BLOCKQUOTE>

<P>Since an integer literal is prvalue that is not an
object, this definition does not allow it to be a
constant expression.</P>

<P><B>Proposed resolution (February, 2016):</B></P>

<P>Change 5.20 [expr.const] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P>A <I>constant expression</I> is either a glvalue core constant
expression whose value refers to an entity that is a
permitted result of a constant expression (as defined
below), or a prvalue core constant expression whose value <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is
an object where, for that object and its subobjects</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">satisfies the following constraints</SPAN>:</P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the value is an object of class
type,</SPAN> each non-static data member of reference type
refers to an entity that is a permitted result of a constant
expression, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN></P></LI>

<LI><P>if the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">object or
subobject</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">value</SPAN> is of pointer type, it
contains the address of an object with static storage
duration, the address past the end of such an object
(5.7 [expr.add]), the address of a function, or a
null pointer value<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">, and</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the value is an object of class or array type,
each subobject satisfies these constraints for the value.</SPAN></P></LI>

</UL>

<P>An entity is a <I>permitted result of a constant
expression</I> if...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2140"></A><H4>2140.
  
Lvalue-to-rvalue conversion of <TT>std::nullptr_t</TT>
</H4><B>Section: </B>4.1&#160; [conv.lval]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-06-12




<P>The current rules in 4.1 [conv.lval] paragraph 2 do
not require fetching the value in memory of an object of type
<TT>std::nullpt_t</TT> in order to produce its prvalue.
This choice has implications that may not have been
considered for questions like whether use of
a <TT>std::nullptr_t</TT> that is an inactive member of a
union results in undefined behavior or whether a volatile
<TT>std::nullptr_t</TT> variable in a discarded-value
expression produces a side effect.</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<P>Change 4.1 [conv.lval] bullet 2.3 as follows:</P>

<BLOCKQUOTE>

<P>...In all other cases, the result of the conversion is
determined according to the following rules:</P>

<UL><LI><P>If <TT>T</TT> is (possibly cv-qualified)
<TT>std::nullptr_t</TT>, the result is a null pointer constant
(4.10 [conv.ptr]). <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> Since no value
is fetched from memory, there is no side effect for a volatile
access (1.9 [intro.execution]), and an inactive member of a
union (9.5 [class.union]) may be accessed.
&#8212;<I>end note</I>]</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2141"></A><H4>2141.
  
Ambiguity in <I>new-expression</I> with <I>elaborated-type-specifier</I>
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-06-12




<P>Consider the following example:</P>

<PRE>
  struct A { };

  void foo() {
    new struct A { };
  }
</PRE>

<P>This could be either an <I>elaborated-type-specifier</I>
followed by a <I>braced-init-list</I> or a <I>class-specifier</I>.
There does not appear to be a disambiguation rule for this case.</P>

<P>One possibility for addressing this could be to use
<I>trailing-type-specifier-seq</I> instead of
<I>type-specifier-seq</I> in <I>new-type-id</I>.  That could
also be a purely syntactic alternative to the resolution of
issue 686: change all uses of
<I>type-specifier-seq</I> to <I>trailing-type-specifier-seq</I>
and provide a new grammar production for use in
<I>alias-declaration</I>.</P>

<P><B>Proposed resolution (February, 2016):</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 attribute-specifier-seq<SUB>opt</SUB> <TT>=</TT> <I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-</SPAN>type-id</I></I>
</UL>
</UL>

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

<BLOCKQUOTE>

Each <I>init-declarator</I> in
the <I>init-declarator-list</I> contains exactly
one <I>declarator-id</I>, which is the name declared by
that <I>init-declarator</I> and hence one of the names
declared by the
declaration. The <I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-</SPAN>type-specifier</I>s
(7.1.6 [dcl.type]) in
the <I>decl-specifier-seq</I> and the recursive declarator
structure of the <I>init-declarator</I> describe a type
(8.3 [dcl.meaning]), which is then associated with
the name being declared by the <I>init-declarator</I>.

</BLOCKQUOTE>

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

<UL><I>decl-specifier:</I>
<UL><I>storage-class-specifier</I><BR>
<I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-</SPAN>type-specifier</I><BR>
<I>function-specifier</I><BR>
<TT>friend</TT><BR>
<TT>typedef</TT><BR>
<TT>constexpr</TT><BR>
</UL>
</UL>

<LI><P>Change 7.1 [dcl.spec] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

If a <I>type-name</I> is encountered while parsing
a <I>decl-specifier-seq</I>, it is interpreted as part of
the <I>decl-specifier-seq</I> if and only if there is no
previous <I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-</SPAN>type-specifier</I> other than
a <I>cv-qualifier</I> in the <I>decl-specifier-seq</I>. The
sequence...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

Declarations containing
the <I>decl-specifier</I> <TT>typedef</TT> declare
identifiers that can be used later for naming fundamental
(3.9.1 [basic.fundamental]) or compound
(3.9.2 [basic.compound]) types. The <TT>typedef</TT>
specifier shall not be combined in
a <I>decl-specifier-seq</I> with any other kind of specifier
except a <I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-</SPAN>type-specifier</I>, and it
shall not be used in the <I>decl-specifier-seq</I> of
a <I>parameter-declaration</I> (8.3.5 [dcl.fct])
nor in the <I>decl-specifier-seq</I> of
a <I>function-definition</I> (8.4 [dcl.fct.def]).

</BLOCKQUOTE>

<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 identifier following the
<TT>using</TT> keyword becomes a <I>typedef-name</I> and the
optional <I>attribute-specifier-seq</I> following the
identifier appertains to that <I>typedef-name</I>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">It</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">The <I>defining-type-specifier-seq</I> of the
<I>defining-type-id</I> may define a class or enumeration
only if the <I>alias-declaration</I> is not
the <I>declaration</I> of a <I>template-declaration</I>.
Such a <I>typedef-name</I></SPAN> has the same semantics as
if it were introduced by the <TT>typedef</TT> specifier. In
particular, it does not define a new type. [<I>Example:</I>

</BLOCKQUOTE>

<LI><P>Change 7.1.6 [dcl.type] paragraph 1 as follows:</P></LI>

<UL><I>type-specifier:</I>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>trailing-type-specifier</I><BR>
<I>class-specifier</I><BR>
<I>enum-specifier</I></SPAN>
</UL>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>trailing-type-specifier:</I></SPAN>
<UL><I>simple-type-specifier</I><BR>
<I>elaborated-type-specifier</I><BR>
<I>typename-specifier</I><BR>
<I>cv-qualifier</I>
</UL>
<I>type-specifier-seq:</I>
<UL><I>type-specifier attribute-specifier-seq<SUB>opt</SUB></I><BR>
<I>type-specifier type-specifier-seq</I>
</UL>
<I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-type-specifier:</SPAN></I>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>type-specifier</I><BR>
<I>class-specifier</I><BR>
<I>enum-specifier</I></SPAN>
</UL>
<I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">trailing</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">defining</SPAN>-type-specifier-seq:</I>
<UL><I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">trailing</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">defining</SPAN>-type-specifier attribute-specifier-seq<SUB>opt</SUB></I><BR>
<I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">trailing</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">defining</SPAN>-type-specifier <SPAN style="text-decoration:line-through;background-color:#FFA0A0">trailing</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">defining</SPAN>-type-specifier-seq</I>
</UL>
</UL>

<BLOCKQUOTE><P>The optional <I>attribute-specifier-seq</I> in
a <I>type-specifier-seq</I> or
a <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">trailing</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">defining</SPAN>-type-specifier-seq</I>
appertains to the type denoted by the
preceding <I>type-specifier</I>s <SPAN style="font-weight:bold;background-color:#A0FFA0">or
<I>defining-type-specifier</I>s</SPAN>
(8.3 [dcl.meaning]). The <I>attribute-specifier-seq</I>
affects the type only for the declaration it appears in, not
other declarations involving the same type.</P></BLOCKQUOTE>

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

<BLOCKQUOTE>

As a general rule, at most
one <I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-</SPAN>type-specifier</I> is allowed in
the complete <I>decl-specifier-seq</I> of a declaration or
in a <I>type-specifier-seq</I>
or <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">trailing</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">defining</SPAN>-type-specifier-seq</I>. The
only exceptions to this rule are the following:...

</BLOCKQUOTE>

<LI><P>Change 7.1.6 [dcl.type] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

Except in a declaration of a constructor, destructor, or
conversion function, at least
one <I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-</SPAN>type-specifier</I> that is not
a <I>cv-qualifier</I> shall appear in a
complete <I>type-specifier-seq</I> or a
complete <I>decl-specifier-seq</I>.<SUP>95</SUP>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">A <I>type-specifier-seq</I> shall not define a class or
enumeration unless it appears in the <I>type-id</I> of
an <I>alias-declaration</I> (7.1.3 [dcl.typedef])
that is not the declaration of
a <I>template-declaration</I>.</SPAN>

</BLOCKQUOTE>

<LI><P>Change the grammar in 8 [dcl.decl] paragraph 4
as follows:</P></LI>

<UL><I>trailing-return-type:</I>
<UL><TT>-&gt;</TT> <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>trailing-type-specifier-seq abstract-declarator<SUB>opt</SUB></I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>type-id</I></SPAN>
</UL>
</UL>

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

<UL><I>type-id:</I>
<UL><I>type-specifier-seq abstract-declarator<SUB>opt</SUB></I>
</UL>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>defining-type-id:</I></SPAN>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>defining-type-specifier-seq abstract-declarator<SUB>opt</SUB></I></SPAN>
</UL>
</UL>

<LI><P>Change 12.3.2 [class.conv.fct] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...A <I>decl-specifier</I> in the <I>decl-specifier-seq</I>
of a conversion function (if any) shall be neither
a <I><SPAN style="font-weight:bold;background-color:#A0FFA0">defining-</SPAN>type-specifier</I> nor static. Type
of the conversion function

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2146"></A><H4>2146.
  
Scalar object vs memory location in definition of &#8220;unsequenced&#8221;
</H4><B>Section: </B>1.9&#160; [intro.execution]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>2015-06-22




<P>According to 1.9 [intro.execution] paragraph 15,</P>

<BLOCKQUOTE>

If a side effect on a scalar object is unsequenced relative
to either another side effect on the same scalar object or a
value computation using the value of the same scalar object,
and they are not potentially concurrent
(1.10 [intro.multithread]), the behavior is undefined.

</BLOCKQUOTE>

<P>Should this refer to &#8220;memory location,&#8221; which
also encompasses contiguous bit-fields, as the definition of
data races in 1.10 [intro.multithread] does?  For example,</P>

<PRE>
  struct S {
    int x : 4;
    int y : 4;
    int z : 4;
  };

  void f(int, int, int);
  int g(int, S&amp;);

  int main(int argc, char ** argv) {
    S s = { argc, argc+1, argc+2 };
    f(++s.x, g(++s.y, s), ++s.z);
  }
</PRE>

<P><B>Proposed resolution (February, 2016):</B></P>

<P>Change 1.9 [intro.execution] paragraph 15 as follows:</P>

<BLOCKQUOTE>

...If a side effect on a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">scalar
object</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">memory location
(1.7 [intro.memory])</SPAN> is unsequenced relative to
either another side effect on the same <SPAN style="text-decoration:line-through;background-color:#FFA0A0">scalar
object</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">memory location</SPAN> or a value
computation using the value of <SPAN style="font-weight:bold;background-color:#A0FFA0">any object in</SPAN> the
same <SPAN style="text-decoration:line-through;background-color:#FFA0A0">scalar object</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">memory location</SPAN>,
and they are not potentially concurrent
(1.10 [intro.multithread]), the behavior is
undefined. [<I>Note:</I> The next section...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2147"></A><H4>2147.
  
Initializer-list arguments and pack deduction
</H4><B>Section: </B>14.8.2.1&#160; [temp.deduct.call]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-06-22




<P>The current wording of 14.8.2.1 [temp.deduct.call] paragraph
1 dealing with deduction for a trailing parameter pack refers to
&#8220;the type&#8221; of the argument, which does not apply to
an initializer list.  There is implementation divergence in the
handling of an example like</P>

<PRE>
  #include &lt;initializer_list&gt;

  template &lt;typename... T&gt;
  void q(std::initializer_list&lt;std::initializer_list&lt;T&gt;&gt;... tt);

  void bar() { q({{0}}, {{'\0'}}); }
</PRE>

<P><B>Proposed resolution (September, 2015):</B></P>

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

<BLOCKQUOTE>

...For a function parameter pack that occurs at the end of
the <I>parameter-declaration-list</I>, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the type <TT>A</TT> of</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">deduction is performed for</SPAN> each remaining argument of the
call<SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is compared with</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">taking</SPAN> the
type <TT>P</TT> of the <I>declarator-id</I> of the function parameter
pack <SPAN style="font-weight:bold;background-color:#A0FFA0">as the corresponding function template parameter type</SPAN>. Each
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">comparison</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">deduction</SPAN> deduces template arguments for
subsequent positions in the template parameter packs expanded by the
function parameter pack. When a function parameter pack appears in a
non-deduced context (14.8.2.5 [temp.deduct.type]), the type of that
parameter pack is never deduced. [<I>Example:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2153"></A><H4>2153.
  
<I>pure-specifier</I> in friend declaration
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-06-30




<P>The current wording does not appear to ban
a <I>pure-specifier</I> from a friend declaration.</P>

<P><B>Proposed resolution (February, 2016):</B></P>

<P>Change 9.2 [class.mem] paragraph 6 as follows:</P>

<BLOCKQUOTE>

...A <I>pure-specifier</I> shall be used only in the
declaration of a virtual function
(10.3 [class.virtual]) <SPAN style="font-weight:bold;background-color:#A0FFA0">that is not a <TT>friend</TT>
declaration</SPAN>.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2154"></A><H4>2154.
  
Ambiguity of <I>pure-specifier</I>
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-06-30




<P>There does not appear to be a rule to disambiguate a
<I>pure-specifier</I> and a <I>brace-or-equal-initializer</I> in
a member declarator.</P>

<P><B>Proposed resolution (February, 2016):</B></P>

<P>Add the following as a new paragraph following 9.2 [class.mem]
paragraph 3:</P>

<BLOCKQUOTE>

<P>[<I>Note:</I> A single name can denote several function
members provided their types are sufficiently different
(Clause 13 [over]). &#8212;<I>end note</I>]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">In a <I>member-declarator</I>, an <TT>=</TT> immediately
following the <I>declarator</I> is interpreted as introducing
a <I>pure-specifier</I> if the <I>declarator-id</I> has function
type, otherwise it is interpreted as introducing a
<I>brace-or-equal-initializer</I>. [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct S {
    using T = void();
    T * p = 0;        //<SPAN style="font-family:Times;font-style:italic"> OK: brace-or-equal-initializer</SPAN>
    virtual T f = 0;  //<SPAN style="font-family:Times;font-style:italic"> OK: pure-specifier</SPAN>
  };</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2156"></A><H4>2156.
  
Definition of enumeration declared by <I>using-declaration</I>
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-07-06




<P>The description of enumeration declarations in 7.2 [dcl.enum]
does not, but should, contain similar wording to that preventing
a class definition from defining a class type named by a
<I>using-declaration</I>:</P>

<BLOCKQUOTE>

If a <I>class-head-name</I> contains
a <I>nested-name-specifier</I>, the <I>class-specifier</I>
shall refer to a class that was previously declared directly
in the class or namespace to which
the <I>nested-name-specifier</I> refers, or in an element of
the inline namespace set (7.3.1 [namespace.def]) of
that namespace (i.e., not merely inherited or introduced by
a <I>using-declaration</I>), and the <I>class-specifier</I>
shall appear in a namespace enclosing the previous
declaration.  In such cases,
the <I>nested-name-specifier</I> of
the <I>class-head-name</I> of the definition shall not begin
with a <I>decltype-specifier</I>.

</BLOCKQUOTE>

<P><B>Proposed resolution (February, 2016):</B></P>

<P>Add the following as a new paragraph at the end of
7.2 [dcl.enum]:</P>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">If an <I>enum-head</I> contains a <I>nested-name-specifier</I>,
the <I>enum-specifier</I> shall refer to an enumeration that was
previously declared directly in the class or namespace to which the
<I>nested-name-specifier</I> refers, or in an element of the
inline namespace set (7.3.1 [namespace.def]) of that
namespace (i.e., not merely inherited or introduced by
a <I>using-declaration</I>), and the <I>enum-specifier</I>
shall appear in a namespace enclosing the previous
declaration.  In such cases,
the <I>nested-name-specifier</I> of the <I>enum-head</I> of the
definition shall not begin with a <I>decltype-specifier</I>.</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2163"></A><H4>2163.
  
Labels in <TT>constexpr</TT> functions
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-07-24




<P>The requirements for <TT>constexpr</TT> functions do not,
but presumably should, forbid the appearance of a label in the
function body (<TT>goto</TT>s are prohibited).</P>

<P><B>Proposed resolution (January, 2016):</B></P>

<P>Add the following as an additional bullet following
7.1.5 [dcl.constexpr] bullet 3.5.2:</P>

<BLOCKQUOTE>

<P>The definition of a <TT>constexpr</TT> function shall satisfy the
following requirements:</P>

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

<LI><P>its <I>function-body</I> shall be <TT>=
delete</TT>, <TT>= default</TT>, or
a <I>compound-statement</I> that does not contain</P></LI>

<UL><LI><P>an <I>asm-definition</I>,</P></LI>

<LI><P>a <TT>goto</TT> statement,</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">an identifier label (6.1 [stmt.label]),</SPAN></P></LI>

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

</UL>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2167"></A><H4>2167.
  
Non-member references with lifetimes within the current evaluation
</H4><B>Section: </B>5.20&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-08-11


<P>The current wording of 5.20 [expr.const] bullet 2.9 says:</P>

<UL><LI><P>an <I>id-expression</I> that refers to a variable
or data member of reference type unless the reference has a
preceding initialization and either</P></LI>

<UL><LI><P>it is initialized with a constant expression or</P></LI>

<LI><P>it is a non-static data member of an object whose
lifetime began within the evaluation of <TT>e</TT>;</P></LI>

</UL>

</UL>

<P>This incorrectly excludes non-member references whose lifetime
began within the current evaluation.</P>

<P><B>Proposed resolution (February, 2016):</B></P>

<P>Change 5.20 [expr.const] bullet 2.9.2 as follows:</P>

<BLOCKQUOTE>

<P>A <I>conditional-expression</I> e is a <I>core constant
expression</I> unless the evaluation of e, following the rules
of the abstract machine (1.9 [intro.execution]), would
evaluate one of the following expressions:</P>

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

<LI><P>an <I>id-expression</I> that refers to a variable or data
member of reference type unless the reference has a
preceding initialization and either</P></LI>

<UL><LI><P>it is initialized with a constant expression or</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">it is a non-static data member of an object
whose</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">its</SPAN> lifetime began within the
evaluation of <TT>e</TT>;</P></LI>

</UL>

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

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2175"></A><H4>2175.
  
Ambiguity with attribute in conversion operator declaration
</H4><B>Section: </B>8.2&#160; [dcl.ambig.res]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2015-09-17


<P>The declaration</P>

<PRE>
  operator int [[noreturn]] ();
</PRE>

<P>is ambiguous with respect to the binding of the attribute.  It
could either be parsed (as apparently intended by the user) as
part of the <I>noptr-declarator</I> (8 [dcl.decl]
paragraph 4) or as part of the <I>type-specifier-seq</I>
(7.1.6 [dcl.type] paragraph 1) of the
<I>conversion-type-id</I> (12.3.2 [class.conv.fct]
paragraph 1).  Current implementations disambiguate this
declaration in favor of the latter interpretation, issuing an
error for the declaration because the <TT>noreturn</TT>
attribute cannot apply to a type.</P>

<P><B>Proposed resolution (February, 2016):</B></P>

<P>Change 12.3.2 [class.conv.fct] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P>The <I>conversion-type-id</I> shall not represent a function
type nor an array type. The <I>conversion-type-id</I> in
a <I>conversion-function-id</I> is the longest <SPAN style="text-decoration:line-through;background-color:#FFA0A0">possible</SPAN>
sequence of <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>conversion-declarator</I>s</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">tokens that could possibly form a
<I>conversion-type-id</I></SPAN>. [<I>Note:</I>
This prevents ambiguities between the declarator operator <TT>*</TT>
and its expression counterparts. [<I>Example:</I></P>

<PRE>
  &amp;ac.operator int*i;  //<SPAN style="font-family:Times;font-style:italic"> syntax error:</SPAN>
                       //<SPAN style="font-family:Times;font-style:italic"> parsed as: </SPAN>&amp;(ac.operator int *)i
                       //<SPAN style="font-family:Times;font-style:italic"> not as: </SPAN>&amp;(ac.operator int)*i
</PRE>

<P>The <TT>*</TT> is the pointer declarator and not the
multiplication operator. &#8212;<I>end
example</I>] <SPAN style="font-weight:bold;background-color:#A0FFA0">This rule also prevents ambiguities for
attributes.  [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  operator int [[noreturn]] (); //<SPAN style="font-family:Times;font-style:italic"> error: </SPAN>noreturn<SPAN style="font-family:Times;font-style:italic"> attribute applied to a type</SPAN></SPAN>

</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN> &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2176"></A><H4>2176.
  
Destroying the returned object when a destructor throws
</H4><B>Section: </B>5.2.2&#160; [expr.call]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-09-28




<P>Consider the following example:</P>

<PRE>
  #include &lt;stdio.h&gt;

  struct X {
    X() { puts("X()"); }
    X(const X&amp;) { puts("X(const X&amp;)"); }
    ~X() { puts("~X()"); }
  };

  struct Y { ~Y() noexcept(false) { throw 0; } };

  X f() {
    try {
      Y y;
      return {};
    } catch (...) {
    }
    return {};
  }

  int main() {
    f();
  }
</PRE>

<P>Current implementations print <TT>X()</TT> twice but
<TT>~X()</TT> only once.  That is obviously wrong, but it is
not clear that the current wording covers this case.</P>

<P><B>Proposed resolution (February, 2016):</B></P>

<P>Change 15.2 [except.ctor] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P>The destructor is invoked for each automatic object of
class type constructed<SPAN style="font-weight:bold;background-color:#A0FFA0">, but not yet destroyed,</SPAN>
since the try block was entered.  <SPAN style="font-weight:bold;background-color:#A0FFA0">If an exception is
thrown during the destruction of temporaries or local
variables for a <TT>return</TT> statement
(6.6.3 [stmt.return]), the destructor for the
returned object (if any) is also invoked.</SPAN> The
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">automatic</SPAN> objects are destroyed in the reverse
order of the completion of their construction.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct A { };

  struct Y { ~Y() noexcept(false) { throw 0; } };

  A f() {
    try {
      A a;
      Y y;
      A b;
      return {};   //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    } catch (...) {
    }
    return {};     //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
  }</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">At <TT>#1</TT>, the returned object of type <TT>A</TT>
is constructed.  Then, the local variable <TT>b</TT> is
destroyed (6.6 [stmt.jump]).  Next, the local variable
<TT>y</TT> is destroyed, causing stack unwinding, resulting in
the destruction of the returned object, followed by the
destruction of the local variable <TT>a</TT>.  Finally, the
returned object is constructed again at <TT>#2</TT>.
&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2180"></A><H4>2180.
  
Virtual bases in destructors and defaulted assignment operators
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

 <B>Date: </B>2015-10-13




<P>According to 12.8 [class.copy] paragraph 28,</P>

<BLOCKQUOTE>

The implicitly-defined copy/move assignment operator for a
non-union class X performs memberwise copy/move assignment
of its subobjects. The direct base classes of X are assigned
first, in the order of their declaration in
the <I>base-specifier-list</I>, and then the immediate
non-static data members of X are assigned, in the order in
which they were declared in the class definition...
It is unspecified whether subobjects representing virtual
base classes are assigned more than once by the
implicitly-defined copy/move assignment operator.

</BLOCKQUOTE>

<P>However, the determination of whether a defaulted
copy/move assignment operator is defined as deleted
(paragraph 23) considers only the &#8220;potentially
constructed&#8221; subobjects:</P>

<BLOCKQUOTE>

<P>A defaulted copy/move assignment operator for class <TT>X</TT> is
defined as deleted if <TT>X</TT> has:</P>

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

<LI><P>a potentially constructed subobject of class type <TT>M</TT> (or
array thereof) that cannot be copied/moved...</P></LI>

</UL>

</BLOCKQUOTE>

<P>where &#8220;potentially constructed&#8221; is defined (in
12 [special] paragraph 5) as:</P>

<BLOCKQUOTE>

For a class, its non-static data members, its non-virtual
direct base classes, and, if the class is not abstract
(10.4 [class.abstract]), its virtual base classes are
called its <I>potentially constructed subobjects</I>.

</BLOCKQUOTE>

<P>i.e., excluding direct virtual base classes of abstract
classes.  This seems contradictory, since an implementation is
expressly permitted to assign such base classes and thus
presumably is permitted to fail if no such assignment is
possible.</P>

<P>Similarly, 12.4 [class.dtor] paragraph 8 says,</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 non-static data members,
the destructors for <TT>X</TT>'s direct base classes and,
if <TT>X</TT> is the type of the most derived class
(12.6.2 [class.base.init]), its destructor calls the
destructors for <TT>X</TT>'s virtual base classes.

</BLOCKQUOTE>

<P>This appears to allow a virtual base's destructor to be
called more than once, once for each class naming it as a
direct virtual base and once for the most-derived class.</P>

<P><B>Proposed resolution (February, 2016):</B></P>

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

<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 non-static data members,
the destructors for <TT>X</TT>'s <SPAN style="font-weight:bold;background-color:#A0FFA0">non-virtual</SPAN>
direct base classes and, if <TT>X</TT> is the type of the
most derived class (12.6.2 [class.base.init]), its
destructor calls the destructors for <TT>X</TT>'s virtual
base classes. All destructors are called as if...

</BLOCKQUOTE>

<LI><P>Change 12.8 [class.copy] bullet 23.4 as follows:</P></LI>

<BLOCKQUOTE>

<P>A defaulted copy/move assignment operator for class <TT>X</TT> is
defined as deleted if <TT>X</TT> has:</P>

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

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially constructed
subobject</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">direct non-static data member</SPAN> of
class type <TT>M</TT> (or array thereof) <SPAN style="font-weight:bold;background-color:#A0FFA0">or a direct base
class <TT>M</TT></SPAN> that cannot be
copied/moved because overload resolution
(13.3 [over.match]), as applied to <TT>M</TT>'s
corresponding assignment operator, results in an ambiguity
or a function that is deleted or inaccessible from the
defaulted assignment operator.</P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<BR><BR></BODY>
</HTML>
