<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core Motions
   </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
      &#160;P0164</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2015-10-23</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>
</TABLE><BR CLEAR="ALL"><BR><CENTER>
<H2>
     Core Language Working Group "ready" Issues
    </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/n4597.pdf">WG21 N4527</A>.
   </P>
<HR><A NAME="1274"></A><H4>1274.
  
Common nonterminal for <I>expression</I> and <I>braced-init-list</I>
</H4><B>Section: </B>6.5.4&#160; [stmt.ranged]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-03-25




<P>It would be helpful to have a single grammar term for
<I>expression</I> and <I>braced-init-list</I>, which often occur
together in the text.  In particular, 6.5.4 [stmt.ranged]
paragraph 1 allows both, but the description of <TT>__RangeT</TT>
refers only to the <I>expression</I> case; such errors would be less
likely if the common term were available.</P>

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

<OL><LI><P>Add a new production to the grammar in 8.5 [dcl.init]
paragraph 1:</P></LI>

<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>expr-or-braced-init-list:</I></SPAN>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>expression</I></SPAN><BR>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>braced-init-list</I></SPAN>
</UL>
</UL>

<LI><P>Change the grammar in 5.2 [expr.post] paragraph 1
as follows:</P></LI>

<UL><I>postfix-expression:</I>
<UL><I>primary-expression</I><BR>
<I>postfix-expression</I> <TT>[</TT> <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">expr-or-braced-init-list</SPAN></I> <TT>]</TT><BR>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>postfix-expression</I> <TT>[</TT> <I>braced-init-list</I> <TT>]</TT><BR></SPAN>
<I>postfix-expression</I> <TT>(</TT> <I>expression-list<SUB>opt</SUB></I> <TT>)</TT><BR>
...
</UL>
</UL>

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

<UL><I>for-range-initializer:</I>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>expression</I></SPAN><BR>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>braced-init-list</I></SPAN><BR>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>expr-or-braced-init-list</I></SPAN>
</UL>
</UL>

<LI><P>Change 6.5.4 [stmt.ranged] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">For a range-based <TT>for</TT> statement of the form</SPAN></P>

<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>for (</TT> <I>for-range-declaration</I> <TT>:</TT> <I>expression</I> <TT>)</TT> <I>statement</I></SPAN>
</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">let <I>range-init</I> be equivalent to the <I>expression</I>
surrounded by parentheses<SUP>90</SUP></SPAN></P>

<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>(</TT> <I>expression</I> <TT>)</TT></SPAN></UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">and for a range-based <TT>for</TT> statement of the form</SPAN></P>

<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>for (</TT> <I>for-range-declaration</I> <TT>:</TT> <I>braced-init-list</I> <TT>)</TT> <I>statement</I></SPAN>
</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">let <I>range-init</I> be equivalent to
the <I>braced-init-list</I>. In each case,
a</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A</SPAN> range-based for statement is equivalent
to</P>

<PRE>
  {
  auto &amp;&amp; __range = <SPAN style="text-decoration:line-through;background-color:#FFA0A0">range-init</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>for-range-initializer</I></SPAN>;
    for ( auto __begin = begin-expr,
               __end = end-expr;
          __begin != __end;
          ++__begin ) {
      <I>for-range-declaration</I> = *__begin;
      <I>statement</I>
    }
  }
</PRE>

<P>where</P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the <I>for-range-initializer</I> is an
<I>expression</I>, it is regarded as if it were surrounded
by parentheses (so that a comma operator cannot be
reinterpreted as delimiting
two <I>init-declarator</I>s);</SPAN></P></LI>

<LI><P><TT>__range</TT>, <TT>__begin</TT>,
and <TT>__end</TT> are variables defined for exposition
only<SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">;</SPAN> and</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>_RangeT</TT> is the type of the expression,
and</SPAN></P></LI>

<LI><P><I>begin-expr</I> and <I>end-expr</I> are determined as
follows:</P></LI>

<UL><LI><P>if <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>_RangeT</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the
<I>for-range-initializer</I></SPAN> is an <SPAN style="font-weight:bold;background-color:#A0FFA0">expression
of</SPAN> array type <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>R</TT></SPAN>, <I>begin-expr</I>
and <I>end-expr</I> are <TT>__range</TT> and <TT>__range +
__bound</TT>, respectively, where <TT>__bound</TT> is the
array
bound. If <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>_RangeT</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>R</TT></SPAN>
is an array of unknown size or an array of incomplete type,
the program is ill-formed;</P></LI>

<LI><P>if <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>_RangeT</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the
<I>for-range-initializer</I></SPAN> is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">an expression of</SPAN> class type <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>C</TT></SPAN>,
the <I>unqualified-id</I>s <TT>begin</TT> and <TT>end</TT>
are looked up in the scope of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">class <TT>_RangeT</TT></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>C</TT></SPAN> as if by class member access lookup
(3.4.5 [basic.lookup.classref]), and if either (or both) finds
at least one declaration, <I>begin-expr</I>
and <I>end-expr</I> are
<TT>__range.begin()</TT> and <TT>__range.end()</TT>,
respectively;</P></LI>

<LI><P>otherwise, <I>begin-expr</I> and <I>end-expr</I> are
<TT>begin(__range)</TT> and <TT>end(__range)</TT>,
respectively, where <TT>begin</TT> and <TT>end</TT> are
looked up in the associated namespaces
(3.4.2 [basic.lookup.argdep]). [<I>Note:</I> Ordinary
unqualified lookup (3.4.1 [basic.lookup.unqual]) is not
performed. &#8212;<I>end note</I>]</P></LI>

</UL>

</UL>

</BLOCKQUOTE>

<LI><P>Change the grammar of 6.6 [stmt.jump] paragraph 1
as follows:</P></LI>

<UL><I>jump-statement:</I>
<UL><TT>break ;</TT><BR>
<TT>continue ;</TT><BR>
<TT>return</TT> <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">expr-or-braced-init-list</SPAN><SUB>opt</SUB></I> <TT>;</TT><BR>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>return</TT> <I>braced-init-list</I> <TT>;</TT></SPAN><BR>
<TT>goto</TT> <I>identifier</I> <TT>;</TT>
</UL>
</UL>

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

<BLOCKQUOTE>

The <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>expression</I>
or <I>braced-init-list</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>expr-or-braced-init-list</I></SPAN>
of a <TT>return</TT> statement is called its operand. A
return statement...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

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

<UL><I>postfix-expression</I> <TT>[</TT> <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">expr-or-braced-init-list</SPAN></I> <TT>]</TT>
</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN></P>

<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>postfix-expression</I> <TT>[</TT> <I>braced-init-list</I> <TT>]</TT></SPAN>
</UL>

<P>Thus, a subscripting expression...</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1391"></A><H4>1391.
  
Conversions to parameter types with non-deduced template arguments
</H4><B>Section: </B>14.8.1&#160; [temp.arg.explicit]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-09-08




<P>According to 14.8.1 [temp.arg.explicit] paragraph 6,</P>

<BLOCKQUOTE>

Implicit conversions (Clause 4 [conv]) will be
performed on a function argument to convert it to the type of the
corresponding function parameter if the parameter type contains
no <I>template-parameter</I>s that participate in template argument
deduction.  [<I>Note:</I> Template parameters do not participate in
template argument deduction if they are explicitly specified...

</BLOCKQUOTE>

<P>But this isn't clear about when these conversions are done.
Consider</P>

<PRE>
    template&lt;class T&gt; struct A {
       typename T::N n;
    };
    template&lt;class T&gt; struct B { };

    template&lt;class T, class T2&gt;
    void foo(const A&lt;T&gt;&amp; r); // #1
    template&lt;class T&gt;
    void foo(const B&lt;T&gt;&amp; r); // #2

    void baz() {
       B&lt;char&gt; b;
       foo(b); // OK
       foo&lt;char&gt;(b); // error
    }
</PRE>

<P>With the explicit template argument, the first parameter of #1
no longer participates in template argument deduction, so
implicit conversions are done.  If we check for the implicit
conversion during the deduction process, we end up instantiating
<TT>A&lt;char&gt;</TT>, resulting in a hard error.  If we wait
until later to check the conversion, we can reject #1 because
<TT>T2</TT> is not deduced and never need to consider the
conversion.</P>

<P>But if we just accept the parameter and leave it up to normal
overload resolution to reject an unsuitable candidate, that
breaks this testcase:</P>

<PRE>
    template&lt;class T&gt;
    struct A {
       typename T::N n;
    };

    template&lt;class T&gt;
    struct B { };

    template &lt;class T, class... U&gt;
    typename A&lt;T&gt;::value_t bar(int, T, U...);

    template &lt;class T&gt;
    T bar(T, T);

    void baz()
    {
       B&lt;char&gt; b;
       bar(b, b);
    }
</PRE>

<P>Here, if deduction succeeds, we substitute in the deduced
arguments of <TT>T = B&lt;char&gt;, U = { }</TT>, and end up
instantiating <TT>A&lt;B&lt;char&gt;&gt;</TT>, which fails.</P>

<P>EDG and GCC currently reject the first testcase and accept the
second; clang accepts both.</P>

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

<P>The position initially favored by CWG was that implicit conversions
are not considered during deduction but are only applied afterwards,
so the second example is ill-formed, and that the normative wording of
the referenced paragraph should be moved into the note.  This approach
does not handle some examples currently accepted by some implementations,
however; for example:</P>

<PRE>
   template &lt;class T&gt; struct Z {
    typedef T::x xx;
   };
   template &lt;class T&gt; Z&lt;T&gt;::xx f(void *, T);
   template &lt;class T&gt; void f(int, T);
   struct A {} a;
   int main() {
     f(1, a); //<SPAN style="font-family:Times;font-style:italic"> If the implementation rules out the first overload</SPAN>
              //<SPAN style="font-family:Times;font-style:italic"> because of the invalid conversion from </SPAN>int<SPAN style="font-family:Times;font-style:italic"> to </SPAN>void*<SPAN style="font-family:Times;font-style:italic">,</SPAN>
              //<SPAN style="font-family:Times;font-style:italic"> the error instantiating </SPAN>Z&lt;A&gt;<SPAN style="font-family:Times;font-style:italic"> will be avoided</SPAN>
   }
</PRE>

<P>Additional discussion is required.</P>

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

<P>The approach needed to accept this code appears to be doing the
convertibility check between deduction and substitution.</P>

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

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

<BLOCKQUOTE>

Template argument deduction is done by comparing each
function template parameter type (call
it <TT>P</TT>) <SPAN style="font-weight:bold;background-color:#A0FFA0">that contains <I>template-parameter</I>s
that participate in template argument deduction</SPAN> with
the type of the corresponding argument of the call (call
it <TT>A</TT>) as described below. If <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>P</TT> is a
dependent type,</SPAN> removing references and cv-qualifiers
from <TT>P</TT> gives
<TT>std::initializer_list&lt;P'&gt;</TT> or <TT>P'[N]</TT>
for some <TT>P'</TT> and <TT>N</TT> and the argument is a
non-empty initializer list (8.5.4 [dcl.init.list]),
then deduction is performed instead for each element of the
initializer list, taking <TT>P'</TT> as a function template
parameter type and the initializer element as its argument,
and in the <TT>P'[N]</TT> case, if <TT>N</TT> is a non-type
template parameter, <TT>N</TT> is deduced from the length of
the initializer list. Otherwise, an initializer list
argument causes the parameter to be considered a non-deduced
context (14.8.2.5 [temp.deduct.type]). [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Delete the note in 14.8.2.1 [temp.deduct.call] paragraph 4:</P></LI>

<BLOCKQUOTE>

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

</BLOCKQUOTE>

<LI><P>Add the following as a new paragraph at the end of
14.8.2.1 [temp.deduct.call]:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If deduction succeeds for all parameters that contain
<I>template-parameter</I>s that participate in template
argument deduction, and all template arguments are
explicitly specified, deduced, or obtained from default
template arguments, remaining parameters are then compared
with the corresponding arguments.  For each remaining
parameter <TT>P</TT> with a type that was non-dependent
before substitution of any explicitly-specified template
arguments, if the corresponding argument <TT>A</TT> cannot
be implicitly converted to <TT>P</TT>, deduction fails.
[<I>Note:</I> Parameters with dependent types in which no
<I>template-parameter</I>s participate in template
argument deduction, and parameters that became non-dependent
due to substitution of explicitly-specified template
arguments, will be checked during overload resolution.
&#8212;<I>end note</I>] [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template &lt;class T&gt; struct Z {
    typedef typename T::x xx;
  };
  template &lt;class T&gt; typename Z&lt;T&gt;::xx f(void *, T); //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
  template &lt;class T&gt; void f(int, T);                 //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
  struct A {} a;
  int main() {
    f(1, a);                                         //<SPAN style="font-family:Times;font-style:italic"> OK, deduction fails for #1 because there is no conversion from </SPAN>int<SPAN style="font-family:Times;font-style:italic"> to </SPAN>void*
  }</SPAN>
</PRE>

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

</BLOCKQUOTE>

<LI><P>Change 14.8.2.4 [temp.deduct.partial] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

Each type nominated above from the parameter template and
the corresponding type from the argument template are used
as the types of <TT>P</TT> and <TT>A</TT>. <SPAN style="font-weight:bold;background-color:#A0FFA0">If a particular
<TT>P</TT> contains no <I>template-parameter</I>s that
participate in template argument deduction, that <TT>P</TT>
is not used to determine the ordering.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 14.8.2.5 [temp.deduct.type] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

In most cases, the types, templates, and non-type values
that are used to compose <TT>P</TT> participate in template
argument deduction. That is, they may be used to determine
the value of a template argument, and the value so
determined must be consistent with the values determined
elsewhere. In certain contexts, however, the value does not
participate in type deduction, but instead uses the values
of template arguments that were either deduced elsewhere or
explicitly specified. If a template parameter is used only
in non-deduced contexts and is not explicitly specified,
template argument deduction fails. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> Under
14.8.2.1 [temp.deduct.call] and 14.8.2.4 [temp.deduct.partial],
if <TT>P</TT> contains no <I>template-parameter</I>s that
appear in deduced contexts, no deduction is done, and so
<TT>P</TT> and <TT>A</TT> need not have the same form.
&#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

</OL>

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

<P><B>Additional note October, 2015:</B></P>

<P>See also issue 1939.</P>

<BR><BR><HR><A NAME="1722"></A><H4>1722.
  
Should lambda to function pointer conversion function be <TT>noexcept</TT>?
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-07-31




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

<BLOCKQUOTE>

The closure type for a non-generic <I>lambda-expression</I> with
no <I>lambda-capture</I> has a public non-virtual non-explicit const
conversion function to pointer to function with C++ language linkage
(7.5 [dcl.link]) having the same parameter and return types as
the closure type's function call operator.

</BLOCKQUOTE>

<P>This does not specify whether the conversion function is
<TT>noexcept(true)</TT> or <TT>noexcept(false)</TT>.  It might be
helpful to nail that down.</P>

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

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

<BLOCKQUOTE>

<P>The closure type for a non-generic <I>lambda-expression</I>
with no <I>lambda-capture</I> has a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">public non-virtual
non-explicit const</SPAN> conversion function to pointer to
function with C++ language linkage
(7.5 [dcl.link]) having the same parameter and
return types as the closure type's function call
operator. The value returned by this conversion function
shall be the address of a function that, when invoked, has
the same effect as invoking the closure type's function call
operator. For a generic lambda with
no <I>lambda-capture</I>, the closure type has a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">public
non-virtual non-explicit const</SPAN> conversion function template
to pointer to function. The conversion function template...
[<I>Example:</I></P>

<PRE>
  auto GL = [](auto a) { std::cout &lt;&lt; a; return a; };
  int (*GL_int)(int) = GL; //<SPAN style="font-family:Times;font-style:italic"> OK: through conversion function template</SPAN>
  GL_int(3);               //<SPAN style="font-family:Times;font-style:italic"> OK: same as </SPAN>GL(3)
</PRE>

</BLOCKQUOTE>

<P>&#8212;<I>end example</I>] <SPAN style="font-weight:bold;background-color:#A0FFA0">The conversion function or
conversion function template is public, non-virtual, non-explicit,
const, and has a non-throwing exception specification
(15.4 [except.spec]).</SPAN>
</P>

<BR><BR><HR><A NAME="1847"></A><H4>1847.
  
Clarifying compatibility during partial ordering
</H4><B>Section: </B>14.8.2.5&#160; [temp.deduct.type]
 &#160;&#160;&#160;

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

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

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




<P>There is implementation divergence in the handling of an example
like</P>

<PRE>
  template&lt;typename D&gt; struct A { };
  template&lt;typename T&gt; struct Wrap1 { typedef T type; };
  template&lt;typename T&gt; struct Wrap2 { typedef T type; };

  template&lt;typename T1&gt;
  A&lt;typename Wrap1&lt;T1&gt;::type&gt;
  fn(const A&lt;T1&gt;&amp; x, const A&lt;T1&gt;&amp; y);

  template&lt;typename T2, typename U&gt;
  A&lt;typename Wrap2&lt;T2&gt;::type&gt;
  fn(const A&lt;T2&gt;&amp; x, const A&lt;U&gt;&amp; y);

  A&lt;int&gt; (*p)(const A&lt;int&gt;&amp;, const A&lt;int&gt;&amp;) = fn;
</PRE>

<P>The implementations that accept this example do so by not
comparing the return types of the two templates during
partial ordering, which seems to make sense given that partial
ordering would not have been performed if the candidate
specializations were not indistinguishable from the perspective of
overload resolution.  However, the existing wording is not clear
that that is how such types are be handled.</P>

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

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

<BR><BR><HR><A NAME="1863"></A><H4>1863.
  
Requirements on thrown object type to support <TT>std::current_exception()</TT>
</H4><B>Section: </B>15.1&#160; [except.throw]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-09-22


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3903.html#CA12">N3690 comment
  CA&#160;12<BR></A>

<P>The specification of <TT>std::current_exception()</TT> in
18.8.5 [propagation] allows either referring to the exception object
itself or to a copy thereof, implying that the exception object must be
copyable.  However, the specification of <I>throw-expression</I> allows
throwing objects that cannot be copied, only moved.  Presumably the
requirements should include a non-deleted accessible copy constructor that
is odr-used by a <I>throw-expression</I>, even if the object being thrown
is moved to the exception object.</P>

<P><B>Additional note, February, 2014:</B></P>

<P>This issue was referred to CWG by EWG at the September, 2013 meeting
but was overlooked at that time.  </P>

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

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

<BLOCKQUOTE>

...A destructor is potentially invoked if it is invoked or
as specified in 5.3.4 [expr.new]<SPAN style="text-decoration:line-through;background-color:#FFA0A0">
and</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN> 12.6.2 [class.base.init]<SPAN style="font-weight:bold;background-color:#A0FFA0">, and
15.1 [except.throw]</SPAN>. A program is ill-formed
if...

</BLOCKQUOTE>

<LI><P>Change 15.1 [except.throw] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

When the thrown object is a class object, the constructor
selected for the copy-initialization <SPAN style="font-weight:bold;background-color:#A0FFA0">as well as the
constructor selected for a copy-initialization considering
the thrown object as an lvalue</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and the
destructor</SPAN> shall be <SPAN style="font-weight:bold;background-color:#A0FFA0">non-deleted and</SPAN>
accessible, even if the copy/move operation is elided
(12.8 [class.copy]). <SPAN style="font-weight:bold;background-color:#A0FFA0">The destructor is
potentially invoked (12.4 [class.dtor]).</SPAN>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1949"></A><H4>1949.
  
&#8220;sequenced after&#8221; instead of &#8220;sequenced before&#8221;
</H4><B>Section: </B>1.9&#160; [intro.execution]
 &#160;&#160;&#160;

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

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

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


<P>The term &#8220;sequenced after&#8221; is used in both the core and
library clauses instead of the more-correct &#8220;sequenced
before.&#8221;</P>



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

<OL><LI><P>Change 1.9 [intro.execution] paragraph 13 as follows:</P></LI>

<BLOCKQUOTE>

<I>Sequenced before</I> is an asymmetric, transitive,
pair-wise relation between evaluations executed by a single
thread (1.10 [intro.multithread]), which induces a partial
order among those evaluations. Given any two
evaluations <I>A</I> and <I>B</I>, if <I>A</I> is sequenced
before <I>B</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">(or, equivalently, <I>B</I>
is <I>sequenced after</I> <I>A</I>)</SPAN>, then the execution
of <I>A</I> shall precede the execution
of <I>B</I>. If <I>A</I> is not sequenced before <I>B</I>...

</BLOCKQUOTE>

<LI><P>Change 1.10 [intro.multithread] paragraph 14 as follows:</P></LI>

<BLOCKQUOTE>

An evaluation <I>A</I> <I>happens before</I> an
evaluation <I>B</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">(or,
equivalently, <I>B</I> <I>happens after</I> <I>A</I>)</SPAN>
if:...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

...<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Every evaluation in the calling function (including other
function calls) that is not otherwise specifically sequenced
before or after the execution of the body of the called
function is indeterminately sequenced with respect to the
execution of the called function</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">For each function
invocation <I>F</I>, for every evaluation <I>A</I> that occurs
within <I>F</I> and every evaluation <I>B</I> that does not occur
within <I>F</I> but is evaluated on the same thread and as part
of the same signal handler (if any), either <I>A</I> is
sequenced before <I>B</I> or <I>B</I> is sequenced before
<I>A</I></SPAN>.<SUP>9</SUP> <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> if <I>A</I> and
<I>B</I> would not otherwise be sequenced then they are
indeterminately sequenced. &#8212;<I>end note</I>]</SPAN>
Several contexts...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

It is implementation-defined whether the dynamic
initialization of a non-local variable with static storage
duration <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is done</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">happens</SPAN> before the
first statement of <TT>main</TT>. If the initialization is
deferred to <SPAN style="text-decoration:line-through;background-color:#FFA0A0">some point in time</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">happen</SPAN>
after the first statement of <TT>main</TT>, it <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall
occur</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">happens</SPAN> before the first odr-use
(3.2 [basic.def.odr]) of any function or variable...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

It is implementation-defined whether the dynamic
initialization of a non-local variable with static or thread
storage duration is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">done</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">sequenced</SPAN>
before the first statement of the initial function of the
thread. If the initialization is deferred to some point in
time <SPAN style="font-weight:bold;background-color:#A0FFA0">sequenced</SPAN> after the first statement of the
initial function of the thread, it <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall
occur</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is sequenced</SPAN> before the first odr-use
(3.2 [basic.def.odr]) of any variable with thread
storage duration defined in the same translation unit as the
variable to be initialized.

</BLOCKQUOTE>

<LI><P>Change 6.5.3 [stmt.for] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...[<I>Note:</I> Thus the first statement specifies
initialization for the loop; the condition
(6.4 [stmt.select]) specifies a
test, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">made</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">sequenced</SPAN> before each
iteration, such that the loop is exited when the condition
becomes <TT>false</TT>; the expression often specifies
incrementing that is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">done</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">sequenced</SPAN>
after each iteration.  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Add the following as a new paragraph at the end of
15 [except]:</P></LI>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">In this section, &#8220;before&#8221; and &#8220;after&#8221;
refer to the &#8220;sequenced before&#8221; relation
(1.9 [intro.execution]).</SPAN>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1975"></A><H4>1975.
  
Permissible declarations for <I>exception-specification</I>s
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

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

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

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




<P>The declarations in which an <I>exception-specification</I> may
appear is not completely clear from the current wording of
15.4 [except.spec] paragraph 2.</P>

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

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

<BLOCKQUOTE>

An <I>exception-specification</I> shall appear only on a
function declarator for a function type, pointer to function
type, reference to function type, or pointer to member
function type that is the top-level type of a
declaration <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or definition</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">of a function,
variable, or non-static data member</SPAN>, or on such a type
appearing as a parameter or return type in <SPAN style="font-weight:bold;background-color:#A0FFA0">such</SPAN> a
function declarator. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">An <I>exception-specification</I> shall
not appear in a typedef declaration
or <I>alias-declaration</I>.</SPAN>  [<I>Example:</I>...

</BLOCKQUOTE>

<P>See also issues 2010,
1995,
1946,
and 1798.</P>

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

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

<BLOCKQUOTE>

An <I>exception-specification</I> shall appear only <SPAN style="text-decoration:line-through;background-color:#FFA0A0">on</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">within a <I>lambda-declarator</I> or within</SPAN> a
function declarator for a function type, pointer to function
type, reference to function type, or pointer to member
function type that is the top-level type of a
declaration <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or definition, or on such a type appearing
as a parameter or return type in a function declarator.
An <I>exception-specification</I> shall not appear in a
typedef declaration or <I>alias-declaration</I>.</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">of a function, variable, or non-static data member.  It
shall appear only on the top-level declarator, on
the <I>declarator</I> of one of its
<I>parameter-declaration</I>s (if any), or on its return
type</SPAN>. [<I>Example:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1981"></A><H4>1981.
  
Implicit contextual conversions and <TT>explicit</TT>
</H4><B>Section: </B>4&#160; [conv]
 &#160;&#160;&#160;

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

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

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




<P>According to 4 [conv] paragraph 5,</P>

<BLOCKQUOTE>

Certain language constructs require conversion to a value
having one of a specified set of types appropriate to the
construct. An expression <TT>e</TT> of class type <TT>E</TT>
appearing in such a context is said to be <I>contextually
implicitly converted to</I> a specified type <TT>T</TT> and
is well-formed if and only if <TT>e</TT> can be implicitly
converted to a type <TT>T</TT> that is determined as
follows: <TT>E</TT> is searched for conversion functions
whose return type is <I>cv</I> <TT>T</TT> or reference
to <I>cv</I> <TT>T</TT> such that <TT>T</TT> is allowed by
the context. There shall be exactly one such <TT>T</TT>.

</BLOCKQUOTE>

<P>This description leaves open two questions: first, can
<TT>explicit</TT> conversion functions be used for this
conversion?  Second, assuming that they cannot, is the
restriction to &#8220;exactly one such <TT>T</TT>&#8221;
enforced before or after exclusion of <TT>explicit</TT>
conversion functions?</P>

<P><B>Notes from the November, 2014 meeting:</B></P>

<P>CWG felt that <TT>explicit</TT> conversion functions should
be removed from consideration before determining the set of
types for the conversion.</P>

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

<P>Change 4 [conv] paragraph 5 as follows:</P>

<BLOCKQUOTE>

...An expression <TT>e</TT> of class type <TT>E</TT>
appearing in such a context is said to be <I>contextually
implicitly converted</I> to a specified type <TT>T</TT> and
is well-formed if and only if <TT>e</TT> can be implicitly
converted to a type <TT>T</TT> that is determined as
follows: <TT>E</TT> is searched for <SPAN style="font-weight:bold;background-color:#A0FFA0">non-explicit</SPAN>
conversion functions whose return type
is <I>cv</I> <TT>T</TT> or reference to <I>cv</I> <TT>T</TT>
such that <TT>T</TT> is allowed by the context. There shall
be exactly one such <TT>T</TT>.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1990"></A><H4>1990.
  
Ambiguity due to optional <I>decl-specifier-seq</I>
</H4><B>Section: </B>7&#160; [dcl.dcl]
 &#160;&#160;&#160;

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

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

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




<P>In an example like</P>

<PRE>
  void f() {
    f();  //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
  }
</PRE>

<P>The statement at #1 is ambiguous and can be parsed as either
an expression or as a declaration.  The problem is the fact
that the <I>decl-specifier-seq</I> in a <I>simple-declaration</I>
is optional.</P>



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

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

<UL><I>declaration:</I>
<UL><I>block-declaration</I><BR>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>nodeclspec-function-declaration</I></SPAN><BR>
<I>function_definition</I>
</UL>
...
</UL><BR>

<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>nodeclspec-function-declaration:</I></SPAN>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>attribute-specifier-seq<SUB>opt</SUB> declarator</I> <TT>;</TT></SPAN>
</UL>
</UL><BR>

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

<UL><I>simple-declaration:</I>
<UL><I>decl-specifier-seq<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><SUB>opt</SUB></SPAN> init-declarator-list</I> <TT>;</TT><BR>
<I>attribute-specifier-seq decl-specifier-seq<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><SUB>opt</SUB></SPAN> init-declarator-list</I> <TT>;</TT>
</UL>
...
</UL>

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

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A</SPAN> <I>simple-declaration</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">or
<I>nodeclspec-function-declaration</I> of the form</SPAN></P>

<UL><I>attribute-specifier-seq<SUB>opt</SUB> decl-specifier-seq<SUB>opt</SUB> init-declarator-list<SUB>opt</SUB></I> <TT>;</TT>
</UL>

<P>is divided into three parts. Attributes are described in
7.6 [dcl.attr]. <I>decl-specifier</I>s, the
principal components of a <I>decl-specifier-seq</I>, are
described in 7.1 [dcl.spec]. declarators, the
components of an <I>init-declarator-list</I>, are described
in Clause
8 [dcl.decl]. The <I>attribute-specifier-seq</I>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">in a <I>simple-declaration</I></SPAN> appertains to each
of the entities declared by the declarators of
the <I>init-declarator-list</I>. [<I>Note:</I>...</P>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Only in function declarations for</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A
<I>nodeclspec-function-declaration</I> shall declare a</SPAN>
constructor<SPAN style="text-decoration:line-through;background-color:#FFA0A0">s</SPAN>, destructor<SPAN style="text-decoration:line-through;background-color:#FFA0A0">s</SPAN>,
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">and type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">or</SPAN> conversion<SPAN style="text-decoration:line-through;background-color:#FFA0A0">s</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">function</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">can the <I>decl-specifier-seq</I> be
omitted</SPAN>.<SUP>93</SUP> <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> a
<I>nodeclspec-function-declaration</I> can only be used in a
<I>template-declaration</I> (Clause 14 [temp]),
<I>explicit-instantiation</I> (14.7.2 [temp.explicit]),
or <I>explicit-specialization</I> (14.7.3 [temp.expl.spec]).
&#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">A list of declarators appears after an optional (Clause
7 [dcl.dcl]) <I>decl-specifier-seq</I>
(7.1 [dcl.spec]). Each</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A</SPAN>
declarator contains exactly one <I>declarator-id</I>; it
names the identifier...

</BLOCKQUOTE>

<LI><P>Change 12.1 [class.ctor] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...<SPAN style="text-decoration:line-through;background-color:#FFA0A0">In a constructor declaration,
each</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Each</SPAN> <I>decl-specifier</I> in
the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">optional</SPAN> <I>decl-specifier-seq</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">of a
constructor declaration (if any)</SPAN> shall
be <TT>friend</TT>,
<TT>inline</TT>, <TT>explicit</TT>,
or <TT>constexpr</TT>. [<I>Example:</I>...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

...Such functions are called conversion functions. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">No return
type can be specified.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A <I>decl-specifier</I> in the
<I>decl-specifier-seq</I> of a conversion function (if any) shall
be neither a <I>type-specifier</I> nor <TT>static</TT>.</SPAN>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">If a conversion function is a member function,
the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The</SPAN> type of the conversion function
(8.3.5 [dcl.fct]) is...

</BLOCKQUOTE>

<LI><P>Delete 12.3.2 [class.conv.fct] paragraph 6:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Conversion functions cannot be declared <TT>static</TT>.</SPAN>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

...<SPAN style="text-decoration:line-through;background-color:#FFA0A0">In a destructor declaration,
each</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Each</SPAN> <I>decl-specifier</I> of the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">optional</SPAN> <I>decl-specifier-seq</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">of a
destructor declaration (if any)</SPAN> shall
be <TT>friend</TT>,
<TT>inline</TT>, or <TT>virtual</TT>.

</BLOCKQUOTE>

</OL>

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

<BR><BR><HR><A NAME="2000"></A><H4>2000.
  
<I>header-name</I> outside <TT>#include</TT> directive
</H4><B>Section: </B>2.4&#160; [lex.pptoken]
 &#160;&#160;&#160;

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

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

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




<P>The &#8220;max munch&#8221; rule could be read to require the
characters <TT>&lt;int&gt;</TT> in <TT>vector&lt;int&gt;</TT> to
be parsed as a <I>header-name</I> rather than as three distinct
tokens.  2.8 [lex.header] paragraph 1 says,</P>

<BLOCKQUOTE>

Header name preprocessing tokens shall only appear within a
<TT>#include</TT> preprocessing directive
(16.2 [cpp.include]).

</BLOCKQUOTE>

<P>However, that is not sufficiently clear that <I>header-name</I>s
are only to be recognized in that context.</P>

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

<OL><LI><P>Change 2.4 [lex.pptoken] bullet 3.3 as follows:</P></LI>

<UL><LI><P>Otherwise, the next preprocessing token is the longest
sequence of characters that could constitute a preprocessing
token, even if that would cause further lexical analysis to
fail<SPAN style="font-weight:bold;background-color:#A0FFA0">, except that a <I>header-name</I> (2.8 [lex.header])
is only formed within a <TT>#include</TT> directive
(16.2 [cpp.include])</SPAN>.</P></LI>

</UL>

<LI><P>Change 2.8 [lex.header] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I></SPAN> Header name preprocessing tokens
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall</SPAN> only appear within a <TT>#include</TT>
preprocessing directive (<SPAN style="text-decoration:line-through;background-color:#FFA0A0">16.2 [cpp.include]</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">see 2.4 [lex.pptoken]</SPAN>). <SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end
note</I>]</SPAN> The sequences in both forms...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2004"></A><H4>2004.
  
Unions with mutable members in constant expressions
</H4><B>Section: </B>5.20&#160; [expr.const]
 &#160;&#160;&#160;

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

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

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




<P>In an example like</P>

<PRE>
  union U { int a; mutable int b; };
  constexpr U u1 = {1};
  int k = (u1.b = 2);
  constexpr U u2 = u1; //<SPAN style="font-family:Times;font-style:italic"> ok!!</SPAN>
</PRE>

<P>The initialization of <TT>u2</TT> is not disqualified by
the current wording of the Standard because the copy is done
via the object representation, not formally involving an
lvalue-to-rvalue conversion.  A restriction should be added
to 5.20 [expr.const] forbidding the evaluation of a
defaulted copy/move construction/assignment on a class type
that has any variant mutable subobjects.</P>

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

<OL><LI><P>Add the following bullet after bullet 3.1 of
7.1.5 [dcl.constexpr]:</P></LI>

<BLOCKQUOTE>

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

<UL><LI><P>it shall not be virtual (10.3 [class.virtual]);</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">for a defaulted copy/move assignment, the class of which
it is a member shall not have a mutable subobject that is a
variant member;</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

<LI><P>Add the following bullet after bullet 4.1 of
7.1.5 [dcl.constexpr]</P></LI>

<BLOCKQUOTE>

<P>The definition of a <TT>constexpr</TT> constructor shall
satisfy the following constraints:</P>

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

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">for a defaulted copy/move constructor, the class
shall not have a mutable subobject that is a variant
member;</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2006"></A><H4>2006.
  
Cv-qualified <TT>void</TT> types
</H4><B>Section: </B>3.9.2&#160; [basic.compound]
 &#160;&#160;&#160;

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

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

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




<P>According to 3.9.2 [basic.compound] paragraph 3,</P>

<BLOCKQUOTE>

The type of a pointer to <TT>void</TT> or a pointer to an object type
is called an <I>object pointer type</I>. [<I>Note:</I> A pointer to
<TT>void</TT> does not have a pointer-to-object type, however,
because <TT>void</TT> is not an object type. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>This wording excludes cv-qualified <TT>void</TT> types.  There
are other references in the Standard to &#8220;<TT>void</TT>
type&#8221; that are apparently intended to include cv-qualified
versions as well.</P>

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

<OL><LI><P>Change 3.9 [basic.types] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

...Incompletely-defined object types and <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the void types</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I> <TT>void</TT></SPAN> are incomplete types
(3.9.1 [basic.fundamental])...

</BLOCKQUOTE>

<LI><P>Change 3.9 [basic.types] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

An object type is a (possibly cv-qualified) type that is not
a function type, not a reference type, and not <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a void type</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I> <TT>void</TT></SPAN>.

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The <TT>void</TT> type has an empty set of values. The</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">A type <I>cv</I></SPAN> <TT>void</TT> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">type</SPAN> is
an incomplete type that cannot be completed<SPAN style="font-weight:bold;background-color:#A0FFA0">; such a type
has an empty set of values</SPAN>. It is used as
the return type for functions that do not return a
value. Any expression can be explicitly converted to type <I>cv</I>
<TT>void</TT> (5.4 [expr.cast]). An expression of type
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void</TT> shall be used only as an
expression statement (6.2 [stmt.expr]), as an
operand of a comma expression (5.19 [expr.comma]),
as a second or third operand of <TT>?:</TT>
(5.16 [expr.cond]), as the operand of
<TT>typeid</TT>, <TT>noexcept</TT>, or <TT>decltype</TT>, as
the expression in a return statement
(6.6.3 [stmt.return]) for a function with the return
type <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void</TT>, or as the operand
of an explicit conversion to type <I>cv</I> <TT>void</TT>.

</BLOCKQUOTE>

<LI><P>Change bullet 1.3 of 3.9.2 [basic.compound] as follows:</P></LI>

<UL><LI><P><I>pointers</I>
to <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void</TT> or objects or
functions (including static members of classes) of a given
type, 8.3.1 [dcl.ptr];</P></LI></UL>

<LI><P>Change 3.9.2 [basic.compound] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

The type of a pointer to <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void</TT>
or a pointer to an object type is called an <I>object
pointer type</I>. [<I>Note:</I>...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2015"></A><H4>2015.
  
odr-use of deleted virtual functions
</H4><B>Section: </B>8.4.3&#160; [dcl.fct.def.delete]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-10-05


<P>It is not clear that the odr-use of a virtual function described in
3.2 [basic.def.odr] paragraph 3 is exempt from the prohibition
against referring to a deleted function (8.4.3 [dcl.fct.def.delete]
paragraph 2).</P>

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

<P>Change 8.4.3 [dcl.fct.def.delete] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A program that refers to a deleted function implicitly or
explicitly, other than to declare it, is ill-formed.
[<I>Note:</I> This includes calling the function implicitly
or explicitly and forming a pointer or pointer-to-member to
the function. It applies even for references in expressions
that are not potentially-evaluated. If a function is
overloaded, it is referenced only if the function is
selected by overload resolution. <SPAN style="font-weight:bold;background-color:#A0FFA0">The implicit odr-use
(3.2 [basic.def.odr]) of a virtual function does not, by
itself, constitute a reference.</SPAN> &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2016"></A><H4>2016.
  
Confusing wording in description of conversion function
</H4><B>Section: </B>12.3.2&#160; [class.conv.fct]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-10-05


<P>The statement in 12.3.1 [class.conv.ctor] paragraph 1,</P>

<BLOCKQUOTE>

No return type can be specified.

</BLOCKQUOTE>

<P>is confusing, since a conversion operator has a return type.  It
would be more precise to phrase the restriction in terms of the
permissible <I>decl-specifier</I>s in the function's
<I>decl-specifier-seq</I>.  The next sentence is also problematic,</P>

<BLOCKQUOTE>

If a conversion function is a member function, the
type of the conversion function (8.3.5 [dcl.fct])
is &#8220;function taking no parameter
returning <I>conversion-type-id</I>&#8221;.

</BLOCKQUOTE>

<P>as it implies that a conversion function might not be a member
function.</P>

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

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

<BR><BR><HR><A NAME="2019"></A><H4>2019.
  
Member references omitted from description of storage duration
</H4><B>Section: </B>3.7.5&#160; [basic.stc.inherit]
 &#160;&#160;&#160;

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

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

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


<P>According to 3.7.5 [basic.stc.inherit] paragraph 1,</P>

<BLOCKQUOTE>

The storage duration of member subobjects, base class
subobjects and array elements is that of their complete
object (1.8 [intro.object]).

</BLOCKQUOTE>

<P>This wording does not cover member references, which should also
have the same storage duration as the object of which they are a
member.</P>

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

<P>Change 3.7.5 [basic.stc.inherit] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The storage duration of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">member</SPAN> subobjects<SPAN style="text-decoration:line-through;background-color:#FFA0A0">,
base class subobjects</SPAN> and <SPAN style="text-decoration:line-through;background-color:#FFA0A0">array
elements</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">reference members</SPAN> is that of their
complete object (1.8 [intro.object]).

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2024"></A><H4>2024.
  
Dependent types and unexpanded parameter packs
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

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

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

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




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

<PRE>
  template&lt;typename ...Ts&gt; struct X { X(int); };
  template&lt;typename T&gt; using Y = int;
  template&lt;typename ...Ts&gt; void f() {
    X&lt;Y&lt;Ts&gt;...&gt; x;
  }
</PRE>

<P>The presence of the ellipsis should make the reference to
<TT>X</TT> a dependent type, but there is no rule making it so.</P>

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

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

<BLOCKQUOTE>

<P>A type is dependent if it is</P>

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

<LI><P>a <I>simple-template-id</I> in which either the
template name is a template parameter or any of the template
arguments is a dependent type or an expression that is
type-dependent or value-dependent <SPAN style="font-weight:bold;background-color:#A0FFA0">or is a pack
expansion</SPAN>, or</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2026"></A><H4>2026.
  
Zero-initialization and <TT>constexpr</TT>
</H4><B>Section: </B>3.6&#160; [basic.start]
 &#160;&#160;&#160;

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

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

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




<P>According to 3.6.2 [basic.start.init] paragraph 2,</P>

<BLOCKQUOTE>

Variables with static storage duration (3.7.1 [basic.stc.static]) or
thread storage duration (3.7.2 [basic.stc.thread]) shall be
zero-initialized (8.5 [dcl.init]) before any other initialization
takes place.

</BLOCKQUOTE>

<P>Does this apply to constant initialization as well?  For example,
should the following be well-formed, relying on the presumed
zero-initialization preceding the constant initialization?</P>

<PRE>
  constexpr int i = i;
  struct s {
    constexpr s() : v(v) { }
    int v;
  };
  constexpr s s1;
</PRE>

<P><B>Notes from the November, 2014 meeting:</B></P>

<P>CWG agreed that constant initialization should be considered as
happening instead of zero initialization in these cases, making the
declarations ill-formed.</P>

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

<OL><LI><P>Rename 3.6.2 [basic.start.init] and make the indicated
changes, moving parts of its content to a new section immediately
following, as indicated below:</P></LI>

<BLOCKQUOTE>

<TABLE><TR><TD><B>3.6.2 <SPAN style="text-decoration:line-through;background-color:#FFA0A0">I</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">Static
i</SPAN>nitialization <SPAN style="text-decoration:line-through;background-color:#FFA0A0">of non-local
variables</SPAN></B></TD>

<TD ALIGN="RIGHT" VALIGN="TOP"><B>[basic.start<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.init</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">.static</SPAN>]</B></TD>

</TR>

</TABLE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">There are two broad classes of named non-local variables:
those with static storage duration
(3.7.1 [basic.stc.static]) and those with thread storage
duration (3.7.2 [basic.stc.thread]). Non-local variables</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">Variables</SPAN> with static storage duration are
initialized as a consequence of program
initiation. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">Non-local
variables</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Variables</SPAN> with thread storage
duration are initialized as a consequence of thread
execution. Within each of these phases of initiation,
initialization occurs as follows.</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Variables with static storage duration
(3.7.1 [basic.stc.static]) or thread storage duration
(3.7.2 [basic.stc.thread]) shall be zero-initialized
(8.5 [dcl.init]) before any other initialization
takes place.</SPAN> A <I>constant initializer</I> for an
object <TT>o</TT> is an expression that is a
constant expression, except that it may also invoke
<TT>constexpr</TT> constructors for o and its subobjects even if
those objects are of non-literal class types [<I>Note:</I>
such a class may have a non-trivial destructor &#8212;<I>end
note</I>]. <I>Constant initialization</I> is performed:</P>

<UL><LI><P>if each full-expression (including implicit conversions) that
appears in the initializer of a reference with static or
thread storage duration is a constant expression
(5.20 [expr.const]) and the reference is bound to a
glvalue designating an object with static storage duration,
to a temporary object (see 12.2 [class.temporary]) or
subobject thereof, or to a function;</P></LI>

<LI><P>if an object with static or thread storage duration is
initialized by a constructor call, and if the initialization
full-expression is a constant initializer for the object;</P></LI>

<LI><P>if an object with static or thread storage duration is not
initialized by a constructor call and if either the object
is value-initialized or every full-expression that appears
in its initializer is a constant expression.</P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If constant initialization is not performed, a variable
with static storage duration (3.7.1 [basic.stc.static]) or
thread storage duration (3.7.2 [basic.stc.thread]) is
zero-initialized (8.5 [dcl.init]).</SPAN>
Together, zero-initialization and constant initialization
are called <I>static initialization</I>; all other initialization
is <I>dynamic initialization</I>. Static initialization shall be
performed before any dynamic initialization takes place.
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Dynamic initialization of a non-local variable with static
storage duration is <I>unordered</I> if the variable is an
implicitly or explicitly instantiated specialization, and
otherwise is <I>ordered</I> [<I>Note:</I> an explicitly specialized
static data member or variable template specialization has
ordered initialization. &#8212;<I>end note</I>]. Variables
with ordered initialization defined within a single
translation unit shall be initialized in the order of their
definitions in the translation unit. If a program starts a
thread (30.3 [thread.threads]), the subsequent
initialization of a variable is unsequenced with respect to
the initialization of a variable defined in a different
translation unit.  Otherwise, the initialization of a
variable is indeterminately sequenced with respect to the
initialization of a variable defined in a different
translation unit. If a program starts a thread, the
subsequent unordered initialization of a variable is
unsequenced with respect to every other dynamic
initialization. Otherwise, the unordered initialization of a
variable is indeterminately sequenced with respect to every
other dynamic initialization. [<I>Note:</I> This definition
permits initialization of a sequence of ordered variables
concurrently with another sequence. &#8212;<I>end note</I>]</SPAN>
[<I>Note:</I> The <SPAN style="font-weight:bold;background-color:#A0FFA0">dynamic</SPAN> initialization of
<SPAN style="font-weight:bold;background-color:#A0FFA0">non-local variables is described in 3.6.3
[basic.start.dynamic]; that of</SPAN> local static variables
is described in 6.7 [stmt.dcl].  &#8212;<I>end
note</I>]</P>

<P>An implementation is permitted to perform the
initialization of a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">non-local</SPAN> variable with
static <SPAN style="font-weight:bold;background-color:#A0FFA0">or thread</SPAN> storage duration as a static
initialization even if such initialization is not required
to be done statically, provided that</P>

<UL><LI><P>the dynamic version of the initialization does not change
the value of any other object of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">namespace scope</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">static or thread storage duration</SPAN> prior to
its initialization, and</P></LI>

<LI><P>the static version of the initialization produces the same
value in the initialized variable as would be produced by
the dynamic initialization if all variables not required to
be initialized statically were initialized dynamically.</P></LI>

</UL>

<P>[<I>Note:</I> As a consequence, if the initialization of an
object <TT>obj1</TT> refers to an object <TT>obj2</TT> of namespace scope
potentially requiring dynamic initialization and defined
later in the same translation unit, it is unspecified
whether the value of <TT>obj2</TT> used will be the value of the
fully initialized <TT>obj2</TT> (because <TT>obj2</TT> was statically
initialized) or will be the value of <TT>obj2</TT> merely
zero-initialized. For example,</P>

<PRE>
  inline double fd() { return 1.0; }
  extern double d1;
  double d2 = d1;   //<SPAN style="font-family:Times;font-style:italic"> unspecified:</SPAN>
                    //<SPAN style="font-family:Times;font-style:italic"> may be statically initialized to </SPAN>0.0<SPAN style="font-family:Times;font-style:italic"> or</SPAN>
                    //<SPAN style="font-family:Times;font-style:italic"> dynamically initialized to </SPAN>0.0<SPAN style="font-family:Times;font-style:italic"> if </SPAN>d1<SPAN style="font-family:Times;font-style:italic"> is</SPAN>
                    //<SPAN style="font-family:Times;font-style:italic"> dynamically initialized, or </SPAN>1.0<SPAN style="font-family:Times;font-style:italic"> otherwise</SPAN>
  double d1 = fd(); //<SPAN style="font-family:Times;font-style:italic"> may be initialized statically or dynamically to </SPAN>1.0
</PRE>

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

</BLOCKQUOTE>

<LI><P>Insert a new section after 3.6.2 [basic.start.init]:</P></LI>

<BLOCKQUOTE>

<TABLE><TR><TD><SPAN style="font-weight:bold;background-color:#A0FFA0">3.6.3 Dynamic initialization of non-local variables</SPAN></TD>

<TD ALIGN="RIGHT" VALIGN="TOP"><SPAN style="font-weight:bold;background-color:#A0FFA0">[basic.start.dynamic]</SPAN></TD>

</TR>

</TABLE>

</BLOCKQUOTE>

<LI><P>Move part of 3.6.2 [basic.start.init] paragraph 2 as
paragraph 1 of the new section:</P></LI>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">Dynamic initialization of a non-local variable with static
storage duration is unordered if the variable is an
implicitly or explicitly instantiated specialization, and
otherwise is ordered [<I>Note:</I> an explicitly specialized
static data member or variable template specialization has
ordered initialization. &#8212;<I>end note</I>]. Variables
with ordered initialization defined within a single
translation unit shall be initialized in the order of their
definitions in the translation unit. If a program starts a
thread (30.3 [thread.threads]), the subsequent
initialization of a variable is unsequenced with respect to
the initialization of a variable defined in a different
translation unit.  Otherwise, the initialization of a
variable is indeterminately sequenced with respect to the
initialization of a variable defined in a different
translation unit. If a program starts a thread, the
subsequent unordered initialization of a variable is
unsequenced with respect to every other dynamic
initialization. Otherwise, the unordered initialization of a
variable is indeterminately sequenced with respect to every
other dynamic initialization. [<I>Note:</I> This definition
permits initialization of a sequence of ordered variables
concurrently with another sequence. &#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

<LI><P>Move paragraphs 4-6 of 3.6.2 [basic.start.init]
as paragraphs 2-4 of the new section:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">It is implementation-defined whether the dynamic
initialization of a non-local variable with static storage
duration is done before the first statement of <TT>main</TT>. If the
initialization is deferred to some point in time after the
first statement of <TT>main</TT>, it shall occur before the first
odr-use (3.2 [basic.def.odr]) of any function or
variable defined in the same translation unit as the
variable to be initialized. [<I>Footnote:</I> 
A non-local variable with static storage duration having
initialization with side-effects must be initialized even if
it is not odr-used (3.2 [basic.def.odr],
3.7.1 [basic.stc.static]). &#8212;<I>end footnote</I>]
[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  //<SPAN style="font-family:Times;font-style:italic"> - File 1 -</SPAN>
  #include "a.h"
  #include "b.h"
  B b;
  A::A(){
    b.Use();
  }

  //<SPAN style="font-family:Times;font-style:italic"> - File 2 -</SPAN>
  #include "a.h"
  A a;

  //<SPAN style="font-family:Times;font-style:italic"> - File 3 -</SPAN>
  #include "a.h"
  #include "b.h"
  extern A a;
  extern B b;
  int main() {
    a.Use();
    b.Use();
}</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">It is implementation-defined whether either <TT>a</TT>
or <TT>b</TT> is initialized before <TT>main</TT> is entered
or whether the initializations are delayed until <TT>a</TT>
is first odr-used in
<TT>main</TT>. In particular, if <TT>a</TT> is initialized
before <TT>main</TT> is entered, it is not guaranteed
that <TT>b</TT> will be initialized before it is odr-used by
the initialization of <TT>a</TT>, that is,
before <TT>A::A</TT> is called. If, however, <TT>a</TT> is
initialized at some point after the first statement
of <TT>main</TT>, <TT>b</TT> will be initialized prior to
its use in <TT>A::A</TT>. &#8212;<I>end example</I>]</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">It is implementation-defined whether the dynamic
initialization of a non-local variable with static or thread
storage duration is done before the first statement of the
initial function of the thread. If the initialization is
deferred to some point in time after the first statement of
the initial function of the thread, it shall occur before
the first odr-use (3.2 [basic.def.odr]) of any variable
with thread storage duration defined in the same translation
unit as the variable to be initialized.</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If the initialization of a non-local variable with static or
thread storage duration exits via an exception,
<TT>std::terminate</TT> is called (15.5.1 [except.terminate]).</SPAN></P>

</BLOCKQUOTE>

<LI>Change 6.7 [stmt.dcl] paragraph 4 as follows:</LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The zero-initialization (8.5 [dcl.init]) of all
block-scope variables with static storage duration
(3.7.1 [basic.stc.static]) or thread storage duration
(3.7.2 [basic.stc.thread]) is performed before any other
initialization takes place. Constant initialization
(3.6.2 [basic.start.init]) of a block-scope entity with
static storage duration, if applicable, is performed before
its block is first entered.  An implementation is permitted
to perform early initialization of other block-scope
variables with static or thread storage duration under the
same conditions that an implementation is permitted to
statically initialize a variable with static or thread
storage duration in namespace scope
(3.6.2 [basic.start.init]). Otherwise such a variable is
initialized</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Dynamic initialization of a block-scope
variable with static storage duration (3.7.1 [basic.stc.static])
or thread storage duration (3.7.2 [basic.stc.thread]) is
performed</SPAN> the first time control passes...

</BLOCKQUOTE>

</OL>

<P><I>Editing note: all existing cross-references to
3.6.2 [basic.start.init] must be examined to determine
which of the two current sections should be targeted.</I></P>

<BR><BR><HR><A NAME="2027"></A><H4>2027.
  
Unclear requirements for multiple <TT>alignas</TT> specifiers
</H4><B>Section: </B>7.6.2&#160; [dcl.align]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

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




<P>The description of <I>alignment-specifier</I>s is unclear.  For
example, 7.6.2 [dcl.align] bullet 2.2 says,</P>

<BLOCKQUOTE>

if the constant expression evaluates to a fundamental alignment, the
alignment requirement of the declared entity shall be the specified
fundamental alignment

</BLOCKQUOTE>

<P>However, paragraph 4 says,</P>

<BLOCKQUOTE>

When multiple <I>alignment-specifier</I>s are specified for an entity, the
alignment requirement shall be set to the strictest specified alignment.

</BLOCKQUOTE>

<P>meaning that a less-strict alignment will be ignored, rather than
being the alignment of the entity, and presumably meaning that no
diagnostic is required for an insufficiently-strict alignment if a
more stringent requirement is also supplied.</P>

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

<OL><LI><P>Change 7.6.2 [dcl.align] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

<P>When the <I>alignment-specifier</I> is of the form
<TT>alignas(</TT> <I>constant-expression</I> <TT>)</TT>:</P>

<UL><LI><P>the <I>constant-expression</I> shall be an integral constant
expression<SPAN style="font-weight:bold;background-color:#A0FFA0">;</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if the constant expression evaluates to a fundamental
alignment, the alignment requirement of the declared entity
shall be the specified fundamental alignment</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if the constant expression evaluates to an extended
alignment and the implementation supports that alignment in
the context of the declaration, the alignment of the
declared entity shall be that alignment</SPAN></P></LI>

<LI><P>if the constant expression <SPAN style="font-weight:bold;background-color:#A0FFA0">does not evaluate to
an alignment value (3.11 [basic.align]), or</SPAN>
evaluates to an extended alignment and the implementation
does not support that alignment in the context of the
declaration, the program is ill-formed<SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if the constant expression evaluates to zero, the alignment
specifier shall have no effect</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">otherwise, the program is ill-formed.</SPAN></P></LI>

</UL>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">When multiple <I>alignment-specifier</I>s are specified
for an entity, the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The</SPAN> alignment
requirement <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall be set to</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">of an entity
is</SPAN> the strictest <SPAN style="text-decoration:line-through;background-color:#FFA0A0">specified</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">non-zero</SPAN> alignment
<SPAN style="font-weight:bold;background-color:#A0FFA0">specified by its <I>alignment-specifier</I>s, if any; otherwise,
the <I>alignment-specifier</I>s have no effect</SPAN>.

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2031"></A><H4>2031.
  
Missing incompatibility for <TT>&amp;&amp;</TT>
</H4><B>Section: </B>C.2.3&#160; [diff.cpp03.expr]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Melissa Mears
 &#160;&#160;&#160;

 <B>Date: </B>2014-10-31


<P>The introduction of rvalue references in C++11 changed the
interpretation of some previously well-formed examples such as
the following:</P>

<PRE>
  struct Struct { template &lt;typename T&gt; operator T(); };
  bool example_1 = new int &amp;&amp; false;               //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
  bool example_2 = &amp;Struct::operator int &amp;&amp; false; //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
</PRE>

<P>Previously the <TT>&amp;&amp;</TT> was interpreted as an operator,
while it is now part of a <I>type-name</I>.  However, this change is
not mentioned in Annex C [diff].</P>

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

<P>Add the following as a new subsection in C.2.3 [diff.cpp03.expr]:</P>

<BLOCKQUOTE>

<P>5.15 [expr.log.or]<BR>
<B>Change:</B> <TT>&amp;&amp;</TT> is valid in a <I>type-name</I><BR>
<B>Rationale:</B> Required for new features<BR>
<B>Effect on original feature:</B> Valid C++ 2003 code may fail to
compile or produce different results in this International
Standard, as the following example illustrates:</P>

<PRE>
  bool b1 = new int &amp;&amp; false;           //<SPAN style="font-family:Times;font-style:italic"> previously </SPAN>false<SPAN style="font-family:Times;font-style:italic">, now ill-formed</SPAN>
  struct S { operator int(); };
  bool b2 = &amp;S::operator int &amp;&amp; false;  //<SPAN style="font-family:Times;font-style:italic"> previously </SPAN>false<SPAN style="font-family:Times;font-style:italic">, now ill-formed</SPAN>
</PRE>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2052"></A><H4>2052.
  
Template argument deduction vs overloaded operators
</H4><B>Section: </B>13.5&#160; [over.oper]
 &#160;&#160;&#160;

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

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

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




<P>In an example like</P>

<PRE>
  struct A { operator int(); };
  template&lt;typename T&gt; T operator&lt;&lt;(T, int);
  void f(A a) { 1 &lt;&lt; a; }
</PRE>

<P>Template argument deduction succeeds for the operator template,
producing the signature <TT>operator&lt;&lt;(int,int)</TT>.  The
resulting declaration is synthesized and added to the overload
set, per 14.8.3 [temp.over] paragraph 1.  However, this
violates the requirement of 13.5 [over.oper] paragraph 6,</P>

<BLOCKQUOTE>

An operator function shall either be a non-static member
function or be a non-member function that has at least one
parameter whose type is a class, a reference to a class, an
enumeration, or a reference to an enumeration.

</BLOCKQUOTE>

<P>This is not a SFINAE context, so the program is
ill-formed, rather than selecting the built-in operator.</P>

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

<P>Change 14.8.3 [temp.over] paragraph 1 as follows,</P>

<BLOCKQUOTE>

...If, for a given function template, argument deduction fails
<SPAN style="font-weight:bold;background-color:#A0FFA0">or the synthesized function template specialization
would be ill-formed</SPAN>, no such function is added to the
set of candidate functions for that template.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2075"></A><H4>2075.
  
Passing short initializer lists to array reference parameters
</H4><B>Section: </B>13.3.3.1.5&#160; [over.ics.list]
 &#160;&#160;&#160;

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

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

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




<P>According to 13.3.3.1.5 [over.ics.list] paragraph 5 says,</P>

<BLOCKQUOTE>

Otherwise, if the parameter type is &#8220;array of <TT>N</TT>
<TT>X</TT>&#8221;, if the initializer list has
exactly <TT>N</TT> elements or if it has fewer than <TT>N</TT>
elements and <TT>X</TT> is default-constructible, and if all the
elements of the initializer list can be implicitly converted
to <TT>X</TT>, the implicit conversion sequence is the worst
conversion necessary to convert an element of the list to <TT>X</TT>.

</BLOCKQUOTE>

<P>There are terminological problems with this formulation.
&#8220;Default constructible&#8221; is not otherwise used in the
Standard and should instead refer to an implicit conversion
sequence from an empty <I>braced-init-list</I>.  Similarly,
&#8220;can be implicitly converted&#8221; should instead refer to the
existence of an implicit conversion sequence.</P>

<P><B>Proposed resolution, May, 2015:</B></P>

<P>Replace the indicated wording with:</P>

<BLOCKQUOTE>

Otherwise, if the parameter type is &#8220;array of <TT>N</TT>
<TT>X</TT>,&#8221; if there exists an implicit conversion sequence
for each element of the array from the corresponding element of the
initializer list (or from <TT>{}</TT> if there is no such element),
the implicit conversion sequence is the worst such implicit
conversion sequence.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2101"></A><H4>2101.
  
Incorrect description of type- and value-dependence
</H4><B>Section: </B>14.6.2&#160; [temp.dep]
 &#160;&#160;&#160;

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

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

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




<P>According to 14.6.2 [temp.dep] paragraph 1,</P>

<BLOCKQUOTE>

Expressions may be <I>type-dependent</I> (on the type of a
template parameter) or <I>value-dependent</I> (on the value
of a non-type template parameter).

</BLOCKQUOTE>

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

<P>Change 14.6.2 [temp.dep] paragraph 1 to read,</P>

<BLOCKQUOTE>

An expression may be <I>type-dependent</I> (that is, its
type may depend on a template parameter)
or <I>value-dependent</I> (that is, its value when evaluated
as a constant expression (5.20 [expr.const]) may
depend on a template parameter) as described in this
subclause."

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2120"></A><H4>2120.
  
Array as first non-static data member in standard-layout class
</H4><B>Section: </B>9&#160; [class]
 &#160;&#160;&#160;

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

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

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


<P>The specification for determining whether a derived class
is a standard-layout class, considering the types of its bases
and those associated with its initial member, overlooked the
case of a class whose first member is an array.</P>

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

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

<BLOCKQUOTE>

<P>...<I>M</I>(<TT>X</TT>) is defined as follows:</P>

<UL><LI><P>If <TT>X</TT> is a non-union class type, the
set <I>M</I>(<TT>X</TT>) is empty if
<TT>X</TT> has no (possibly inherited (Clause
10 [class.derived])) non-static data members;
otherwise, it consists of the type of the first non-static
data member of <TT>X</TT> (where said member may be an anonymous
union), <TT>X<SUB>0</SUB></TT>, and the elements of
<I>M</I>(<TT>X<SUB>0</SUB></TT>).</P></LI>

<LI><P>If <TT>X</TT> is a union type, the set <I>M</I>(<TT>X</TT>) is
the union of all <I>M</I>(<TT>U</TT><SUB><I>i</I></SUB>) and the set
containing all <TT>U</TT><SUB><I>i</I></SUB>, where each
<TT>U</TT><SUB><I>i</I></SUB> is the type of the <I>i</I>th
non-static data member of <TT>X</TT>.</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>X</TT> is an array type with element type
<TT>X<SUB>e</SUB></TT>, the set <I>M</I>(<TT>X</TT>) consists of
<TT>X<SUB>e</SUB></TT> and the elements of
<I>M</I>(<TT>X<SUB>e</SUB></TT>).</SPAN></P></LI>

<LI><P>If <TT>X</TT> is a non-class<SPAN style="font-weight:bold;background-color:#A0FFA0">, non-array</SPAN> type, the
set <I>M</I>(<TT>X</TT>) is empty.</P></LI>

</UL>

<P>[<I>Note:</I> <I>M</I>(<TT>X</TT>) is the set of the types of all
non-base-class subobjects that are guaranteed in a
standard-layout class to be at a zero offset in
<TT>X</TT>. &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

<BR><BR></BODY>
</HTML>
