<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core "ready" Issues
   </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
       &#160;P0519R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2016-11-11</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
     for the
     November, 2016 (Issaquah) 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="1395"></A><H4>1395.
  
Partial ordering of variadic templates reconsidered
</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>John Spicer
 &#160;&#160;&#160;

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




<P>The resolution of issue 692 (found in
document N3281) made the following example ambiguous and thus
ill-formed:</P>

<PRE>
    template&lt;class T&gt;
    void print(ostream &amp;os, const T &amp;t) {
        os &lt;&lt; t;
    }

    template &lt;class T, class... Args&gt;
    void print(ostream &amp;os, const T &amp;t, const Args&amp;... rest) {
        os &lt;&lt; t &lt;&lt; ", ";
        print(os, rest...);
    }

    int main() {
        print(cout, 42);
        print(cout, 42, 1.23);
    }
</PRE>

<P>This pattern seems fairly intuitive; is it reason to reconsider or
modify the outcome of issue 692?</P>

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

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

<P>CWG agreed that the example should be accepted, handling this case
as a late tiebreaker, preferring an omitted parameter over a parameter
pack.</P>

<P><B>Additional note (March, 2013):</B></P>

<P>For another example:</P>

<PRE>
  template&lt;typename ...T&gt; int f(T*...) {
    return 1;
  }
  template&lt;typename T&gt; int f(const T&amp;) {
    return 2;
  }
  int main() {
    if (f((int*)0) != 1) {
       return 1;
    }
    return 0;
  }
</PRE>

<P>This worked as expected prior to the resolution of
issue 692.</P>

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

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

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">If <TT>A</TT> was transformed from a function parameter pack
and <TT>P</TT> is not a parameter pack, type deduction fails.  Otherwise,
using</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Using</SPAN> the resulting types <TT>P</TT> and <TT>A</TT>,
the deduction is then done as described in
14.8.2.5 [temp.deduct.type]. If <TT>P</TT> is a function parameter pack,
the type <TT>A</TT> of each remaining parameter type of the argument
template is compared with the type <TT>P</TT> of the <I>declarator-id</I>
of the function parameter pack. Each comparison deduces template arguments
for subsequent positions in the template parameter packs expanded by the
function parameter pack. <SPAN style="font-weight:bold;background-color:#A0FFA0">Similarly, if <TT>A</TT> was transformed from a
function parameter pack, it is compared with each remaining parameter type
of the parameter template.</SPAN> If deduction succeeds for a given type,
the type from the argument template is considered to be at least as
specialized as the type from the parameter template. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Add the following as a new paragraph following
14.8.2.4 [temp.deduct.partial] paragraph 10:</P></LI>

<BLOCKQUOTE>

<P>Function template <TT>F</TT> is at least as specialized as function
template <TT>G</TT> if, for each pair of types used to determine the
ordering, the type from <TT>F</TT> is at least as specialized as the type
from <TT>G</TT>. <TT>F</TT> is more specialized than <TT>G</TT>
if <TT>F</TT> is at least as specialized as <TT>G</TT> and <TT>G</TT> is
not at least as specialized as <TT>F</TT>.</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If, after considering the above, function template <TT>F</TT> is at
least as specialized as function template <TT>G</TT> and vice-versa, and if
<TT>G</TT> has a trailing paramter pack for which <TT>F</TT> does not have a
corresponding parameter, and if <TT>F</TT> does not have a trailing
parameter pack, then <TT>F</TT> is more specialized
than <TT>G</TT>. </SPAN></P>

</BLOCKQUOTE>

</OL>

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

<BR><BR><HR><A NAME="1825"></A><H4>1825.
  
Partial ordering between variadic and non-variadic function templates
</H4><B>Section: </B>14.8.2.4&#160; [temp.deduct.partial]
 &#160;&#160;&#160;

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

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

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




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

<PRE>
  template &lt;class ...T&gt; int f(T*...)  { return 1; }
  template &lt;class T&gt;  int f(const T&amp;) { return 2; }
  void g() {
    f((int*)0);
  }
</PRE>

<P>the current specification makes the call ambiguous
because deduction fails in both directions: with A
being <TT>T</TT> and P being <TT>T*</TT> in one direction
and A being <TT>T*</TT> and P being <TT>T</TT>, because
14.8.2.4 [temp.deduct.partial] paragraph 8 says,</P>

<BLOCKQUOTE>

If A was transformed from a function parameter pack and P is
not a parameter pack, type deduction fails.

</BLOCKQUOTE>

<P>It is not clear whether this is the best outcome, however; it
might be better to consider the first template more specialized,
with the variadic/non-variadic test being a tie-breaker if there
is no other reason to prefer one over the other based on the
parameter types.</P>

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

<P>CWG felt that the best approach would be, when comparing <TT>P</TT>
and <TT>A</TT>, if <TT>A</TT> is a pack and <TT>P</TT> is not, <TT>A</TT>
should be repeated for each remaining instance of <TT>P</TT> and then use
the variadic/nonvariadic criterion as a late tiebreaker if the result is
still ambiguous.  This would apply in the general case (including
14.8.2.4 [temp.deduct.partial]), not just in function calls.</P>

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

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

<BR><BR><HR><A NAME="1961"></A><H4>1961.
  
Potentially-concurrent actions within a signal handler
</H4><B>Section: </B>1.10&#160; [intro.multithread]
 &#160;&#160;&#160;

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

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

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




<P>According to 1.10 [intro.multithread] paragraph 23,</P>

<BLOCKQUOTE>

<P>Two actions are <I>potentially concurrent</I> if</P>

<UL><LI><P>they are performed by different threads, or</P></LI>

<LI><P>they are unsequenced, and at least one is performed by a
signal handler.</P></LI>

</UL>

</BLOCKQUOTE>

<P>This definition should exclude the case when both actions
are performed by a signal handler.</P>

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

<P>SG1 agrees that the existing wording should be amended to
say something like &#8220;and they are not both performed by
the same signal handler invocation.&#8221;</P>

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

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

<BLOCKQUOTE>

<P>Two actions are <I>potentially concurrent</I> if</P>

<UL><LI><P>they are performed by different threads, or</P></LI>

<LI><P>they are unsequenced, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN> at least one is performed by a
signal handler<SPAN style="font-weight:bold;background-color:#A0FFA0">, and they are not both performed by the
same signal handler invocation</SPAN>.</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2143"></A><H4>2143.
  
Value-dependency via injected-class-name
</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>Maxim Kartashev
 &#160;&#160;&#160;

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




<P>There does not appear to be a rule that causes <TT>p</TT>
or <TT>this</TT> to be dependent in the following example:</P>

<PRE>
  template &lt;typename T&gt; struct A {
     void foo() {
        A* p = 0;
        bar(p);    //<SPAN style="font-family:Times;font-style:italic"> will be found by ADL at the point of instantiation</SPAN>
        bar(this); //<SPAN style="font-family:Times;font-style:italic"> same here</SPAN>
     }
  };

  void bar(...);

  int main() {
     A&lt;int&gt; a;
     a.foo();
  }
</PRE>

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

<P>Change 14.6.2.1 [temp.dep.type] bullet 9.7 as follows:</P>

<BLOCKQUOTE>

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

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

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">an injected-type-name (Clause
9 [class]) of a class template or</SPAN>
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 or is a pack expansion,
or</P></LI>

<LI><P>denoted by...</P></LI>

</UL>

</BLOCKQUOTE>

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

<P>Change 14.6.2.1 [temp.dep.type] bullet 9.7 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 or is a pack expansion
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> This includes an
injected-class-name (Clause 9 [class]) of a class
template used without a <I>template-argument-list</I>.
&#8212;<I>end note</I>]</SPAN>, or</P></LI>

<LI><P>denoted by...</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2155"></A><H4>2155.
  
Defining classes and enumerations via <I>using-declaration</I>s
</H4><B>Section: </B>7.3.1.2&#160; [namespace.memdef]
 &#160;&#160;&#160;

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

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

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


<P>The resolution of issue 1838 was
intended to resolve issue 1021 but does
not actually do so, as it applies only to declarations with a
<I>declarator-id</I>, which is not true of classes and enumerations.
</P>

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

<OL><LI><P>Change 7.3.1.2 [namespace.memdef] paragraph 1 as
follows:</P></LI>

<BLOCKQUOTE>

A declaration in a namespace <TT>N</TT> (excluding declarations in
nested scopes) whose <I>declarator-id</I> is
an <I>unqualified-id</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">(8.3 [dcl.meaning]), whose
<I>class-head-name</I> (Clause 9 [class]) or
<I>enum-head-name</I> (7.2 [dcl.enum]) is an
<I>identifier</I>, or whose <I>elaborated-type-specifier</I> is
of the form <I>class-key attribute-specifier-seq<SUB>opt</SUB>
identifier</I> (7.1.6.3 [dcl.type.elab]), or that is an
<I>opaque-enum-declaration</I>,</SPAN> declares (or redeclares)
<SPAN style="font-weight:bold;background-color:#A0FFA0">its <I>unqualified-id</I> or <I>identifier</I> as</SPAN> a member
of <TT>N</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">, and may be a definition</SPAN>. [<I>Note:</I>...

</BLOCKQUOTE>

<LI><P>Change the grammar of 7.2 [dcl.enum] as follows:</P></LI>

<UL><I>enum-head</I>:
<UL><I>enum-key attribute-specifier-seq<SUB>opt</SUB> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">identifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">enum-head-name</SPAN><SUB>opt</SUB> enum-base<SUB>opt</SUB></I><BR>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>enum-key attribute-specifier-seq<SUB>opt</SUB> nested-name-specifier identifier enum-base<SUB>opt</SUB></I></SPAN>
</UL>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>enum-head-name:</I></SPAN>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>nested-name-specifier<SUB>opt</SUB> identifier</I></SPAN>
</UL>
</UL>

</OL>

<BR><BR><HR><A NAME="2271"></A><H4>2271.
  
Aliasing <TT>this</TT>
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-06-20


<P>The restrictions against aliasing <TT>this</TT> inside a constructor
should apply to all objects, not just to const objects.</P>

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

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

<BLOCKQUOTE>

<P>During the construction of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a <TT>const</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an</SPAN>
object, if the value of the object or any of its subobjects is accessed
through a glvalue that is not obtained, directly or indirectly, from the
constructor's <TT>this</TT> pointer, the value of the object or subobject
thus obtained is unspecified. [<I>Example:</I></P>

<PRE>
  struct C;
  void no_opt(C*);

  struct C {
    int c;
    C() : c(0) { no_opt(this); }
  };

  const C cobj;

  void no_opt(C* cptr) {
    int i = cobj.c * 100; //<SPAN style="font-family:Times;font-style:italic"> value of </SPAN>cobj.c<SPAN style="font-family:Times;font-style:italic"> is unspecified</SPAN>
    cptr-&gt;c = 1;
    cout &lt;&lt; cobj.c * 100  //<SPAN style="font-family:Times;font-style:italic"> value of </SPAN>cobj.c<SPAN style="font-family:Times;font-style:italic"> is unspecified</SPAN>
         &lt;&lt; '\n';
  }

<SPAN style="font-weight:bold;background-color:#A0FFA0">  extern struct D d;
  struct D {
    D(int a) : a(a), b(d.a) {}
    int a, b;
  };
  D d = D(1);             //<SPAN style="font-family:Times;font-style:italic"> value of </SPAN>d.b<SPAN style="font-family:Times;font-style:italic"> is unspecified</SPAN></SPAN>
</PRE>

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

</BLOCKQUOTE>

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