<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;P0384R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2016-05-30</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 "tentatively ready" Issues
     for the
     June, 2016 (Oulu) 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 N4582</A>.
   </P>
<HR><A NAME="1861"></A><H4>1861.
  
Values of a bit-field
</H4><B>Section: </B>9.6&#160; [class.bit]
 &#160;&#160;&#160;

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

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

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




<P>The resolution of issue 1816 left many
aspects of bit-fields unspecified, including whether a signed bit field
has a sign bit and the meaning of the bit-field width. Also, the
requirement in 3.9.1 [basic.fundamental] paragraph 1 that</P>

<BLOCKQUOTE>

For narrow character types, all bits of the object representation
participate in the value representation.

</BLOCKQUOTE>

<P>should not apply to oversize character-typed bit-fields.</P>

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

<P>CWG decided to address only the issue of oversized bit-fields of
narrow character types at this time, splitting off the more general
questions regarding bit-fields to issue 1943.</P>

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

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

<BLOCKQUOTE>

...For narrow character types, all bits of the object
representation participate in the value representation.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> A bit-field of narrow character type
whose length is larger than the number of bits in the object
representation of that type has padding bits; see
9.6 [class.bit]. &#8212;<I>end note</I>]</SPAN> For
unsigned narrow character types, each possible bit pattern
of the value representation represents a distinct number...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2022"></A><H4>2022.
  
Copy elision in 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>Jason Merrill
 &#160;&#160;&#160;

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




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

<PRE>
  struct A {
    void *p;
    constexpr A(): p(this) {}
  };

  constexpr A a;		//<SPAN style="font-family:Times;font-style:italic"> well-formed</SPAN>
  constexpr A b = A();          //<SPAN style="font-family:Times;font-style:italic"> ?</SPAN>
</PRE>

<P>The declaration of <TT>a</TT> seems well-formed because the address
of <TT>a</TT> is constant.</P>

<P>The declaration of <TT>b</TT>, however, seems to depend on whether
copy elision is performed.  If it is, the declaration is the equivalent
of <TT>a</TT>; if not, however, this creates a temporary and initializes
<TT>p</TT> to the address of that temporary, making the initialization
non-constant and the declaration ill-formed.</P>

<P>It does not seem desirable for the well-formedness of the program
to depend on whether the implementation performs an optional copy
elision.</P>

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

<P>CWG decided to leave it unspecified whether copy elision is
performed in cases like this and to add a note to
12.8 [class.copy] to make clear that that outcome is
intentional.</P>

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

<P>CWG agreed that copy elision should be mandatory in constant
expressions.</P>

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

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

<BLOCKQUOTE>

...Expressions that satisfy these requirements<SPAN style="font-weight:bold;background-color:#A0FFA0">, assuming
that copy elision is performed,</SPAN> are called
<I>constant expressions</I>. [<I>Note:</I>...

</BLOCKQUOTE>

<LI><P>Change 7.1.5 [dcl.constexpr] paragraph 7 as follows,
breaking the existing running text into a bulleted list:</P></LI>

<BLOCKQUOTE>

<P>A call to a <TT>constexpr</TT> function produces the same result as a
call to an equivalent non-<TT>constexpr</TT> function in all respects
except that</P>

<UL><LI>

<P>a call to a <TT>constexpr</TT> function can appear in a constant
expression <SPAN style="font-weight:bold;background-color:#A0FFA0">(5.20 [expr.const]) and</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">copy elision is mandatory in a constant expression
(12.8 [class.copy])</SPAN>.</P></LI>

</UL>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

<P>...This elision of copy/move operations, called copy elision,
is permitted in the following circumstances (which may be
combined to eliminate multiple copies):</P>

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

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">Copy elision is required where an expression is
evaluated in a context requiring a constant expression
(5.20 [expr.const]) and in constant initialization
(3.6.2 [basic.start.static]). [<I>Note:</I> Copy elision
might not be performed if the same expression is evaluated
in another context. &#8212;<I>end note</I>]</SPAN>
[<I>Example:</I></P>

<PRE>
  class Thing {
  public:
    Thing();
    ~Thing();
    Thing(const Thing&amp;);
  };

  Thing f() {
    Thing t;
    return t;
  }

  Thing t2 = f();

<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct A {
    void *p;
    constexpr A(): p(this) {}
  };

  constexpr A a;        //<SPAN style="font-family:Times;font-style:italic"> well-formed, </SPAN>a.p<SPAN style="font-family:Times;font-style:italic"> points to </SPAN>a
  constexpr A b = A();  //<SPAN style="font-family:Times;font-style:italic"> well-formed, </SPAN>b.p<SPAN style="font-family:Times;font-style:italic"> points to </SPAN>b

  void g() {
    A c = A();          //<SPAN style="font-family:Times;font-style:italic"> well-formed, </SPAN>c.p<SPAN style="font-family:Times;font-style:italic"> may point to </SPAN>c<SPAN style="font-family:Times;font-style:italic"> or to an ephemeral temporary</SPAN>
  }</SPAN>
</PRE>

<P>Here the criteria for elision can be combined...</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2076"></A><H4>2076.
  
List-initialization of arguments for constructor parameters
</H4><B>Section: </B>13.3.3.1&#160; [over.best.ics]
 &#160;&#160;&#160;

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

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

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




<P>The resolution of issue 1467 made
some plausible constructs ill-formed.  For example,</P>

<PRE>
   struct A { A(int); };
   struct B { B(A); };
   B b{{0}};
</PRE>

<P>This is now ambiguous, because the text disallowing 
user-defined conversions for <TT>B</TT>'s copy and move
constructors was removed from 13.3.3.1 [over.best.ics]
paragraph 4.  Another example:</P>

<PRE>
  struct Params { int a; int b; };
  class Foo {
  public:
    Foo(Params);
  };
  Foo foo{{1, 2}};
</PRE>

<P>This is now ambiguous between <TT>Foo(Params)</TT> and
<TT>Foo(Foo&amp;&amp;)</TT>.</P>

<P>For non-class types, we allow initialization from a
single-item list to perform a copy only if the element
within the list is not itself a list
(13.3.3.1.5 [over.ics.list] bullet 9.1).  The analogous
rule for this case would be to add back the bullet in
13.3.3.1 [over.best.ics] paragraph 4, but only in the
case where the initializer is itself an initializer list:</P>

<BLOCKQUOTE>

the second phase of 13.3.1.7 [over.match.list]
when the initializer list has exactly one
element <SPAN style="font-weight:bold;background-color:#A0FFA0">that is itself an initializer list</SPAN>, where the
target is the first parameter of a constructor of class <TT>X</TT>,
and the conversion is to <TT>X</TT> or reference to (possibly
cv-qualified) <TT>X</TT>,

</BLOCKQUOTE>

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

<P>Change 13.3.3.1 [over.best.ics] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>...and the constructor or user-defined conversion function is a
candidate by</P>

<UL><LI><P>13.3.1.3 [over.match.ctor], when the argument is
the temporary in the second step of a class
copy-initialization, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN></P></LI>

<LI><P>13.3.1.4 [over.match.copy],
13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref]
(in all cases), <SPAN style="font-weight:bold;background-color:#A0FFA0">or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">the second phase of 13.3.1.7 [over.match.list] when the
initializer list has exactly one element that is itself an initializer
list, and the target is the first parameter of a constructor of
class <TT>X</TT>, and the conversion is to <TT>X</TT> or reference to
(possibly cv-qualified) <TT>X</TT>,</SPAN></P></LI>

</UL>

<P>user-defined conversion sequences are not
considered. [<I>Note:</I>...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2091"></A><H4>2091.
  
Deducing reference non-type template arguments
</H4><B>Section: </B>14.8.2.5&#160; [temp.deduct.type]
 &#160;&#160;&#160;

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

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

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




<P>According to 14.8.2.5 [temp.deduct.type] paragraph 17,</P>

<BLOCKQUOTE>

If <TT>P</TT> has a form that contains <TT>&lt;i&gt;</TT>,
and if the type of the corresponding value of <TT>A</TT>
differs from the type of <TT>i</TT>, deduction fails.

</BLOCKQUOTE>

<P>This gives the wrong result for an example like:</P>

<PRE>
  template&lt;int &amp;&gt; struct X;
  template&lt;int &amp;N&gt; void f(X&lt;N&gt;&amp;);
  int n;
  void g(X&lt;n&gt; &amp;x) { f(x); }
</PRE>

<P>Here, <TT>P</TT> is <TT>X&lt;N&gt;</TT>, which contains
<TT>&lt;i&gt;</TT>.  The type of <TT>i</TT> is <TT>int&amp;</TT>.
The corresponding value from <TT>A</TT> is <TT>n</TT>, which is a
glvalue of type <TT>int</TT>.  Presumably this should be valid.</P>

<P>I think this rule means to say something like,</P>

<BLOCKQUOTE>

If <TT>P</TT> has a form that contains <TT>&lt;i&gt;</TT>, and the type
of <TT>i</TT> differs from the type of the corresponding template
parameter of the template named by the enclosing <I>simple-template-id</I>,
deduction fails.

</BLOCKQUOTE>

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

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

<BLOCKQUOTE>

If <TT>P</TT> has a form that contains <TT>&lt;i&gt;</TT>,
and if the type of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the corresponding value
of <TT>A</TT> differs from the type
of</SPAN> <TT>i</TT> <SPAN style="font-weight:bold;background-color:#A0FFA0">differs from the type of the
corresponding template parameter of the template named by
the enclosing <I>simple-template-id</I></SPAN>, deduction
fails. If <TT>P</TT> has a form that
contains <TT>[i]</TT>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2137"></A><H4>2137.
  
List-initialization from object of same type
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

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

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

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




<P>It is not clear in code like the following that selecting
a copy/move constructor is the correct choice when an
initializer list contains a single element of the type
being initialized, as required by issue 1467:</P>

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

  struct Q {
    Q() { std::cout &lt;&lt; "default\n"; }
    Q(Q const&amp;) { std::cout &lt;&lt; "copy\n"; }
    Q(Q&amp;&amp;) { std::cout &lt;&lt; "move\n"; }
    Q(std::initializer_list&lt;Q&gt;) { std::cout &lt;&lt; "initializer list\n"; }
  };

  int main() {
    Q x = Q { Q() };
  }
</PRE>

<P>Here the intent is that <TT>Q</TT> objects can contain
other <TT>Q</TT> objects, but this is broken by the
resolution of issue 1467.</P>

<P>Perhaps the presence of an initializer-list constructor
should change the outcome?</P>

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

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

<BLOCKQUOTE>

List-initialization of an object or reference of
type <TT>T</TT> is defined as follows:

<UL><LI>

<P>If <TT>T</TT> is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a class type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an
aggregate class</SPAN> and the initializer list has a single
element of type <I>cv</I> <TT>U</TT>, where <TT>U</TT>
is <TT>T</TT> or a class derived from
<TT>T</TT>, the object is initialized from that element (by
copy-initialization for copy-list-initialization, or by
direct-initialization for
direct-list-initialization).</P></LI>

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

</UL>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

If the parameter type is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an
aggregate</SPAN> class <TT>X</TT> and the initializer list
has a single element of type <I>cv</I> <TT>U</TT>,
where <TT>U</TT> is <TT>X</TT> or a class derived
from <TT>X</TT>, the implicit conversion sequence is the one
required to convert the element to the parameter type.

</BLOCKQUOTE>

<LI><P>Change 13.3.3.1.5 [over.ics.list] paragraph 6 as
follows, breaking the existing running text into a bulleted list:</P></LI>

<BLOCKQUOTE>

<P>Otherwise, if the parameter is a non-aggregate
class <TT>X</TT> and overload resolution per
13.3.1.7 [over.match.list] chooses a single best
constructor <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>C</TT></SPAN> of <TT>X</TT> to perform
the initialization of an object of type <TT>X</TT> from the
argument initializer <SPAN style="text-decoration:line-through;background-color:#FFA0A0">list,</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">list:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>C</TT> is not an initializer-list
constructor and the initializer list has a single element of
type <I>cv</I> <TT>U</TT>, where <TT>U</TT> is <TT>X</TT> or
a class derived from <TT>X</TT>, the implicit conversion
sequence has Exact Match rank if <TT>U</TT> is <TT>X</TT>,
or Conversion rank if <TT>U</TT> is derived
from <TT>X</TT></SPAN></P></LI>

<LI>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">Otherwise,</SPAN> the implicit conversion sequence is a user-defined
conversion sequence with the second standard conversion
sequence an identity conversion.</P></LI>

</UL>

<P>If multiple constructors are viable...</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2145"></A><H4>2145.
  
Parenthesized declarator in function definition
</H4><B>Section: </B>8.4.1&#160; [dcl.fct.def.general]
 &#160;&#160;&#160;

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

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

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




<P>According to 8.4.1 [dcl.fct.def.general] paragraph 2,</P>

<BLOCKQUOTE>

<P>The <I>declarator</I> in a <I>function-definition</I> shall have
the form</P>

<UL><TT>D1 (</TT> <I>parameter-declaration-clause</I> <TT>)</TT> <I>cv-qualifier-seq<SUB>opt</SUB></I>
<UL><I>ref-qualifier<SUB>opt</SUB> exception-specification<SUB>opt</SUB> attribute-specifier-seq<SUB>opt</SUB> trailing-return-type<SUB>opt</SUB></I></UL>
</UL>

</BLOCKQUOTE>

<P>However, in practice implementations accept a parenthesized
declarator in a function definition.</P>

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

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

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The <I>declarator</I> in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">In</SPAN> a <I>function-definition</I><SPAN style="text-decoration:line-through;background-color:#FFA0A0"> shall have
the form</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN></P>

<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>D1</TT> <I>parameters-and-qualifiers trailing-return-type<SUB>opt</SUB></I></SPAN></UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">either <TT>void</TT> <I>declarator</I> <TT>;</TT> or
<I>declarator</I> <TT>;</TT> shall be a well-formed function
declarator</SPAN> as described in
8.3.5 [dcl.fct]. A function shall be defined only
in namespace or class scope.</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2171"></A><H4>2171.
  
Triviality of copy constructor with less-qualified parameter
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

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

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

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




<P>Issue 1333 says that a defaulted
copy constructor with a less-const-qualified parameter type than
the implicit declaration is non-trivial.  This is inconsistent
with the usual pattern that whether a special member function
is callable is separate from whether it is trivial; the different
declaration only affects whether you can call it with a <TT>const</TT>
argument, it doesn't affect the operations involved.  Should this
outcome be reconsidered?</P>

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

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

<BLOCKQUOTE>

A copy/move constructor for class <TT>X</TT> is trivial if it is not
user-provided<SPAN style="text-decoration:line-through;background-color:#FFA0A0">, its parameter-type-list is equivalent to the
parameter-type-list of an implicit declaration,</SPAN> and if...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

A copy/move assignment operator for class <TT>X</TT> is trivial if it
is not user-provided<SPAN style="text-decoration:line-through;background-color:#FFA0A0">, its parameter-type-list is equivalent
to the parameter-type-list of an implicit declaration,</SPAN> and
if...

</BLOCKQUOTE>

</OL>

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