<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;P0576R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2017-02-06</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
     February, 2016 (Kona) 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/2016/n4606.pdf">WG21 N4606</A>.
   </P>
<HR><A NAME="2194"></A><H4>2194.
  
Impossible case in list initialization
</H4><B>Section: </B>13.3.1.7&#160; [over.match.list]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Robert Haberlach
 &#160;&#160;&#160;

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


<P>According to 13.3.1.7 [over.match.list] paragraph 1 says,</P>

<BLOCKQUOTE>

If the initializer list has no elements and <TT>T</TT> has a default
constructor, the first phase is omitted.

</BLOCKQUOTE>

<P>However, this case cannot occur. If <TT>T</TT> is a non-aggregate
class type with a default constructor and the initializer is an
empty initializer list, the object will be value-constructed, per
8.6.4 [dcl.init.list] bullet 3.4. Overload resolution is only
necessary if default-initialization (or a check of its semantic
constraints) is implied, with the relevant section concerning
candidates for overload resolution being 13.3.1.3 [over.match.ctor].</P>

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

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

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

<BLOCKQUOTE>

<P>When objects of non-aggregate class type <TT>T</TT> are list-initialized
such that 8.6.4 [dcl.init.list] specifies that overload resolution is
performed according to the rules in this section, overload resolution
selects the constructor in two phases:</P>

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

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

</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the initializer list has no elements and <TT>T</TT> has a
default constructor, the first phase is omitted.</SPAN> In
copy-list-initialization, if an explicit constructor is chosen...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2198"></A><H4>2198.
  
Linkage of enumerators
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

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

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

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




<P>According to the rules in 3.5 [basic.link] paragraph 4,
the enumerators of an enumeration type with linkage also have linkage.
Having same-named enumerators in different translation units
would seem to be innocuous. Is there a rationale for this rule?</P>

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

<P>Delete 3.5 [basic.link] bullet 4.5:</P>

<BLOCKQUOTE>

<P>An unnamed namespace or a namespace declared directly or indirectly within
an unnamed namespace has internal linkage. All other namespaces have
external linkage. A name having namespace scope that has not been given
internal linkage above has the same linkage as the enclosing namespace if
it is the name of</P>

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

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">an enumerator belonging to an enumeration with linkage;
or</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2201"></A><H4>2201.
  
Cv-qualification of array types
</H4><B>Section: </B>3.9.3&#160; [basic.type.quali&#64257;er]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Robert Haberlach
 &#160;&#160;&#160;

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


<P>Issue 1059 changed 3.9.3 [basic.type.quali&#64257;er]
paragraph 6 to read,</P>

<BLOCKQUOTE>

An array type whose elements are cv-qualified is also considered to have
the same cv-qualifications as its elements.

</BLOCKQUOTE>

<P>However, that change overlooked the earlier statement in paragraph
2,</P>

<BLOCKQUOTE>

A compound type (3.9.2 [basic.compound]) is not cv-qualified by the
cv-qualifiers (if any) of the types from which it is compounded. Any
cv-qualifiers applied to an array type affect the array element type, not
the array type (8.3.4 [dcl.array]).

</BLOCKQUOTE>

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

<P>Change 3.9.3 [basic.type.quali&#64257;er] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A compound type (3.9.2 [basic.compound]) is not cv-qualified by the
cv-qualifiers (if any) of the types from which it is compounded. Any
cv-qualifiers applied to an array type affect the array element type<SPAN style="text-decoration:line-through;background-color:#FFA0A0">,
not the array type</SPAN> (8.3.4 [dcl.array]).

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2206"></A><H4>2206.
  
Composite type of object and function pointers
</H4><B>Section: </B>5&#160; [expr]
 &#160;&#160;&#160;

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

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

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


<P>Consider an example like</P>

<PRE>
  void *p;
  void (*pf)();
  auto x = true ? p : pf;
</PRE>

<P>The rules in 5 [expr] paragraph 13 say that the composite
type between a <TT>void*</TT> and a function pointer type is
<TT>void*</TT>. This is surprising, since a function pointer type
cannot be implicitly converted to <TT>void*</TT>.</P>

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

<P>Change 5 [expr] bullet 14.5 as follows:</P>

<BLOCKQUOTE>

<P>The <I>cv-combined type</I> of two types <TT>T1</TT> and <TT>T2</TT> is
a type <TT>T3</TT> similar to <TT>T1</TT> whose cv-qualification signature
(4.5 [conv.qual]) is:</P>

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

<LI><P>if <TT>T1</TT> or <TT>T2</TT> is &#8220;pointer to <I>cv1</I>
<TT>void</TT>&#8221; and the other type is &#8220;pointer to <I>cv2</I>
<TT>T</TT>&#8221;, <SPAN style="font-weight:bold;background-color:#A0FFA0">where <TT>T</TT> is an object type or
<TT>void</TT>,</SPAN> &#8220;pointer to <I>cv12</I> <TT>void</TT>&#8221;,
where <I>cv12</I> is the union of <I>cv1</I> and <I>cv2</I>;</P></LI>

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

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2214"></A><H4>2214.
  
Missing requirement on representation of integer values
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

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

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

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


<P>According to 3.9.1 [basic.fundamental] paragraph 3,</P>

<BLOCKQUOTE>

The range of non-negative values of a signed integer type is a subrange of
the corresponding unsigned integer type, and the value representation of
each corresponding signed/unsigned type shall be the same.

</BLOCKQUOTE>

<P>The corresponding wording from C11 is,</P>

<BLOCKQUOTE>

The range of nonnegative values of a signed integer type is a subrange of
the corresponding unsigned integer type, and the representation of the same
value in each type is the same.

</BLOCKQUOTE>

<P>The C wording is arguably clearer, but it loses the implication of
the C++ wording that the sign bit of a signed type is part of the value
representation of the corresponding unsigned type.</P>

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

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

<BLOCKQUOTE>

...The standard and extended unsigned integer types are collectively called
unsigned integer types. The range of non-negative values of a signed
integer type is a subrange of the corresponding unsigned integer
type, <SPAN style="font-weight:bold;background-color:#A0FFA0">the representation of the same value in each of the two types is
the same,</SPAN> and the value representation of each corresponding
signed/unsigned type shall be the same. The standard signed integer
types...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2220"></A><H4>2220.
  
Hiding index variable in range-based <TT>for</TT>
</H4><B>Section: </B>6.5.4&#160; [stmt.ranged]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-01-08


<P>Given an example like</P>

<PRE>
  void f() {
    int arr[] = { 1, 2, 3 };
    for (int val : arr) {
      int val;   //<SPAN style="font-family:Times;font-style:italic"> Redeclares index variable</SPAN>
    }
  }
</PRE>

<P>one might expect that the redeclaration of the index variable would
be an error, as it is in the corresponding classic <TT>for</TT>
statement. However, the restriction that makes the latter an error is
phrased in terms of the <I>condition</I> nonterminal in
6.4 [stmt.select] paragraph 3, and the range-based <TT>for</TT>
does not refer to <I>condition</I>. Should there be an explicit
prohibition of such a redeclaration?</P>

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

<P>Add the following as a new paragraph before 6.5 [stmt.iter]
paragraph 4:</P>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If a name introduced in an <I>init-statement</I>
or <I>for-range-declaration</I> is redeclared in the outermost block of the
substatement, the program is ill-formed. [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  void f() {
    for (int i = 0; i &lt; 10; ++i)
      int i = 0;          //<SPAN style="font-family:Times;font-style:italic"> error: redeclaration</SPAN>
    for (int i : { 1, 2, 3 })
      int i = 1;          //<SPAN style="font-family:Times;font-style:italic"> error: redeclaration</SPAN>
  }</SPAN>
</PRE>

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

<P>[<I>Note:</I> The requirements on conditions in iteration statements are
described in 6.4 [stmt.select]. &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2224"></A><H4>2224.
  
Member subobjects and base-class casts
</H4><B>Section: </B>5.2.9&#160; [expr.static.cast]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Aaron Ballman
 &#160;&#160;&#160;

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




<P>The current wording of 5.2.9 [expr.static.cast] paragraph 2 appears
to permit the following example:</P>

<PRE>
  struct B {
    int i;
  };

  struct D : B {
    int j;
    B b;
  };

  int main() {
    D d;

    B &amp;br = d.b;
    D &amp;dr = static_cast&lt;D&amp;&gt;(br);  //<SPAN style="font-family:Times;font-style:italic"> Okay?</SPAN>
  }
</PRE>

<P>Presumably such casts should only be supported if the operand
object is a base class subobject, not a member subobject.</P>

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

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

<BLOCKQUOTE>

...If the object of type &#8220;<I>cv1</I> <TT>B</TT>&#8221; is actually
a <SPAN style="font-weight:bold;background-color:#A0FFA0">base</SPAN> subobject of an object of type <TT>D</TT>, the result
refers to the enclosing object of type <TT>D</TT>. Otherwise, the behavior
is undefined. [<I>Example:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2259"></A><H4>2259.
  
Unclear context describing ambiguity
</H4><B>Section: </B>8.2&#160; [dcl.ambig.res]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-04-12




<P>According to 8.2 [dcl.ambig.res] paragraph 3,</P>

<BLOCKQUOTE>

Another ambiguity arises in a <I>parameter-declaration-clause</I> of a
function declaration, or in a <I>type-id</I> that is the operand of a
<TT>sizeof</TT> or <TT>typeid</TT> operator, when a <I>type-name</I> is
nested in parentheses.

</BLOCKQUOTE>

<P>There are two problems here: first,
a <I>parameter-declaration-clause</I> appears in
a <I>lambda-expression</I>, not just in a function declaration.  Second,
the ambiguity can arise in a <I>type-id</I> appearing in any context, not
just in a <TT>sizeof</TT> or <TT>typeid</TT> expression.</P>

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

<P>Change 8.2 [dcl.ambig.res] paragraph 3 as follows:</P>

<BLOCKQUOTE>

Another ambiguity arises in a <I>parameter-declaration-clause</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">of a
function declaration, or in a <I>type-id</I> that is the operand of a
<TT>sizeof</TT> or <TT>typeid</TT> operator</SPAN>, when a <I>type-name</I>
is nested in parentheses. In this case, the choice is between the
declaration of a parameter of type pointer to function and the declaration
of a parameter with redundant parentheses around
the <I>declarator-id</I>. The resolution is to consider
the <I>type-name</I> as a <I>simple-type-specifier</I> rather than
a <I>declarator-id</I>. [<I>Example:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2262"></A><H4>2262.
  
Attributes for <I>asm-definition</I>
</H4><B>Section: </B>7.4&#160; [dcl.asm]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-05-04




<P>There does not seem to be a good reason not to permit attributes on
an <TT>asm</TT> declaration. This would be handy for things like:</P>

<PRE>
  [[vendor::asm_syntax("intel")]] asm(...); 
</PRE>

<P><B>Notes from the December, 2016 teleconference:</B>
</P>

<P>The omission seems to have been an oversight that should be corrected.</P>

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

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

<BLOCKQUOTE>

<P>An <TT>asm</TT> declaration has the form</P>

<UL><I>asm-definition:</I>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>attribute-specifier-seq<SUB>opt</SUB></I></SPAN> <TT>asm (</TT> <I>string-literal</I> <TT>) ;</TT></UL>
</UL>

<P>The <TT>asm</TT> declaration is conditionally-supported; its meaning is
implementation-defined. <SPAN style="font-weight:bold;background-color:#A0FFA0">The optional <I>attribute-specifier-seq</I> in
an <I>asm-definition</I> appertains to the <TT>asm</TT> declaration.</SPAN>
[<I>Note:</I> Typically it is used to pass information through the
implementation to an assembler. &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

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