<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>

    C++ Standard Core Language
    
      Closed Issues
     </TITLE>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  .DEL { text-decoration:line-through; background-color: #FFD0D0 }
  @media (prefers-color-scheme: dark) {
    HTML { background-color:#202020; color:#f0f0f0; }
    A { color:#5bc0ff; }
    A:visited { color:#c6a8ff; }
    A:hover, a:focus { color:#afd7ff; }
    INS { background-color:#033a16; color:#aff5b4; }
    .INS { background-color: #033a16; }
    DEL { background-color:#67060c; color:#ffdcd7; }
    .DEL { background-color:#67060c; }
  }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2025-09-12</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 14882:2024
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD>
<TD>
      &#160;Jens Maurer
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;<A HREF="mailto://jens.maurer@gmx.net">jens.maurer@gmx.net</A>
</TD>
</TR>
</TABLE>
<BR CLEAR="ALL"><BR><CENTER><H2>

     C++ Standard Core Language
     
       Closed Issues,
      

     Revision
     118</H2></CENTER>
<BR><P>
      This document contains the C++ core language issues for which the
      Committee (J16 + WG21) has decided that no action is required,
      that is, issues with status
      "<A HREF="#NAD%20Status">NAD</A>" ("Not A Defect"),
      "<A HREF="#Dup%20Status">dup</A>" (duplicate),
      "<A HREF="#Concepts%20Status">concepts</A>," and
      "<A HREF="#Extension%20Status">extension</A>."
     </P>
<P>
    This document is part of a group of related documents that
    together describe the issues that have been raised regarding the
    C++ Standard.  The other documents in the group are:
   </P>
<UL>
<LI>
<A HREF="cwg_active.html">Active Issues List</A>, which contains
      explanatory material for the entire document group and a list of
      the issues that have not yet been acted upon by the Committee.
     </LI>
<LI>
<A HREF="cwg_defects.html">Defect Reports List</A>, which contains
      the issues that have been categorized by the Committee as Defect
      Reports, as well as other issues accepted by the Committee, along
      with their proposed resolutions.
     </LI>
<LI>
<A HREF="cwg_toc.html">Table of Contents</A>, which contains a
     summary listing of all issues in numerical order.
    </LI>
<LI>
<A HREF="cwg_index.html">Index by Section</A>, which contains a
     summary listing of all issues arranged in the order of the
     sections of the Standard with which they deal most directly.
    </LI>
<LI>
<A HREF="cwg_status.html">Index by Status</A>, which contains a
     summary listing of all issues grouped by status.
    </LI>
</UL>
<P>
     For more information, including a description of the meaning of
     the issue status codes and instructions on reporting new issues,
     please see <A HREF="cwg_active.html">the Active Issues List</A>.
    </P>
<P>
    Section references in this document reflect the section numbering
    of document
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/n5014.pdf">WG21 N5014</A>.
   </P>
<HR>
<A NAME="NAD%20Status"></A><H3>Issues with "NAD" Status</H3>
<HR>
<A NAME="1067"></A><H4>1067.
  
<TT>[[hiding]]</TT>, <I>using-declaration</I>s, and multiple inheritance
</H4>
<B>Section: </B>_N3225_.7.6.5&#160; [<A href="https://wg21.link/dcl.attr.override">dcl.attr.override</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-03-26<BR>




<P>The intent appears to be that the following example is well-formed,
even though <TT>D::f(int)</TT> hides <TT>B2::f()</TT>:</P>

<PRE>
    struct B1 { void f(); };
    struct B2 { void f(); };
    struct[[base_check]] D: B1, B2 {
      using B1::f;
      void f(int);
    };
</PRE>

<P>However, this is not reflected in the current wording.</P>

<P><B>Rationale (November, 2010):</B></P>

<P>The consensus of the CWG was that the <I>using-declaration</I>
does, indeed, hide <TT>B2::f()</TT> and thus <TT>D</TT> should be
ill-formed.</P>

<BR><BR><HR>
<A NAME="167"></A><H4>167.
  
Deprecating static functions
</H4>
<B>Section: </B>_N3225_.D.2&#160; [<A href="https://wg21.link/depr.static">depr.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Darin Adler
 &#160;&#160;&#160;

 <B>Date: </B>8 Sep 1999<BR>



<P>_N3225_.D.2 [<A href="https://wg21.link/depr.static">depr.static</A>]
 says that declaring
namespace-scope <I>objects</I> as <TT>static</TT> is deprecated.
Declaring namespace-scope <I>functions</I> as <TT>static</TT> should
also be deprecated.</P>

<P>
<B>Proposed resolution (10/99):</B> In both
9.9.2.2 [<A href="https://wg21.link/namespace.unnamed#2">namespace.unnamed</A>] paragraph 2
and
_N3225_.D.2 [<A href="https://wg21.link/depr.static#1">depr.static</A>] paragraph 1,
 replace</P>

<BLOCKQUOTE>
when declaring objects in a namespace scope
</BLOCKQUOTE>

with

<BLOCKQUOTE>
when declaring entities in a namespace scope
</BLOCKQUOTE>

In addition, there are a number of locations in the Standard where use
of or reference to <TT>static</TT> should be reconsidered.  These
include:

<UL>
<LI>6.3 [<A href="https://wg21.link/basic.def.odr#5">basic.def.odr</A>] paragraph 5,
</LI>
<LI>6.7 [<A href="https://wg21.link/basic.link#6">basic.link</A>] paragraph 6,
</LI>
<LI>6.10.3.2 [<A href="https://wg21.link/basic.start.static#4">basic.start.static</A>] paragraph 4,
</LI>
<LI>7.7 [<A href="https://wg21.link/expr.const#2">expr.const</A>] paragraph 2,
</LI>
<LI>9.2 [<A href="https://wg21.link/dcl.spec#2">dcl.spec</A>] paragraph 2,
</LI>
<LI>9.12 [<A href="https://wg21.link/dcl.link#7">dcl.link</A>] paragraph 7,
 and</LI>
<LI>9.3.4.5 [<A href="https://wg21.link/dcl.array#4">dcl.array</A>] paragraph 4.
</LI>
</UL>

<P><B>Rationale (04/00):</B></P>

<P>This issue, along with <A HREF="cwg_closed.html#174">issue 174</A>, has
been subsumed by <A HREF="cwg_defects.html#223">issue 223</A>.  Until the
committee determines the meaning of deprecation, it does not make
sense either to extend or reduce the number of features to which it is
applied.</P>
<BR><BR><HR>
<A NAME="174"></A><H4>174.
  
Undeprecating global static
</H4>
<B>Section: </B>_N3225_.D.2&#160; [<A href="https://wg21.link/depr.static">depr.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lawrence Crowl
 &#160;&#160;&#160;

 <B>Date: </B>25 Oct 1999<BR>



<P>The decision to deprecate global static should be reversed.</P>

<OL>
<LI>
We cannot deprecate static because it is an important part of C and to
abandon it would make C++ unnecessarily incompatible with C.</LI>

<LI>
Because templates may be instantiated on members of unnamed namespaces,
some compilation systems may place such symbols in the global linker
space, which could place a significant burden on the linker.  Without
static, programmers have no mechanism to avoid the burden.</LI>

</OL>

<P><B>Rationale (04/00):</B></P>

<P>This issue, along with <A HREF="cwg_closed.html#167">issue 167</A>, has
been subsumed by <A HREF="cwg_defects.html#223">issue 223</A>.  Until the
committee determines the meaning of deprecation, it does not make
sense either to extend or reduce the number of features to which it is
applied.</P>
<BR><BR><HR>
<A NAME="1150"></A><H4>1150.
  
Inheriting constructors have not been implemented
</H4>
<B>Section: </B>_N4527_.12.9&#160; [<A href="https://wg21.link/class.inhctor">class.inhctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US65">N3092 comment
  US&#160;65<BR></A>

<P>Inheriting constructors should not be part of C++0x unless they
have implementation experience.</P>

<P><B>Rationale (March, 2011):</B></P>

<P>The full Committee voted not to remove this feature.</P>

<BR><BR><HR>
<A NAME="687"></A><H4>687.
  
<TT>template</TT> keyword with <I>unqualified-id</I>s
</H4>
<B>Section: </B>_N4567_.5.1.1&#160; [<A href="https://wg21.link/expr.prim.general">expr.prim.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mihai Rusu
 &#160;&#160;&#160;

 <B>Date: </B>27 February, 2008<BR>


<P>[Addressed with a different approach by paper P0846R0, adopted at the November, 2017 meeting.]</P>

<P>Consider the following:</P>

<PRE>
    namespace N {
        struct A { };
        template&lt;typename T&gt;
        T func(const A&amp;) { return T(); }
    }

    void f() {
        N::A a;
        func&lt;int&gt;(a);    //<SPAN CLASS="cmnt"> error</SPAN>
    }
</PRE>

<P>Although argument-dependent lookup would allow <TT>N::func</TT>
to be found in this call, the <TT>&lt;</TT> is taken as a
less-than operator rather than as the beginning of a template
argument list.  If the use of the <TT>template</TT> keyword for
syntactic disambiguation were permitted for <I>unqualified-id</I>s,
this problem could be solved by prefixing the function name with
<TT>template</TT>, allowing the <I>template-id</I> to be parsed
and argument-dependent lookup to be performed.</P>

<P><B>Rationale (July, 2009):</B></P>

<P>This suggestion would need a full proposal and discussion by
the EWG before the CWG could consider it.</P>

<BR><BR><HR>
<A NAME="2134"></A><H4>2134.
  
Objectless references to non-static member functions
</H4>
<B>Section: </B>_N4567_.5.1.1&#160; [<A href="https://wg21.link/expr.prim.general">expr.prim.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-06-03<BR>




<P>Bullet 13.3 of _N4567_.5.1.1 [<A href="https://wg21.link/expr.prim.general">expr.prim.general</A>] permits only
non-static data members to appear without an object expression
in an unevaluated operand.  There does not appear to be a
good reason to exclude non-static member functions from this
permission.</P>

<P><B>Rationale (October, 2015):</B></P>

<P>Without knowing the type of <TT>this</TT>, overload
resolution cannot be performed, and it seems not worth the
trouble to allow member functions only in the case where there
is no overloading.</P>

<BR><BR><HR>
<A NAME="596"></A><H4>596.
  
Replacing an exception object
</H4>
<B>Section: </B>_N4606_.15.5.2&#160; [<A href="https://wg21.link/except.unexpected">except.unexpected</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>12 September 2006<BR>


<P>When a function throws an exception that is not in its
<I>exception-specification</I>, <TT>std::unexpected()</TT> is called.
According to _N4606_.15.5.2 [<A href="https://wg21.link/except.unexpected#2">except.unexpected</A>] paragraph 2,</P>

<BLOCKQUOTE>

If [<TT>std::unexpected()</TT>] throws or rethrows an exception that
the <I>exception-specification</I> does not allow then the following
happens: If the <I>exception-specification</I> does not include the class
<TT>std::bad_exception</TT> (17.9.4 [<A href="https://wg21.link/bad.exception">bad.exception</A>]) then
the function <TT>std::terminate()</TT> is called, otherwise the thrown
exception is replaced by an implementation-defined object of the type
<TT>std::bad_exception,</TT> and the search for another handler will
continue at the call of the function
whose <I>exception-specification</I> was violated.

</BLOCKQUOTE>

<P>The &#8220;replaced by&#8221; wording is imprecise and undefined.
For example, does this mean that the destructor is called for the
existing exception object, or is it simply abandoned?  Is the
replacement <I>in situ</I>, so that a pointer to the existing
exception object will now point to the <TT>std::bad_exception</TT>
object?</P>

<P>
<U>Mike Miller</U>: The call to <TT>std::unexpected()</TT> is
not described as analogous to invoking a handler, but if it were,
that would resolve this question; it is clearly specified what
happens to the previous exception object when a new exception is
thrown from a handler (14.2 [<A href="https://wg21.link/except.throw#4">except.throw</A>] paragraph 4).</P>

<P>This approach would also clarify other questions that have been
raised regarding the requirements for stack unwinding.  For
example, 14.6.2 [<A href="https://wg21.link/except.terminate#2">except.terminate</A>] paragraph 2 says that</P>

<BLOCKQUOTE>

In the situation where no matching handler is found, it is
implementation-defined whether or not the stack is unwound before
<TT>std::terminate()</TT> is called.

</BLOCKQUOTE>

<P>This requirement could be viewed as in conflict with the statement
in _N4606_.15.5.2 [<A href="https://wg21.link/except.unexpected#1">except.unexpected</A>] paragraph 1 that</P>

<BLOCKQUOTE>

If a function with an <I>exception-specification</I> throws an exception that
is not listed in the <I>exception-specification</I>, the function
<TT>std::unexpected()</TT> is called (_N4606_.D.6 [<A href="https://wg21.link/exception.unexpected">exception.unexpected</A>])
immediately after completing the stack unwinding for the former
function.

</BLOCKQUOTE>

<P>If it is implementation-defined whether stack unwinding occurs before
calling <TT>std::terminate()</TT> and <TT>std::unexpected()</TT> is
called only after doing stack unwinding, does that mean that it is
implementation-defined whether <TT>std::unexpected()</TT> is called
if there is ultimately no handler found?</P>

<P>Again, if invoking <TT>std::unexpected()</TT> were viewed as
essentially invoking a handler, the answer to this would be clear,
because unwinding occurs before invoking a handler.</P>

<P><B>Rationale (February, 2017):</B></P>

<P>The issue is moot after the adoption of document P0003.</P>

<BR><BR><HR>
<A NAME="2393"></A><H4>2393.
  
Pseudo-destructors and object lifetime
</H4>
<B>Section: </B>_N4778_.7.6.1.4&#160; [<A href="https://wg21.link/expr.pseudo">expr.pseudo</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2018-11-07<BR>


<P>With the changes for <A HREF="cwg_defects.html#2256">issue 2256</A>,
extending destruction to apply to objects of scalar type, should
invoking a pseudo-destructor end the lifetime of that object?</P>

<P><B>Rationale (February, 2019):</B></P>

<P>This question is resolved by paper P0593R4.</P>

<BR><BR><HR>
<A NAME="156"></A><H4>156.
  
Name lookup for conversion functions
</H4>
<B>Section: </B>_N4868_.6.5.6&#160; [<A href="https://wg21.link/basic.lookup.classref">basic.lookup.classref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Derek Inglis
 &#160;&#160;&#160;

 <B>Date: </B>18 Aug 1999<BR>





<P>Paragraph 7 of
_N4868_.6.5.6 [<A href="https://wg21.link/basic.lookup.classref">basic.lookup.classref</A>]
 says,</P>

<BLOCKQUOTE>
If the <I>id-expression</I> is a <I>conversion-function-id</I>, its
<I>conversion-type-id</I> shall denote the same
type in both the context in which the
entire <I>postfix-expression</I> occurs
and in the context of the class of the object
expression (or the class pointed to by the pointer expression).
</BLOCKQUOTE>

Does this mean that the following example is ill-formed?

<PRE>
    struct A { operator int(); } a;
    void foo() {
      typedef int T;
      a.operator T(); // 1) error T is not found in the context
		      // of the class of the object expression?
    }
</PRE>

The second bullet in paragraph 1 of
6.5.5.2 [<A href="https://wg21.link/class.qual">class.qual</A>]
 says,

<BLOCKQUOTE>
a <I>conversion-type-id</I> of an
<I>operator-function-id</I> is looked up both
in the scope of the class and in the
context in which the entire <I>postfix-expression</I>
occurs and shall refer to the
same type in both contexts
</BLOCKQUOTE>

How about:

<PRE>
    struct A { typedef int T; operator T(); };
    struct B : A { operator T(); } b;
    void foo() {
      b.A::operator T(); // 2) error T is not found in the context
			 // of the postfix-expression?
    }
</PRE>

Is this interpretation correct?  Or was the intent for
this to be an error only if
<TT>T</TT> was found in both scopes and referred to different entities?

<P>If the intent was for these to be errors,
how do these rules apply to template
arguments?</P>

<PRE>
    template &lt;class T1&gt; struct A { operator T1(); }
    template &lt;class T2&gt; struct B : A&lt;T2&gt; {
      operator T2();
      void foo() {
	T2 a = A&lt;T2&gt;::operator T2(); // 3) error? when instantiated T2 is not
				     // found in the scope of the class
	T2 b = ((A&lt;T2&gt;*)this)-&gt;operator T2(); // 4) error when instantiated?
      }
    }
</PRE>

<P>(Note bullets 2 and 3 in paragraph 1 of
6.5.5.2 [<A href="https://wg21.link/class.qual">class.qual</A>]
 refer to
<I>postfix-expression</I>.  It would be better to use
<I>qualified-id</I> in both cases.)</P>

<P>
<U>Erwin Unruh</U>:
The intent was that you look in both contexts. If you find it only once,
that's the symbol. If you find it in both, both symbols must be "the same"
in some respect. (If you don't find it, its an error).</P>

<P>
<U>Mike Miller</U>:
What's not clear to me in these examples is whether what is
being looked up is <TT>T</TT> or <TT>int</TT>.
Clearly the <TT>T</TT> has to be
looked up somehow, but the "name" of a conversion function
clearly involves the base (non-typedefed) type, not typedefs
that might be used in a definition or reference (cf
6.1 [<A href="https://wg21.link/basic.pre#7">basic.pre</A>] paragraph 7
and
11.4.8 [<A href="https://wg21.link/class.conv#5">class.conv</A>] paragraph 5)
.
(This is true even for types that must be written
using typedefs because of the limited syntax in
<I>conversion-type-id</I>s &#8212; e.g., the "name" of the conversion
function in the following example</P>

<PRE>
    typedef void (*pf)();
    struct S {
	operator pf();
    };
</PRE>

is <TT>S::operator void(*)()</TT>, even though you can't write its name
directly.)

<P>My guess is that this means that in each scope you look up
the type named in the reference and form the canonical
operator name; if the name used in the reference isn't found
in one or the other scope, the canonical name constructed
from the other scope is used.  These names must be identical,
and the <I>conversion-type-id</I> in the canonical operator name must
not denote different types in the two scopes (i.e., the type
might not be found in one or the other scope, but if it's found
in both, they must be the same type).</P>

<P>I think this is all very vague in the current wording.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>This issue was resolved by the resolution of
<A HREF="cwg_defects.html#1111">issue 1111</A>.</P>

<BR><BR><HR>
<A NAME="95"></A><H4>95.
  
Elaborated type specifiers referencing names declared in friend decls
</H4>
<B>Section: </B>_N4868_.9.8.2.3&#160; [<A href="https://wg21.link/namespace.memdef">namespace.memdef</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>9 Feb 1999<BR>




<P>A change was introduced into the language that made names first declared
in friend declarations "invisible" to normal lookups until such time that
the identifier was declared using a non-friend declaration. This is described
in _N4868_.9.8.2.3 [<A href="https://wg21.link/namespace.memdef#3">namespace.memdef</A>] paragraph 3
and
11.8.4 [<A href="https://wg21.link/class.friend#9">class.friend</A>] paragraph 9
(and perhaps other places).</P>

<P>The standard gives examples of how this all works with friend declarations,
but there are some cases with nonfriend elaborated type specifiers for
which there are no examples, and which might yield surprising results.</P>

<P>The problem is that an elaborated type specifier is sometimes a declaration
and sometimes a reference. The meaning of the following code changes depending
on whether or not friend class names are injected (visibly) into the enclosing
namespace scope.</P>
<PRE>
    struct A;
    struct B;
    namespace N {
        class X {
            friend struct A;
            friend struct B;
        };
        struct A *p;     // N::A with friend injection, ::A without
        struct B;        // always N::B
    }
</PRE>
Is this the desired behavior, or should
all elaborated type specifiers (and not just those of the form
"<I>class-key&#160;identifier</I>;") have the effect of finding
previously declared "invisible"
names and making them visible?

<P>
<U>Mike Miller</U>: That's not how I would categorize the effect of
"<TT>struct B;</TT>". That declaration introduces the name
"<TT>B</TT>" into namespace <TT>N</TT>
in exactly the same fashion as if the friend declaration did not exist.
The preceding friend declaration simply stated that, if a class
<TT>N::B</TT> were
ever defined, it would have friendly access to the members of
<TT>N::X</TT>. In
other words, the lookups in both "<TT>struct A*</TT>..." and
"<TT>struct B;</TT>" ignore
the friend declarations.</P>

<P>(The standard is schizophrenic on the issue of whether such friend declarations
introduce names into the enclosing namespace. 6.4 [<A href="https://wg21.link/basic.scope#4">basic.scope</A>] paragraph 4
says,
<UL>friend declarations (11.8.4 [<A href="https://wg21.link/class.friend">class.friend</A>]
) may introduce a (possibly not visible) name
into an enclosing name-space</UL>
while 6.4.2 [<A href="https://wg21.link/basic.scope.pdecl#6">basic.scope.pdecl</A>] paragraph 6
says exactly the opposite:
<UL>friend declarations refer to functions or classes that are members
of the nearest enclosing namespace, but they do not introduce new names
into that namespace (_N4868_.9.8.2.3 [<A href="https://wg21.link/namespace.memdef">namespace.memdef</A>]
).</UL>
Both of these are just notes; the normative text doesn't commit itself
either way, just stating that the name is not found until actually declared
in the enclosing namespace scope. I prefer the latter description; I think
it makes the behavior you're describing a lot clearer and easier to understand.)</P>

<P>
<U>John Spicer</U>: The previous declaration of B is not completely
ignored though, because certainly changing "friend struct B;" to "friend
union B;" would result in an error when B was later redeclared as a struct,
wouldn't it?</P>

<P>
<U>Bill Gibbons</U>: Right. I think the intent was to model this after
the existing rule for local declarations of functions (which dates back
to C), where the declaration is introduced into the enclosing scope but
the name is not. Getting this right requires being somewhat more rigorous
about things like the ODR because there may be declaration clashes even
when there are no name clashes. I suspect that the standard gets this right
in most places but I would expect there to be a few that are still wrong,
in addition to the one Mike pointed out.</P>

<P>
<U>Mike Miller</U>: Regarding <I>would result in an error when <TT>B</TT>
was later redeclared</I>
</P>

<P>I don't see any reason why it should. The restriction that the class-key
must agree is found in 9.2.9.5 [<A href="https://wg21.link/dcl.type.elab">dcl.type.elab</A>]

and is predicated on having found a matching
declaration in a lookup according to 6.5.6 [<A href="https://wg21.link/basic.lookup.elab">basic.lookup.elab</A>]
.
Since a lookup of a name declared
only (up to that point) in a friend declaration does not find that name
(regardless of whether you subscribe to the "does-not-introduce" or "introduces-invisibly"
school of thought), there can't possibly be a mismatch. </P>

<P>I don't
think that the Standard's necessarily broken here. There is no requirement
that a class declared in a friend declaration ever be defined. Explicitly
putting an incompatible declaration into the namespace where that friend
class would have been defined is, to me, just making it impossible to define
&#8212; which is no problem, since it didn't have to be defined anyway. The
only error would occur if the same-named but unbefriended class attempted
to use the nonexisting grant of friendship, which would result in an access
violation.</P>

<P>(BTW, I couldn't
find anything in the Standard that forbids <I>defining</I> a class with a mismatched
<I>class-key</I>, only using one in an
<I>elaborated-type-specifier</I>. Is this a hole
that needs to be filled?)</P>

<P>
<U>John Spicer</U>: This is what 9.2.9.5 [<A href="https://wg21.link/dcl.type.elab#3">dcl.type.elab</A>] paragraph 3
says:
<UL>The <I>class-key</I> or <TT>enum</TT> keyword present in the
<I>elaborated-type-specifier</I>
shall agree in kind with the declaration to which the name in the
<I>elaborated-type-specifier</I>
refers. This rule also applies to the form of <I>elaborated-type-specifier</I>
that declares a <I>class-name</I> or <TT>friend</TT> class since it can be
construed as
referring to the definition of the class. Thus, in any
<I>elaborated-type-specifier</I>,
the <TT>enum</TT> keyword shall be used to refer to an enumeration (9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
),
the <TT>union</TT> <I>class-key</I> shall be used to refer to a union
(Clause 11 [<A href="https://wg21.link/class">class</A>]
),
and either the <TT>class</TT> or <TT>struct</TT> <I>class-key</I>
shall be used to refer to a class
(Clause 11 [<A href="https://wg21.link/class">class</A>]
) declared using the
<TT>class</TT> or <TT>struct</TT> <I>class-key</I>.</UL>
The latter part of this paragraph (beginning "This rule also applies...")
is somewhat murky to me, but I think it could be interpreted to say that</P>
<PRE>
            class B;
            union B {};
</PRE>
and
<PRE>
            union B {};
            class B;
</PRE>
are both invalid. I think this paragraph is <I>intended</I> to say that. I'm
not so sure it actually does say that, though.

<P>
<U>Mike Miller</U>: Regarding <I>I think the intent was to model this
after the existing rule for local declarations of functions (which dates
back to C)</I>
</P>

<P>Actually, that's not the C (1989) rule. To quote the Rationale from
X3.159-1989:</P>
<UL>While it was generally agreed that it is poor practice to take advantage
of an external declaration once it had gone out of scope, some argued that
a translator had to remember the declaration for checking anyway, so why
not acknowledge this? The compromise adopted was to decree essentially
that block scope rules apply, but that a conforming implementation need
not diagnose a failure to redeclare an external identifier that had gone
out of scope (undefined behavior).</UL>

<P>Regarding <I>Getting this right requires being somewhat more rigorous</I>
</P>

<P>Yes, I think if this is to be made illegal, it would have to be done
with the ODR; the name-lookup-based current rules clearly (IMHO) don't
apply. (Although to be fair, the [non-normative] note in 6.4 [<A href="https://wg21.link/basic.scope#4">basic.scope</A>] paragraph 4
sounds as
if it expects friend invisible injection to trigger the multiple-declaration
provisions of that paragraph; it's just that there's no normative text
implementing that expectation.)</P>

<P>
<U>Bill Gibbons</U>: Nor does the ODR currently disallow:</P>
<PRE>
    translation unit #1    struct A;

    translation unit #2    union A;
</PRE>
since it only refers to class definitions, not declarations.

<P>But the obvious form of the missing rule (all declarations of a class
within a program must have compatible struct/class/union keys) would also
answer the original question.</P>

<P>The declarations need not be visible. For example:</P>
<PRE>
    translation unit #1    int f() { return 0; }

    translation unit #2:   void g() {
                               extern long f();
                           }
</PRE>
is ill-formed even though the second "<TT>f</TT>" is not a visible declaration.

<P>
<B>Rationale (10/99):</B> The main issue (differing behavior of
standalone and embedded <I>elaborated-type-specifier</I>s) is as
the Committee intended.  The remaining questions mentioned in the
discussion may be addressed in dealing with related issues.</P>

<P>(See also issues
<A HREF="cwg_defects.html#136">136</A>,
<A HREF="cwg_defects.html#138">138</A>,
<A HREF="cwg_defects.html#139">139</A>,
<A HREF="cwg_defects.html#143">143</A>,
<A HREF="cwg_closed.html#165">165</A>, and
<A HREF="cwg_defects.html#166">166</A>.)</P>
<BR><BR><HR>
<A NAME="165"></A><H4>165.
  
Definitions of friends and block-scope externs
</H4>
<B>Section: </B>_N4868_.9.8.2.3&#160; [<A href="https://wg21.link/namespace.memdef">namespace.memdef</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Derek Inglis
 &#160;&#160;&#160;

 <B>Date: </B>7 Sep 1999<BR>



<P>_N4868_.9.8.2.3 [<A href="https://wg21.link/namespace.memdef#2">namespace.memdef</A>] paragraph 2
says,</P>

<BLOCKQUOTE>
Members of a named namespace can also be defined outside that
namespace by explicit qualification
(6.5.5.3 [<A href="https://wg21.link/namespace.qual">namespace.qual</A>]
) of the name being
defined, provided that the entity being defined was already declared
in the namespace...
</BLOCKQUOTE>

It is not clear whether block-scope <TT>extern</TT> declarations and
<TT>friend</TT> declarations are sufficient to permit the named
entities to be defined outside their namespace.  For example,

<PRE>
    namespace NS {
       struct A { friend struct B; };
       void foo() { extern void bar(); }
    }
    struct NS::B { };   // 1) legal?
    void NS::bar() { }  // 2) legal?
</PRE>

<P>
<B>Rationale (10/99):</B> Entities whose names are "invisibly
injected" into a namespace as a result of <TT>friend</TT> declarations
are not "declared" in that namespace until an explicit declaration of
the entity appears at namespace scope.  Consequently, the definitions
in the example are ill-formed.</P>

<P>(See also issues
<A HREF="cwg_closed.html#95">95</A>,
<A HREF="cwg_defects.html#136">136</A>,
<A HREF="cwg_defects.html#138">138</A>,
<A HREF="cwg_defects.html#139">139</A>,
<A HREF="cwg_defects.html#143">143</A>, and
<A HREF="cwg_defects.html#166">166</A>.)</P>
<BR><BR><HR>
<A NAME="553"></A><H4>553.
  
Problems with friend allocation and deallocation functions
</H4>
<B>Section: </B>_N4868_.9.8.2.3&#160; [<A href="https://wg21.link/namespace.memdef">namespace.memdef</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dmitriy Litskalov
 &#160;&#160;&#160;

 <B>Date: </B>16 December 2005<BR>


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

<PRE>
    class C {
       public: enum E {};

       friend void* operator new(size_t, E);
       friend void  operator delete(void*, E);
    };

    void foo() {
       C::E e;
       C* ptr = new(e) C();
    }
</PRE>

<P>This code, which is valid in global scope, becomes ill-formed when
the class definition is moved into a namespace, and there is no way
to make it valid:</P>

<PRE>
    namespace N {
       class C {
          public: enum E {};

          friend void* operator new(size_t, E);
          friend void  operator delete(void*, E);
       };
    }

    void foo() {
       N::C::E e;
       N::C* ptr = new(e) N::C();
    }
</PRE>

<P>The reason for this is that non-member allocation and deallocation
functions are required to be members of the global scope (6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation#1">basic.stc.dynamic.allocation</A>] paragraph 1, 6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation#1">basic.stc.dynamic.deallocation</A>] paragraph 1)
, unqualified friend declarations declare names in the
innermost enclosing namespace (_N4868_.9.8.2.3 [<A href="https://wg21.link/namespace.memdef#3">namespace.memdef</A>] paragraph 3)
, and these functions cannot be declared in global scope
at a point where the friend declarations could refer to them using
<I>qualified-id</I>s because their second parameter is a member of the
class and thus can't be named before the class containing the friend
declarations is defined.</P>

<P>Possible solutions for this conundrum include invention of some
mechanism to allow a friend declaration to designate a namespace scope
other than the innermost enclosing namespace in which the friend class
or function is to be declared or to relax the innermost enclosing
namespace lookup restriction in _N4868_.9.8.2.3 [<A href="https://wg21.link/namespace.memdef#3">namespace.memdef</A>] paragraph 3
for friend declarations that nominate allocation and
deallocation functions. </P>

<P><B>Rationale (April, 2006):</B></P>

<P>The CWG acknowledged that it is not always possible to move
code from the global scope into a namespace but felt that this
problem was not severe enough to warrant changing the language to
accommodate it.  Possible solutions include moving the enumeration
outside the class or defining member allocation and deallocation
functions.</P>

<BR><BR><HR>
<A NAME="673"></A><H4>673.
  
Injection of names from <I>elaborated-type-specifier</I>s in <TT>friend</TT> declarations
</H4>
<B>Section: </B>_N4868_.9.8.2.3&#160; [<A href="https://wg21.link/namespace.memdef">namespace.memdef</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>6 February, 2008<BR>


<P>_N4868_.9.8.2.3 [<A href="https://wg21.link/namespace.memdef#3">namespace.memdef</A>] paragraph 3 is intended to prevent
injection of names from <TT>friend</TT> declarations into the containing
namespace scope:</P>

<BLOCKQUOTE>

If a <TT>friend</TT> declaration in a non-local class first declares a
class or function the friend class or function is a member of the
innermost enclosing namespace. The name of the friend is not found by
unqualified lookup (6.5.3 [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>]) or by qualified lookup
(6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>]) until a matching declaration is provided
in that namespace scope (either before or after the class definition
granting friendship).

</BLOCKQUOTE>

<P>However, this does not address names declared by
<I>elaborated-type-specifier</I>s that are part of the <TT>friend</TT>
declaration.  Are these names intended to be visibly injected?  For
example, is the following well-formed?</P>

<PRE>
    class A {
        friend class B* f();
    };
    B* bp;    //<SPAN CLASS="cmnt"> Is </SPAN>B<SPAN CLASS="cmnt"> visible here?</SPAN>
</PRE>

<P>Implementations differ in their treatment of this example: EDG
and MSVC++ 8.0 accept it, while g++ 4.1.1 rejects it.</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The current specification does not restrict injection of names
in <I>elaborated-type-specifier</I>s, and the consensus of the CWG
was that no change is needed on this point.</P>

<BR><BR><HR>
<A NAME="1077"></A><H4>1077.
  
Explicit specializations in non-containing namespaces
</H4>
<B>Section: </B>_N4868_.9.8.2.3&#160; [<A href="https://wg21.link/namespace.memdef">namespace.memdef</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-06-13<BR>




<P>The current wording of _N4868_.9.8.2.3 [<A href="https://wg21.link/namespace.memdef">namespace.memdef</A>] and
13.9.4 [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>] requires that an explicit specialization
be declared either in the same namespace as the template or in an
enclosing namespace.  It would be convenient to relax that requirement
and allow the specialization to be declared in a non-enclosing
namespace to which one or more if the template arguments belongs.</P>

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

<P>See EWG issue 48.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a feature request, not a defect.</P>

<BR><BR><HR>
<A NAME="37"></A><H4>37.
  
When is uncaught_exception() true?
</H4>
<B>Section: </B>_N5001_.14.6.3&#160; [<A href="https://wg21.link/except.uncaught">except.uncaught</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>10 Aug 1998<BR>





<P>The term "throw exception" seems to sometimes refer to an expression
of the form "<TT>throw</TT> <I>expr</I>" and
sometimes just to the "<I>expr</I>"
portion thereof.</P>

<P>As a result it is not quite clear to me
whether when "<TT>uncaught_exception()</TT>"
becomes true: before or after the temporary
copy of the value of "<I>expr</I>".</P>

<P>Is there a definite consensus about that?</P>

<P>
<B>Rationale:</B>

The standard is sufficiently clear; the phrase "to be thrown" indicates
that the throw itself (which includes the copy to the temporary object)
has not yet begun. The footnote in
14.6.2 [<A href="https://wg21.link/except.terminate#1">except.terminate</A>] paragraph 1
reinforces
this ordering. </P>

<P>See also <A HREF="cwg_defects.html#475">issue 475</A>.</P>
<BR><BR><HR>
<A NAME="2034"></A><H4>2034.
  
Deprecating <TT>uncaught_exception()</TT>
</H4>
<B>Section: </B>_N5001_.14.6.3&#160; [<A href="https://wg21.link/except.uncaught">except.uncaught</A>]
 &#160;&#160;&#160;

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

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

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


<P>With the adoption of paper N4259 specifying the
<TT>std::uncaught_exceptions()</TT> function, the
<TT>std::uncaught_exception()</TT> function should be
deprecated.</P>

<P><B>Rationale (May, 2015):</B></P>

<P>This has already been done; see _N4140_.D.9 [<A href="https://wg21.link/depr.uncaught">depr.uncaught</A>].</P>

<BR><BR><HR>
<A NAME="449"></A><H4>449.
  
Consistency in use of hyphen with names of "non" entities
</H4>
<B>Section: </B>Clause 3&#160; [<A href="https://wg21.link/intro.defs">intro.defs</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>14 Jan 2004<BR>


<P>The standard is inconsistent in its use of a hyphen on the
following:
nontype vs. non-type,
non-dependent vs. nondependent,
non-deduced vs. nondeduced, and
non-template vs. nontemplate.
We should pick a preferred form.</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>If this isn't a purely editorial issue, nothing is.  We're referring this
to the editor. We prefer the hyphenated forms.</P>

<BR><BR><HR>
<A NAME="1947"></A><H4>1947.
  
Digit separators following non-octal prefix
</H4>
<B>Section: </B>5.13.2&#160; [<A href="https://wg21.link/lex.icon">lex.icon</A>]
 &#160;&#160;&#160;

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

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

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


<P>(From item JP 03 of the Japanese National Body comments on the C++14
DIS ballot.)</P>

<P>A digit separator is allowed immediately following the
prefix for an octal literal but not for a binary or
hexadecimal literal.  For example, <TT>0'01</TT> is
permitted but <TT>0b'01</TT> and <TT>0x'01</TT> are not.
This asymmetry makes tools such as automatic code generators
more complicated than necessary.  The digit separator should
be consistently allowed or disallowed immediately following
the prefix in all non-decimal integer literals.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>CWG felt that the reported asymmetry is not a major difficulty
and that it is more natural to think of the leading <TT>0</TT> in
an octal literal as part of the numeric value rather than as a
separate prefix, as it is with <TT>0b</TT> and <TT>0x</TT>.
Consequently there was no consensus for a change to the existing
specification.</P>

<BR><BR><HR>
<A NAME="937"></A><H4>937.
  
Restrictions on values of template arguments in user-defined literals
</H4>
<B>Section: </B>5.13.9&#160; [<A href="https://wg21.link/lex.ext">lex.ext</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>11 July, 2009<BR>


<P>5.13.9 [<A href="https://wg21.link/lex.ext">lex.ext</A>] paragraphs 3-4 state in notes that the
arguments to a literal operator template &#8220;can only contain
characters from the basic source character set.&#8221; This
restriction does not appear to occur anywhere in normative text,
however.</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The characters in the template arguments are the characters
comprising <I>n</I>, the integer literal, or <I>f</I>, the floating
literal. As such, they are constrained by the grammar to be members
of the basic character set, and no further normative restriction is
needed.</P>

<BR><BR><HR>
<A NAME="1108"></A><H4>1108.
  
User-defined literals have not been implemented
</H4>
<B>Section: </B>5.13.9&#160; [<A href="https://wg21.link/lex.ext">lex.ext</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US18">N3092 comment
  US&#160;18<BR></A>

<P>User-defined literals should not be part of C++0x unless they have
implementation experience.</P>

<P><B>Rationale (March, 2011):</B></P>

<P>The feature has been implemented.</P>

<BR><BR><HR>
<A NAME="1474"></A><H4>1474.
  
User-defined literals and <TT>&lt;inttypes.h&gt;</TT> format macros
</H4>
<B>Section: </B>5.13.9&#160; [<A href="https://wg21.link/lex.ext">lex.ext</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-03-05<BR>




<P>The format macros that are part of <TT>&lt;inttypes.h&gt;</TT>
(incorporated into C++11 as <TT>&lt;cinttypes&gt;</TT>) are
conventionally written with no whitespace separating them from the
rest of the format string, e.g.,</P>

<PRE>
  printf("foo = "PRIu32", bar = "PRIi8"\n", foo, bar);
  printf("baz = "PRIu32"\n", baz);
</PRE>

<P>This usage conflicts with user-defined literals.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>CWG felt that whether this form of these macros needed to be
supported in C++ should be examined by EWG.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>EWG determined that no action should be taken on this issue.</P>

<BR><BR><HR>
<A NAME="1871"></A><H4>1871.
  
Non-identifier characters in <I>ud-suffix</I>
</H4>
<B>Section: </B>5.13.9&#160; [<A href="https://wg21.link/lex.ext">lex.ext</A>]
 &#160;&#160;&#160;

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

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

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




<P>A <I>ud-suffix</I> is defined in 5.13.9 [<A href="https://wg21.link/lex.ext">lex.ext</A>] as
an <I>identifier</I>.  This prevents plausible user-defined literals
for currency symbols, which are not categorized as identifier
characters.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>CWG felt that a decision on whether to allow this capability or
not should be considered by EWG.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a request for a new feature, which should be proposed in a
paper to EWG. SG16 recommended not adding the feature.</P>

<BR><BR><HR>
<A NAME="2152"></A><H4>2152.
  
Can an alternative token be used as a <I>ud-suffix</I>?
</H4>
<B>Section: </B>5.13.9&#160; [<A href="https://wg21.link/lex.ext">lex.ext</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-06-28<BR>


<P>According to the grammar in 5.13.9 [<A href="https://wg21.link/lex.ext">lex.ext</A>], a
<I>ud-suffix</I> is an <I>identifier</I>.  However, implementations
seem to agree that <TT>"x"or"y"</TT> is equivalent to <TT>"xy"or</TT>
and not to <TT>true</TT>.  Should the Standard permit identifier-like
alternative tokens as <I>ud-suffix</I>es?</P>

<P><B>Rationale (October, 2015):</B></P>

<P>The <I>identifier</I> in a <I>ud-suffix</I> is required to
begin with an underscore, and the identifier-like alternative
tokens do not satisfy this requirement.</P>

<BR><BR><HR>
<A NAME="2423"></A><H4>2423.
  
Typedefs, names, and entities
</H4>
<B>Section: </B>6.1&#160; [<A href="https://wg21.link/basic.pre">basic.pre</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>2019-07-29<BR>


<P>According to 6.1 [<A href="https://wg21.link/basic.pre#4">basic.pre</A>] paragraph 4,</P>

<BLOCKQUOTE>

A name is a use of an <I>identifier</I>
(5.11 [<A href="https://wg21.link/lex.name">lex.name</A>]), <I>operator-function-id</I>
(12.4 [<A href="https://wg21.link/over.oper">over.oper</A>]), <I>literal-operator-id</I>
(12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]), <I>conversion-function-id</I>
(11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]), or <I>template-id</I>
(13.3 [<A href="https://wg21.link/temp.names">temp.names</A>]) that denotes an entity or label
(8.8.6 [<A href="https://wg21.link/stmt.goto">stmt.goto</A>], 8.2 [<A href="https://wg21.link/stmt.label">stmt.label</A>]).

</BLOCKQUOTE>

<P>Since typedefs are neither entities nor labels, it appears
that a <I>typedef-name</I> is not a name.</P>

<P>There is an additional discrepancy regarding alias templates.
According to 6.1 [<A href="https://wg21.link/basic.pre#3">basic.pre</A>] paragraph 3, templates
(including, presumably, alias templates) and their specializations
are entities. However, the note in 13.3 [<A href="https://wg21.link/temp.names#6">temp.names</A>] paragraph 6
says,</P>

<BLOCKQUOTE>

[<I>Note:</I> A <I>simple-template-id</I> that names a class
template specialization is a <I>class-name</I>
(11.3 [<A href="https://wg21.link/class.name">class.name</A>]). Any
other <I>simple-template-id</I> that names a type is
a <I>typedef-name</I>. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>Thus an alias template specialization both is and is not an
entity.</P>

<BR><BR><HR>
<A NAME="50"></A><H4>50.
  
Converting pointer to incomplete type to same type
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>13 Oct 1998<BR>



<P>In 6.3 [<A href="https://wg21.link/basic.def.odr#4">basic.def.odr</A>] paragraph 4

bullet 4, it's presumably the case that a conversion to <TT>T*</TT>
requires that <TT>T</TT> be complete only if the conversion is from a different
type. One could argue that there is no conversion (and therefore
the text is accurate as it stands) if a cast does not change the type of
the expression, but it's probably better to be more explicit here.</P>

<P>On the other hand, this text is non-normative (it's in a note).</P>

<P>
<B>Rationale (04/99):</B>
The relevant normative text makes this clear.  Implicit conversion
and <TT>static_cast</TT> are defined (in
7.3 [<A href="https://wg21.link/conv">conv</A>]
 and
7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
,
respectively) as equivalent to declaration with initialization, which
permits pointers to incomplete types, and <TT>dynamic_cast</TT>
(7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]
) explicitly
prohibits pointers to incomplete types.</P>
<BR><BR><HR>
<A NAME="1110"></A><H4>1110.
  
Incomplete return type should be allowed in <TT>decltype</TT> operand
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#DE9">N3092 comment
  DE&#160;9<BR></A>
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US22">N3092 comment
  US&#160;22<BR></A>

<P>
<TT>decltype</TT> applied to a function call expression
requires a complete type (7.6.1.3 [<A href="https://wg21.link/expr.call#3">expr.call</A>] paragraph 3
and 6.3 [<A href="https://wg21.link/basic.def.odr#4">basic.def.odr</A>] paragraph 4), even
though <TT>decltype</TT>'s result might be used in a way
that does not actually require a complete type. This might
cause undesired and excessive template instantiations.
Immediately applying <TT>decltype</TT> should not require a
complete type, for example, for the return type of a
function call.</P>

<P><B>Additional note (October, 2010):</B></P>



<P>Another potential consideration in this question is the use
of the return type in template argument deduction.  If the return
type is a specialization of a class template, one would want an
error occurring in the instantiation of that specialization to
cause a deduction failure, which would argue in favor of requiring
the type to be complete.  (However, that might also be covered by
&#8220;when the completeness of the class type affects the semantics
of the program&#8221; in 13.9.2 [<A href="https://wg21.link/temp.inst#1">temp.inst</A>] paragraph 1.)</P>

<P><B>Rationale (November, 2010):</B></P>

<P>The CWG was persuaded by the SFINAE consideration.</P>

<P><B>Note:</B></P>

<P>This issue was raised again at the March, 2011 meeting and paper N3276,
implementing this recommendation, was adopted for the FDIS.</P>

<BR><BR><HR>
<A NAME="1254"></A><H4>1254.
  
odr-use vs template arguments and constexpr functions
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-08<BR>




<P>The relationship between when an expression is potentially evaluated,
especially with respect to contexts requiring constant expressions,
and non-type template arguments is not clear and should be clarified.
In particular, it seems that these contexts should be
potentially-evaluated.</P>

<P>See also <A HREF="cwg_defects.html#1378">issue 1378</A>.</P>

<P><B>Additional note, January, 2012:</B></P>

<P>Further discussion indicates that this is not a defect and should be
closed as such. 
</P>

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

<P>CWG determined that the current wording is clear enough that an
instantiation is required whenever it affects the semantics of the
program.</P>

<BR><BR><HR>
<A NAME="2240"></A><H4>2240.
  
<TT>this</TT> is not odr-used in a constant expression
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-03-04<BR>


<P>According to 6.3 [<A href="https://wg21.link/basic.def.odr#3">basic.def.odr</A>] paragraph 3,</P>

<BLOCKQUOTE>

<TT>this</TT> is odr-used if it appears as a potentially-evaluated
expression (including as the result of the implicit transformation in the
body of a non-static member function (11.4.3 [<A href="https://wg21.link/class.mfct.non.static">class.mfct.non.static</A>])).

</BLOCKQUOTE>

<P>This wording does not distinguish between constant and non-constant
expressions in determining whether <TT>this</TT> is odr-used or not.</P>

<P><B>Notes from the April, 2018 teleconference:</B></P>

<P>Specification of the odr-use of <TT>this</TT> was done to allow
determination of whether <TT>this</TT> should be captured by a lambda.
Recent changes to determine capture syntactically, rather than by odr-use,
have rendered this issue almost moot. However, 6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
still describes when <TT>this</TT> is odr-used; this specification is no
longer necessary and should be removed.</P>

<P><B>Rationale (February, 2019):</B></P>

<P>This specification is now used by contracts.</P>

<BR><BR><HR>
<A NAME="2367"></A><H4>2367.
  
Lambdas in default arguments vs the ODR
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2017-11-10<BR>


<P>According to 6.3 [<A href="https://wg21.link/basic.def.odr#6.5">basic.def.odr</A>] bullet 6.5,</P>

<UL>
<LI>

<P>in each definition of <TT>D</TT>, a default argument used by an (implicit or
explicit) function call is treated as if its token sequence were present in
the definition of <TT>D</TT>; that is, the default argument is subject to the
requirements described in this paragraph (and, if the default argument has
subexpressions with default arguments, this requirement applies
recursively)</P>
</LI>

</UL>

<P>However, this rule is insufficient to handle a case like:</P>

<PRE>
  struct A {
    template&lt;typename T&gt; A(T);
  };
  void f(A a = []{});
  inline void g() {
    f();
  }
</PRE>

<P>This should be an ODR violation, because the call to f() will invoke a
different specialization of the constructor template in each translation
unit, but it is not, because the rule says this example is equivalent
to:</P>

<PRE>
  inline void g() {
   f([]{});
  }
</PRE>

<P>which is not an ODR violation, since the type of the closure object
will be the same in every translation unit (9.2.8 [<A href="https://wg21.link/dcl.inline#6">dcl.inline</A>] paragraph 6)
..</P>

<P><B>Notes from the October, 2018 teleconference:</B></P>

This will be addressed by work already underway to rework the
relationship between lambdas and the ODR.


<P><B>Rationale (February, 2021):</B></P>

<P>The resolution of <A HREF="cwg_defects.html#2300">issue 2300</A>
makes clear that this example is an ODR violation.</P>

<BR><BR><HR>
<A NAME="1433"></A><H4>1433.
  
<I>trailing-return-type</I> and point of declaration
</H4>
<B>Section: </B>6.4.2&#160; [<A href="https://wg21.link/basic.scope.pdecl">basic.scope.pdecl</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-12-20<BR>




<P>This seems like it should be well-formed:</P>

<PRE>
    template &lt;class T&gt; T list(T x);

    template &lt;class H, class ...T&gt;
    auto list(H h, T ...args) -&gt; decltype(list(args...));

    auto list3 = list(1, 2, 3);
</PRE>

<P>but it isn't, because the second list isn't in scope in its
own <I>trailing-return-type</I>; the point of declaration is after the
declarator, which includes the <I>trailing-return-type</I>.  And since
<TT>int</TT> has no associated namespaces, the call in the return type
only sees the first list.  G++, EDG and Clang all reject the
testcase on this basis.</P>

<P>But this seems like a natural pattern for writing variadic
function templates, and we could support it by moving the point
of declaration to the <TT>-&gt;</TT>.  This would mean having to
deal with a function that only has a placeholder for a return
type, but I think we can handle that.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>This is a request for an extension to the language and is thus more
appropriately addressed by EWG.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a breaking change whose benefits and trade-offs need to be
carefully analyzed.</P>

<BR><BR><HR>
<A NAME="42"></A><H4>42.
  
Redefining names from base classes
</H4>
<B>Section: </B>6.4.7&#160; [<A href="https://wg21.link/basic.scope.class">basic.scope.class</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>15 Sep 1998<BR>





<P>Consider this code:</P>
<PRE>
    struct Base {
        enum { a, b, c, next };
    };

    struct Derived : public Base {
        enum { d = Base::next, e, f, next };
    };

</PRE>
The idea is that the enumerator "next" in each class is the next available
value for enumerators in further derived classes.

<P>If we had written</P>
<PRE>
    enum { d = next, e, f, next };

</PRE>
I think we would run afoul of 6.4.7 [<A href="https://wg21.link/basic.scope.class">basic.scope.class</A>]
:
<BLOCKQUOTE>A name <TT>N</TT> used in a class <TT>S</TT> shall refer to
the same declaration in its context and when re-evaluated in the completed
scope of <TT>S</TT>. No diagnostic is required for a violation of this
rule.</BLOCKQUOTE>
But in the original code, we don't have an unqualified "next" that refers
to anything but the current scope. I think the intent was to allow the
code, but I don't find the wording clear on on that point.

<P>Is there another section that makes it clear whether the original code
is valid? Or am I being obtuse? Or should the quoted section say "An unqualified
name N used in a class ..."?</P>

<P>
<B>Rationale (04/99):</B> It is sufficiently clear that "name"
includes qualified names and hence the usual lookup rules make this
legal.</P>
<BR><BR><HR>
<A NAME="1429"></A><H4>1429.
  
Scope of a member template's template parameter
</H4>
<B>Section: </B>6.4.9&#160; [<A href="https://wg21.link/basic.scope.temp">basic.scope.temp</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-12-09<BR>




<P>Consider:</P>

<PRE>
    struct A {
        struct B { typedef int X; };
    };

    template&lt;class B&gt; struct C : A {
        B::X q; // Ok: A::B.
        struct U { typedef int X; };
        template&lt;class U&gt;
            struct D;
    };

    template&lt;class B&gt;
    template&lt;class U&gt;
    struct C&lt;B&gt;::D {
        typename U::X r; // which U?
    };

    C&lt;int&gt;::D&lt;double&gt; y;
</PRE>

<P>In the definition of <TT>D</TT>, <TT>U</TT> definitely needs
to be in scope as soon as it's declared because it might have
been used in subsequent template parameter declarations, or it
might have been used in the <I>id-expression</I> that names the
declared entity &#8212; just as <TT>B</TT> is used in
<TT>C&lt;B&gt;::D</TT>. (So 6.4.9 [<A href="https://wg21.link/basic.scope.temp">basic.scope.temp</A>] does the right
thing for that purpose.)</P>

<P>But it would be nice if the result of lookup did not depend on
whether <TT>D</TT>'s body appears lexically inside <TT>C</TT>'s body;
currently, we don't seem to have the wording that makes it
so.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>This example is covered by the wording in 13.8.2 [<A href="https://wg21.link/temp.local">temp.local</A>]
paragraphs 7-8: the template parameter is found.</P>

<BR><BR><HR>
<A NAME="2078"></A><H4>2078.
  
Name lookup of <I>mem-initilizer-id</I>
</H4>
<B>Section: </B>6.5.2&#160; [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-01-31<BR>




<P>The name lookup in a <I>base-specifier</I> and a
<I>mem-initializer</I> differ in that the former ignores non-type
names but the latter does not.  When the <I>mem-initializer-id</I>
is qualified, this can lead to surprising results:</P>

<PRE>
  struct file_stat : ::stat {    //<SPAN CLASS="cmnt"> the class</SPAN>
    file_stat() : ::stat{} {}    //<SPAN CLASS="cmnt"> the function</SPAN>
  };
</PRE>

<P><B>Rationale (May, 2015):</B></P>

<P>The use of a <I>qualified-id</I> as a <I>mem-initializer-id</I>
is sufficiently unusual that it is not worth changing the lookup
rules to accommodate it.</P>

<BR><BR><HR>
<A NAME="2567"></A><H4>2567.
  
Operator lookup ambiguity
</H4>
<B>Section: </B>6.5.2&#160; [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-04-01<BR>




<P>Consider:</P>

<PRE>
  struct B1 {
    bool operator==(B1 const&amp;) const;
  };
  struct B2 {
    bool operator==(B2 const&amp;) const;
  };
  struct D: B1, B2 {} d;
  bool operator==(D const&amp;, D const&amp;);

  auto r = d == d; //<SPAN CLASS="cmnt"> ambiguous?</SPAN>
</PRE>

<P>There is implementation divergence in handling this example; some
implementations select the non-member operator, others diagnose an
ambiguous lookup.</P>

<P>Member name lookup for <TT>operator==</TT> is ambiguous, making the
program ill-formed per 6.5.2 [<A href="https://wg21.link/class.member.lookup#6">class.member.lookup</A>] paragraph 6:</P>

<BLOCKQUOTE>

The result of the search is the declaration set of S(N, T). If it is
an invalid set, the program is ill-formed.

</BLOCKQUOTE>

<P>There is no provision for simply failing if the lookup is invoked
as part of some larger lookup, as in the case of a lookup for an
overloaded operator (12.2.2.3 [<A href="https://wg21.link/over.match.oper#3">over.match.oper</A>] paragraph 3):</P>

<BLOCKQUOTE>

For a unary operator @ with an operand of type cv1 T1, and for a
binary operator @ with a left operand of type cv1 T1 and a right
operand of type cv2 T2, four sets of candidate functions, designated
<I>member candidates</I>, <I>non-member candidates</I>, <I>built-in
candidates</I>, and <I>rewritten candidates</I>, are constructed as
follows:

<UL>
<LI>If T1 is a complete class type or a class currently being defined,
the set of member candidates is the result of a search
for <TT>operator@</TT> in the scope of T1; otherwise, ....</LI>

<LI>For the operators =, [], or -&gt;, the set of non-member
candidates is empty; otherwise, it includes the result of unqualified
lookup for <TT>operator@</TT> in the rewritten function call
(6.5.3 [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>], 6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]), ignoring all
member functions. ...</LI>

<LI>For the operator <TT>,</TT>, the unary operator <TT>&amp;</TT>, or
the operator <TT>-&gt;</TT>, the built-in candidates set is empty.
For all other operators, the built-in candidates include all of the
candidate operator functions defined in 12.5 [<A href="https://wg21.link/over.built">over.built</A>] that
...</LI>

<LI>The rewritten candidate set is determined as follows: ...</LI>

</UL>

</BLOCKQUOTE>

<P>It is unclear whether that is intended or desirable.</P>

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

<P>Change in 6.5.2 [<A href="https://wg21.link/class.member.lookup#6">class.member.lookup</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<DEL>The result of the search is</DEL> <INS>If</INS> the declaration set of S(N, T)<DEL>. If it</DEL> is
<DEL>an</DEL> invalid <DEL>set</DEL>, <DEL>the program is ill-formed</DEL>
<INS>the result of the
search is an empty set; otherwise, the result is that set.</INS>

</BLOCKQUOTE>

<P><B>Rationale (CWG 2023-06-17)</B></P>

<P>Changing the lookup rules to yield an empty set has undesirable
effects on non-operator lookup, where fall-back to non-member lookup
is actually desired.  The intended outcome for the example is as
specified (i.e. the program is ill-formed).  The example can be
addressed by making <TT>operator==</TT> a member of <TT>D</TT>.</P>

<BR><BR><HR>
<A NAME="192"></A><H4>192.
  
Name lookup in parameters
</H4>
<B>Section: </B>6.5.3&#160; [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alan Nash
 &#160;&#160;&#160;

 <B>Date: </B>6 Jan 2000<BR>





<P>The description of name lookup in the
<I>parameter-declaration-clause</I> of member functions in
6.5.3 [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>]
paragraphs 7-8 is
flawed in at least two regards.</P>

<P>First, both paragraphs 7 and 8 apply to the
<I>parameter-declaration-clause</I> of a member function definition
and give different rules for the lookup.  Paragraph 7 applies to names
"used in the definition of a class <TT>X</TT> outside of a member
function body...," which includes the
<I>parameter-declaration-clause</I> of a member function definition,
while paragraph 8 applies to names following the function's
<I>declarator-id</I> (see the proposed resolution of
<A HREF="cwg_defects.html#41">issue 41</A>), including the
<I>parameter-declaration-clause</I>.</P>

<P>Second, paragraph 8 appears to apply to the type names used in the
<I>parameter-declaration-clause</I> of a member function defined
inside the class definition.  That is, it appears to allow the
following code, which was not the intent of the Committee:</P>

<PRE>
    struct S {
        void f(I i) { }
        typedef int I;
    };
</PRE>

<P><B>Additional note, January, 2012:</B></P>

<P>
<I>brace-or-equal-initializer</I>s for non-static data members are
intended effectively as syntactic sugar for <I>mem-initializer</I>s in
constructor definitions; the lookup should be the same.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>This issue was resolved by the resolution of
<A HREF="cwg_defects.html#1352">issue 1352</A>.</P>

<BR><BR><HR>
<A NAME="231"></A><H4>231.
  
Visibility of names after <I>using-directive</I>s
</H4>
<B>Section: </B>6.5.3&#160; [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>J&#246;rg Barfurth
 &#160;&#160;&#160;

 <B>Date: </B>31 May 2000<BR>


<P>The wording of 6.5.3 [<A href="https://wg21.link/basic.lookup.unqual#2">basic.lookup.unqual</A>] paragraph 2 is
misleading.  It says:</P>

<BLOCKQUOTE>

The declarations from the namespace nominated by a
<I>using-directive</I> become visible in a namespace enclosing the
<I>using-directive</I>; see 9.9.4 [<A href="https://wg21.link/namespace.udir">namespace.udir</A>].

</BLOCKQUOTE>

<P>According to 9.9.4 [<A href="https://wg21.link/namespace.udir#1">namespace.udir</A>] paragraph 1, that
namespace is</P>

<BLOCKQUOTE>

the nearest enclosing namespace which contains both the
<I>using-directive</I> and the nominated namespace.

</BLOCKQUOTE>

<P>That would seem to imply the following:</P>

<PRE>
    namespace outer {
        namespace inner {
            int i;
        }
        void f() {
            using namespace inner;
        }
        int j = i;   // inner::i is "visible" in namespace outer
    }
</PRE>

<P>
<B>Suggested resolution:</B> Change the first sentence of
6.5.3 [<A href="https://wg21.link/basic.lookup.unqual#2">basic.lookup.unqual</A>] paragraph 2 to read:</P>

<BLOCKQUOTE>

The declarations from the namespace nominated by a
<I>using-directive</I> become visible in the scope in which the
<I>using-directive</I> appears after the <I>using-directive</I>.

</BLOCKQUOTE>

<P><B>Notes from the 4/02 meeting:</B></P>

<P>After a lot of discussion of possible wording changes, we decided
the wording should be left alone.  6.5.3 [<A href="https://wg21.link/basic.lookup.unqual#2">basic.lookup.unqual</A>] paragraph 2
is not intended to be a full specification; that's in
9.9.4 [<A href="https://wg21.link/namespace.udir#1">namespace.udir</A>] paragraph 1.  See also
6.4.6 [<A href="https://wg21.link/basic.scope.namespace#1">basic.scope.namespace</A>] paragraph 1.</P>

<BR><BR><HR>
<A NAME="1906"></A><H4>1906.
  
Name lookup in member <TT>friend</TT> declaration
</H4>
<B>Section: </B>6.5.3&#160; [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-03-30<BR>




<P>According to 6.5.3 [<A href="https://wg21.link/basic.lookup.unqual#10">basic.lookup.unqual</A>] paragraph 10,</P>

<BLOCKQUOTE>

In a <TT>friend</TT> declaration naming a member function, a name used in the
function declarator and not part of a <I>template-argument</I> in
the <I>declarator-id</I> is first looked up in the scope of the member
function's class (6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]). If it is not found, or if the
name is part of a <I>template-argument</I> in the <I>declarator-id</I>, the
look up is as described for unqualified names in the definition of the
class granting friendship.

</BLOCKQUOTE>

<P>The corresponding specification for non-<TT>friend</TT> declarations
in paragraph 8 applies the class-scope lookup only to names that
follow the <I>declarator-id</I>.  The same should be true in
<TT>friend</TT> declarations.</P>

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

<OL>
<LI><P>Change 6.5.3 [<A href="https://wg21.link/basic.lookup.unqual#8">basic.lookup.unqual</A>] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

<P>For the members of a class <TT>X</TT>, a name used in a member function
body, in a default argument, in a <I>noexcept-specifier</I>, in
the <I>brace-or-equal-initializer</I> of a non-static data member
(11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]), or in the <DEL>definition</DEL>
<INS>declaration</INS> of a class member outside of the definition
of <TT>X</TT><DEL>,</DEL> following the
member's <I>declarator-id</I><SUP>32</SUP>, shall be declared in one of the
following ways:</P>

<UL>
<LI><P>before its use in the block in which it is used or in an
enclosing block (8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>]) <INS>within the body of the
member function</INS>, or</P></LI>

<LI><P>
<DEL>shall be</DEL> <INS>as</INS> a member of class <TT>X</TT>
or <DEL>be</DEL> <INS>as</INS> a member of a base class of <TT>X</TT>
(6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]), or</P></LI>

<LI><P>if <TT>X</TT> is a nested class of class <TT>Y</TT>
(11.4.12 [<A href="https://wg21.link/class.nest">class.nest</A>]), shall be a member of <TT>Y</TT>, or shall be
a member of a base class of <TT>Y</TT> (this lookup applies in turn
to <TT>Y</TT>'s enclosing classes, starting with the innermost enclosing
class),<SUP>33</SUP> or</P></LI>

<LI><P>if <TT>X</TT> is a local class (11.6 [<A href="https://wg21.link/class.local">class.local</A>]) or is a
nested class of a local class, before the definition of class <TT>X</TT> in
a block enclosing the definition of class <TT>X</TT>, or</P></LI>

<LI><P>if <TT>X</TT> is a member of namespace <TT>N</TT>, or is a nested
class of a class that is a member of <TT>N</TT>, or is a local class or a
nested class within a local class of a function that is a member
of <TT>N</TT>, before the use of the name, in namespace <TT>N</TT> or in
one of <TT>N</TT>'s enclosing namespaces<DEL>.</DEL><INS>, or</INS>
</P></LI>

<LI><P><INS>for a friend declaration in a class <TT>Y</TT>, in a scope that
would be searched for a name appearing within <TT>Y</TT>.</INS></P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Delete 6.5.3 [<A href="https://wg21.link/basic.lookup.unqual#10">basic.lookup.unqual</A>] paragraph 10 and combine its
example with that of paragraph 8:</P></LI>

<BLOCKQUOTE>

<P><DEL>In a <TT>friend</TT> declaration naming a member function, a name
used in the function declarator and not part of a <I>template-argument</I>
in the <I>declarator-id</I> is first looked up in the scope of the member
function's class (6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]). If it is not found, or if the
name is part of a <I>template-argument</I> in the <I>declarator-id</I>, the
look up is as described for unqualified names in the definition of the
class granting friendship. [<I>Example:</I></DEL></P>

<PRE>
<DEL>  struct A {
    typedef int AT;
    void f1(AT);
    void f2(float);
    template &lt;class T&gt; void f3();
  };
  struct B {
    typedef char AT;
    typedef float BT;
    friend void A::f1(AT);     //<SPAN CLASS="cmnt"> parameter type is A::AT</SPAN>
    friend void A::f2(BT);     //<SPAN CLASS="cmnt"> parameter type is B::BT</SPAN>
    friend void A::f3&lt;AT&gt;(); //<SPAN CLASS="cmnt"> template argument is B::AT</SPAN>
  };</DEL>
</PRE>

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

</BLOCKQUOTE>

</OL>

<P><B>Notes from the February, 2018 teleconference:</B></P>

<P>There was some concern as to whether the added lookup for friend
function declarations placed the additional lookups in the correct sequence
relative to the existing lookups and whether the new specification reflects
any existing practice. </P>

<P><B>Rationale (March, 2018):</B></P>

<P>After further discussion, CWG determined that the semantics described in
the existing wording were the most appropriate out of the alternatives
considered.</P>

<BR><BR><HR>
<A NAME="2357"></A><H4>2357.
  
Lookup in member function declarations
</H4>
<B>Section: </B>6.5.3&#160; [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2017-09-07<BR>


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

<PRE>
  template &lt;typename T&gt;
  void doit(const T&amp; t, const T&amp; t2) { }

  template &lt;typename T&gt;
  struct Container {
    auto doit(Container&lt;T&gt; &amp;rhs)
    noexcept(noexcept(doit(T{}, T{})))
       -&gt; decltype(doit(T{}, T{}));
  };

  Container&lt;int&gt; c;
</PRE>

<P>This would appear to be ill-formed because the exception specification
is a delayed-parse region, where the lookup is in the context of the
completed class, while the lookup in the <TT>decltype</TT> in the return
type is done immediately. The latter should find the two-parameter
version of <TT>doit</TT>, as expected, while the former finds the
member, one-parameter version. Current implementations accept the code,
however, and it seems unfortunate that the meaning would be different in
the two contexts.</P>

<P><B>Rationale, June, 2018:</B></P>

<P>The example is ill-formed: the reference to <TT>doit</TT> in the
return type would refer to the member function in the completed class,
which is ill-formed, no diagnostic required, per 6.4.7 [<A href="https://wg21.link/basic.scope.class#2">basic.scope.class</A>] paragraph 2.
</P>

<BR><BR><HR>
<A NAME="91"></A><H4>91.
  
A union's associated types should include the union itself
</H4>
<B>Section: </B>6.5.4&#160; [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2 Feb 1999<BR>





<P>When a union is used in argument-dependent lookup, the union's type
is not an associated class type. Consequently, code like this will fail
to work.</P>
<PRE>
    union U {
        friend void f(U);
    };

    int main() {
        U u;
        f(u);  // error: no matching f &#8212; U is not an associated class
    }
</PRE>
Is this an error in the description of unions in argument-dependent lookup?

<P>Also, this section is written as if unions were distinct from classes.
So adding unions to the "associated classes" requires either rewriting
the section so that "associated classes" can include unions, or changing
the term to be more inclusive, e.g. "associated classes and unions" or
"associated types".</P>

<P>
<U>Jason Merrill</U>: Perhaps in both cases, the standard text was intended
to only apply to anonymous unions.</P>

<P>
<U>Liam Fitzpatrick</U>: One cannot create expressions of an
anonymous union type.</P>

<P>
<B>Rationale (04/99):</B> Unions are class types, so the example is
well-formed. Although the wording here could be improved, it does not rise
to the level of a defect in the Standard.</P>
<BR><BR><HR>
<A NAME="225"></A><H4>225.
  
Koenig lookup and fundamental types
</H4>
<B>Section: </B>6.5.4&#160; [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Derek Inglis
 &#160;&#160;&#160;

 <B>Date: </B>26 Jan 2000<BR>


<P>In discussing <A HREF="cwg_defects.html#197">issue 197</A>, the question
arose as to whether the handling of fundamental types in
argument-dependent lookup is actually what is desired.  This question
needs further discussion.</P>

<P><B>Rationale (March, 2011):</B></P>

<P>There does not seem to be sufficient motivation at this point,
with an additional eleven years' experience, to make a change.</P>
<BR><BR><HR>
<A NAME="384"></A><H4>384.
  
Argument-dependent lookup and operator functions
</H4>
<B>Section: </B>6.5.4&#160; [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>18 Sept 2002<BR>




<P>I believe the following code example should unambiguously call the
member operator+. Am I right?</P>
<PRE>
  //--- some library header ---
  //
  namespace N1 {
    template&lt;class T&gt; struct Base { };

    template&lt;class T&gt; struct X {
      struct Y : public Base&lt;T&gt; {     // here's a member operator+
        Y operator+( int _Off ) const { return Y(); }
      };

      Y f( unsigned i ) { return Y() + i; } // the "+" in question
    };
  }

  //--- some user code ---
  //
  namespace N2 {
    struct Z { };

    template&lt;typename T&gt;              // here's another operator+
    int* operator+( T , unsigned ) { static int i ; return &amp;i ; }
  }

  int main() {
    N1::X&lt; N2::Z &gt; v;
    v.f( 0 );
  }
</PRE>
<P>My expectation is that 6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 would govern, specifically:
<BLOCKQUOTE>
  If the ordinary unqualified lookup of the name finds the
  declaration of a class member function, the associated
  namespaces and classes are not considered.
</BLOCKQUOTE>
So I think the member should hide the otherwise-better-matching one in
the associated namespace. Here's what compilers do:</P>

<P>  Agree with me and call the member operator+:
    Borland 5.5, Comeau 4.3.0.1, EDG 3.0.1, Metrowerks 8.0, MSVC 6.0</P>

<P>  Disagree with me and try to call N2::operator+:
    gcc 2.95.3, 3.1.1, and 3.2; MSVC 7.0</P>

<P>Simple so far, but someone tells me that 12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
muddies the waters.
There, paragraph 10 summarizes that subclause:
<BLOCKQUOTE>
  [Note: the lookup rules for operators in expressions are
  different than the lookup rules for operator function names
  in a function call, ...
</BLOCKQUOTE>
In particular, consider the above call to "Y() + unsigned" and please
help me step through 12.2.2.3 [<A href="https://wg21.link/over.match.oper#3">over.match.oper</A>] paragraph 3:
<BLOCKQUOTE>
  ... for a binary operator @ with a left operand of a type whose
  cv-unqualified version is T1 and a right operand of a type
  whose cv-unqualified version is T2,
</BLOCKQUOTE>
OK so far, here @ is +, and T1 is N1::X::Y.
<BLOCKQUOTE>
  three sets of candidate functions, designated member candidates,
  non-member candidates and built-in candidates, are constructed
  as follows:
</BLOCKQUOTE>
[and later are union'd together to get the candidate list]
<BLOCKQUOTE>
  If T1 is a class type, the set of member candidates is the result
  of the qualified lookup of T1::operator@ (over.call.func);
  otherwise, the set of member candidates is empty.
</BLOCKQUOTE>
So there is one member candidate, N1::X::Y::operator+.
<BLOCKQUOTE>
  The set of non-member candidates is the result of the unqualified
  lookup of operator@ in the context of the expression according to
  the usual rules for name lookup in unqualified function calls
  (basic.lookup.argdep) except that all member functions are ignored.
</BLOCKQUOTE>
</P>

<P>*** This is the question: What does that last phrase mean? Does it mean:</P>

<P>a) first apply the usual ADL rules to generate a candidate list, then
ignore any member functions in that list (this is what I believe and
hope it means, and in particular it means that the presence of a member
will suppress names that ADL would otherwise find in the associated
namespaces); or</P>

<P>b) something else?</P>

<P>In short, does N2::operator+ make it into the candidate list? I think it
shouldn't. Am I right?</P>

<P>
<U>John Spicer</U>:
I believe that the answer is sort-of "a" above.  More specifically, the
unqualified lookup consists of a "normal" unqualified lookup and ADL.
ADL always deals with only namespace members, so the "ignore members
functions" part must affect the normal lookup, which should ignore class
members when searching for an operator.</P>

<P>I suspect that the difference between compilers may have to do with details
of argument-dependent lookup.  In the example given, the argument types
are "N1::X&lt;N2::Z&gt;::Y" and "unsigned int".  In order for N2::operator+ to
be a candidate, N2 must be an associated namespace.</P>

<P>N1::X&lt;N2::Z&gt;::Y is a class type, so
6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>] says that its associated classes are
its direct and indirect base classes, and its namespaces are the namespaces
of those classes.  So, its associated namespace is just N1.</P>

<P>6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>] also says:
<BLOCKQUOTE>
If T is a template-id, its associated namespaces and classes are the
    namespace  in  which  the template is defined; for member templates,
    the member template's class; the namespaces and  classes  associated
    with  the types of the template arguments provided for template type
    parameters (excluding template template parameters); the  namespaces
    in  which  any  template  template  arguments  are  defined; and the
    classes in which any member  templates  used  as  template  template
    arguments  are  defined.   [Note: non-type template arguments do not
    contribute to the set of associated namespaces.  ]
</BLOCKQUOTE>
First of all, there is a problem with the term "is a template-id".  template-id
is a syntactic constuct and you can't really talk about a type being a
template-id.  Presumably, this is intended to mean "If T is the type of a
class template specialization ...".
But does this apply to N1::X&lt;N2::Z&gt;::Y?
Y is a class nested within a class template specialization.  In addition,
its base class is a class template specialization.</P>

<P>I think this raises two issues:</P>
<OL>
<LI>
Should the enclosing class(es) of a class, and their template argument lists
 (if any) contribute to the associated classes/namespaces for ADL?</LI>

<LI>Should the template argument lists of base classes contribute to the
   associated classes/namespaces for ADL?</LI>
</OL>

<P><B>Notes from the April 2003 meeting:</B></P>

<P>The ADL rules in the standard sort of look at if they are fully
recursive, but in fact they are not; in some cases, enclosing classes
and base classes are considered, and in others they are not.
Microsoft and g++ did fully-recursive implementations, and
EDG and IBM did it the other way.  Jon Caves reports that Microsoft saw
no noticeable difference (e.g., no complaints from customers
internal or external) when they made this change, so we believe
that even if the rules are imperfect the way they are in the
standard, they are clear and the imperfections are small enough
that programmers will not notice them.  Given that, it seemed
prudent to make no changes and just close this issue.</P>

<P>The template-id issue is spun off as
<A HREF="cwg_defects.html#403">issue 403</A>.</P>

<BR><BR><HR>
<A NAME="2136"></A><H4>2136.
  
Argument-dependent lookup and initializer lists
</H4>
<B>Section: </B>6.5.4&#160; [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Ryou Ezoe
 &#160;&#160;&#160;

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




<P>Argument-dependent lookup does not consider the elements of
an initializer list used as an argument. This seems inconsistent:
</P>

<PRE>
  namespace NS {
    struct X { } ;
    void f( std::initializer_list&lt;X&gt; ) { }
  }

  int main() {
    NS::X x ;
    //<SPAN CLASS="cmnt"> ADL fails to find </SPAN>NS::f
    f( {x,x,x} ) ;

    //<SPAN CLASS="cmnt"> OK. ADL finds </SPAN>NS::f
    auto i = {x,x,x} ;
    f( i ) ;

    //<SPAN CLASS="cmnt"> Also OK</SPAN>
    f( std::initializer_list&lt;NS::X&gt;{x,x,x} ) ;
  }
</PRE>

<P><B>Rationale (October, 2015):</B></P>

<P>Argument-dependent lookup makes sense when the arguments
correspond to actual parameters of the function.  In the
case of an initializer list, however, the elements of the
initializer list need not bear any relationship to the
actual parameter type of the function; instead, they
provide values for aggregate initialization or construction
of the object being initialized, and there is no reason
to expect that that type will have the same associated
namespace as the types of the elements of the initializer
list.</P>

<BR><BR><HR>
<A NAME="2142"></A><H4>2142.
  
Missing definition of associated classes and namespaces
</H4>
<B>Section: </B>6.5.4&#160; [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-06-13<BR>




<P>One would expect to find a definition of the terms
&#8220;associated class&#8221; and &#8220;associated
namespace&#8221; in 6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>], but there
is none.  Note also that &#8220;associated class&#8221; is
used in a different sense in 7.6.10 [<A href="https://wg21.link/expr.eq">expr.eq</A>]
bullet 3.6, and that drafting being proposed for other
issues also uses the term differently.</P>

<P><B>Rationale (October, 2015):</B></P>

<P>CWG felt that the current usage is plain English, not a
technical term, and is clear enough.</P>

<BR><BR><HR>
<A NAME="635"></A><H4>635.
  
Names of constructors and destructors of templates
</H4>
<B>Section: </B>6.5.5.2&#160; [<A href="https://wg21.link/class.qual">class.qual</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>23 May 2007<BR>




<P>There is a discrepancy between the syntaxes allowed for defining a
constructor and a destructor of a class template.  For example:</P>

<PRE>
    template &lt;class&gt; struct S { S(); ~S (); };
    template &lt;class T&gt; S&lt;T&gt;::S&lt;T&gt;() { }        // error
    template &lt;class T&gt; S&lt;T&gt;::~S&lt;T&gt;() { }       // okay
</PRE>

<P>The reason for this is that 6.5.5.2 [<A href="https://wg21.link/class.qual#2">class.qual</A>] paragraph 2
says that <TT>S::S</TT> is &#8220;considered to name
the constructor,&#8221; which is not a template and thus cannot
accept a template argument list.  On the other hand, the
second <TT>S</TT> in <TT>S::~S</TT> finds the
injected-class-name, which &#8220;can be used with or without a
<I>template-argument-list</I>&#8221; (13.8.2 [<A href="https://wg21.link/temp.local#1">temp.local</A>] paragraph 1)
 and thus satisfies the requirement to name the
destructor's class (11.4.7 [<A href="https://wg21.link/class.dtor#1">class.dtor</A>] paragraph 1).</P>

<P>Would it make sense to allow the <I>template-argument-list</I>
in the constructor declaration and thus make the language just a
little easier to use?</P>

<P><B>Rationale (July, 2007):</B></P>

<P>The CWG noted that the suggested change would be confusing in the
case where the class template had both template and non-template
constructors.</P>

<BR><BR><HR>
<A NAME="132"></A><H4>132.
  
Local types and linkage
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>25 June 1999<BR>





<P>6.7 [<A href="https://wg21.link/basic.link#8">basic.link</A>] paragraph 8
says,</P>

<BLOCKQUOTE>
A name with no linkage (notably, the name of a class or enumeration
declared in a local scope
(6.4.3 [<A href="https://wg21.link/basic.scope.block">basic.scope.block</A>]
)) shall not be
used to declare an entity with linkage.
</BLOCKQUOTE>

This wording does not, but should, prohibit use of an unnamed local
type in the declaration of an entity with linkage.  For example,

<PRE>
    void f() {
        extern struct { } x;  // currently allowed
    }
</PRE>

<P>
<B>Proposed resolution:</B> Change the text in
6.7 [<A href="https://wg21.link/basic.link#8">basic.link</A>] paragraph 8 from:</P>

<BLOCKQUOTE>A name with no linkage (notably, the name of a class or enumeration
declared in a local scope (6.4.3 [<A href="https://wg21.link/basic.scope.block">basic.scope.block</A>])) shall not be used to declare an entity
with linkage.</BLOCKQUOTE>
to:
<BLOCKQUOTE>A name with no linkage (notably, the name of a class or enumeration
declared in a local scope (6.4.3 [<A href="https://wg21.link/basic.scope.block">basic.scope.block</A>])) or an unnamed type shall not be used
to declare an entity with linkage.</BLOCKQUOTE>
In section 6.7 [<A href="https://wg21.link/basic.link#8">basic.link</A>] paragraph 8, add to the example, before the
closing brace of function <TT>f</TT>:
<BLOCKQUOTE>
<TT>extern struct {} x;&#160;&#160;&#160; //</TT> <I>ill-formed</I>
</BLOCKQUOTE>

<P>
<B>Rationale (10/00):</B> The proposed change would have introduced
an incompatibility with the C language.  For example, the global
declaration</P>

<PRE>
    static enum { A, B, C } abc;
</PRE>

<P>represents an idiom that is used in C but would be prohibited
under this resolution.</P>

<BR><BR><HR>
<A NAME="278"></A><H4>278.
  
External linkage and nameless entities
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>12 Apr 2000<BR>




<P>It is unclear to what extent entities without names match
across translation units.  For example,</P>

<PRE>
    struct S {
       int :2;
       enum { a, b, c } x;
       static class {} *p;
    };
</PRE>

<P>If this declaration appears in multiple translation units, are
all these members "the same" in each declaration?</P>

<P>A similar question can be asked about non-member declarations:</P>

<PRE>
    // Translation unit 1:
    extern enum { d, e, f } y;

    // Translation unit 2:
    extern enum { d, e, f } y;

    // Translation unit 3:
    enum { d, e, f } y;
</PRE>

<P>Is this valid C++?  Is it valid C?</P>

<P>
<U>James Kanze</U>: <TT>S::p</TT> cannot be defined, because to
do so requires a type specifier and the type cannot be named.
<TT>::y</TT> is valid C because C only requires compatible, not
identical, types.  In C++, it appears that there is a new type in
each declaration, so it would not be valid.  This differs from
<TT>S::x</TT> because the unnamed type is part of a named type
&#8212; but I don't know where or if the Standard says that.</P>

<P>
<U>John Max Skaller</U>:
It's not valid C++, because the type is a synthesised, unique name
for the enumeration type which differs across translation units, as if:</P>

<PRE>
    extern enum _synth1 { d,e,f} y;
    ..
    extern enum _synth2 { d,e,f} y;
</PRE>

<P>had been written.</P>

<P>However, within a class, the ODR implies the types are the same:</P>

<PRE>
    class X { enum { d } y; };
</PRE>

<P>in two translation units ensures that the type of member <TT>y</TT>
is the same: the two <TT>X</TT>'s obey the ODR and so denote the same class,
and it follows that there's only one member <TT>y</TT> and one type that it
has.</P>

<P>(See also issues <A HREF="cwg_closed.html#132">132</A> and
<A HREF="cwg_defects.html#216">216</A>.)</P>

<P><B>Rationale (February, 2021):</B></P>

<P>The resolution of <A HREF="cwg_defects.html#2300">issue 2300</A>
and paper P2115R0 have resolved these questions.</P>

<BR><BR><HR>
<A NAME="2230"></A><H4>2230.
  
Linkage of <TT>extern "C"</TT> function in unnamed namespace
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-03-09<BR>




<P>Consider:</P>

<PRE>
  namespace {
    extern "C" void f() { }
  }
</PRE>

<P>Does <TT>f</TT> have internal or external linkage?  Implementations
seem to give <TT>f</TT> external linkage, but the standard prescribes
internal linkage per 6.7 [<A href="https://wg21.link/basic.link#4">basic.link</A>] paragraph 4.</P>

<P><B>Rationale (November, 2016):</B></P>

<P>The specification is as intended.</P>

<BR><BR><HR>
<A NAME="1879"></A><H4>1879.
  
Inadequate definition of alignment requirement
</H4>
<B>Section: </B>6.8.3&#160; [<A href="https://wg21.link/basic.align">basic.align</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-02-24<BR>




<P>For certain data types on some hardware, a given object can
be accessed most efficiently with one alignment but can be
successfully accessed if allocated at a less-stringent boundary.
Should the Standard specify the minimum or the preferred alignment
as the value of the <TT>alignof</TT>?</P>

<P><B>Rationale (June, 2014):</B></P>

<P>The existing wording is clear that the result <TT>alignof</TT>
is the minimal alignment.  If an operator returning the preferred
alignment is desired, that request should be addressed to EWG.</P>

<BR><BR><HR>
<A NAME="234"></A><H4>234.
  
Reuse of base class subobjects
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bill Wade
 &#160;&#160;&#160;

 <B>Date: </B>28 Jun 2000<BR>


<P>6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>] and 11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>] discuss
explicit management of object lifetime.  It seems clear that most
object lifetime issues apply to sub-objects (array elements, and data
members) as well.  The standard supports</P>

<PRE>
     struct X { T t } x;
     T* pt = &amp;x.t;
     pt-&gt;~T();
     new(pt) T;
</PRE>

<P>and this kind of behavior is useful  in allocators.</P>

<P>However the standard does not seem to prohibit the same operations
on base sub-objects.</P>

<PRE>
   struct D: B{ ... } d;
   B* pb = &amp;d;
   pb-&gt;~B();
   new(pb) B;
</PRE>

<P>However if <TT>B</TT> and/or <TT>D</TT> have virtual member
functions or virtual bases, it is unlikely that this code will result
in a well-formed <TT>D</TT> object in current implementations (note
that the various lines may be in different functions).</P>

<P>
<B>Suggested resolution:</B> 11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>] should be
modified so that explicit destruction of base-class sub-objects be
made illegal, or legal only under some restrictive conditions.</P>

<P><B>Rationale (04/01):</B></P>

<P>Reallocation of a base class subobject is already disallowed
by 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7.</P>

<BR><BR><HR>
<A NAME="1050"></A><H4>1050.
  
Effects of thread support on object lifetime
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hans Boehm
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-11<BR>


<P>6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>] was never adjusted for threads.  In particular,
it describes what may be done with objects in various intervals.  In
general when the Standard uses words like &#8220;during,&#8221; it is
referring to intervals defined by &#8220;sequenced before&#8221; ordering.
In this context, however, all the specifications need to use the
&#8220;happens before&#8221; ordering.</P>

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

<P>Add the following at the beginning of 6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]:</P>

<BLOCKQUOTE>

All statements about the ordering of evaluations in this section,
using words like &#8220;before,&#8221; &#8220;after,&#8221; and
&#8220;during,&#8221; refer to the &#8220;happens before&#8221;
order defined in 6.10.2 [<A href="https://wg21.link/intro.multithread">intro.multithread</A>]. [<I>Note:</I> We
ignore situations in which evaluations are unordered by
&#8220;happens before,&#8221; since these require a data race
(6.10.2 [<A href="https://wg21.link/intro.multithread">intro.multithread</A>]), which already results in undefined
behavior. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>Rationale (August, 1020):</B></P>

<P>The text is already in the FCD.</P>

<BR><BR><HR>
<A NAME="1280"></A><H4>1280.
  
Object reallocation and reference members
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-27<BR>




<P>The restrictions in 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7 on when
the storage for an object containing a reference member can be reused
seem overly restrictive.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>CWG did not find a persuasive use case for a change to the existing
rules.</P>

<BR><BR><HR>
<A NAME="1285"></A><H4>1285.
  
Trivial destructors and object lifetime
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

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

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




<P>The Standard is self-contradictory regarding which destructor calls
end the lifetime of an object.  6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1
says,</P>

<BLOCKQUOTE>

<P>The lifetime of an object of type T ends when:</P>

<UL>
<LI><P>if <TT>T</TT> is a class type with a non-trivial destructor
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]), the destructor call starts, or
</P></LI>

<LI><P>the storage which the object occupies is reused or released.
</P></LI>

</UL>

</BLOCKQUOTE>

<P>i.e., the lifetime of an object of a class type with a
trivial destructor persists until its storage is reused or released.
However, 11.4.7 [<A href="https://wg21.link/class.dtor#15">class.dtor</A>] paragraph 15 says,</P>

<BLOCKQUOTE>

Once a destructor is invoked for an object, the object no longer
exists; the behavior is undefined if the destructor is invoked for an
object whose lifetime has ended (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]).

</BLOCKQUOTE>

<P>implying that invoking any destructor, even a trivial one, ends
the lifetime of the associated object.  Similarly, 11.9.5 [<A href="https://wg21.link/class.cdtor#1">class.cdtor</A>] paragraph 1
says,</P>

<BLOCKQUOTE>

For an object with a non-trivial destructor, referring to any
non-static member or base class of the object after the destructor
finishes execution results in undefined behavior.

</BLOCKQUOTE>

<P>A similar question arises for
pseudo-destructors for non-class types.</P>

<P><B>Notes from the August, 2011 meeting:</B></P>

<P>CWG will need a paper exploring this topic before it can act on
the issue.</P>



<P><B>Rationale (February, 2021):</B></P>

<P>The resolution of <A HREF="cwg_defects.html#2256">issue 2256</A>
makes it clear that the destruction of an object, no matter
how accomplished, ends its lifetime.</P>

<BR><BR><HR>
<A NAME="2665"></A><H4>2665.
  
Replacing a subobject with a complete object
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-12-06<BR>


<P>Subclause 6.8.4 [<A href="https://wg21.link/basic.life#8.5">basic.life</A>] bullet 8.5 says that o1 is
only transparently replaceable by o2 if</P>

<BLOCKQUOTE>

either o1 and o2 are both complete objects, or o1 and o2 are direct
subobjects of objects p1 and p2, respectively, and p1 is
transparently replaceable by p2.

</BLOCKQUOTE>

<P>This disallows most of the intended uses of the transparent
replacement rule, including example 3 in 11.5.1 [<A href="https://wg21.link/class.union.general">class.union.general</A>],
which is similar to:</P>

<PRE>
  union A { int n; string s; };
  A a;
  //<SPAN CLASS="cmnt"> Does not transparently replace </SPAN>A::s<SPAN CLASS="cmnt"> subobject, because</SPAN>
  //<SPAN CLASS="cmnt"> the created object is a complete object.</SPAN>
  new (&amp;a.s) string("hello");
  string t = a.s;
</PRE>

<P>The rule was changed in response to NB comment US 041 (C++20 CD) in
what appears to be an over-reach: US 041 says that a member subobject
should not transparently replace an unrelated member subobject, but is
silent about complete objects transparently replacing members.</P>

<P><B>CWG 2023-01-06</B></P>

<P>Issues <A HREF="cwg_active.html#2676">2676</A> and
<A HREF="cwg_active.html#2677">2677</A> were split off from this issue.</P>

<P>Subclause 6.8.2 [<A href="https://wg21.link/intro.object#2">intro.object</A>] paragraph 2 specifies that "the
created object is a subobject of [the original] containing object" for
the example above.  This issue is therefore NAD.</P>

<BR><BR><HR>
<A NAME="967"></A><H4>967.
  
Exception specification of replacement allocation function
</H4>
<B>Section: </B>6.8.6.5&#160; [<A href="https://wg21.link/basic.stc.dynamic">basic.stc.dynamic</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>15 September, 2009<BR>




<P>The global allocation functions are implicitly declared in every
translation unit with <I>exception-specification</I>s
(6.8.6.5 [<A href="https://wg21.link/basic.stc.dynamic#2">basic.stc.dynamic</A>] paragraph 2).  It is not clear what
should happen if a replacement allocation function is declared without
an <I>exception-specification</I>.  Is that a conflict with the
implicitly-declared function (as it would be with explicitly-declared
functions, and presumably is if the <TT>&lt;new&gt;</TT> header is
included)?  Or does the new declaration replace the implicit one,
including the lack of an <I>exception-specification</I>?  Or does the
implicit declaration prevail?  (Regardless of the
<I>exception-specification</I> or lack thereof, it is presumably
undefined behavior for an allocation function to exit with an
exception that cannot be caught by a handler of type
<TT>std::bad_alloc</TT> (6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>] paragraph
3).)</P>

<P><B>Rationale (November, 2014):</B></P>

<P>The predeclared allocation functions no longer have an
<I>exception-specification</I>, so formally this issue is no longer
applicable.  As noted in the rationale of
<A HREF="cwg_closed.html#1948">issue 1948</A>, however, the intent is that
the predeclarations are no different from ordinary declarations,
so the replacement functions must have compatible
<I>exception-specification</I>s.</P>

<BR><BR><HR>
<A NAME="1948"></A><H4>1948.
  
<I>exception-specification</I> of replacement global <TT>new</TT>
</H4>
<B>Section: </B>6.8.6.5&#160; [<A href="https://wg21.link/basic.stc.dynamic">basic.stc.dynamic</A>]
 &#160;&#160;&#160;

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

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

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




<P>Some implementations accept code like</P>

<PRE>
  #include &lt;cstddef&gt; //<SPAN CLASS="cmnt"> to get </SPAN>size_t
  void* operator new(std::size_t) noexcept { ... }
</PRE>

<P>This declaration conflicts with the predeclaration of
<TT>operator new</TT> with no <I>exception-specification</I>.</P>

<P>See also <A HREF="cwg_closed.html#967">issue 967</A>.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>The specification intentionally makes such replacement functions
ill-formed.</P>

<BR><BR><HR>
<A NAME="2238"></A><H4>2238.
  
Contradictory alignment requirements for allocation
</H4>
<B>Section: </B>6.8.6.5.2&#160; [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-03-03<BR>


<P>Speaking of the value returned by an allocation function,
6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation#2">basic.stc.dynamic.allocation</A>] paragraph 2 says,</P>

<BLOCKQUOTE>

The pointer returned shall be suitably aligned so that it can be converted
to a pointer of any complete object type with a fundamental alignment
requirement

</BLOCKQUOTE>

<P>However, the various &#8220;<I>Effects</I>&#8221; specifications
in 17.6.3 [<A href="https://wg21.link/new.delete">new.delete</A>] have a different formulation:</P>

<BLOCKQUOTE>

...allocate <TT>size</TT> bytes of storage suitably aligned to represent
any object of that size.

</BLOCKQUOTE>

<P>These should be reconciled.</P>

<P><B>Rationale (November, 2016):</B></P>

<P>The adoption of paper P0035R4 has rendered this issue moot.</P>

<BR><BR><HR>
<A NAME="117"></A><H4>117.
  
Timing of destruction of temporaries
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>14 May 1999<BR>





<P>6.8.7 [<A href="https://wg21.link/class.temporary#4">class.temporary</A>] paragraph 4
seems
self-contradictory:</P>
<BLOCKQUOTE>

the temporary that holds the result of the expression shall persist
until the object's initialization is complete... the temporary
is destroyed after it has been copied, before or when the
initialization completes.

</BLOCKQUOTE>

How can it be destroyed "before the initialization completes" if
it is required to "persist until the object's initialization is
complete?"

<P><B>Rationale (04/00):</B></P>

<P>It was suggested that "before the initialization completes" refers
to the case in which some part of the initialization terminates by
throwing an exception.  In that light, the apparent contradiction does
not apply.</P>

<BR><BR><HR>
<A NAME="1651"></A><H4>1651.
  
Lifetime extension of temporary via reference to subobject
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-04-15<BR>


<P>The resolution of issues <A HREF="cwg_defects.html#616">616</A> and
<A HREF="cwg_defects.html#1213">1213</A>, making the result of a member access or
subscript expression applied to a prvalue an xvalue, means that binding a
reference to such a subobject of a temporary does not extend the
temporary's lifetime. 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>] should be revised to ensure
that it does.</P>

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

<P>This issue is resolved by the resolution of
<A HREF="cwg_defects.html#1299">issue 1299</A>.</P>

<P><B>Rationale (February, 2019):</B></P>

<P>This concern is already covered by 6.8.7 [<A href="https://wg21.link/class.temporary#6">class.temporary</A>] paragraph 6:
</P>

<BLOCKQUOTE>

The temporary object to which the reference is bound or the
temporary object that is the complete object of a subobject
to which the reference is bound persists for the lifetime of
the reference if...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1695"></A><H4>1695.
  
Lifetime extension via <I>init-capture</I>
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-05-31<BR>




<P>If an <I>init-capture</I> binds a const reference to a temporary,
is the lifetime of the temporary extended to match that of the lambda?
For example,</P>

<PRE>
   struct S { ~S(); };
   const S f();
   auto &amp;&amp;lambda = [&amp;x(f())] () -&gt; auto&amp; { return x; };
   auto &amp;y = lambda(); //<SPAN CLASS="cmnt"> ok?</SPAN>
</PRE>

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

<P>CWG agreed that there is no lifetime extension in this example.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>After further consideration, CWG agreed that this example should
extend the lifetime of the temporary (because the notional variable
is a reference) and that the existing text is clear enough in this
regard.</P>

<BR><BR><HR>
<A NAME="290"></A><H4>290.
  
Should memcpy be allowed into a POD with a const member?
</H4>
<B>Section: </B>6.9&#160; [<A href="https://wg21.link/basic.types">basic.types</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Garry Lancaster
 &#160;&#160;&#160;

 <B>Date: </B>12 Jun 2001<BR>


<P>Following the definition in Clause 11 [<A href="https://wg21.link/class#4">class</A>] paragraph 4
the following is a valid POD (actually a POD-struct):</P>

<PRE>
    struct test
    {
        const int i;
    };
</PRE>

<P>The legality of PODs with const members is also implied by the text of
7.6.2.8 [<A href="https://wg21.link/expr.new#15.1">expr.new</A>] bullet 15.1, sub-bullet 2 and
11.9.3 [<A href="https://wg21.link/class.base.init#4.2">class.base.init</A>] bullet 4.2.</P>

<P>6.9 [<A href="https://wg21.link/basic.types#3">basic.types</A>] paragraph 3 states that</P>

<BLOCKQUOTE>
For any POD type
<TT>T</TT>, if two pointers to <TT>T</TT> point to distinct objects
<TT>obj1</TT> and <TT>obj2</TT>, if the value of <TT>obj1</TT> is copied
into <TT>obj2</TT>, using the <TT>memcpy</TT> library function, <TT>obj2</TT>
shall subsequently hold the same value as <TT>obj1</TT>.
</BLOCKQUOTE>

<P><I>[Note: this text was changed by TC1, but the essential point
stays the same.]</I></P>

<P>This implies that the following is required to work:</P>

<PRE>
    test obj1 = { 1 };
    test obj2 = { 2 };
    memcpy( &amp;obj2, &amp;obj1, sizeof(test) );
</PRE>

<P>The memcpy of course changes the value of the const member, surely
something that shouldn't be allowed.</P>

<P><B>Suggested resolution:</B></P>

<P>It is recommended that 6.9 [<A href="https://wg21.link/basic.types#3">basic.types</A>] paragraph 3 be
reworded to exclude PODs which contain (directly or indirectly) members
of const-qualified type.</P>

<P><B>Rationale (October, 2004):</B></P>

<P>9.2.9.2 [<A href="https://wg21.link/dcl.type.cv#4">dcl.type.cv</A>] paragraph 4 already forbids
modifying a const member of a POD struct.  The prohibition need
not be repeated in 6.9 [<A href="https://wg21.link/basic.types">basic.types</A>].</P>

<BR><BR><HR>
<A NAME="646"></A><H4>646.
  
Can a class with a constexpr copy constructor be a literal type?
</H4>
<B>Section: </B>6.9&#160; [<A href="https://wg21.link/basic.types">basic.types</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>9 Aug 2007<BR>




<P>6.9 [<A href="https://wg21.link/basic.types#11">basic.types</A>] paragraph 11 requires that a class
type have a trivial copy constructor in order to be classified as a
literal type.  This seems overly restrictive; presumably having a
constexpr copy constructor would suffice.  (Note that a trivial
copy constructor is a constexpr constructor according to
9.2.6 [<A href="https://wg21.link/dcl.constexpr#4">dcl.constexpr</A>] paragraph 4.)</P>

<P><B>Rationale (June, 2008):</B></P>

<P>A copy constructor takes a reference as its first parameter, thus
no user-declared copy constructor can be constexpr.</P>

<BR><BR><HR>
<A NAME="1334"></A><H4>1334.
  
Layout compatibility and cv-qualification
</H4>
<B>Section: </B>6.9&#160; [<A href="https://wg21.link/basic.types">basic.types</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-06-23<BR>




<P>Should cv-qualified and cv-unqualified versions of fundamental types
be considered to be layout-compatible types?</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The purpose of &#8220;layout compatible&#8221; types in C++ is
for C compatibility with respect to the common initial sequence of
structs appearing in unions.  However, C requires that corresponding
members have compatible types, and compatible types must have the
same cv-qualification.  Consequently, this issue is not a defect.</P>

<BR><BR><HR>
<A NAME="627"></A><H4>627.
  
Values behaving as types
</H4>
<B>Section: </B>6.9.2&#160; [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Gennaro Prota
 &#160;&#160;&#160;

 <B>Date: </B>15 March 2007<BR>


<P>6.9.2 [<A href="https://wg21.link/basic.fundamental#6">basic.fundamental</A>] paragraph 6 states,</P>

<BLOCKQUOTE>

As described below, <TT>bool</TT> values behave as integral types.

</BLOCKQUOTE>

<P>This sentence looks definitely out of order: how can a value behave
as a type?</P>

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

<P>Remove the sentence entirely, as it doesn't supply anything that
isn't already stated in the following paragraphs and in the
referenced section about integral promotion.</P>

<P><B>Rationale (July, 2007):</B></P>

<P>This is, at most, an editorial issue with no substantive
impact.  The suggestion has been forwarded to the project editor
for consideration.</P>

<BR><BR><HR>
<A NAME="1276"></A><H4>1276.
  
Reference to <TT>stdint.h</TT>
</H4>
<B>Section: </B>6.9.2&#160; [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-03-26<BR>




<P>6.9.2 [<A href="https://wg21.link/basic.fundamental#5">basic.fundamental</A>] paragraph 5 refers to a C header instead
of to its C++ equivalent:</P>

<BLOCKQUOTE>

...Types <TT>char16_t</TT> and <TT>char32_t</TT> denote distinct types
with the same size, signedness, and alignment as
<TT>uint_least16_t</TT> and <TT>uint_least32_t</TT>, respectively, in
<TT>&lt;stdint.h&gt;</TT>, called the underlying types.

</BLOCKQUOTE>

<P><B>Rationale (August, 2011)</B></P>

<P>This is an editorial issue that has been transmitted to the project
editor.</P>

<BR><BR><HR>
<A NAME="1448"></A><H4>1448.
  
Integral values of type <TT>bool</TT>
</H4>
<B>Section: </B>6.9.2&#160; [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-01-19<BR>




<P>Although 6.9.2 [<A href="https://wg21.link/basic.fundamental#7">basic.fundamental</A>] paragraph 7 classifies
<TT>bool</TT> as an integral type, the values of <TT>true</TT> and
<TT>false</TT> are not specified &#8212; only that the results of
converting them to another integral type are <TT>1</TT> and
<TT>0</TT>, respectively.  This omission leaves unspecified whether
<TT>false</TT> is an integral null pointer constant or not.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>The resolution of <A HREF="cwg_defects.html#903">issue 903</A> makes it
clear that <TT>false</TT> is not a null pointer constant.</P>

<BR><BR><HR>
<A NAME="1040"></A><H4>1040.
  
Memory model issues
</H4>
<B>Section: </B>6.10.2&#160; [<A href="https://wg21.link/intro.multithread">intro.multithread</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Paul McKinney
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-03<BR>


<P>This issue is for tracking various concerns that are raised in paper
N3057.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>The paper was voted in in Pittsburgh.</P>

<BR><BR><HR>
<A NAME="1470"></A><H4>1470.
  
Thread migration
</H4>
<B>Section: </B>6.10.2&#160; [<A href="https://wg21.link/intro.multithread">intro.multithread</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Detlef Vollman
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-14<BR>




<P>It is not clear from the wording of 6.10.2 [<A href="https://wg21.link/intro.multithread">intro.multithread</A>] that
different statements in the same function cannot be executed by different
threads.</P>

<P><B>Rationale (September, 2013):</B></P>

<P>SG-1 determined that the existing wording is clear enough.</P>

<BR><BR><HR>
<A NAME="1661"></A><H4>1661.
  
Preservation of infinite loops
</H4>
<B>Section: </B>6.10.2&#160; [<A href="https://wg21.link/intro.multithread">intro.multithread</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-04-15<BR>




<P>According to 6.10.2 [<A href="https://wg21.link/intro.multithread#24">intro.multithread</A>] paragraph 24,</P>

<BLOCKQUOTE>

<P>The implementation may assume that any thread will eventually do one of
the following:</P>

<UL>
<LI><P>terminate,</P></LI>

<LI><P>make a call to a library I/O function,</P></LI>

<LI><P>access or modify a volatile object, or</P></LI>

<LI><P>perform a synchronization operation or an atomic operation.</P></LI>

</UL>

<P>[<I>Note:</I> This is intended to allow compiler transformations such as
removal of empty loops, even when termination cannot be
proven. &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

<P>Some programmers find this liberty afforded to implementations to
be disadvantageous; see <A HREF="http://blog.regehr.org/archives/161">
this blog post</A> for a discussion of the subject.</P>

<P><B>Rationale (October, 2015)</B></P>

<P>SG1 reaffirms the original intent of this specification.</P>

<BR><BR><HR>
<A NAME="2954"></A><H4>2954.
  
Simultaneous modifications of an atomic object
</H4>
<B>Section: </B>6.10.2.2&#160; [<A href="https://wg21.link/intro.races">intro.races</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-08<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/636">#636</A>.)
</P>

<P>Subclause 6.10.2.2 [<A href="https://wg21.link/intro.races#4">intro.races</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

All modifications to a particular atomic object M occur in some
particular total order, called the <I>modification order</I> of M. ...

</BLOCKQUOTE>

<P>Is the total order a strict total order?  If not, modifications may
appear to occur simultaneously.</P>

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

<OL>
<LI>
<P>Change in 6.10.2.2 [<A href="https://wg21.link/intro.races#4">intro.races</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

All modifications to a particular atomic object M occur in some
particular <INS>strict</INS> total order, called the <I>modification
order</I> of M. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 32.5.4 [<A href="https://wg21.link/atomics.order#4">atomics.order</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

There is a single <INS>strict</INS> total order S on all
memory_order::seq_cst operations, including fences, that satisfies the
following constraints. ...

</BLOCKQUOTE>
</LI>
</OL>

<P><B>Additional notes (November, 2024)</B></P>

<P>Forwarded to SG1 and LWG by decision of the CWG chair, via
<A HREF="https://github.com/cplusplus/papers/issues/2137">paper issue 2137</A>.</P>

<P><B>CWG 2024-11-08</B></P>

<P>If "modifications [...] occur in some particular total order", one
can equivalently define a strict or non-strict total order over them,
as those are isomorphic. Phrases like "A is earlier than B in the
modification order of M" plainly refer to &lt;, not &lt;=.</P>

<BR><BR><HR>
<A NAME="269"></A><H4>269.
  
Order of initialization of multiply-defined static data members
of class templates
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>8 Feb 2001<BR>


<P>According to 6.3 [<A href="https://wg21.link/basic.def.odr#5">basic.def.odr</A>] paragraph 5, it is possible
for a static data member of a class template to be defined more than
once in a given program provided that each such definition occurs in a
different translation unit and the ODR is met.</P>

<P>Now consider the following example:</P>

<P><I><B>src1.cpp:</B></I></P>

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

    int  initializer()
    {
       static int   counter;
       return  counter++;
    }

    int   g_data1 = initializer();

    template&lt;class T&gt;
    struct  exp  {
       static int   m_data;
    };
    template&lt;class T&gt;
    int  exp&lt;T&gt;::m_data = initializer();

    int   g_data2 = initializer();
    extern int   g_data3;

    int  main()
    {
       std::cout &lt;&lt; exp&lt;char&gt;::m_data &lt;&lt; ", " &lt;&lt; g_data1 &lt;&lt; ", "
	  &lt;&lt; g_data2 &lt;&lt; ", " &lt;&lt; g_data3 &lt;&lt; std::endl;
       return  0;
    }
</PRE>

<P><I><B>src2.cpp:</B></I></P>

<PRE>
    extern int  initializer();
    int  g_data3 = initializer();

    template&lt;class T&gt;
    struct  exp  {
       static int   m_data;
    };
    template&lt;class T&gt;
    int  exp&lt;T&gt;::m_data = initializer();

    void  func()
    {
      exp&lt;char&gt;::m_data++;
    }
</PRE>

<P>The specialization <TT>exp&lt;char&gt;::m_data</TT> is implicitly
instaniated in both translation units, hence (13.9.2 [<A href="https://wg21.link/temp.inst#1">temp.inst</A>] paragraph 1) its initialization occurs. And for both
definitions of <TT>exp&lt;T&gt;::m_data</TT> the ODR is met. According
to 6.10.3.2 [<A href="https://wg21.link/basic.start.static#1">basic.start.static</A>] paragraph 1:</P>

<BLOCKQUOTE>

Objects with static storage duration defined in namespace scope in the
same translation unit and dynamically initialized shall be initialized
in the order in which their definition appears in the translation
unit.

</BLOCKQUOTE>

<P>But for <TT>exp&lt;T&gt;::m_data</TT> we have two definitions. Does
it mean that both <TT>g_data1</TT> and <TT>g_data3</TT> are guaranteed
to be dynamically initialized before
<TT>exp&lt;char&gt;::m_data</TT>?</P>

<P>
<U>Suggested Resolution</U>:
Insert the following sentence before the last two sentences of
6.3 [<A href="https://wg21.link/basic.def.odr#5">basic.def.odr</A>] paragraph 5:</P>

<BLOCKQUOTE>

<P>In the case of <TT>D</TT> being a static data member of a class
template the following shall also hold:</P>

<UL>
<LI>
for a given (not explicit) specialization of <TT>D</TT> initialized dynamically
(6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]), the accumulated set of objects initialized dynamically
in namespace scope before the specialization of <TT>D</TT> shall be the same in every
translation unit that contains the definition for this specialization.
</LI>
</UL>

</BLOCKQUOTE>

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

<P>It was decided that this issue is not linked to
<A HREF="cwg_defects.html#270">issue 270</A> and that there is no problem, because
there is only one instantiation (see 5.2 [<A href="https://wg21.link/lex.phases#8">lex.phases</A>] paragraph 8).
</P>
<BR><BR><HR>
<A NAME="465"></A><H4>465.
  
May constructors of global objects call <TT>exit()</TT>?
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>26 Feb 2004<BR>




<P>The subject line pretty much says it all.  It's a possibility that
hadn't ever occurred to me.  I don't see any prohibition in the
standard, and I also don't think the possibility introduces any logical
inconsistencies.  The proper behavior, presumably, would be to go
through the list of already-constructed objects (not including the
current one, since its constructor wouldn't have finished executing)
and destroy them in reverse order.  Not fundamentally hard, and I'm
sure lots of existing implementations already do that.</P>

<P>I'm just not sure whether the standard was intended to support this, or
whether it's just that nobody else thought of it either.  If the
former, then a non-normative note somewhere in
6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>] might be nice.</P>

<P><B>Rationale (October 2004):</B></P>

<P>There is nothing in the Standard to indicate that this usage
is prohibited, so it must be presumed to be permitted.</P>

<BR><BR><HR>
<A NAME="1749"></A><H4>1749.
  
Confusing definition for constant initializer
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-09-12<BR>


<P>According to 6.10.3.2 [<A href="https://wg21.link/basic.start.static#2">basic.start.static</A>] paragraph 2,</P>

<BLOCKQUOTE>

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 <TT>o</TT> 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>].

</BLOCKQUOTE>

<P>This would be clearer if worded as something like,</P>

<BLOCKQUOTE>

A <I>constant initializer</I> for an object <TT>o</TT> is an expression
that would be a constant expression if every <TT>constexpr</TT> constructor
invoked for <TT>o</TT> and its subobjects were a constructor for a literal
class type.

</BLOCKQUOTE>

<P><B>Rationale (February, 2014):</B></P>

<P>CWG felt that the existing wording is clear enough.</P>

<BR><BR><HR>
<A NAME="640"></A><H4>640.
  
Accessing destroyed local objects of static storage duration
</H4>
<B>Section: </B>6.10.3.3&#160; [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Howard Hinnant
 &#160;&#160;&#160;

 <B>Date: </B>30 July 2007<BR>




<P>6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic#2">basic.start.dynamic</A>] paragraph 2 says,</P>

<BLOCKQUOTE>

If a function contains a local object of static storage duration
that has been destroyed and the function is called during the
destruction of an object with static storage duration, the
program has undefined behavior if the flow of control passes
through the definition of the previously destroyed local object.

</BLOCKQUOTE>

<P>I would like to turn this behavior from undefined to
well-defined behavior for the purpose of achieving a graceful
shutdown, especially in a multi-threaded world.</P>

<P>Background: Alexandrescu describes the &#8220;phoenix
singleton&#8221; in <I>Modern C++ Design</I>.  This is a class
used as a function local static, that will reconstruct itself,
and reapply itself to the <TT>atexit</TT> chain, if the program
attempts to use it after it is destructed in the <TT>atexit</TT>
chain.  It achieves this by setting a &#8220;destructed
flag&#8221; in its own state in its destructor.  If the object is
later accessed (and a member function is called on it), the
member function notes the state of the &#8220;destructed
flag&#8221; and does the reconstruction dance.  The phoenix
singleton pattern was designed to address issues only in
single-threaded code where accesses among static objects can have
a non-scoped pattern.  When we throw in multi-threading, and the
possibility that threads can be running after <TT>main</TT>
returns, the chances of accessing a destroyed static
significantly increase.</P>

<P>The very least that I would like to see happen is to standardize what
I believe is existing practice:  When an object is destroyed in the
<TT>atexit</TT> chain, the memory the object occupied is left in
whatever state the destructor put it in.  If this can only be
reliably done for objects with standard layout, that would be an
acceptable compromise.  This would allow objects to set &#8220;I'm
destructed&#8221; flags in their state and then do something
well-defined if accessed, such as throw an exception.</P>

<P>A possible refinement of this idea is to have the compiler set
up a 3-state flag around function-local statics instead of the
current 2-state flag:</P>

<UL>
<LI>Not constructed yet</LI>
<LI>Constructed but not destroyed yet</LI>
<LI>Destroyed</LI>
</UL>

<P>We have the first two states today.  We might choose to add
the third state, and if execution passes over a function-local
static with &#8220;destroyed&#8221; state, an exception could be
thrown.  This would mean that we would not have to guarantee
memory stability in destroyed objects of static duration.</P>

<P>This refinement would break phoenix singletons, and is not
required for the <TT>~mutex()</TT>/<TT>~condition()</TT> I've
described and prototyped.  But it might make it easier for Joe
Coder to apply this kind of guarantee to his own types.</P>

<P><B>Rationale (CWG 2023-05-12)</B></P>

<P>This is an extension that requires a paper targeted at EWG.</P>

<BR><BR><HR>
<A NAME="71"></A><H4>71.
  
Incorrect cross reference
</H4>
<B>Section: </B>Clause 7&#160; [<A href="https://wg21.link/expr">expr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Neal Gafter
 &#160;&#160;&#160;

 <B>Date: </B>15 Oct 1998<BR>





<P>An operator expression can, according to
Clause 7 [<A href="https://wg21.link/expr">expr</A>]

paragraph 2, require transformation into function call syntax. The
reference in that paragraph is to
12.4 [<A href="https://wg21.link/over.oper">over.oper</A>]
, but it should be to
12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
.</P>

<P>
<B>Rationale (04/99):</B> The subsections
12.4.2 [<A href="https://wg21.link/over.unary">over.unary</A>]
,
12.4.3 [<A href="https://wg21.link/over.binary">over.binary</A>]
, etc. of the referenced
section are in fact relevant.</P>
<BR><BR><HR>
<A NAME="584"></A><H4>584.
  
Unions and aliasing
</H4>
<B>Section: </B>7.2.1&#160; [<A href="https://wg21.link/basic.lval">basic.lval</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>comp.std.c++
 &#160;&#160;&#160;

 <B>Date: </B>10 June 2006<BR>


<P>The C++ standard says in 7.2.1 [<A href="https://wg21.link/basic.lval">basic.lval</A>], in paragraph 15:</P>

<UL><LI><P>an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively, a
member of a subaggregate or contained union),</P></LI></UL>

<P>Note that it is a literal copy from the C standard, but this is of
course not the problem.</P>

<P>In C, union is not defined as an aggregate type. Therefore it is
appropriate to say &#8220;aggregate or union.&#8221; But things
changed in C++: aggregate type includes union type now (though not all
unions are aggregates), and it becomes clear that the
&#8220;union&#8221; in &#8220;aggregate or union&#8221; is redundant
and should be deleted.</P>

<P>The above cited paragraph could be changed to:</P>

<UL><LI><P>an aggregate type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate)</P></LI></UL>

<P><B>Rationale (October, 2006):</B></P>

<P>As noted in the issue, not all unions are aggregates, but those
that are not aggregates still allow aliasing.  That part of the
specification would be lost with the suggested change.</P>

<BR><BR><HR>
<A NAME="1026"></A><H4>1026.
  
Cv-qualified non-class rvalues
</H4>
<B>Section: </B>7.2.1&#160; [<A href="https://wg21.link/basic.lval">basic.lval</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jerry Coffin
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-01<BR>




<P>Historically, based on C's treatment, cv-qualification of non-class
rvalues has been ignored in C++.  With the advent of rvalue references,
it's not quite as clear that this is desirable.  For example, some
implementations are reported to print <TT>const rvalue</TT> for the
following program:</P>

<PRE>
const int bar() {
   return 5;
}

void pass_int(int&amp;&amp; i) {
   printf("rvalue\n");
}

void pass_int(const int&amp;&amp; i) {
   printf("const rvalue\n");
}

int main() {
   pass_int(bar());
}

</PRE>

<P><B>Rationale (August, 2010):</B></P>

<P>The current specification is as intended.</P>

<BR><BR><HR>
<A NAME="1998"></A><H4>1998.
  
Additional sources of xvalue expressions
</H4>
<B>Section: </B>7.2.1&#160; [<A href="https://wg21.link/basic.lval">basic.lval</A>]
 &#160;&#160;&#160;

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

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

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


<P>According to 7.2.1 [<A href="https://wg21.link/basic.lval#1">basic.lval</A>] paragraph 1,</P>

<BLOCKQUOTE>

An xvalue is the result of certain kinds of expressions
involving rvalue references (9.3.4.3 [<A href="https://wg21.link/dcl.ref">dcl.ref</A>]).

</BLOCKQUOTE>

<P>However, there are now expressions not involving rvalue
references whose results are xvalues, e.g., a member access
expression in which the left operand is a prvalue.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>The cited wording does not preclude other kinds of
expressions that result in xvalues.  This wording could be
expanded editorially if a more extensive coverage is desired.</P>

<BR><BR><HR>
<A NAME="617"></A><H4>617.
  
Lvalue-to-rvalue conversions of uninitialized <TT>char</TT> objects
</H4>
<B>Section: </B>7.3.2&#160; [<A href="https://wg21.link/conv.lval">conv.lval</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alan Stokes
 &#160;&#160;&#160;

 <B>Date: </B>6 February 2007<BR>




<P>According to 7.3.2 [<A href="https://wg21.link/conv.lval#1">conv.lval</A>] paragraph 1, applying the
lvalue-to-rvalue conversion to any uninitialized object results in
undefined behavior.  However, character types are intended to allow
any data, including uninitialized objects and padding, to be copied
(hence the statements in 6.9.2 [<A href="https://wg21.link/basic.fundamental#1">basic.fundamental</A>] paragraph 1
that &#8220;For character types, all bits of the object representation
participate in the value representation&#8221; and in
7.2.1 [<A href="https://wg21.link/basic.lval#15">basic.lval</A>] paragraph 15 that <TT>char</TT> and
<TT>unsigned char</TT> types can alias any object).  The
lvalue-to-rvalue conversion should be permitted on uninitialized
objects of character type without evoking undefined behavior.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>The Standard now clearly specifies the handling of
indeterminate values for <TT>unsigned char</TT>
and <TT>std::byte</TT> types; see
6.8.5 [<A href="https://wg21.link/basic.indet">basic.indet</A>].</P>

<BR><BR><HR>
<A NAME="303"></A><H4>303.
  
Integral promotions on bit-fields
</H4>
<B>Section: </B>7.3.7&#160; [<A href="https://wg21.link/conv.prom">conv.prom</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Kiril Avdeiv
 &#160;&#160;&#160;

 <B>Date: </B>24 Jul 2001<BR>


<P>Paragraph 3 of section 7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>] contains a statement
saying that if a bit-field is larger than int or unsigned int, no integral
promotions apply to it. This phrase needs further clarification, as it
is hardly possible to fugure out what it means. See below.</P>

<P>Assuming a machine with a size of general-purpose register equal 32
bits (where a byte takes up 8 bits) and a C++ implementation where an
int is 32 bits and a long is 64 bits. And the following snippet of
code:</P>
<PRE>
    struct ExternalInterface {
      long field1:36, field2:28;
    };
    int main() {
      ExternalInterface  myinstance = { 0x100000001L, 0x12,};
      if(myinstance.field1 &lt; 0x100000002L) { //do something }
    }
</PRE>

<P>Does the standard prohibit the implementation from promoting field1's
value into two general purpose registers? And imposes a burden of
using shift machine instructions to work with the field's value? What
else could that phrase mean?</P>

<P>Either alternative is implementation specific, so I don't understand
why the phrase "If the bit-field is larger yet, no integral promotions
apply to it" made it to the standard.</P>

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

<P>The standard of course does not dictate what an implementation
might do with regard to use of registers or shift instructions in
the generated code.  The phrase cited means only that a larger
bit-field does not undergo integral promotions, and therefore it
retains the type with which it was declared (<TT>long</TT> in
the above example).  The Core Working Group judged that this
was sufficiently clear in the standard.</P>
<P>Note that 11.4.10 [<A href="https://wg21.link/class.bit#1">class.bit</A>] paragraph 1
indicates that any bits in excess of the size of the underlying type
are padding bits and do not participate in the value representation.
Therefore the <TT>field1</TT> bit field in the above example is not
capable of holding the indicated values, which require more than 32 bits.</P>

<BR><BR><HR>
<A NAME="566"></A><H4>566.
  
Conversion of negative floating point values to integer type
</H4>
<B>Section: </B>7.3.11&#160; [<A href="https://wg21.link/conv.fpint">conv.fpint</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Seungbeom Kim
 &#160;&#160;&#160;

 <B>Date: </B>13 March 2006<BR>


<P>Section 7.3.11 [<A href="https://wg21.link/conv.fpint#1">conv.fpint</A>] paragraph 1 states:</P>

<BLOCKQUOTE>

An rvalue of a floating point type can be converted to an rvalue of an
integer type. The conversion truncates; that is, the fractional part
is discarded.

</BLOCKQUOTE>

<P>Here, the concepts of &#8220;truncation&#8221; and
&#8220;fractional part&#8221; seem to be used without precise
definitions. When -3.14 is converted into an integer, is the
truncation toward zero or away from zero? Is the fractional part -0.14
or 0.86? The standard seem to give no clear answer to these.</P>

<P>Suggested resolution:</P>

<OL>

<LI><P>Replace &#8220;truncates&#8221; with &#8220;truncates toward
zero.&#8221;</P></LI>

<LI><P>Replace &#8220;the fractional part&#8221; with &#8220;the
fractional part (where that of <TT>x</TT> is defined
as <TT>x-floor(x)</TT> for nonnegative <TT>x</TT>
and <TT>x-ceiling(x)</TT> for negative <TT>x</TT>);&#8221; there
should be a better wording for this, or the entire statement
&#8220;that is, the fractional part is discarded&#8221; can be removed,
once the meaning of &#8220;truncation&#8221; becomes unambiguous as
above.</P></LI>

</OL>

<P><B>Rationale (October, 2006):</B></P>

<P>The specification is clear enough: &#8220;fractional part&#8221;
refers to the digits following the decimal point, so that -3.14
converted to <TT>int</TT> becomes -3.</P>

<BR><BR><HR>
<A NAME="2139"></A><H4>2139.
  
Floating-point requirements for integer representation
</H4>
<B>Section: </B>7.3.11&#160; [<A href="https://wg21.link/conv.fpint">conv.fpint</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Tony Van Eerd
 &#160;&#160;&#160;

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




<P>There is no normative requirement regarding the ability
of floating-point values to represent integer values
exactly; however, 7.3.11 [<A href="https://wg21.link/conv.fpint#2">conv.fpint</A>] paragraph 2
appears to implicitly rely on their ability to represent the
values 0 and 1:</P>

<BLOCKQUOTE>

If the source type is <TT>bool</TT>, the value <TT>false</TT> is converted to
zero and the value <TT>true</TT> is converted to one.

</BLOCKQUOTE>

<P><B>Rationale (October, 2015):</B></P>

<P>CWG felt that the cited passage should be read as indicating
that converting true and false should have the same result as
converting 1 and 0 and thus do not imply a requirement that
those values be represented exactly.</P>

<BR><BR><HR>
<A NAME="456"></A><H4>456.
  
Is initialized const int or const bool variable a null pointer constant?
</H4>
<B>Section: </B>7.3.12&#160; [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lloyd Lewins
 &#160;&#160;&#160;

 <B>Date: </B>31 Jan 2004<BR>


<P>In the following code, I expect both "null" and "FALSE" to be null
pointer constants -- and that the code should compile and output the
string "int*" twice to cout:</P>
<PRE>
#include &lt;iostream&gt;

using namespace std;

void foo(int* p)
{
     cout &lt;&lt; "int*" &lt;&lt; endl;
}

int main(void)
{
     const int null = 0;
     foo(null);
     const bool FALSE = false;
     foo(FALSE);
}
</PRE>
<P>ISO/IEC 14882-1998 7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>] states:</P>
<BLOCKQUOTE>
An  integral constant expression rvalue of integer type that evaluates
to zero (called a /null pointer constant/)  can  be  converted  to  a
pointer  type.
</BLOCKQUOTE>
<P>Stroustrup appears to agree with me -- he states (3rd edition page 88):</P>
<BLOCKQUOTE>
In C, it has been popular to define a macro NULL to represent the zero
pointer. Because of C++`s tighter type checking, the use of plain 0,
rather than any suggested NULL macro, leads to fewer problems. If you
feel you must define NULL, use:
<PRE>
   const int NULL = 0;
</PRE>
</BLOCKQUOTE>
<P>However gcc 3.3.1 rejects this code with the errors:</P>
<PRE>
     bug.cc:17: error: invalid conversion from `int' to `int*'
     bug.cc:19: error: cannot convert `const bool' to `int*' for argument `1' to `
         void foo(int*)'
</PRE>
<P>I have reported this as a bug
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13867), but the gcc team
states that 4.10 requires that a null pointer constant must be an rvalue
-- and no implicit conversion from an lvalue to an rvalue is required
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=396):</P>
<BLOCKQUOTE>
a null pointer constant is an integral constant expression rvalue that
evaluates to zero [4.10/1] in this case `null' is an lvalue. The
standard does not specify that lvalue-&gt;rvalue decay happens here, so
`null' is not a null pointer constant.
</BLOCKQUOTE>

<P>I disagree with the gcc teams interpretation -- I don't see why
7.2.1 [<A href="https://wg21.link/basic.lval">basic.lval</A>] doesn't apply:</P>
<BLOCKQUOTE>
Whenever  an  lvalue appears in a context where an rvalue is expected,
the lvalue is converted to an rvalue;
</BLOCKQUOTE>
<P>The insertion of the word rvalue appears to have occurred during
standardization -- it is not present in either Stroustrup 2nd edition or
the 3rd edition. Does the committee deliberately intend to exclude an
lvalue as a null pointer constant by adding the word rvalue? If so, it
leads to the rather bizarre fact that "null" is not a null pointer
constant, but "null + 0" is!</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>We think this is just a bug in gcc.  The const variable does
get converted to an rvalue in this context.  This case is not
really any different than cases like
<PRE>
  const int null = 0;
  int i = null;
</PRE>
or
<PRE>
  const int i = 1;
  int a[i];
</PRE>
(which are accepted by gcc).
No one would argue that the second lines of those examples
are invalid because the variables are lvalues, and yet the conversions
to rvalue happen implicitly for the same reason cited above -- the
contexts require an rvalue. </P>

<BR><BR><HR>
<A NAME="794"></A><H4>794.
  
Base-derived conversion in member type of pointer-to-member conversion
</H4>
<B>Section: </B>7.3.13&#160; [<A href="https://wg21.link/conv.mem">conv.mem</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2009-03-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#CH1">N2800 comment
  CH&#160;1<BR></A>

<P>Currently both implicit (7.3.13 [<A href="https://wg21.link/conv.mem">conv.mem</A>]) and explicit
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]) conversions of pointers to members permit
only cases in which the type of the member is the same except for
cv-qualification.  It would seem reasonable to allow conversions in
which one member type is a base class of the other.  For example:</P>

<PRE>
    struct B { };
    struct D: B { };
    struct X {
        D d;
    };
    struct Y: X { };
    B Y::* pm = &amp;X::d;  // Currently ill-formed: type of d is D, not B
</PRE>

<P>(See also <A HREF="cwg_defects.html#170">issue 170</A>.)</P>

<P><B>EWG 2022-11-11</B></P>

<P>The change is plausible, but needs a paper to EWG.</P>

<BR><BR><HR>
<A NAME="795"></A><H4>795.
  
Dependency of lambdas on <TT>&lt;functional&gt;</TT>
</H4>
<B>Section: </B>7.5.6&#160; [<A href="https://wg21.link/expr.prim.lambda">expr.prim.lambda</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK45">N2800 comment
  UK&#160;45<BR></A>

<P>7.5.6 [<A href="https://wg21.link/expr.prim.lambda#2">expr.prim.lambda</A>] paragraph 2 says,</P>

<BLOCKQUOTE>

A closure object behaves as a function object (22.10 [<A href="https://wg21.link/function.objects">function.objects</A>])...

</BLOCKQUOTE>

<P>This linkage to <TT>&lt;functional&gt;</TT> increases the dependency
of the language upon the library and is inconsistent with the definition
of &#8220;freestanding&#8221; in 16.4.2.5 [<A href="https://wg21.link/compliance">compliance</A>].</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The reference to 22.10 [<A href="https://wg21.link/function.objects">function.objects</A>] appears in a note, not
in normative text, and is intended only to clarify the meaning of the
term &#8220;function object.&#8221;  The CWG does not believe that this
reference creates any dependency on any library facility.</P>

<BR><BR><HR>
<A NAME="958"></A><H4>958.
  
Lambdas and <TT>decltype</TT>
</H4>
<B>Section: </B>7.5.6&#160; [<A href="https://wg21.link/expr.prim.lambda">expr.prim.lambda</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>31 August, 2009<BR>




<P>The following case is ill-formed:</P>

<PRE>
    int f (int&amp;);
    void* f (const int&amp;);

    int main()
    {
       int i;
       [=] ()-&gt; decltype(f(i)) { return f(i); };
    }
</PRE>

<P>The <TT>decltype(f(i))</TT> is not of the form
<TT>decltype((x))</TT>, and also not within the body of the lambda, so
the special rewriting rule doesn't apply. So, the call in the decltype
selects the first overload, and the call in the body selects the
second overload, and there's no conversion from <TT>void*</TT> to
<TT>int</TT>, so the return-statement is ill-formed.</P>

<P>This pattern is likely to arise frequently because of the
retrictions on deducing the return type from the body of the lambda.</P>

<P>
<U>Daveed Vandevoorde</U>: The pattern may be common, but it
probably doesn't matter much in practice.  It's most likely that
overloaded functions that differ only in the cv-qualification of their
parameters will have related return types.</P>

<P><B>Rationale (October, 2009):</B></P>

<P>The consensus of the CWG was that this is not a sufficiently
important problem to warrant changing the existing specification.</P>

<BR><BR><HR>
<A NAME="1118"></A><H4>1118.
  
Implicit lambda capture via explicit copy constructor
</H4>
<B>Section: </B>7.5.6.3&#160; [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#FI19">N3092 comment
  FI&#160;19<BR></A>

<P>According to 7.5.6 [<A href="https://wg21.link/expr.prim.lambda#21">expr.prim.lambda</A>] paragraph 21,</P>

<BLOCKQUOTE>

When the <I>lambda-expression</I> is evaluated, the entities
that are captured by copy are used to direct-initialize each
corresponding non-static data member of the resulting
closure object.

</BLOCKQUOTE>

<P>This apparently means that if the capture-default
is to copy, entities captured by default, implicitly,
are copied even in cases where the copy constructors of
such entities are explicit.  It should be required that
such entities be captured explicitly instead.</P>

<P>See also <A HREF="cwg_defects.html#1020">issue 1020</A>.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>The behavior is according to the original design and is
similar to what would happen if the constructor of the
closure object initialized the members for the captured
entities using <I>mem-initializer</I>s.  CWG did not see
sufficient motivation to change the design.</P>

<BR><BR><HR>
<A NAME="1663"></A><H4>1663.
  
Capturing an empty pack expansion
</H4>
<B>Section: </B>7.5.6.3&#160; [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR><BR>


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



<P>The conditions under which a closure class has a conversion function
to a pointer-to-function type are given in 7.5.6 [<A href="https://wg21.link/expr.prim.lambda#6">expr.prim.lambda</A>] 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...

</BLOCKQUOTE>

<P>Does this apply to a lambda whose <I>lambda-capture</I> is empty
by virtue of being an empty pack expansion?  For example, is the
following well-formed?</P>

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

  template &lt;typename ...Args&gt;
  void foo(Args ...args) {
    auto xf = [args ...] { };
    std::atexit(xf);
  }
</PRE>

<P>This is likely a violation of the rule in 13.8 [<A href="https://wg21.link/temp.res#8">temp.res</A>] paragraph 8,
</P>

<BLOCKQUOTE>

If every valid specialization of a variadic template requires an empty
template parameter pack, the template is ill-formed, no diagnostic
required.

</BLOCKQUOTE>

<P>Does this need to be clarified?</P>

<P><B>Rationale (September, 2013):</B></P>

<P>The statement in 7.5.6 [<A href="https://wg21.link/expr.prim.lambda#6">expr.prim.lambda</A>] paragraph 6 is a
syntactic constraint, not a semantic one.  The example has a
<I>lambda-capture</I>, regardless of its expansion in a given
instantiation.  This is consistent with the intent expressed in
13.7.4 [<A href="https://wg21.link/temp.variadic#6">temp.variadic</A>] paragraph 6:</P>

<BLOCKQUOTE>

When <I>N</I> is zero, the instantiation of the expansion produces an empty
list. Such an instantiation does not alter the syntactic interpretation of
the enclosing construct...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1743"></A><H4>1743.
  
<I>init-capture</I>s in nested lambdas
</H4>
<B>Section: </B>7.5.6.3&#160; [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-08-30<BR>




<P>According to 7.6.1.2 [<A href="https://wg21.link/expr.sub#11">expr.sub</A>] paragraph 11,</P>

<BLOCKQUOTE>

No entity is captured by an <I>init-capture</I>.

</BLOCKQUOTE>

<P>It should be made clearer that a variable, odr-used by
an <I>init-capture</I> in a nested lambda, is still captured by the
containing lambda as a result of the <I>init-capture</I>.</P>

<P>Rationale (October, 2015):</P>

<P>Subsequent edits have removed the offending phraseXS.</P>

<BR><BR><HR>
<A NAME="2159"></A><H4>2159.
  
Lambda capture and local <TT>thread_local</TT> variables
</H4>
<B>Section: </B>7.5.6.3&#160; [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-07-15<BR>




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

<PRE>
  void f() {
    thread_local int n = 10;
    std::thread([&amp;] { std::cout &lt;&lt; n &lt;&lt; std::endl; }).join();
  }
</PRE>

<P>This function prints <TT>0</TT>, because:</P>

<OL>
<LI><P>The lambda does not capture <TT>n</TT>
</P></LI>

<LI><P>
<TT>n</TT> is not initialized on the spawned thread
prior to the invocation of the lambda.</P></LI>

</OL>

<P><B>Additional note, March, 2016:</B></P>

<P>SG1 discussed this issue and concluded that the issues should be
resolved follows:</P>

<OL>
<LI><P>If the program would result in a capture by reference of a local
thread-local variable, then it is ill-formed.</P></LI>

<LI><P>If the program has a capture by value of a local thread-local variable,
then a copy of the value from the calling thread is captured (and
initialized in the calling thread, if necessary).</P></LI>

</OL>

<P>The rationale for #1 is that, if we allowed capture of local
thread-locals, some programmers will have one intuition of what to expect
and other programmers will have the opposite intuition.  It's better to
forbid both interpretations.  We don't want to say simply that there is
<B>no</B> capture by reference of thread-locals, because simply ignoring
the local thread-local might result in name-lookup finding a global
variable by the same name, which would be very confusing.</P>

<P><B>Rationale (March, 2017):</B></P>

<P>Only automatic variables are captured. A lambda accessing a thread-local
variable would be ill-formed.</P>

<BR><BR><HR>
<A NAME="1555"></A><H4>1555.
  
Language linkage and function type compatibility
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-09-18<BR>




<P>Currently function types with different language linkage are not
compatible, and 7.6.1.3 [<A href="https://wg21.link/expr.call#1">expr.call</A>] paragraph 1 makes it undefined
behavior to call a function via a type with a different language linkage.
These features are generally not enforced by most current implementations
(although some do) between functions with C and C++ language linkage.
Should these restrictions be relaxed, perhaps as conditionally-supported
behavior?</P>

<P><B>Rationale (October, 2012):</B></P>

<P>CWG felt that this language design question would be better
considered by EWG.</P>

<P><B>EWG 2022-11-11</B></P>

<P>Any changes in this area should be pursued via a paper to EWG.</P>

<BR><BR><HR>
<A NAME="1525"></A><H4>1525.
  
Array bound inference in temporary array
</H4>
<B>Section: </B>7.6.1.4&#160; [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-07-18<BR>


<P>Should the determination of array bounds from an initializer, described
in 9.5.2 [<A href="https://wg21.link/dcl.init.aggr#4">dcl.init.aggr</A>] paragraph 4, apply to creation of a temporary
array using the <TT>T{</TT><I>expr</I><TT>}</TT> syntax?  E.g., is the
following example well-formed?</P>

<PRE>
  typedef int ARR[];
  int* p = ARR{1,2,3};
</PRE>

<P>(See also issues <A HREF="cwg_closed.html#1300">1300</A>,
<A HREF="cwg_defects.html#1307">1307</A>, and <A HREF="cwg_closed.html#1326">1326</A>.)</P>

<P><B>Rationale (October, 2012):</B></P>

<P>The example is valid, according to the new wording of
9.5.2 [<A href="https://wg21.link/dcl.init.aggr#4">dcl.init.aggr</A>] paragraph 4.</P>

<BR><BR><HR>
<A NAME="1585"></A><H4>1585.
  
Value category of member access of rvalue reference member
</H4>
<B>Section: </B>7.6.1.5&#160; [<A href="https://wg21.link/expr.ref">expr.ref</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-11-13<BR>




<P>According to 7.6.1.5 [<A href="https://wg21.link/expr.ref#4">expr.ref</A>] paragraph 4,</P>

<BLOCKQUOTE>

If <TT>E2</TT> is declared to have type &#8220;reference to
<TT>T</TT>,&#8221; then <TT>E1.E2</TT> is an lvalue...

</BLOCKQUOTE>

<P>This applies to rvalue reference types as well as to lvalue
reference types, based on the rationale from Clause 7 [<A href="https://wg21.link/expr#7">expr</A>] paragraph 7
that</P>

<BLOCKQUOTE>

In general... named rvalue references are treated as lvalues and
unnamed rvalue references to objects are treated as xvalues...

</BLOCKQUOTE>

<P>Since a non-static data member has a name, it would appear most
naturally to fall into the lvalue category.  This makes sense as well
from the perspective that the target of such a reference does not bear
any necessary correlation with the value category of the object
expression; in particular, an xvalue object might have an rvalue
reference member referring to a different object from which it would
be an error to move.</P>

<P>On the other hand, rvalue reference members have limited utility
and are likely only to occur as the result of template argument
deduction in the context of perfect forwarding, such as using a
<TT>std::pair</TT> to forward values.  In such cases, a <TT>first</TT>
or <TT>second</TT> member of rvalue reference type would be most
naturally treated as having the same value category as that of the
object expression.  The utility of this usage may outweigh the safety
considerations that shaped the current policy.</P>

<P><B>Rationale (April, 2013):</B></P>

<P>The design of rvalue references in the language is complex, and CWG felt
that an attempt to change the existing rules to accommodate this case ran the
risk of breaking other cases.  Treating named rvalue reference members as
lvalues, consistently with other named rvalue references, is also safer in that
it prevents the inadvertent theft of resources from an object to which such
a member refers.</P>

<BR><BR><HR>
<A NAME="2231"></A><H4>2231.
  
Class member access to static data member template
</H4>
<B>Section: </B>7.6.1.5&#160; [<A href="https://wg21.link/expr.ref">expr.ref</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-02-18<BR>




<P>Consider:</P>

<PRE>
  struct A {
    template&lt;class T&gt; static int X;
  };
  template&lt;class T&gt; int A::X = T{};

  A{}.X&lt;int&gt;; // <SPAN CLASS="cmnt">error</SPAN>
  A::X&lt;int&gt;;  // <SPAN CLASS="cmnt">OK</SPAN>
</PRE>

<P>Implementations seem to reject the class member access, despite
7.6.1.5 [<A href="https://wg21.link/expr.ref#6.1">expr.ref</A>] bullet 6.1 stating the contrary.</P>

<P><B>Rationale (November, 2016):</B></P>

<P>The specification is as intended.</P>

<BR><BR><HR>
<A NAME="528"></A><H4>528.
  
Why are incomplete class types not allowed with <TT>typeid</TT>?
</H4>
<B>Section: </B>7.6.1.8&#160; [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dave Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>18 May 2005<BR>




<P>7.6.1.8 [<A href="https://wg21.link/expr.typeid#4">expr.typeid</A>] paragraph 4 says,</P>

<BLOCKQUOTE>

When <TT>typeid</TT> is applied to a <I>type-id</I>, the result refers
to a <TT>std::type_info</TT> object representing the type of
the <I>type-id</I>.  If the type of the <I>type-id</I> is a reference
type, the result of the <TT>typeid</TT> expression refers to
a <TT>std::type_info</TT> object representing the referenced type. If
the type of the <I>type-id</I> is a class type or a reference to a
class type, the class shall be completely-defined.

</BLOCKQUOTE>

<P>I'm wondering whether this is not overly restrictive.  I can't
think of a reason to require that <TT>T</TT> be completely-defined
in <TT>typeid(T)</TT> when <TT>T</TT> is a class type.  In fact,
several popular compilers enforce that restriction
for <TT>typeid(T)</TT>, but not for <TT>typeid(T&amp;)</TT>.  Can
anyone explain this?
</P>

<P>
<U>Nathan Sidwell</U>: I think this restriction is so that whenever
the compiler has to emit a typeid object of a class type, it knows
what the base classes are, and can therefore emit an array of
pointers-to-base-class typeids.  Such a tree is necessary to implement
<TT>dynamic_cast</TT> and exception catching (in a commonly
implemented and obvious manner).  If the class could be incomplete,
the compiler might have to emit a typeid for incomplete <TT>Foo</TT>
in one object file and a typeid for complete <TT>Foo</TT> in another
object file.  The compilation system will then have to make sure that
(a) those compare equal and (b) the complete <TT>Foo</TT> gets
priority, if that is applicable.
</P>

<P>Unfortunately, there is a problem with exceptions that means there
still can be a need to emit typeids for incomplete class.  Namely one
can throw a pointer-to-pointer-to-incomplete.  To implement the
matching of pointer-to-derived being caught by pointer-to-base, it is
necessary for the typeid of a pointer type to contain a pointer to the
typeid of the pointed-to type.  In order to do the qualification
matching on a multi-level pointer type, one has a chain of pointer
typeids that can terminate in the typeid of an incomplete type.  You
cannot simply NULL-terminate the chain, because one must distinguish
between different incomplete types.</P>

<P>
<U>Dave Abrahams</U>: So if implementations are still required to
be able to do it, for all practical purposes, why aren't we letting
the user have the benefits?</P>

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

<P>There was some concern expressed that this might be difficult under
the IA64 ABI.  It was also observed that while it is necessary to
handle exceptions involving incomplete types, there is no requirement
that the RTTI data structures be used for exception handling.</P>

<P><B>Rationale (2023-05-12)</B></P>

<P>This is an extension that requires a paper targeted at EWG,
investigating any ABI concerns.</P>
			    
<BR><BR><HR>
<A NAME="2512"></A><H4>2512.
  
<TT>typeid</TT> and incomplete class types
</H4>
<B>Section: </B>7.6.1.8&#160; [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2021-08-19<BR>




<P>According to 7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>] paragraphs 2-3,</P>

<BLOCKQUOTE>

<P>When <TT>typeid</TT> is applied to a glvalue whose type is a
polymorphic class type (11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]), the
result refers to a <TT>std::type_info</TT> object
representing the type of the most derived object
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) (that is, the dynamic type) to
which the glvalue refers...</P>

<P>When <TT>typeid</TT> is applied to an expression other
than a glvalue of a polymorphic class type, the result
refers to a <TT>std::type_info</TT> object representing the
static type of the expression.</P>

</BLOCKQUOTE>

<P>The status of a glvalue of incomplete class type is not
clear from this specification. Since it is not known
whether an incomplete class type is polymorphic or not,
the existing wording could be read either as giving that
case undefined behavior or as falling into paragraph 3 and
always returning the static type.</P>

<P>The wording for <TT>dynamic_cast</TT> requires class
types to be complete, as does paragraph 4, describing
<TT>typeid</TT> applied to a <I>type-id</I>.</P>

<P><B>Rationale (December, 2021):</B></P>

<P>The change was already applied via the editorial
review process, with approval from CWG at the
2021-08-24 teleconference.</P>

<BR><BR><HR>
<A NAME="294"></A><H4>294.
  
Can <TT>static_cast</TT> drop exception specifications?
</H4>
<B>Section: </B>7.6.1.9&#160; [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>27 Jun 2001<BR>


<P>[Picked up by evolution group at October 2002 meeting.]</P>

<P>Is it okay for a <TT>static_cast</TT> to drop exception
specifications?</P>
<PRE>
    void f() throw(int);
    int main () {
      static_cast&lt;void (*)() throw()&gt;(f);  // Okay?
      void (*p)() throw() = f;  // Error
    }
</PRE>

<P>The fact that a <TT>static_cast</TT> is defined, more or less,
as an initialization suggests that a check ought to be made.</P>

<P>One tricky point: this is another case where the general rule that
the reverse of an implicit cast is allowed as a <TT>static_cast</TT>
bites you -- the reverse conversion doesn't drop exception
specifications, and so is okay.  Perhaps this should be treated
like casting away constness.</P>

<P>
<U>Mike Miller</U> comments
:
I don't think that case can arise.  According to 14.5 [<A href="https://wg21.link/except.spec">except.spec</A>],
</P>
<BLOCKQUOTE>
An exception-specification shall appear only on a function
declarator in a function, pointer, reference, or pointer to
member declaration or definition.
</BLOCKQUOTE>
<P>We strengthened that in <A HREF="cwg_defects.html#87">issue 87</A>
(voted to DR status in Copenhagen) to</P>
<BLOCKQUOTE>
An exception-specification 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 or
definition, or on such a type appearing as a parameter or
return type in a function declarator.
</BLOCKQUOTE>
<P>As I read that, you can't put an exception-specification on the
type-id in a static_cast, which means that a static_cast can
only weaken, not strengthen, the exception specification.</P>

<P>The core WG discussed this at the 10/01 meeting and agreed.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group recommended closing this issue with no
further consideration.  See paper J16/07-0033 = WG21 N2173.</P>

<BR><BR><HR>
<A NAME="2814"></A><H4>2814.
  
Alignment requirement of incomplete class type
</H4>
<B>Section: </B>7.6.1.9&#160; [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Janet Cobb
 &#160;&#160;&#160;

 <B>Date: </B>2023-10-20<BR>


<P>Consider:</P>

<PRE>
  struct X;       //<SPAN CLASS="cmnt"> declared, but not defined</SPAN>

  int i;
  X* p = static_cast&lt;X*&gt;(static_cast&lt;void*&gt;(&amp;i));
</PRE>

<P>Is the value of <TT>p</TT> unspecified per
7.6.1.9 [<A href="https://wg21.link/expr.static.cast#14">expr.static.cast</A>] paragraph 14?</P>

<BLOCKQUOTE>

A prvalue of type &#8220;pointer to cv1 void&#8221; can be converted
to a prvalue of type &#8220;pointer to cv2 T&#8221;, where T is an
object type and cv2 is the same cv-qualification as, or greater
cv-qualification than, cv1. If the original pointer value represents
the address A of a byte in memory and A does not satisfy the alignment
requirement of T, then the resulting pointer value is unspecified.
Otherwise, ...

</BLOCKQUOTE>

<P>Is that a case where implementations have to possibly pessimize a
use of an undefined class, because a later definition can have the
worst possible properties?  Such a situation can also occur for
pointer-to-members of undefined classes.</P>

<P><B>CWG 2023-12-15</B></P>

<P>The resulting pointer value should be unspecified if <TT>T</TT> is
incomplete.</P>

<P><B>CWG 2024-03-18</B></P>

<P>CWG decided to reverse direction here and to constrain
implementations, not programs.</P>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<P>Change in 7.6.1.9 [<A href="https://wg21.link/expr.static.cast#14">expr.static.cast</A>] paragraph 14 and add bullets as
follows:</P>

<BLOCKQUOTE>

A prvalue of type &#8220;pointer to cv1 void&#8221; can be converted
to a prvalue of type &#8220;pointer to cv2 T&#8221;, where T is an
object type and cv2 is the same cv-qualification as, or greater
cv-qualification than, cv1. If the original pointer value represents
the address A of a byte in memory
<INS><TT>, T</TT> is complete,</INS> and
A does not satisfy the alignment requirement of T,
then the resulting pointer value is unspecified.  Otherwise, ...

</BLOCKQUOTE>

<P><U>Possible resolution:</U></P>

<P>Change in 7.6.1.9 [<A href="https://wg21.link/expr.static.cast#14">expr.static.cast</A>] paragraph 14 and add bullets as
follows:</P>

<BLOCKQUOTE>

A prvalue of type &#8220;pointer to cv1 void&#8221; can be converted
to a prvalue of type &#8220;pointer to cv2 T&#8221;, where T is an
object type and cv2 is the same cv-qualification as, or greater
cv-qualification than, cv1. If the original pointer value represents
the address A of a byte in memory
<INS><TT>, T</TT> is complete anywhere in the program,</INS> and
A does not satisfy the alignment requirement of T,
then the resulting pointer value is unspecified.  Otherwise, ...

</BLOCKQUOTE>

<P><B>CWG 2024-06-28</B></P>

<P>It is understood that a pointer value of type <TT>T*</TT> may point
to an object whose type is unrelated to <TT>T</TT>.  (Any access
through such a pointer value is undefined behavior.)  However, C++
maintains the invariant that the address represented by a pointer
value of type <TT>T*</TT> is always suitably aligned for a <TT>T</TT>.
The rule that is the concern of this issue ensures the invariant holds
even when values of type <TT>T*</TT> are obtained by casting, and not
by taking the address of an object.  For the latter case, the
invariant holds because an object cannot exist unless its storage is
aligned suitably.</P>

<P>The rule that is the concern of this issue therefore primarily
constrains user programs, not implementations.  It is unclear which
"pessimizations" are expected from casting to a type whose alignment
requirements are unknown at the point of the cast.  Note that the
resulting unspecified pointer value may be an invalid pointer value
(6.9.4 [<A href="https://wg21.link/basic.compound">basic.compound</A>]), which is essentially useless.  Note also
that incomplete class types may have (minimum) alignment requirements,
because an <I>alignment-specifier</I> can appear in
an <I>elaborated-type-specifier</I>.</P>

<P><B>Additional notes (January, 2025)</B></P>

<PRE>
  //<SPAN CLASS="cmnt"> Maybe in a different translation unit</SPAN>
  struct X;
  X *f(void *p) { return static_cast&lt;X*&gt;(p); }

  //<SPAN CLASS="cmnt"> translation unit boundary</SPAN>
  struct alignas(2) X { char c[2]; } x;
  void h(X *p) {
   //<SPAN CLASS="cmnt"> #1</SPAN>
  }

  int main() {
   //<SPAN CLASS="cmnt"> Details of q aren't relevant here, the point is simply that this pointer is not properly aligned for an X.</SPAN>
   void *q = &amp;x.c[1];
   X *misaligned = f(q);
   h(misaligned);
  }
</PRE>

<P>Consider the value of <TT>p</TT> at #1.  If <TT>p</TT> was obtained
by casting, the status quo rule in 7.6.1.9 [<A href="https://wg21.link/expr.static.cast#13">expr.static.cast</A>] paragraph 13 says that <TT>p</TT> has an unspecified pointer value if
misaligned. That pointer value can be an invalid pointer value
(6.9.4 [<A href="https://wg21.link/basic.compound#3.4">basic.compound</A>] paragraph 3.4).  An lvalue-to-rvalue conversion
on an object storing an invalid pointer value is
implementation-defined (7.3.2 [<A href="https://wg21.link/conv.lval#3.3">conv.lval</A>] paragraph 3.3), and
thus might trap.  There is no guarantee that invalid pointer values
have a predictable bit-pattern.</P>

<P>Effectively, the implementation can assume that <TT>p</TT> is
suitably aligned at <TT>p</TT>.</P>

<BR><BR><HR>
<A NAME="800"></A><H4>800.
  
Safely-derived pointers and object pointers converted from function pointers
</H4>
<B>Section: </B>7.6.1.10&#160; [<A href="https://wg21.link/expr.reinterpret.cast">expr.reinterpret.cast</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK57">N2800 comment
  UK&#160;57<BR></A>

<P>It is not specified under what conditions an object pointer created
by converting a function pointer, as described in 7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast#8">expr.reinterpret.cast</A>] paragraph 8, will be safely-derived, particularly in
light of the conditionally-supported, implementation-defined nature of
such conversions.</P>

<P><B>Notes from the March, 2009 meeting:</B></P>

<P>If this is to be addressed, the result should not be as suggested,
i.e., a requirement for implementation documentation appearing only in a
note.  At the least, such a requirement must be in normative text.</P>



<P><B>Rationale (July, 2009):</B></P>

<P>The definition of &#8220;safely-derived pointer&#8221; is clearly and
exclusively formulated in terms of pointers to objects. So no
implementation is required to maintain safe pointer derivation through
conversion to and from a function-pointer type.</P>

<P>On the other hand, any garbage-collecting implementation is free to
treat function pointers the same as object pointers for purposes of
collection. This would provide the effect of safe pointer derivation
through function-pointer types. An implementation is even free to
document this behavior, if it so chooses.</P>

<P>However, converting a pointer to a dynamically-allocated object
into a function pointer would be a very strange and almost always
pointless and unsafe thing to do. There is no need for the standard to
encourage this sort of behavior, even to the extent of adding a note
mentioning the possibility.</P>

<BR><BR><HR>
<A NAME="944"></A><H4>944.
  
<TT>reinterpret_cast</TT> for all types with the same size and alignment
</H4>
<B>Section: </B>7.6.1.10&#160; [<A href="https://wg21.link/expr.reinterpret.cast">expr.reinterpret.cast</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>15 July, 2009<BR>


<P>During the discussion of <A HREF="cwg_defects.html#799">issue 799</A>, which
specified the result of using <TT>reinterpret_cast</TT> to convert an
operand to its own type, it was observed that it is probably reasonable
to allow <TT>reinterpret_cast</TT> between any two types that have the
same size and alignment.</P>

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

<P>It has been suggested that this question may more properly be
the province of EWG, especially in light of discussions during
the resolution of <A HREF="cwg_defects.html#330">issue 330</A>.
</P>

<P><B>Rationale (May, 2015):</B></P>

<P>CWG agreed that this question should be considered from a
language design perspective and is thus being referred to EWG.</P>

<P><B>Rationale (June, 2021):</B></P>

<P>EWG resolved to close this issue.  The <TT>bit_cast</TT> function
addresses some of the use-cases.  Supporting other use-cases would
need a paper.
See <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1018r11.html#CWG944">vote</A>.</P>

<BR><BR><HR>
<A NAME="2225"></A><H4>2225.
  
<TT>reinterpret_cast</TT> to same floating-point type
</H4>
<B>Section: </B>7.6.1.10&#160; [<A href="https://wg21.link/expr.reinterpret.cast">expr.reinterpret.cast</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-01-14<BR>




<P>Consider this inconsistency:</P>

<PRE>
  void func(long l, float f) {
   (void)reinterpret_cast&lt;long *&gt;(&amp;l); //<SPAN CLASS="cmnt"> ok</SPAN>
   (void)reinterpret_cast&lt;long&gt;(l); //<SPAN CLASS="cmnt"> ok</SPAN>
   (void)reinterpret_cast&lt;float *&gt;(&amp;f); //<SPAN CLASS="cmnt"> ok</SPAN>
   (void)reinterpret_cast&lt;float&gt;(f); //<SPAN CLASS="cmnt"> ill-formed</SPAN>
  }
</PRE>

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

<P>Change in 7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast#2">expr.reinterpret.cast</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

... An expression of <DEL>integral</DEL><INS>arithmetic</INS>,
enumeration, pointer, or pointer-to-member type can be explicitly
converted to its own type; such a cast yields the value of its
operand.

</BLOCKQUOTE>

<P><B>Rationale (November, 2016):</B></P>

<P>The specification is as intended.</P>

<BR><BR><HR>
<A NAME="203"></A><H4>203.
  
Type of address-of-member expression
</H4>
<B>Section: </B>7.6.2.2&#160; [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lisa Lippincott
 &#160;&#160;&#160;

 <B>Date: </B>8 Feb 2000<BR>



<P>7.6.2.2 [<A href="https://wg21.link/expr.unary.op#2">expr.unary.op</A>] paragraph 2
indicates
that the type of an address-of-member expression reflects the class in
which the member was declared rather than the class identified in the
<I>nested-name-specifier</I> of the <I>qualified-id</I>.  This
treatment is unintuitive and can lead to strange code and unexpected
results.  For instance, in</P>

<PRE>
    struct B { int i; };
    struct D1: B { };
    struct D2: B { };

    int (D1::* pmD1) = &amp;D2::i;   // NOT an error
</PRE>

More seriously, template argument deduction can give surprising
results:

<PRE>
    struct A {
       int i;
       virtual void f() = 0;
    };

    struct B : A {
       int j;
       B() : j(5)  {}
       virtual void f();
    };

    struct C : B {
       C() { j = 10; }
    };

    template &lt;class T&gt;
    int DefaultValue( int (T::*m) ) {
       return T().*m;
    }

    ... DefaultValue( &amp;B::i )    // Error: A is abstract
    ... DefaultValue( &amp;C::j )    // returns 5, not 10.
</PRE>

<P>
<B>Suggested resolution:</B>
7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 should be changed to
read,</P>

<BLOCKQUOTE>
If the member is a nonstatic member (perhaps by inheritance) of the
class nominated by the <I>nested-name-specifier</I> of the
<I>qualified-id</I> having type <TT>T</TT>, the type of the result is
"pointer to member of class <I>nested-name-specifier</I> of type
<TT>T</TT>."
</BLOCKQUOTE>

and the comment in the example should be changed to read,

<BLOCKQUOTE>
<TT>// <I>has type </I>int B::*</TT>
</BLOCKQUOTE>

<P><B>Notes from 04/00 meeting:</B></P>

<P>The rationale for the current treatment is to permit the widest
possible use to be made of a given address-of-member expression.
Since a pointer-to-base-member can be implicitly converted to a
pointer-to-derived-member, making the type of the expression a
pointer-to-base-member allows the result to initialize or be assigned
to either a pointer-to-base-member or a pointer-to-derived-member.
Accepting this proposal would allow only the latter use.</P>

<P><B>Additional notes:</B></P>

<P>Another problematic example has been mentioned:</P>

<PRE>
    class Base {
    public:
      int func() const;
    };

    class Derived : public Base {
    };

    template&lt;class T&gt;
    class Templ {
    public:
      template&lt;class S&gt;
      Templ(S (T::*ptmf)() const);
    };

    void foo()
    {
      Templ&lt;Derived&gt; x(&amp;Derived::func);    // <I>ill-formed</I>
    }
</PRE>

<P>In this example, even though the conversion of
<TT>&amp;Derived::func</TT> to <TT>int (Derived::*)() const</TT> is
permitted, the initialization of <TT>x</TT> cannot be done because
template argument deduction for the constructor fails.</P>

<P>If the suggested resolution were adopted, the amount of code broken
by the change might be reduced by adding an implicit conversion from
pointer-to-derived-member to pointer-to-base-member for appropriate
address-of-member expressions (not for arbitrary pointers to members,
of course).</P>

<P>(See also issues <A HREF="cwg_closed.html#247">247</A> and
<A HREF="cwg_defects.html#1121">1121</A>.)</P>

<P><B>Additional notes (September, 2012):</B></P>

<P>Tomasz Kami&#324;ski pointed out three additional motivating
examples:</P>

<PRE>
  struct Very_base { int a; };
  struct Base1 : Very_base {};
  struct Base2 : Very_base {};
  struct Derived : Base1, Base2 {}

  int main() {
    Derived d;
    int Derived:: * a_ptr = &amp;Derived::Base1::a; //<SPAN CLASS="cmnt">error: </SPAN>Very_base<SPAN CLASS="cmnt"> ambiguous despite qualification</SPAN>
  };
</PRE>

<P>Also:</P>

<PRE>
  struct Base { int a; };
  struct Derived : Base { int b; };

  template&lt;typename Class, typename Member_type, Member_type Base:: * ptr&gt;
  Member_type get(Class &amp;c) { return c.*ptr; }

  void call(int (*f)(Derived &amp;));

  int main() {
    call(&amp;get&lt;Derived, int, &amp;Derived::b&gt;); //<SPAN CLASS="cmnt"> Works correctly</SPAN>
    call(&amp;get&lt;Derived, int, &amp;Derived::a&gt;); //<SPAN CLASS="cmnt"> Fails because </SPAN>&amp;Derived::a<SPAN CLASS="cmnt"> returns an </SPAN>int Base::*
                                           //<SPAN CLASS="cmnt"> and no conversions are applied to pointer to member</SPAN>
                                           //<SPAN CLASS="cmnt"> (as specified in 13.4.3 [<A href="https://wg21.link/temp.arg.nontype#5">temp.arg.nontype</A>] paragraph 5)</SPAN>
    call(&amp;get&lt;Base, int, &amp;Derived::a&gt;);    //<SPAN CLASS="cmnt">Template function is instantiated properly but has invalid type</SPAN>
  }
</PRE>

<P>Finally:</P>

<PRE>
  struct Base { int a; };
  struct Derived : private Base {
  public:
    using Base::a; //<SPAN CLASS="cmnt">make </SPAN>a<SPAN CLASS="cmnt"> accessible</SPAN>
  };

  int main() {
    Derived d;
    d.a; //<SPAN CLASS="cmnt"> valid</SPAN>
    int Derived::* ptr = &amp;Derived::a; //<SPAN CLASS="cmnt"> Conversion from </SPAN>int Base::*<SPAN CLASS="cmnt"> to </SPAN>int Derived::*
                                      //<SPAN CLASS="cmnt"> is ill-formed because the base class is inaccessible</SPAN>
  }
</PRE>



<P><B>Rationale (October, 2012):</B></P>

<P>CWG felt that such a change to the existing semantics would be better
considered by EWG rather than as a defect.</P>

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

<P>EWG has determined that the utility of such a change is outweighed
by the fact that it would break code. See EWG issue 89.</P>

<BR><BR><HR>
<A NAME="232"></A><H4>232.
  
Is indirection through a null pointer undefined behavior?
</H4>
<B>Section: </B>7.6.2.2&#160; [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>5 Jun 2000<BR>




<P>At least a couple of places in the IS state that indirection
through a null pointer produces undefined behavior: 6.10.1 [<A href="https://wg21.link/intro.execution#4">intro.execution</A>] paragraph 4 gives "dereferencing the null pointer" as an
example of undefined behavior, and 9.3.4.3 [<A href="https://wg21.link/dcl.ref#4">dcl.ref</A>] paragraph 4
(in a note) uses this supposedly undefined behavior as
justification for the nonexistence of "null references."</P>

<P>However, 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#1">expr.unary.op</A>] paragraph 1, which describes
the unary "*" operator, does <I>not</I> say that the behavior is
undefined if the operand is a null pointer, as one might expect.
Furthermore, at least one passage gives dereferencing a null pointer
well-defined behavior: 7.6.1.8 [<A href="https://wg21.link/expr.typeid#2">expr.typeid</A>] paragraph 2
says</P>

<BLOCKQUOTE>
If the lvalue expression is obtained by applying the unary * operator
to a pointer and the pointer is a null pointer value (7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]), the <TT>typeid</TT> expression throws the
<TT>bad_typeid</TT> exception (17.7.5 [<A href="https://wg21.link/bad.typeid">bad.typeid</A>]).
</BLOCKQUOTE>

<P>This is inconsistent and should be cleaned up.</P>

<P>
<U>Bill Gibbons</U>:</P>

<P>At one point we agreed that dereferencing a null pointer was
<I>not</I> undefined; only using the resulting value had undefined
behavior.</P>

<P>For example:</P>

<PRE>
    char *p = 0;
    char *q = &amp;*p;
</PRE>

<P>Similarly, dereferencing a pointer to the end of an array should be
allowed as long as the value is not used:</P>

<PRE>
    char a[10];
    char *b = &amp;a[10];   // equivalent to "char *b = &amp;*(a+10);"
</PRE>

<P>Both cases come up often enough in real code that they should be
allowed.</P>

<P>
<U>Mike Miller</U>:</P>

<P>I can see the value in this, but it doesn't seem to be well
reflected in the wording of the Standard.  For instance, presumably
<TT>*p</TT> above would have to be an lvalue in order to be the
operand of "<TT>&amp;</TT>", but the definition of "lvalue" in
7.2.1 [<A href="https://wg21.link/basic.lval#2">basic.lval</A>] paragraph 2 says that "an lvalue refers to
an object."  What's the object in <TT>*p</TT>?  If we were to allow
this, we would need to augment the definition to include the result of
dereferencing null and one-past-the-end-of-array.</P>

<P>
<U>Tom Plum</U>:</P>

<P>Just to add one more recollection of the intent: I was <I>very</I>
happy when (I thought) we decided that it was only the attempt to
actually fetch a value that creates undefined behavior.  The words
which (I thought) were intended to clarify that are the first three
sentences of the lvalue-to-rvalue conversion, 7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]:</P>

<BLOCKQUOTE>

An lvalue (7.2.1 [<A href="https://wg21.link/basic.lval">basic.lval</A>]) of a non-function, non-array
type <TT>T</TT> can be converted to an rvalue.  If <TT>T</TT> is an
incomplete type, a program that necessitates this conversion is
ill-formed.  If the object to which the lvalue refers is not an object
of type <TT>T</TT> and is not an object of a type derived from
<TT>T</TT>, or if the object is uninitialized, a program that
necessitates this conversion has undefined behavior.

</BLOCKQUOTE>

<P>In other words, it is only the act of "fetching", of
lvalue-to-rvalue conversion, that triggers the ill-formed or undefined
behavior.  Simply forming the lvalue expression, and then for example
taking its address, does not trigger either of those errors.  I
described this approach to WG14 and it may have been incorporated into
C 1999.</P>

<P>
<U>Mike Miller</U>:</P>

<P>If we admit the possibility of null lvalues, as Tom is suggesting
here, that significantly undercuts the rationale for prohibiting "null
references" -- what is a reference, after all, but a named lvalue?  If
it's okay to create a null lvalue, as long as I don't invoke the
lvalue-to-rvalue conversion on it, why shouldn't I be able to capture
that null lvalue as a reference, with the same restrictions on its
use?</P>

<P>I am not arguing in favor of null references.  I don't want them in
the language.  What I am saying is that we need to think carefully
about adopting the permissive approach of saying that it's all right
to create null lvalues, as long as you don't use them in certain ways.
If we do that, it will be very natural for people to question why they
can't pass such an lvalue to a function, as long as the function
doesn't do anything that is not permitted on a null lvalue.
</P>

<P>If we want to allow <TT>&amp;*(p=0)</TT>, maybe we should change
the definition of "<TT>&amp;</TT>" to handle dereferenced null
specially, just as <TT>typeid</TT> has special handling, rather than
changing the definition of lvalue to include dereferenced nulls, and
similarly for the array_end+1 case.  It's not as general, but I think
it might cause us fewer problems in the long run.
</P>

<P><B>Notes from the October 2003 meeting:</B></P>

<P>See also <A HREF="cwg_closed.html#315">issue 315</A>, which deals with
the call of a static member function through a null pointer.</P>

<P>We agreed that the approach in the standard seems okay:
<TT>p = 0; *p;</TT> is not inherently an error.  An
lvalue-to-rvalue conversion would give it undefined behavior.</P>

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

<P>(Note: the resolution of <A HREF="cwg_defects.html#453">issue 453</A>
also resolves part of this issue.)</P>

<OL>

<LI>
<P>Add the indicated words to 7.2.1 [<A href="https://wg21.link/basic.lval#2">basic.lval</A>] paragraph 2:
</P>

<BLOCKQUOTE>

An lvalue refers to an object or function <INS>or is an empty lvalue
(7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>])</INS>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Add the indicated words to 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#1">expr.unary.op</A>] paragraph 1:
</P>

<BLOCKQUOTE>

The unary <TT>*</TT> operator performs <I>indirection</I>: the
expression to which it is applied shall be a pointer to an object
type, or a pointer to a function type and the result is an lvalue
referring to the object or function to which the expression
points<INS>, if any. If the pointer is a null pointer value
(7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]) or points one past the last element
of an array object (7.6.6 [<A href="https://wg21.link/expr.add">expr.add</A>]), the result is an
<I>empty lvalue</I> and does not refer to any object or function.
An empty lvalue is not modifiable</INS>.  If the type of the
expression is &#8220;pointer to <TT>T</TT>,&#8221; the type of
the result is &#8220;<TT>T</TT>.&#8221; [<I>Note:</I> a pointer to an
incomplete type (other than cv void) can be dereferenced. The
lvalue thus obtained can be used in limited ways (to initialize a
reference, for example); this lvalue must not be converted to an
rvalue, see 7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>].&#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>
<P>Add the indicated words to 7.3.2 [<A href="https://wg21.link/conv.lval#1">conv.lval</A>] paragraph 1:
</P>

<BLOCKQUOTE>

If the object to which the lvalue refers is not an object of type
<TT>T</TT> and is not an object of a type derived from
<TT>T</TT>, or if the object is uninitialized, <INS>or if the
lvalue is an empty lvalue (7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]),</INS> a
program that necessitates this conversion has undefined behavior.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 6.10.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>] as indicated:</P>

<BLOCKQUOTE>

Certain other operations are described in this International
Standard as undefined (for example, the effect of <DEL>dereferencing
the null pointer</DEL> <INS>division by zero</INS>).

</BLOCKQUOTE>

</LI>

</OL>

<P><B>Note (March, 2005):</B></P>

<P>The 10/2004 resolution interacts with the resolution of <A HREF="cwg_defects.html#73">issue 73</A>.  We added wording to 6.9.4 [<A href="https://wg21.link/basic.compound#3">basic.compound</A>] paragraph 3 to the effect that a pointer containing
the address one past the end of an array is considered to &#8220;point
to&#8221; another object of the same type that might be located there.
The 10/2004 resolution now says that it would be undefined behavior to
use such a pointer to fetch the value of that object.  There is at
least the appearance of conflict here; it may be all right, but it at
needs to be discussed further.</P>

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

<P>The CWG agreed that there is no contradiction between this
direction and the resolution of <A HREF="cwg_defects.html#73">issue 73</A>.
However, &#8220;not modifiable&#8221; is a compile-time concept, while
in fact this deals with runtime values and thus should produce
undefined behavior instead.  Also, there are other contexts in which
lvalues can occur, such as the left operand of <TT>.</TT>
or <TT>.*</TT>, which should also be restricted.  Additional drafting
is required.</P>

<P>(See also <A HREF="cwg_defects.html#1102">issue 1102</A>.)</P>



<P><B>CWG 2023-11-06</B></P>

<P>There is no consensus to pursue the introduction of empty lvalues,
without prejudice to a potential future paper addressed to EWG.  The
implicit undefined behavior in 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#1">expr.unary.op</A>] paragraph 1
is handled in <A HREF="cwg_defects.html#2823">issue 2823</A>.</P>

<BR><BR><HR>
<A NAME="610"></A><H4>610.
  
Computing the negative of <TT>0U</TT>
</H4>
<B>Section: </B>7.6.2.2&#160; [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>comp.std.c++
 &#160;&#160;&#160;

 <B>Date: </B>21 December 2006<BR>


<P>In 7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>], part of paragraph 7 describes
how to compute the negative of an unsigned quantity:</P>

<BLOCKQUOTE>

The negative of an unsigned quantity is computed by subtracting
its value from 2<SUP><I>n</I></SUP>, where <I>n</I> is the number
of bits in the promoted operand.  The type of the result is the
type of the promoted operand.

</BLOCKQUOTE>

<P>According to this method, <TT>-0U</TT> will get the value
2<SUP><I>n</I></SUP>&#160;-&#160;0 = 2<SUP><I>n</I></SUP>, where
<I>n</I> is the number of bits in an unsigned int.  However,
2<SUP><I>n</I></SUP> is obviously out of the range of values
representable by an unsigned int and thus not the actual value
of <TT>-0U</TT>.  To get the result, a truncating conversion
must be applied.</P>

<P><B>Rationale (April, 2007):</B></P>

<P>As noted in the issue description, a &#8220;truncating
conversion&#8221; is needed.  This conversion is supplied without
need of an explicit mention, however, by the nature of unsigned
arithmetic given in 6.9.2 [<A href="https://wg21.link/basic.fundamental#4">basic.fundamental</A>] paragraph 4:</P>

<BLOCKQUOTE>

Unsigned integers, declared <TT>unsigned</TT>, shall obey the laws of
arithmetic modulo 2<SUP><I>n</I></SUP> where <I>n</I> is the number of
bits in the value representation of that particular size of
integer.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1923"></A><H4>1923.
  
Lvalues of type <TT>void</TT>
</H4>
<B>Section: </B>7.6.2.2&#160; [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-05-06<BR>




<P>There does not seem to be any significant technical obstacle to
allowing a <TT>void*</TT> pointer to be dereferenced, and that would
avoid having to use weighty circumlocutions when casting to a
reference to an object designated by such a pointer.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>This request for a language extension should be evaluated by EWG
before any action is taken.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a request for a new feature, which should be proposed in a
paper to EWG.</P>

<BR><BR><HR>
<A NAME="2454"></A><H4>2454.
  
Tail recursion and coroutine symmetric transfer
</H4>
<B>Section: </B>7.6.2.4&#160; [<A href="https://wg21.link/expr.await">expr.await</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lewis Baker
 &#160;&#160;&#160;

 <B>Date: </B>2020-02-14<BR>


<P>Paper P0913R0 proposed adding support for a symmetric-transfer
capability intended to allow coroutines to be recursively
resumed without consuming an unbounded amount of stack space.
However, the current wording does not required this, only
suggesting it in a note in bullet 5.1.1 of
7.6.2.4 [<A href="https://wg21.link/expr.await">expr.await</A>]. This should be a normative
requirement.</P>

<P><B>Rationale (July, 2020):</B></P>

<P>This issue is essentially about implementation limits, which
are impossible to specify normatively, and it is inappropriate
to specify the desired and forbidden implementation techniques
in the Standard.</P>

<BR><BR><HR>
<A NAME="2472"></A><H4>2472.
  
Value categories in <I>await-expression</I>s
</H4>
<B>Section: </B>7.6.2.4&#160; [<A href="https://wg21.link/expr.await">expr.await</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2021-01-18<BR>


<P>According to 7.6.2.4 [<A href="https://wg21.link/expr.await">expr.await</A>] bullets 3.3 and 3.4,</P>

<BLOCKQUOTE>

<P>Evaluation of an <I>await-expression</I> involves the
following auxiliary types, expressions, and objects:</P>

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

<LI>

<P>
<I>o</I> is determined by enumerating the applicable
<TT>operator co_await</TT> functions for an
argument <I>a</I> (12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]), and
choosing the best one through overload resolution
(12.2 [<A href="https://wg21.link/over.match">over.match</A>]). If overload resolution is
ambiguous, the program is ill-formed. If no viable functions
are found, <I>o</I> is <I>a</I>. Otherwise, <I>o</I> is a
call to the selected function with the
argument <I>a</I>. If <I>o</I> would be a prvalue, the
temporary materialization conversion
(7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>]) is applied.</P>
</LI>

<LI><P>
<I>e</I> is an lvalue referring to the result of
evaluating the (possibly-converted) <I>o</I>.</P></LI>

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

</UL>

</BLOCKQUOTE>

<P>However, the temporary materialization conversion
produces an xvalue, not an lvalue. Should <I>e</I>
be a glvalue instead of an lvalue?</P>

<P><B>Rationale (February, 2021):</B></P>

<P>The specification is as intended; <I>o</I> is converted
to an lvalue if it is an xvalue result of the temporary
materialization conversion. <I>e</I> is used in both bullets
3.7 and 3.8; if it were an xvalue instead of an lvalue,
the call to <TT>await_suspend</TT> could steal <I>e</I>'s
resources and leave the call to <TT>await_resume</TT> with
a defunct object, which would be undesirable.</P>

<BR><BR><HR>
<A NAME="1606"></A><H4>1606.
  
<TT>sizeof</TT> closure class
</H4>
<B>Section: </B>7.6.2.5&#160; [<A href="https://wg21.link/expr.sizeof">expr.sizeof</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-18<BR>


<P>The standard forbids a lambda from appearing in a <TT>sizeof</TT>
operand:</P>

<BLOCKQUOTE>

A <I>lambda-expression</I> shall not appear in an unevaluated operand
(Clause 7 [<A href="https://wg21.link/expr">expr</A>]).

</BLOCKQUOTE>

<P>(7.5.6 [<A href="https://wg21.link/expr.prim.lambda#2">expr.prim.lambda</A>] paragraph 2).  However, there appears to be
no prohibition of the equivalent usage when a variable or data member has a
closure class as its type:</P>

<PRE>
  int main() {
    int i = 1;
    int j = 1;
    auto f = [=]{ return i + j;};
    return sizeof(f);
  }
</PRE>

<P>According to 7.5.6 [<A href="https://wg21.link/expr.prim.lambda#3">expr.prim.lambda</A>] paragraph 3, the size
of a closure class is not specified, so that it could vary between
translation units or between otherwise link-compatible implementations,
which could result in ODR violations if the size is used as a template
non-type argument, for example.  Should the Standard forbid taking the
size of a closure class?  Or should this simply be left as an ABI issue,
as is done with other size and alignment questions?</P>

<P><B>Additional note, April, 2013:</B></P>

<P>It was observed that generic function wrappers like
<TT>std::function</TT> rely on the ability to make compile-time
decisions based on the size of the function object, and forbidding
the application of <TT>sizeof</TT> to closure classes would make
that unnecessarily difficult.  </P>

<P><B>Rationale (April, 2013):</B></P>

<P>CWG agreed that the ODR and portability considerations were not
sufficient to outweigh the utility of applying <TT>sizeof</TT> to
closure classes as mentioned in the April, 2013 note and that the
issues are more appropriately dealt with in an ABI specification.</P>

<BR><BR><HR>
<A NAME="1678"></A><H4>1678.
  
Naming the type of an array of runtime bound
</H4>
<B>Section: </B>7.6.2.5&#160; [<A href="https://wg21.link/expr.sizeof">expr.sizeof</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-05-08<BR>


<P>According to 7.6.2.5 [<A href="https://wg21.link/expr.sizeof#1">expr.sizeof</A>] paragraph 1,</P>

<BLOCKQUOTE>

The <TT>sizeof</TT> operator shall not be applied to an expression that has
function or incomplete type, to an enumeration type whose underlying type
is not fixed before all its enumerators have been declared, to an array of
runtime bound, to the parenthesized name of such types, or to a glvalue
that designates a bit-field.

</BLOCKQUOTE>

<P>However, it is not possible to name the type of an array of runtime
bound, neither by <TT>typedef</TT> nor <TT>decltype</TT>, so the
reference to &#8220;the parenthesized name of such types&#8221; should
precede rather than follow &#8220;to an array of unknown bound.&#8221;</P>

<P><B>Rationale (September, 2013):</B></P>

<P>Arrays of runtime bound were moved from the normative specification
to a proposed Technical Specification.</P>

<BR><BR><HR>
<A NAME="1008"></A><H4>1008.
  
Querying the alignment of an object
</H4>
<B>Section: </B>7.6.2.6&#160; [<A href="https://wg21.link/expr.alignof">expr.alignof</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2009-11-27<BR>




<P>The current specification of the <TT>alignof</TT> operator
(7.6.2.6 [<A href="https://wg21.link/expr.alignof">expr.alignof</A>]) allows it to be applied only to types,
not to objects.  Since the <TT>align</TT> attribute may be applied
to objects, and since existing practice permits querying the
alignment of objects, it should be considered whether to allow
this in Standard C++ as well.</P>

<P><B>Additional note, April, 2020:</B></P>

<P>A <A HREF="https://godbolt.org/z/_SN8iF">survey of current
implementations</A> shows that most have already implemented the
extension; the example there illustrates one motivation for its
use. The principle of least astonishment would suggest that it
is surprising for <TT>sizeof</TT> and <TT>alignof</TT> to behave
differently in this regard.</P>

<P><B>Additional note (April, 2022)</B></P>

<P>This is a request for an extension, which is pursued by paper
P2152 (Querying the alignment of an object).</P>

<BR><BR><HR>
<A NAME="1685"></A><H4>1685.
  
Value category of <TT>noexcept</TT> expression
</H4>
<B>Section: </B>7.6.2.7&#160; [<A href="https://wg21.link/expr.unary.noexcept">expr.unary.noexcept</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-05-16<BR>




<P>According to 7.6.2.7 [<A href="https://wg21.link/expr.unary.noexcept#2">expr.unary.noexcept</A>] paragraph 2,</P>

<BLOCKQUOTE>

The result of the <TT>noexcept</TT> operator is a constant of
type <TT>bool</TT> and is an rvalue.

</BLOCKQUOTE>

<P>Obviously, the result should be a prvalue.</P>

<P>(See also <A HREF="cwg_defects.html#1642">issue 1642</A>, which deals with
missing specifications of value categories.)</P>

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

<P>This issue is being handled editorially and is being placed in
"review" status to ensure that the change has been made.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>The change has been made editorially.</P>

<BR><BR><HR>
<A NAME="31"></A><H4>31.
  
Looking up new/delete
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>23 Jun 1998<BR>





<P>Section 11.4.11 [<A href="https://wg21.link/class.free#4">class.free</A>] paragraph 4
says:</P>
<BLOCKQUOTE>If a <I>delete-expression</I> begins with a unary <TT>::</TT> operator, the
deallocation function's name is looked up in global scope. Otherwise,
if the <I>delete-expression</I> is used to deallocate a class object whose static
type has a virtual destructor, the deallocation function is the one found
by the lookup in the definition of the dynamic type's virtual destructor
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]
).
Otherwise, if the <I>delete-expression</I> is used to deallocate
an object of class <TT>T</TT> or array thereof, the static and dynamic types of
the object shall be identical and the deallocation function's name is
looked up in the scope of <TT>T</TT>. If this lookup fails to find the name, the
name is looked up in the global scope. If the result of the lookup is ambiguous
or inaccessible, or if the lookup selects a placement deallocation function,
the program is ill-formed.</BLOCKQUOTE>
I contrast that with 7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]

paragraphs 16 and 17:
<BLOCKQUOTE>If the <I>new-expression</I> creates an object or an array of objects
of class type, access and ambiguity control are done for the allocation
function, the deallocation function (11.4.11 [<A href="https://wg21.link/class.free">class.free</A>]
), and the constructor
(11.4.5 [<A href="https://wg21.link/class.ctor">class.ctor</A>]
). If the <I>new-expression</I> creates an array of objects of class
type, access and ambiguity control are done for the destructor (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]
).

<P>If any part of the object initialization described above terminates
by throwing an exception and a suitable deallocation function can be found,
the deallocation function is called to free the memory in which the object
was being constructed, after which the exception continues to propagate
in the context of the <I>new-expression</I>. If no unambiguous matching deallocation
function can be found, propagating the exception does not cause the object's
memory to be freed. [<I>Note:</I> This is appropriate when the called allocation
function does not allocate memory; otherwise, it is likely to result in
a memory leak. ]</P>
</BLOCKQUOTE>
I think nothing in the latter paragraphs implies that the deallocation
function found is the same as that for a corresponding <I>delete-expression</I>.
I suspect that may not have been intended and that the lookup should occur
"as if for a <I>delete-expression</I>".

<P><B>Rationale:</B></P>

<P>Paragraphs 16 through 18 are sufficiently correct and unambiguous as
written.</P>
<BR><BR><HR>
<A NAME="130"></A><H4>130.
  
Sequence points and <I>new-expression</I>s
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>20 June 1999<BR>





<P>Clause 7 [<A href="https://wg21.link/expr#4">expr</A>] paragraph 4
appears to
grant an implementation the right to generate code for a function
call like</P>

<PRE>
    f(new T1, new T2)
</PRE>

in the order

<UL>
<LI>allocate memory for the <TT>T1</TT> object</LI>
<LI>allocate memory for the <TT>T2</TT> object</LI>
<LI>call the <TT>T1</TT> constructor</LI>
<LI>call the <TT>T2</TT> constructor</LI>
<LI>call <TT>f</TT>
</LI>
</UL>

However, 7.6.2.8 [<A href="https://wg21.link/expr.new#17">expr.new</A>] paragraph 17

seems to require the deallocation of the storage for an object only
if part of the initialization of that object terminates with an
exception.  Given the ordering above, this specification would
appear to allow the memory for the <TT>T2</TT> object to be leaked
if the <TT>T1</TT> constructor throws an exception.

<P>Suggested resolution: either forbid the ordering above or expand
the requirement for reclaiming storage to include exceptions thrown
in all operations between the allocation and the completion of the
constructor.</P>

<P>
<B>Rationale (10/99):</B> Even in the "traditional" ordering of the calls
to allocation functions and constructors, memory can still leak.  For
instance, if <TT>T1</TT> were successfully constructed and then the
construction of <TT>T2</TT> were terminated by an exception, the
memory for <TT>T1</TT> would be lost.  Programmers concerned about
memory leaks will avoid this kind of construct, so it seems
unnecessary to provide special treatment for it to avoid the memory
leaks associated with one particular implementation strategy.</P>
<BR><BR><HR>
<A NAME="473"></A><H4>473.
  
Block-scope declarations of allocator functions
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>12 Jul 2004<BR>


<P>Looking up <TT>operator new</TT> in a <I>new-expression</I>
uses a different mechanism from ordinary lookup.  According to
7.6.2.8 [<A href="https://wg21.link/expr.new#9">expr.new</A>] paragraph 9,</P>

<BLOCKQUOTE>
If the <I>new-expression</I> begins with a unary <TT>::</TT>
operator, the allocation function's name is looked up in the
global scope. Otherwise, if the allocated type is a class type
<TT>T</TT> or array thereof, the allocation function's name is
looked up in the scope of <TT>T</TT>. If this lookup fails to
find the name, or if the allocated type is not a class type, the
allocation function's name is looked up in the global scope.
</BLOCKQUOTE>

<P>Note in particular that the scope in which the
<I>new-expression</I> occurs is not considered.  For example,</P>

<PRE>
    void f() {
        void* operator new(std::size_t, void*);
        int* i = new int;    // okay?
    }
</PRE>

<P>In this example, the implicit reference to <TT>operator
new(std::size_t)</TT> finds the global declaration, even though
the block-scope declaration of <tt>operator new</tt> with a
different signature would hide it from an ordinary reference.</P>

<P>This seems strange; either the block-scope declaration should
be ill-formed or it should be found by the lookup.</P>

<P><B>Notes from October 2004 meeting:</B></P>

<P>The CWG agreed that the block-scope declaration should not be
found by the lookup in a <I>new-expression</I>.  It would,
however, be found by ordinary lookup if the allocation function
were invoked explicitly.</P>

<P><B>Rationale</B></P>

<P>The wording correctly reflects the intent; block-scope allocation
functions are not found by the special lookup in
a <I>new-expression</I>.</P>

<BR><BR><HR>
<A NAME="1566"></A><H4>1566.
  
Should <TT>new std::initializer_list&lt;T&gt;</TT> be ill-formed?
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-10-10<BR>




<P>A <I>new-expression</I> that creates an object whose type is a
specialization of <TT>std::initializer_list</TT> initialized from an
initializer list results in undefined behavior if the object survives
past the end of the full-expression, when the lifetime of the underlying
array object ends.  Since such a <I>new-expression</I> is effectively
useless, should it be made ill-formed?</P>

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

<P>The consensus of CWG was that this usage should be ill-formed.</P>

<P><B>Rationale (February, 2013):</B></P>

<P>Because the library emulation of <TT>std::is_constructible</TT> uses
unevaluated <I>new-expression</I>s in the implementation, making a
<TT>new</TT> of <TT>std::initializer_list</TT> ill-formed would give the
wrong results for its constructibility.  CWG determined that it would be
acceptable to leave diagnosing of actual undefined behavior resulting from
such constructs to the discretion of the implementation.</P>

<BR><BR><HR>
<A NAME="1259"></A><H4>1259.
  
Deleting a POD via a pointer to base
</H4>
<B>Section: </B>7.6.2.9&#160; [<A href="https://wg21.link/expr.delete">expr.delete</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-10<BR>




<P>It is currently undefined behavior to delete a derived-class object
via a pointer to a base class unless the base class has a virtual
destructor.  It has been suggesed that this could be allowed for a
standard-layout class.  If so, presumably the caveats about a
deallocation function or non-trivial destructor found in 7.6.2.9 [<A href="https://wg21.link/expr.delete#5">expr.delete</A>] paragraph 5 that currently apply to incomplete types
would need to be extended to apply to the derived class in such cases.</P>

<P>Another objection that was raised is that such a change would make it
more difficult to extend C++ in the future to have global deallocation
functions that can take the size of the object being deleted as an
argument, as is currently possible for member deallocation functions.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The specification is as intended; changes to the restriction would
need to be considered in a larger context by EWG.</P>

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

<P>EWG has decided not to make a change in this area. See EWG issue
99.</P>

<BR><BR><HR>
<A NAME="2239"></A><H4>2239.
  
Sized deallocation with a trivial destructor
</H4>
<B>Section: </B>7.6.2.9&#160; [<A href="https://wg21.link/expr.delete">expr.delete</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-03-03<BR>


<P>According to 7.6.2.9 [<A href="https://wg21.link/expr.delete#10">expr.delete</A>] paragraph 10, deletion of an
array of a class with both sized and non-sized deallocation functions is
not required to call the sized version if the destructor is trivial:</P>

<BLOCKQUOTE>

<P>If deallocation function lookup finds both a usual deallocation function
with only a pointer parameter and a usual deallocation function with both a
pointer parameter and a size parameter, the function to be called is
selected as follows:</P>

<UL>
<LI><P>If the type is complete and if, for the second alternative
(delete array) only, the operand is a pointer to a class type with a
non-trivial destructor or a (possibly multi-dimensional) array thereof, the
function with two parameters is selected.</P></LI>

<LI><P>Otherwise, it is unspecified which of the two deallocation functions
is selected.</P></LI>

</UL>

</BLOCKQUOTE>

<P>However, if only a sized deallocation function is specified as a
class-specific deallocation function, it is not clear how the size
argument is to be determined if the class has a trivial destructor.</P>

<P><B>Rationale (November, 2016):</B></P>

<P>The adoption of paper P0035R4 has rendered this issue moot.</P>

<BR><BR><HR>
<A NAME="2925"></A><H4>2925.
  
Deleting a pointer to an incomplete enumeration type
</H4>
<B>Section: </B>7.6.2.9&#160; [<A href="https://wg21.link/expr.delete">expr.delete</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2024-08-14<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/597">#597</A>.)</P>

<P>Paper
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3144r2.pdf">P3144R2</A>
(Deleting a Pointer to an Incomplete Type Should be Ill-formed),
approved in June, 2024, only covered deletion of incomplete class
types.  However, enumeration types can also be incomplete per
9.8.1 [<A href="https://wg21.link/dcl.enum#6">dcl.enum</A>] paragraph 6:</P>

<BLOCKQUOTE>

An enumeration whose underlying type is fixed is an incomplete type
until immediately after its <I>enum-base</I> (if any), at which point
it becomes a complete type. An enumeration whose underlying type is
not fixed is an incomplete type until the closing } of
its <I>enum-specifier</I> , at which point it becomes a complete type.

</BLOCKQUOTE>

<P>This leads to the following example that ought to be ill-formed as well:</P>

<PRE>
  enum E {
    zero = decltype(delete static_cast&lt;E*&gt;(nullptr), 0){}
  };
</PRE>

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

<P>Change in 7.6.2.9 [<A href="https://wg21.link/expr.delete#4">expr.delete</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

If the <INS>static type of the</INS> object <DEL>being</DEL> <INS>to
be</INS> deleted has incomplete <DEL>class</DEL> type at the point of
deletion, the program is ill-formed.

</BLOCKQUOTE>

<P><B>CWG 2024-09-13</B></P>

<P>Since an enumeration type can never have a user-declared
destructor, there is no risk of introducing undefined behavior that
would be prevented by making deletions involving incomplete
enumeration types ill-formed.  In short, the situation discussed in
this issue is harmless and thus lacks rationale to be made
ill-formed.</P>
<BR><BR><HR>
<A NAME="909"></A><H4>909.
  
Old-style casts with conversion functions
</H4>
<B>Section: </B>7.6.3&#160; [<A href="https://wg21.link/expr.cast">expr.cast</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2 June, 2009<BR>




<P>According to 7.6.3 [<A href="https://wg21.link/expr.cast#4">expr.cast</A>] paragraph 4, one possible
interpretation of an old-style cast is as a <TT>static_cast</TT>
followed by a <TT>const_cast</TT>.  One would therefore expect that
the expressions marked #1 and #2 in the following example would have
the same validity and meaning:</P>

<PRE>
    struct S {
      operator const int* ();
    };

    void f(S&amp; s)  {
      const_cast&lt;int*&gt;(static_cast&lt;const int*&gt;(s));  // #1
      (int*) s;  // #2
    }
</PRE>

<P>However, a number of implementations issue an error on #2.</P>

<P>Is the intent that <TT>(T*)x</TT> should be interpreted as
something like</P>

<PRE>
    const_cast&lt;T*&gt;(static_cast&lt;const volatile T*&gt;(x))
</PRE>

<P><B>Rationale (July, 2009):</B></P>

<P>According to the straightforward interpretation of the wording,
the example should work.  This appears to be just a compiler bug.</P>

<BR><BR><HR>
<A NAME="1124"></A><H4>1124.
  
Error in description of value category of pointer-to-member expression
</H4>
<B>Section: </B>7.6.4&#160; [<A href="https://wg21.link/expr.mptr.oper">expr.mptr.oper</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#JP2">N3092 comment
  JP&#160;2<BR></A>

<P>According to 7.6.4 [<A href="https://wg21.link/expr.mptr.oper#6">expr.mptr.oper</A>] paragraph 6,</P>

<BLOCKQUOTE>

The result of a <TT>.*</TT> expression whose second operand
is a pointer to a data member is of the same value category
(7.2.1 [<A href="https://wg21.link/basic.lval">basic.lval</A>]) as its first operand.

</BLOCKQUOTE>

<P>This is incorrect if the member has a reference type, in
which case the result is an lvalue.</P>

<P><B>Rationale (September, 2010):</B></P>

<P>There are no pointers to member of reference type; see
9.3.4.4 [<A href="https://wg21.link/dcl.mptr#3">dcl.mptr</A>] paragraph 3.</P>

<BR><BR><HR>
<A NAME="55"></A><H4>55.
  
Adding/subtracting pointer and enumeration value
</H4>
<B>Section: </B>7.6.6&#160; [<A href="https://wg21.link/expr.add">expr.add</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>13 Oct 1998<BR>



<P>An expression of the form pointer + enum (see paragraph 5) is not given
meaning, and ought to be, given that paragraph 2 of this section makes
it valid. Presumably, the enum value should be converted to an integral
value, and the rest of the processing done on that basis. Perhaps
we want to invoke the integral promotions here.</P>

<P>[Should this apply to (pointer - enum) too?]</P>

<P>
<B>Rationale (04/99):</B>
Paragraph 1 invokes "the usual arithmetic conversions" for operands
of enumeration type.</P>

<P>(It was later pointed out that the builtin operator
<TT><I>T*</I> operator+(<I>T</I>*, ptrdiff_t)</TT>
(12.5 [<A href="https://wg21.link/over.built#13">over.built</A>] paragraph 13)
 is
selected by overload resolution.  Consequently, according to
12.2.2.3 [<A href="https://wg21.link/over.match.oper#7">over.match.oper</A>] paragraph 7,

the operand of enumeration type is converted to <TT>ptrdiff_t</TT>
before being interpreted according to the rules in
7.6.6 [<A href="https://wg21.link/expr.add">expr.add</A>]
.)</P>
<BR><BR><HR>
<A NAME="567"></A><H4>567.
  
Can <TT>size_t</TT> and <TT>ptrdiff_t</TT> be larger than <TT>long</TT>?
</H4>
<B>Section: </B>7.6.6&#160; [<A href="https://wg21.link/expr.add">expr.add</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nick MacLaren
 &#160;&#160;&#160;

 <B>Date: </B>14 March 2006<BR>


<P>Code that was portable in C90 and C++98 is no longer portable with
the introduction of data types longer than <TT>long</TT>; code that
could previously cast <TT>size_t</TT> and <TT>ptrdiff_t</TT> to
<TT>long</TT> without loss of precision (because <TT>long</TT> was
the largest type) can no longer rely on that idiom.</P>

<P>The CWG discussed this during the Berlin (April, 2006) meeting.  The
general consensus was that this was unavoidable: there are valid
reasons for implementations to keep <TT>long</TT> at a size less than
that required for address arithmetic.</P>

<P>See paper J16/06-0053 = WG21 N1983, which also suggests the
possibility of required diagnostics for problematic cases as an
alternative to restricting the size of <TT>size_t</TT> and
<TT>ptrdiff_t</TT>.</P>

<P><B>Rationale (October, 2006):</B></P>

<P>This is not an area in which the Standard should override the
decisions of implementors who wish to maintain the size of
<TT>long</TT> for backward compatibility but need a
larger <TT>size_t</TT> to deal with expanded address spaces.  Also,
diagnostics of the sort described are better treated as quality of
implementation issues rather than topics for standardization.</P>

<BR><BR><HR>
<A NAME="1314"></A><H4>1314.
  
Pointer arithmetic within standard-layout objects
</H4>
<B>Section: </B>7.6.6&#160; [<A href="https://wg21.link/expr.add">expr.add</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-05-06<BR>




<P>According to 6.9 [<A href="https://wg21.link/basic.types#4">basic.types</A>] paragraph 4,</P>

<BLOCKQUOTE>

The <I>object representation</I> of an object of type <TT>T</TT> is
the sequence of <I>N</I> <TT>unsigned char</TT> objects taken up by
the object of type <TT>T</TT>, where <I>N</I> equals
<TT>sizeof(T)</TT>.

</BLOCKQUOTE>

<P>and 6.8.2 [<A href="https://wg21.link/intro.object#5">intro.object</A>] paragraph 5,</P>

<BLOCKQUOTE>

An object of trivially copyable or standard-layout type (6.9 [<A href="https://wg21.link/basic.types">basic.types</A>]) shall occupy contiguous bytes of storage.

</BLOCKQUOTE>

<P>Do these passages make pointer arithmetic (7.6.6 [<A href="https://wg21.link/expr.add#5">expr.add</A>] paragraph 5)
 within a standard-layout object well-defined (e.g., for
writing one's own version of <TT>memcpy</TT>?</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The current wording is sufficiently clear that this usage is
permitted.</P>

<BR><BR><HR>
<A NAME="2548"></A><H4>2548.
  
Array prvalues and additive operators
</H4>
<B>Section: </B>7.6.6&#160; [<A href="https://wg21.link/expr.add">expr.add</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrey Erokhin
 &#160;&#160;&#160;

 <B>Date: </B>2022-03-08
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Consider</P>

<PRE>
  int main()
  {
    using IA = int[];
    IA{ 1, 2, 3 } + 0;
  }
</PRE>

<P>This appears to be ill-formed given the current wording, because
the operand is already a prvalue, thus 7.2.1 [<A href="https://wg21.link/basic.lval#6">basic.lval</A>] paragraph 6 does not apply and the array-to-pointer conversion is not
applied:</P>

<BLOCKQUOTE>

Whenever a glvalue appears as an operand of an operator that expects a
prvalue for that operand, the lvalue-to-rvalue
(7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]), array-to-pointer
(7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]), or function-to-pointer
(7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]) standard conversions are applied to
convert the expression to a prvalue.

</BLOCKQUOTE>

<P>This outcome might be an oversight in the resolution for
<A HREF="cwg_defects.html#1232">issue 1232</A>.</P>

<P>See also
<A HREF="https://github.com/llvm/llvm-project/issues/54016">clang issue 54016</A>.</P>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<P>Change in 7.6.6 [<A href="https://wg21.link/expr.add#1">expr.add</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The additive operators + and - group left-to-right. The usual
arithmetic conversions (7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are performed for
operands of arithmetic or enumeration type. <INS>The array-to-pointer
conversion (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]) is applied to an operand of
array type.</INS>

</BLOCKQUOTE>

<P><B>CWG 2023-07-14</B></P>

<P>CWG is generally in favor of the proposed resolution, but the
interaction with the surrounding text needs to be checked in more
detail after a Working Draft reflecting the Varna straw polls has
become available.</P>

<P><B>Additional notes (September, 2023)</B></P>

<P>It is questionable which use-cases are being addressed by this
change.  On the other hand, <TT>IA{1,2,3}[1]</TT> already works today
(7.2.1 [<A href="https://wg21.link/basic.lval#6">basic.lval</A>] paragraph 6 and 7.6.1.2 [<A href="https://wg21.link/expr.sub#2">expr.sub</A>] paragraph 2).  However, the latter does cause temporary lifetime
extension (6.8.7 [<A href="https://wg21.link/class.temporary#6">class.temporary</A>] paragraph 6), whereas the
near-equivalent <TT>*(IA{1,2,3} + 1)</TT> does not.
</P>

<P>Similar to the addition case, indirection through an array prvalue
is also not valid today.  Consistency seems desirable.</P>

<P>
<I>Related vendor tickets</I>:
<A HREF="https://github.com/llvm/llvm-project/issues/54016">clang</A>,
<A HREF="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264">gcc</A>.</P>

<P><U>Possible resolution (amended 2023-10-09):</U></P>

<OL>

<LI>
<P>Change in 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#1">expr.unary.op</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The unary <TT>*</TT> operator performs indirection. <INS>The
array-to-pointer conversion (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]) is applied to
an operand of array type; the possibly converted</INS> <DEL>Its</DEL>
operand shall be a prvalue of type &#8220;pointer to T&#8221;, where T
is an object or function type. The operator yields an lvalue of type T
denoting the object or function to which the operand points.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#7">expr.unary.op</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

The <INS>unary <TT>+</TT> operator performs promotion.  The
array-to-pointer conversion (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]) is applied to
an operand of array type; the possibly converted</INS> operand <DEL>of
the unary + operator</DEL> shall be a prvalue of arithmetic, unscoped
enumeration, or pointer type <DEL>and the result is the value of the
argument</DEL>. Integral
promotion <INS>(7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>])</INS> is performed on
integral or enumeration operands. <DEL>The type of the result is the
type of the promoted operand.</DEL>
<INS>The operator yields a prvalue of the type of the converted
operand; the result is the value of the converted operand.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.6 [<A href="https://wg21.link/expr.add#1">expr.add</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The additive operators + and - group left-to-right. Each operand shall
be a prvalue. If both operands have arithmetic or unscoped enumeration
type, the usual arithmetic conversions (7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are
performed. Otherwise, if one operand has arithmetic or unscoped
enumeration type, integral promotion is applied
(7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>]) to that operand.  <INS>The
array-to-pointer conversion (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]) is applied to
an operand of array type.</INS> A converted or promoted operand is
used in place of the corresponding original operand for the remainder
of this section.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.1.2 [<A href="https://wg21.link/expr.sub#2">expr.sub</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

... The <INS>result of the</INS> expression <TT>E1[E2]</TT> is identical (by definition)
to <INS>that of</INS> <TT>*((E1)+(E2))</TT>, except that in the case of an array operand,
the result is an lvalue if that operand is an lvalue and an xvalue
otherwise.
<div class="ins">
[ Note: The semantics of <TT>E1[E2]</TT> differ from
those of <TT>*((E1)+(E2))</TT> also for
<UL>
<LI>lifetime extension of temporaries (6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]) and</LI>
<LI>changing the active member of a union via assignment
(11.5.1 [<A href="https://wg21.link/class.union.general">class.union.general</A>]).</LI>
</UL>
-- end note ]</div>

</BLOCKQUOTE>
</LI>
</OL>

<P><B>CWG 2023-09-15 (amended 2023-10-09)</B></P>

<P>CWG seeks advice from EWG whether support for array prvalue
operands should be added for the indirection operator, the
unary <TT>+</TT> operator, and the additive operators, along the lines
of the wording above.  Similar to the <TT>[]</TT> operator, the
specification of the indirection operation could be amended to yield
an xvalue if the argument is a prvalue. The unary <TT>+</TT> operator
is occasionally used to force an array-to-pointer decay.</P>

<P>Forwarded to EWG via
<A HREF="https://github.com/cplusplus/papers/issues/1633">paper issue 1633</A>.</P>

<P>Paper
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2865r2.pdf">P2865R2</A>
seeks to remove the array-to-pointer conversion for the operands of
relational operators, wheras this issue suggests adding more
applications for the array-to-pointer conversion.  These two
directions appear not to be in harmony.</P>

<P><B>EWG 2023-11-07</B></P>

<P>The lack of support for the corner-case in this issue is not a
defect given the direction in P2865 (Remove Deprecated Array
Comparisons from C++26).</P>

<BR><BR><HR>
<A NAME="2087"></A><H4>2087.
  
Left shift of negative value by zero bits
</H4>
<B>Section: </B>7.6.7&#160; [<A href="https://wg21.link/expr.shift">expr.shift</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mattheus Izvekov
 &#160;&#160;&#160;

 <B>Date: </B>2015-02-16<BR>


<P>A shift of zero bits should result in the left operand
regardless of its sign.  However, the current wording of
7.6.7 [<A href="https://wg21.link/expr.shift#2">expr.shift</A>] paragraph 2 makes it undefined
behavior.</P>

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

<P>CWG felt that a reasonable approach might be to
define <TT>&lt;&lt;N</TT> as equivalent to multiplying by
2<SUP><I>N</I></SUP> in all cases; see also the resolution of
<A HREF="cwg_defects.html#1457">issue 1457</A>. The resolution of
this question should also be coordinated with SG6 and SG12,
as well as with WG14.</P>

<P><B>Rationale (February, 2019):</B></P>

<P>This issue is resolved by the adoption of paper P1236.</P>

<BR><BR><HR>
<A NAME="622"></A><H4>622.
  
Relational comparisons of arbitrary pointers
</H4>
<B>Section: </B>7.6.9&#160; [<A href="https://wg21.link/expr.rel">expr.rel</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>26 February 2007<BR>




<P>The relational operators have unspecified results when comparing
pointers that refer to objects that are not members of the same object
or elements of the same array (7.6.9 [<A href="https://wg21.link/expr.rel#2">expr.rel</A>] paragraph 2,
second bullet).  This restriction (which dates from C89) stems from
the desire not to penalize implementations on architectures with
segmented memory by forcing them essentially to simulate a flat
address space for the purpose of these comparisons.  If such an
implementation requires that objects and arrays to fit within a single
segment, this restriction enables pointer comparison to be done simply
by comparing the offset portion of the pointers, which could
be <I>much</I> faster than comparing the full pointer values.</P>

<P>The problem with this restriction in C++ is that it forces users of
the Standard Library containers to use <TT>less&lt;T*&gt;</TT> instead
of the built-in <TT>&lt;</TT> operator to provide a total ordering on
pointers, a usage that is inconvenient and error-prone.  Can the
existing restriction be relaxed in some way to allow the built-in
operator to provide a total ordering?  (John Spicer pointed out that
the actual comparison for a segmented architecture need only supply a
total ordering of pointer values, not necessarily the complete
linearization of the address space.)</P>

<P><B>Rationale (April, 2007):</B></P>

<P>The current specification is clear and was well-motivated.
Analysis of whether this restriction is still needed should be done
via a paper and discussed in the Evolution Working Group rather than
being handled by CWG as an issue/defect.</P>

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

<P>EWG has decided not to make a change in this area.  See EWG issue
91.</P>

<BR><BR><HR>
<A NAME="1400"></A><H4>1400.
  
Function pointer equality
</H4>
<B>Section: </B>7.6.10&#160; [<A href="https://wg21.link/expr.eq">expr.eq</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-09-30<BR>




<P>According to 7.6.10 [<A href="https://wg21.link/expr.eq#2">expr.eq</A>] paragraph 2, two function
pointers only compare equal if they point to the same function.
However, as an optimization, implementations are currently aliasing
functions that have identical definitions.  It is not clear whether the
Standard needs to deal explicitly with this optimization or not.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>The Standard is clear on the requirements, and implementations are
free to optimize within the constraints of the &#8220;as-if&#8221;
rule.</P>

<BR><BR><HR>
<A NAME="2302"></A><H4>2302.
  
Address comparison between different member subobjects
</H4>
<B>Section: </B>7.6.10&#160; [<A href="https://wg21.link/expr.eq">expr.eq</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-04-29<BR>


<P>According to 7.6.10 [<A href="https://wg21.link/expr.eq#2.1">expr.eq</A>] bullet 2.1,</P>

<BLOCKQUOTE>

<P>Comparing pointers is defined as follows:</P>

<UL>
<LI><P>If one pointer represents the address of a complete object, and
another pointer represents the address one past the last element of a
different complete object<SUP>87</SUP>, the result of the comparison is
unspecified.</P></LI>

</UL>

</BLOCKQUOTE>

<P>The use of the term &#8220;complete object&#8221; is confusing. A
complete object is one that is not a subobject of any other object
(6.8.2 [<A href="https://wg21.link/intro.object#2">intro.object</A>] paragraph 2), so this restriction apparently
does not apply to non-static data members. Is the following guaranteed
to work?</P>

<PRE>
  struct S {
    int i[2];
    int j[2];
  };

  constexpr bool check1() {
    S s = { { 1, 2 }, { 3, 4 } };
    return &amp;s.i[2] == &amp;s.j[0];
  }

  static_assert(check1(), "Guaranteed?");
</PRE>

<P>In particular, is there a guarantee that there is no padding
between nonstatic data members of the same type?</P>

<P><B>Rationale (July, 2017):</B></P>

<P>CWG determined that the existing wording is correct: the result of
the comparison is implementation-defined, but not unspecified, so the
program is well-formed but the assertion is not guaranteed to pass.</P>

<BR><BR><HR>
<A NAME="2286"></A><H4>2286.
  
Assignment evaluation order
</H4>
<B>Section: </B>7.6.19&#160; [<A href="https://wg21.link/expr.assign">expr.assign</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-07-06<BR>




<P>P0145 caused this situation:</P>

<PRE>
  extern "C" void abort();

  struct A
  {
    int i;
    int data[10000];
  } a;

  A&amp; aref() { a.i++; return a; }
  int main()
  {
    aref() = a;
    if (a.i != 0)
      abort();
  }
</PRE>

<P>Is <TT>a.i</TT> now required to be 0?</P>

<P>A related example is this:</P>

<PRE>
  int b;
  int&amp; bref() { ++b; return b; }
  int main() {
    bref() = b;
    if (b != 0)
      abort();
  }
</PRE>

<P>Here, <TT>b</TT> is required to be 0 after the assignment, because
the value computation of the RHS of the assignment is sequenced before
any side-effects on the LHS.  The difference in guaranteed behavior
between class and non-class types is disturbing.</P>

<P><B>Rationale (April, 2017):</B></P>

<P>Class copy assignment binds a <TT>const T&amp;</TT>, so
the <TT>A</TT> example actually yields <TT>a.i == 1</TT> after the
assignment.</P>

<BR><BR><HR>
<A NAME="97"></A><H4>97.
  
Use of bool constants in integral constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andy Koenig
 &#160;&#160;&#160;

 <B>Date: </B>18 Feb 1999<BR>





<P>Consider:</P>
<PRE>
    int* p = false;         // Well-formed?
    int* q = !1;            // What about this?
</PRE>

&gt;From 6.9.2 [<A href="https://wg21.link/basic.fundamental#6">basic.fundamental</A>] paragraph 6:

"As described below, <TT>bool</TT> values behave as integral types."

<P>From 7.3.12 [<A href="https://wg21.link/conv.ptr#1">conv.ptr</A>] paragraph 1:
 "A null
pointer constant is an integral constant expression rvalue of integer
type that evaluates to zero."</P>

<P>From 7.7 [<A href="https://wg21.link/expr.const#1">expr.const</A>] paragraph 1:
 "An
<I>integral constant-expression</I> can involve only literals,
enumerators, const variables or static members of integral or
enumeration types initialized with constant expressions, ..."</P>

<P>In 5.13.2 [<A href="https://wg21.link/lex.icon">lex.icon</A>]
: No mention of
<TT>true</TT> or <TT>false</TT> as an integer literal.</P>

<P>From 5.13.7 [<A href="https://wg21.link/lex.bool">lex.bool</A>]
: <TT>true</TT> and
<TT>false</TT> are Boolean literals.</P>

<P>So the definition of <TT>q</TT> is certainly valid, but the
validity of <TT>p</TT> depends on how the sentence in
7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]
 is parsed. Does it mean
<UL>{literals, enumerators, const variables, or static members} of
integral of integral or enumeration types...</UL> Or does it mean
<UL>literals (of any type), enumerators, const variables, or {static
members of integral or enumeration types}</UL> Or something else?</P>

<P>If the latter, then <TT>(3.0 &lt; 4.0)</TT> is a constant expression,
which I don't think we ever wanted. If the former, though, we have the
anomalous notion that <TT>true</TT> and <TT>false</TT> are not constant
expressions.</P>

<P>Now, you may argue that you shouldn't be allowed to convert
<TT>false</TT> to a pointer. But what about this?</P>

<PRE>
    static const bool debugging = false;

    // ...

    int table[debugging? n+1: n];
</PRE>

Whether the definition of table is well-formed hinges on whether
<TT>false</TT> is an integral constant expression.

<P>I think that it should be, and that failure to make it so was just
an oversight.</P>

<P>
<B>Rationale (04/99):</B> A careful reading of
7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]
 indicates that all types of
literals can appear in integral constant expressions, but
floating-point literals must immediately be cast to an integral type.</P>
<BR><BR><HR>
<A NAME="236"></A><H4>236.
  
Explicit temporaries and integral constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>19 Jul 2000<BR>




<P>Does an explicit temporary of an integral type qualify as an
integral constant expression?  For instance,</P>

<PRE>
    void* p = int();    // well-formed?
</PRE>

<P>It would appear to be, since <TT>int()</TT> is an explicit type
conversion according to 7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>] (at least, it's
described in a section entitled "Explicit type conversion") and type
conversions to integral types are permitted in integral constant
expressions (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]).  However, this reasoning is
somewhat tenuous, and some at least have argued otherwise.</P>

<P><B>Note (March, 2008):</B></P>

<P>This issue should be closed as NAD as a result of the rewrite of
7.7 [<A href="https://wg21.link/expr.const">expr.const</A>] in conjunction with the constexpr proposal.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>As given in the preceding note.</P>

<BR><BR><HR>
<A NAME="487"></A><H4>487.
  
Operator overloading in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>24 Nov 2004<BR>


<P>According to 7.7 [<A href="https://wg21.link/expr.const#1">expr.const</A>] paragraph 1,</P>

<BLOCKQUOTE>

In particular, except in <TT>sizeof</TT> expressions, functions,
class objects, pointers, or references shall not be used, and
assignment, increment, decrement, function-call, or comma
operators shall not be used.

</BLOCKQUOTE>

<P>Given a case like</P>

<PRE>
    enum E { e };
    int operator+(int, E);
    int i[4 + e];
</PRE>

<P>does this mean that the overloaded <TT>operator+</TT> is not
considered (because it can't be called), or is it selected by
overload resolution, thus rendering the program ill-formed?</P>

<P><B>Rationale (April, 2005):</B></P>

<P>All expressions, including constant expressions, are subject to
overload resolution.  The example is ill-formed.
</P>

<BR><BR><HR>
<A NAME="807"></A><H4>807.
  
<TT>typeid</TT> expressions in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK51">N2800 comment
  UK&#160;51<BR></A>

<P>
<TT>typeid</TT>
expressions can never be constant, whether or not the
operand is a polymorphic class type. The result of the
expression is a reference, and the <TT>typeinfo</TT> class that the
reference refers to is polymorphic, with a virtual
destructor - it can never be a literal type.
</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The intent of this specification was that the address of such a
<TT>typeinfo</TT> object could be treated as an address constant and
thus usable in constant initialization (contrary to the statement in
the comment, the result of <TT>typeid</TT> is an lvalue, not a
reference).</P>

<BR><BR><HR>
<A NAME="1384"></A><H4>1384.
  
<TT>reinterpret_cast</TT> in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-08-30<BR>




<P>
<TT>reinterpret_cast</TT> was forbidden in constant expressions to
prevent type-punning operations at compile time.  This may have been
too strict, as there are uses for the operator that do not involve
type punning.  For example, a portable implementation of the
<TT>addressof</TT> function could be written as a <TT>constexpr</TT>
function if <TT>reinterpret_cast</TT> could be used in a constant
expression.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>Although <TT>reinterpret_cast</TT> was permitted in address constant
expressions in C++03, this restriction has been implemented in some
compilers and has not proved to break significant amounts of code.
CWG deemed that the complications of dealing with pointers whose tpes
changed (pointer arithmetic and dereference could not be permitted on
such pointers) outweighed the possible utility of relaxing the current
restriction.</P>

<BR><BR><HR>
<A NAME="1407"></A><H4>1407.
  
Integral to <TT>bool</TT> conversion in converted constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-10-21<BR>




<P>The following example appears to be ill-formed, although current
implementations accept it:</P>

<PRE>
  template&lt;bool&gt; struct S { };
  S&lt;0&gt; s;
</PRE>

<P>The reason this is ill-formed is that the non-type template
argument is a converted constant expression of type <TT>bool</TT>
(see 13.4.3 [<A href="https://wg21.link/temp.arg.nontype#5">temp.arg.nontype</A>] paragraph 5), and the second
conversion in the implicit conversion sequence is a boolean
conversion, which is not allowed in the conversion for a
converted constant expression (see 7.7 [<A href="https://wg21.link/expr.const#3">expr.const</A>] paragraph 3)
.  Conversions in the other direction (from
<TT>bool</TT> to integer types) are permitted here, since they're
integral promotions.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>The analysis is correct, and the example is ill-formed.  Implementations
that accept it are in error.</P>

<BR><BR><HR>
<A NAME="1452"></A><H4>1452.
  
Value-initialized objects may be constants
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-12-24<BR>




<P>Some classes that would produce a constant when initialized by
value-initialization are not considered literal types.
For example:</P>

<PRE>
   struct A { int a; };       //<SPAN CLASS="cmnt"> non-constexpr default constructor</SPAN>
   struct B : A {};           //<SPAN CLASS="cmnt"> non-literal type</SPAN>
   constexpr int i = B().a;   //<SPAN CLASS="cmnt"> OK, trivial constructor not called</SPAN>
   constexpr B b = b ();      //<SPAN CLASS="cmnt"> error, constexpr object of non-literal type</SPAN>
</PRE>

<P><B>Additional note (February, 2017):</B></P>

<P>This is effectively <A HREF="cwg_defects.html#644">issue 644</A>, which was
resolved once, then had its resolution backed out via the resolution
of <A HREF="cwg_defects.html#1071">issue 1071</A> (actual drafting in
<A HREF="cwg_defects.html#981">issue 981</A>).</P>

<P><B>Rationale (February, 2021):</B></P>

<P>The adoption of paper P1331R2 (at the July, 2019 meeting)
rendered the question in the issue moot, as the requirement
that a constexpr constructor initialize all its non-static
data members was removed, so the defaulted <TT>B</TT>
default constructor is now constexpr.</P>

<BR><BR><HR>
<A NAME="1540"></A><H4>1540.
  
Use of address constants in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>2012-08-16<BR>




<P>It appears that the current specification of constant expressions in
7.7 [<A href="https://wg21.link/expr.const">expr.const</A>] pararaph 2 permits examples like</P>

<PRE>
  constexpr const char* p = "asdf";
  constexpr char ch = p[2];
</PRE>

<P>This seems unnecessarily complicated for both users and
implementers.  If subscripting were defined directly, rather than in
terms of pointer arithmetic and indirection (see <A HREF="cwg_defects.html#1213">issue 1213</A>), we could still support the obvious cases
of things like</P>

<PRE>
  constexpr char ch2 = "asdf"[2];
</PRE>

<P>without requiring compilers and users to track the target of
address-constant pointers and references.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>CWG was comfortable with this implication of the current wording.</P>

<BR><BR><HR>
<A NAME="1826"></A><H4>1826.
  
<TT>const</TT> floating-point in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-01-04<BR>




<P>A <TT>const</TT> integer initialized with a constant can be
used in constant expressions, but a <TT>const</TT> floating
point variable initialized with a constant cannot.  This was
intentional, to be compatible with C++03 while encouraging the
consistent use of <TT>constexpr</TT>.  Some people have found
this distinction to be surprising, however.</P>

<P>It was also observed that allowing <TT>const</TT> floating
point variables as constant expressions would be an ABI-breaking
change, since it would affect lambda capture.</P>

<P>One possibility might be to deprecate the use of <TT>const</TT>
integral variables in constant expressions.</P>

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

<P>EWG requested CWG to allow use of <TT>const</TT> floating-point
variables in constant expressions.</P>

<P><B>Rationale (May, 2015):</B></P>

<P>CWG felt that the current rules should not be changed and that
programmers desiring floating point values to participate in
constant expressions should use <TT>constexpr</TT> instead of
<TT>const</TT>.</P>

<BR><BR><HR>
<A NAME="1921"></A><H4>1921.
  
<TT>constexpr</TT> constructors and point of initialization of <TT>const</TT> variables
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-05-02<BR>




<P>In an example like</P>

<PRE>
  extern int const x;

  struct A {
    constexpr A () { }
    int value = x;
  };

  int const x = 123;

  constexpr A a;
</PRE>

<P>it is not clear whether the constructor for <TT>A</TT> is
well-formed (because the initialization for <TT>x</TT> has not
yet been seen) and whether that constant value is used in the
initialization of <TT>a</TT>.  There is implementation divergence
on these questions.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>The requirements for a <TT>constexpr</TT> constructor in
9.2.6 [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>] do not require that an initializer be
constant at the point of definition, similar to the provision for
mutually-recursive <TT>constexpr</TT> functions, which require that
at least one of the functions will contain a reference to a
not-yet-defined <TT>constexpr</TT> function.  Determination of
whether an expression is constant or not is made in the context in
which the expression appears, by which time the constant value of
<TT>x</TT> in the exampe above is known.  CWG feels that the
current wording is clear enough that the example is well-formed.</P>

<BR><BR><HR>
<A NAME="1968"></A><H4>1968.
  
Address of <TT>typeid</TT> in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-07-14<BR>




<P>There is implementation divergence on the handling of
<TT>typeid</TT> in constant expressions, for example:</P>

<PRE>
  static_assert(&amp;typeid(int) == &amp;typeid(int), ""); //<SPAN CLASS="cmnt"> #1</SPAN>
</PRE>

<P>According to the current wording, it is unspecified whether
two evaluations of the <TT>typeid</TT> operator produce the same
result, even though <TT>typeid</TT> can be used in constant
expressions as long as its operand is not a glvalue of a
polymorphic class type.  Of particular concern is the case where
<TT>typeid</TT> might be evaluated in different translation
units.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>Because the result of two separate evaluations of the
<TT>typeid</TT> operator are not guaranteed to produce the
same result, the comparison in the example is not permitted in
a constant expression.</P>

<BR><BR><HR>
<A NAME="2005"></A><H4>2005.
  
Incorrect <TT>constexpr</TT> reference initialization requirements
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

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


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

<PRE>
  constexpr int f() { return 5; } //<SPAN CLASS="cmnt"> function must be constexpr</SPAN>
  constexpr int &amp;&amp; q = f();       //<SPAN CLASS="cmnt"> but result is not constant</SPAN>
  constexpr int const &amp; r = 2;    //<SPAN CLASS="cmnt"> temporary is still not constant</SPAN>
  int main() {
    q = 11;                       //<SPAN CLASS="cmnt"> OK</SPAN>
    const_cast&lt; int &amp; &gt;( r ) = 3; //<SPAN CLASS="cmnt"> OK (temporary object is not ROMable)</SPAN>

    constexpr int &amp;&amp; z = 7;       //<SPAN CLASS="cmnt"> Error? Temporary does not have static storage duration?</SPAN>
  }
</PRE>

<P>A constexpr reference must be initialized by a constant
expression (9.2.6 [<A href="https://wg21.link/dcl.constexpr#9">dcl.constexpr</A>] paragraph 9),
yet it may refer to a modifiable temporary object.
Such a temporary is guaranteed static initialization, but it's not ROMable.</P>

<P>A non-const constexpr reference initialized with an lvalue
expression is useful, because it indicates that the
underlying storage of the reference may be statically
initialized, or that no underlying storage is required at
all.</P>

<P>When the initializer is a temporary, finding its address is
trivial. There is no reason to declare any intent the
computation of its address. On the other hand, an initial
value is provided, and that is also required to be a
constant expression, although it's never treated as a
constant.</P>

<P>The situation is worse for local constexpr references. The
initializer generates a temporary when the declaration is
executed. The temporary is a locally scoped, unique
object. This renders constexpr meaningless, because although
the address computation is trivial, it still must be done
dynamically.</P>

<P>
C++11 constexpr references required initialization by
reference constant expressions, which had to &#8220;designate an
object with static storage duration or a function&#8221;
(C++11 7.7 [<A href="https://wg21.link/expr.const#3">expr.const</A>] paragraph 3). A
temporary with automatic storage duration granted by the
reference fails this requirement.</P>

<P>C++14 removes reference constant expressions and the static
storage requirement, rendering the program well-defined with
an apparently defeated constexpr specifier. (GCC and Clang
currently provide the C++11 diagnosis.)</P>

<P>Suggested resolution: a temporary bound to a constexpr
reference should itself be constexpr, implying
const-qualified type. Forbid binding a constexpr reference
to a temporary unless both have static storage duration. (In
local scope, the static specifier fixes the issue nicely.)</P>

<P><B>Rationale (November, 2014):</B></P>

<P>This issue is already covered by 7.7 [<A href="https://wg21.link/expr.const#4">expr.const</A>] paragraph 4,
 which includes conversions and temporaries in the
analysis.</P>

<BR><BR><HR>
<A NAME="2364"></A><H4>2364.
  
Constant expressions, aggregate initialization, and modifications
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2017-10-31<BR>


<P>There is implementation variance in the treatment of the following
example:</P>

<PRE>
  constexpr int f(int x) { return x; }
  int main() {
    struct {
      int x = f(x = 37);
    } constexpr a = { };
  }
</PRE>

<P>Is the assignment to <TT>x</TT> considered to satisfy the requirememts
of 7.7 [<A href="https://wg21.link/expr.const#2.17">expr.const</A>] bullet 2.17,</P>

<BLOCKQUOTE>

modification of an object (7.6.19 [<A href="https://wg21.link/expr.assign">expr.assign</A>],
7.6.1.6 [<A href="https://wg21.link/expr.post.incr">expr.post.incr</A>], 7.6.2.3 [<A href="https://wg21.link/expr.pre.incr">expr.pre.incr</A>]) unless it is
applied to a non-volatile lvalue of literal type that refers to a
non-volatile object whose lifetime began within the evaluation
of <TT>e</TT>;

</BLOCKQUOTE>

<P>assuming that <TT>e</TT> is the full-expression encompassing the
initialization of <TT>a</TT>?</P>

<P><B>Notes from the October, 2018 teleconference:</B></P>

<P>This kind of example was previously ill-formed but it was
inadvertently allowed by the change to the &#8220;non-vacuous
initialization&#8221; rule. That rule should be restricted to
class and array types, making this example again ill-formed.</P>

<P><B>Rationale, February, 2021:</B></P>

<P>The resolution of <A HREF="cwg_defects.html#2256">2256</A> makes
clear that the lifetime of <TT>x</TT> has not begun because
its initialization is not yet complete, so the assignment is
undefined behavior and thus ill-formed in a constant
expression.</P>

<BR><BR><HR>
<A NAME="2349"></A><H4>2349.
  
Class/enumeration names vs conditions
</H4>
<B>Section: </B>Clause 8&#160; [<A href="https://wg21.link/stmt">stmt</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2017-05-04<BR>


<P>According to Clause 8 [<A href="https://wg21.link/stmt#3">stmt</A>] paragraph 3,</P>

<BLOCKQUOTE>

A name introduced by a declaration in a <I>condition</I> (either introduced
by the <I>decl-specifier-seq</I> or the <I>declarator</I> of the condition)
is in scope from its point of declaration until the end of the
substatements controlled by the condition. If the name is redeclared in the
outermost block of a substatement controlled by the condition, the
declaration that redeclares the name is ill-formed.

</BLOCKQUOTE>

<P>This does not exempt class and enumeration names, which can ordinarily
coexist with non-type names in the same scope (_N4868_.6.4.10 [<A href="https://wg21.link/basic.scope.hiding#2">basic.scope.hiding</A>] paragraph 2)
. However, there is implementation variance in the handling
of examples like:</P>

<PRE>
   void g() {
     if (int N = 3) {
       struct N { } n; //<SPAN CLASS="cmnt"> ill-formed but not diagnosed by some implementations</SPAN>
     }
   }

</PRE>

<P>Should the rule for <I>condition</I>s be updated to allow for this
case?</P>

<P><B>Rationale (April, 2018):</B></P>

<P>Hiding of tag names by non-type names was added for C compatibility.
C does not support conditions, and there was no consensus to extend the
tag/non-type hiding rules into contexts where C compatibility is not
required.</P>

<BR><BR><HR>
<A NAME="2344"></A><H4>2344.
  
Redeclaration of names in <I>init-statement</I>s
</H4>
<B>Section: </B>8.5&#160; [<A href="https://wg21.link/stmt.select">stmt.select</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2017-04-19<BR>


<P>According to Clause 8 [<A href="https://wg21.link/stmt#3">stmt</A>] paragraph 3,</P>

<BLOCKQUOTE>

A name introduced by a declaration in a condition (either introduced by
the <I>decl-specifier-seq</I> or the declarator of the condition) is in
scope from its point of declaration until the end of the substatements
controlled by the condition. If the name is redeclared in the outermost
block of a substatement controlled by the condition, the declaration that
redeclares the name is ill-formed.

</BLOCKQUOTE>

<P>Should there be a similar rule about redeclaring names introduced
by <I>init-statement</I>s?</P>

<P><B>Notes from the April, 2018 teleconference:</B></P>

<P>CWG agreed that such a rule should be added.</P>

<P><B>Rationale (January, 2019):</B></P>

<P>The <I>init-statement</I> case is covered by
6.4.3 [<A href="https://wg21.link/basic.scope.block#3">basic.scope.block</A>] paragraph 3. These two references
should be harmonized and cross-referenced appropriately as
an editorial change.</P>

<BR><BR><HR>
<A NAME="2274"></A><H4>2274.
  
Generic lambda capture vs constexpr if
</H4>
<B>Section: </B>8.5.2&#160; [<A href="https://wg21.link/stmt.if">stmt.if</A>]
 &#160;&#160;&#160;

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

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

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




<P>Consider:</P>

<PRE>
  template&lt;typename Iter&gt; void f(Iter a, Iter b) {
    const int v = 10;
    auto do_something = [&amp;] (auto thing) {
      if constexpr (is_random_access_iterator&lt;Iter&gt; &amp;&amp; is_integral&lt;decltype(thing)&gt;)
        *(a + 1) = v;
     };
    do_something(5);
    do_something("foo");
  } 
</PRE>

<P>Determining whether <TT>v</TT> is captured requires instantiating
the "if constexpr", but that results in a hard error for a statement
that will eventually be discarded.</P>

<P><B>Rationale (February, 2018):</B></P>

<P>These questions were resolved by the adoption of paper P0588R1 at the
November, 2017 meeting.</P>

<BR><BR><HR>
<A NAME="2348"></A><H4>2348.
  
Non-templated <TT>constexpr if</TT>
</H4>
<B>Section: </B>8.5.2&#160; [<A href="https://wg21.link/stmt.if">stmt.if</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2017-05-01<BR>


<P>The effect of <TT>constexpr if</TT> in non-templated code is primarily
limited to not requiring definitions for entities that are odr-used in
discarded statements. This eliminates a plausible implementation techique
of simply skipping the tokens of a discarded statement. Should the
Standard allow such an approach? One needed change might be to say that
all diagnosable rules become &#8220;no diagnostic required&#8221; inside
discarded statements.</P>

<P><B>Rationale (April, 2018):</B></P>

<P>The design was thoroughly discussed before adopting the feature and
the current specification was intentionally adopted. Any request for a
change should go through the normal EWG process at this point.</P>

<BR><BR><HR>
<A NAME="1679"></A><H4>1679.
  
Range-based <TT>for</TT> and array of runtime bound
</H4>
<B>Section: </B>8.6.5&#160; [<A href="https://wg21.link/stmt.ranged">stmt.ranged</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-05-09<BR>




<P>The expansion of a range-based <TT>for</TT> in 8.6.5 [<A href="https://wg21.link/stmt.ranged#1">stmt.ranged</A>] paragraph 1
involves a declaration of the form</P>

<PRE>
  auto &amp;&amp; __range = range-init;
</PRE>

<P>However, it is not permitted to bind a reference to an array of
runtime bound (9.3.4.3 [<A href="https://wg21.link/dcl.ref#5">dcl.ref</A>] paragraph 5), even though it
is intended that such arrays can be used in a range-based <TT>for</TT>.</P>

<P><B>Rationale (September, 2013):</B></P>

<P>Arrays of runtime bound were moved from the normative specification
to a proposed Technical Specification.</P>

<BR><BR><HR>
<A NAME="467"></A><H4>467.
  
Jump past initialization of local static variable
</H4>
<B>Section: </B>8.10&#160; [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Kerch Holt
 &#160;&#160;&#160;

 <B>Date: </B>31 Mar 2004<BR>


<P>When jumping past initialization of a local static variable the
value of the static becomes indeterminate. Seems like this
behavior should be illegal just as it is for local variables
with automatic linkage.</P>

<P>Here is an example:</P>
<PRE>
struct X {
    X(int i) : x(i) {}
    int x;
};
int f(int c) {
    if (c)
        goto ly;    // error here for jumping past next stmt.
    static X a = 1;
ly:
    return a.x;  // either 1 or 0 depending on implementation.
}
</PRE>
<P>8.10 [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>] P3 should be changed to:
<BLOCKQUOTE>
A program that jumps from a point where a local variable with automatic
<INS>or static</INS> storage duration is not in scope to a point where it is in
scope is
ill-formed unless the variable has POD type (3.9) and is declared without
an initializer  (8.5).
</BLOCKQUOTE>
This would imply "static X a = 1;" should be flagged as an error.
Note that this behavior a may be a "quality of implementation issue"
which may be covered in 6.7 P4.  Paragraph 4 seems to make the
choice of static/dynamic initialization indeterminate.
Making this an error and thus determinate seems the correct thing
to do since that is what is already required of automatic variables.</P>

<P>
<U>Steve Adamczyk:</U>
Some version of this may be appropriate, but it's common to have code
that is executed only the first time it is reached, and to have
an initialization of a static variable inside such a piece of code.
In such a case, on executions after the first there is indeed a
jump over the declaration, but the static variable is correctly
initialized -- it was initialized the first time the routine
was called.</P>
<PRE>
  void f() {
    static bool first_time = true;
    if (!first_time) goto after_init;
    static int i = g();
    first_time = false;
  after_init:
    ...
  }
</PRE>

<P><B>Rationale (October, 2004):</B></P>

<P>The CWG sees no reason to change this specification.  Local
static variables are different from automatic variables:
automatic variables, if not explicitly initialized, can have
indeterminate (&#8220;garbage&#8221;) values, including trap
representations, while local static variables are subject to zero
initialization and thus cannot have garbage values.</P>

<P>The latitude granted to implementations regarding performing
dynamic initialization of local static objects as if it were
static initialization is exactly parallel to namespace scope
objects (6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]), as are the restrictions
on programmer assumptions.</P>

<BR><BR><HR>
<A NAME="2751"></A><H4>2751.
  
Order of destruction for parameters for operator functions
</H4>
<B>Section: </B>8.10&#160; [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2020-06-10
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Subclause 8.10 [<A href="https://wg21.link/stmt.dcl#2">stmt.dcl</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

Upon each transfer of control (including sequential execution of
statements) within a function from point P to point Q, all variables
with automatic storage duration that are active at P and not at Q are
destroyed in the reverse order of their construction.  ...  when a
function returns, Q is after its body.

</BLOCKQUOTE>

<P>Another description of the same rule is in a note in
8.8.1 [<A href="https://wg21.link/stmt.jump.general#2">stmt.jump.general</A>] paragraph 2:</P>

<BLOCKQUOTE>

[<I>Note 1:</I> On exit from a scope (however accomplished), objects
with automatic storage duration (6.8.6.4 [<A href="https://wg21.link/basic.stc.auto">basic.stc.auto</A>]) that
have been constructed in that scope are destroyed in the reverse order
of their construction. ...  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>However, 12.2.2.3 [<A href="https://wg21.link/over.match.oper#2">over.match.oper</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

... Therefore, the operator notation is first transformed to the
equivalent function-call notation as summarized in Table 18 (where @
denotes one of the operators covered in the specified
subclause). However, the operands are sequenced in the order
prescribed for the built-in operator (7.6 [<A href="https://wg21.link/expr.compound">expr.compound</A>]).

</BLOCKQUOTE>

<P>For <TT>operator+=</TT> (for example), 7.6.19 [<A href="https://wg21.link/expr.assign#1">expr.assign</A>] paragraph 1 requires:</P>

<BLOCKQUOTE>

... The right operand is sequenced before the left operand. ...

</BLOCKQUOTE>

<P>Now, consider an ABI with callee-cleanup and this example:</P>

<PRE>
  void operator&lt;&lt;(A, B);
  void operator+=(A, B);
  void (*p)(A, B) = cond ? &amp;operator&lt;&lt; : &amp;operator+=;
</PRE>

<P>In <TT>A() &lt;&lt; B()</TT>, <TT>A()</TT> is sequenced
before <TT>B()</TT>. In <TT>A() += B()</TT>, <TT>B() is sequenced
before A()</TT>.  For an ABI with callee-cleanup, this means that
<TT>operator&lt;&lt;</TT> must destroy the <TT>B</TT> parameter before
the <TT>A</TT> parameter, and <TT>operator+=</TT> must destroy
the <TT>A</TT> parameter before the <TT>B</TT> parameter.</P>

<P>But this means we have a problem emitting a call to <TT>p(A(),
B())</TT>: no order of parameter initialization guarantees that
parameters are destroyed in reverse construction order.</P>

<P>A possible implementation strategy would be to emit a second
definition of <TT>operator+=</TT> with the opposite parameter
destruction order that is used when naming the function
<TT>operator+=</TT>, e.g. when taking the address or using function
call notation (as opposed to using operator notation).</P>

<P>Another alternative is to relax the rules about destruction of
parameters in the reverse order of construction for the case of binary
operator functions and <TT>operator new</TT> and <TT>operator
delete</TT>.</P>

<P><B>Additional notes (June, 2023)</B></P>

<P>Forwarded to EWG via
<A HREF="https://github.com/cplusplus/papers/issues/1583">paper issue 1583</A>,
per decision of the CWG chair, to either affirm the intent
of the rules (requiring a more involved implementation strategy as
outlined above) or agree on a relaxation of the rules for the order of
destruction of parameters.</P>

<P><B>EWG 2023-11-07</B></P>

<P>Not a defect; the suggested implementation strategy is viable.</P>

<BR><BR><HR>
<A NAME="435"></A><H4>435.
  
Change "declararation or definition" to "declaration"
</H4>
<B>Section: </B>9.1&#160; [<A href="https://wg21.link/dcl.pre">dcl.pre</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>27 Oct 2003<BR>


<P>Because a definition is also a declaration, it might make sense
to change uses of "declaration or definition" to simply "declaration".</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>Jens Maurer prepared drafting for this issue, but we find ourselves
reluctant to actually make the changes.  Though correct, they seemed
more likely to be misread than the existing wording.</P>

<P><B>Proposed resolution:</B></P>
<P>
Remove in Clause 3 [<A href="https://wg21.link/intro.defs">intro.defs</A>] &#8220;<B>parameter</B>&#8221;
the indicated words:</P>
<BLOCKQUOTE>
an object or reference declared as part of a function declaration <DEL>or
definition</DEL>, or in the catch clause of an exception handler, that
acquires a value on entry to the function or handler; ...
</BLOCKQUOTE>

<P>
Remove in 13.2 [<A href="https://wg21.link/temp.param#10">temp.param</A>] paragraph 10
the indicated words:</P>
<BLOCKQUOTE>
The set of default <I>template-argument</I>s available for use with a
template declaration <DEL>or definition</DEL> is obtained by
merging the default arguments from the definition (if in scope) and
all declarations in scope in the same way default function arguments
are (...).
</BLOCKQUOTE>

<P>
Remove in 13.8 [<A href="https://wg21.link/temp.res#2">temp.res</A>] paragraph 2 the indicated words:</P>
<BLOCKQUOTE>
A name used in a template declaration <DEL>or definition</DEL>
and that is dependent on a <I>template-parameter</I> is assumed not to
name a type unless the applicable name lookup finds a type name or the
name is qualified by the keyword <TT>typename</TT>.
</BLOCKQUOTE>

<P>
Remove in 13.8.4.1 [<A href="https://wg21.link/temp.point#1">temp.point</A>] paragraph 1 the indicated words:</P>
<BLOCKQUOTE>
Otherwise, the point of instantiation for such a specialization
immediately follows the namespace scope declaration <DEL>or
definition</DEL> that refers to the specialization.
</BLOCKQUOTE>

<P>
Remove in 13.8.4.1 [<A href="https://wg21.link/temp.point#3">temp.point</A>] paragraph 3 the indicated words:</P>
<BLOCKQUOTE>
Otherwise, the point of instantiation for such a specialization
immediately precedes the namespace scope declaration <DEL>or
definition</DEL> that refers to the specialization.
</BLOCKQUOTE>

<P>
Remove in 13.9.4 [<A href="https://wg21.link/temp.expl.spec#21">temp.expl.spec</A>] paragraph 21 the indicated words:</P>
<BLOCKQUOTE>
Default function arguments shall not be specified in a declaration
<DEL>or a definition</DEL> for one of the following explicit
specializations:
<UL>
<LI>...</LI>
</UL>
[<I>Note:</I> default function arguments may be specified in the
declaration <DEL>or definition</DEL> of a member function of a
class template specialization that is explicitly specialized.  ]
</BLOCKQUOTE>

<P>
Remove in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#18">temp.deduct.type</A>] paragraph 18
the indicated words:</P>
<BLOCKQUOTE>
[Note: a default <I>template-argument</I> cannot be specified in a
function template declaration <DEL>or definition</DEL>; ...]
</BLOCKQUOTE>

<P>
Remove in 16.4.3.2 [<A href="https://wg21.link/using.headers#3">using.headers</A>] paragraph 3
the indicated words:</P>
<BLOCKQUOTE>
A translation unit shall include a header only outside of any external
declaration <DEL>or definition</DEL>, and shall include the
header lexically before the first reference to any of the entities it
declares <DEL>or first defines</DEL> in that translation unit.
</BLOCKQUOTE>

<P><B>Rationale (October, 2004):</B></P>

<P>CWG felt that readers might misunderstand
&#8220;declaration&#8221; as meaning &#8220;non-definition
declaration.&#8221;</P>

<BR><BR><HR>
<A NAME="1325"></A><H4>1325.
  
Omitted declarator in <TT>friend</TT> declarations
</H4>
<B>Section: </B>9.1&#160; [<A href="https://wg21.link/dcl.pre">dcl.pre</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-05-27<BR>




<P>According to 9.1 [<A href="https://wg21.link/dcl.pre#3">dcl.pre</A>] paragraph 3,</P>

<BLOCKQUOTE>

In a <I>simple-declaration</I>, the optional
<I>init-declarator-list</I> can be omitted only when declaring a class
(Clause 11 [<A href="https://wg21.link/class">class</A>]) or enumeration (9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]), that is, when the <I>decl-specifier-seq</I> contains
either a <I>class-specifier</I>, an <I>elaborated-type-specifier</I>
with a <I>class-key</I> (11.3 [<A href="https://wg21.link/class.name">class.name</A>]), or an
<I>enum-specifier</I>.

</BLOCKQUOTE>

<P>This does not allow for the new simplified <TT>friend</TT>
declaration syntax (11.8.4 [<A href="https://wg21.link/class.friend#3">class.friend</A>] paragraph 3), which
permits the forms</P>

<UL>
<TT>friend</TT> <I>simple-type-specifier</I> <TT>;</TT><BR>
<TT>friend</TT> <I>typename-specifier</I> <TT>;</TT>
</UL>

<P><B>Rationale (May, 2014):</B></P>

<P>The <TT>friend</TT> specifier can only appear in a
<I>member-declaration</I>, which contains a <I>member-declarator-list</I>,
not an <I>init-declarator-list</I>.</P>

<BR><BR><HR>
<A NAME="2288"></A><H4>2288.
  
Contradictory optionality in <I>simple-declaration</I>
</H4>
<B>Section: </B>9.1&#160; [<A href="https://wg21.link/dcl.pre">dcl.pre</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-07-12<BR>




<P>Subclause 9.1 [<A href="https://wg21.link/dcl.pre#1">dcl.pre</A>] paragraph 1
defines <I>simple-declaration</I> as:</P>

<BLOCKQUOTE>
<PRE>
<I>simple-declaration :
    decl-specifier-seq init-declarator-list<sub>opt</sub> ;
    attribute-specifier-seq decl-specifier-seq init-declarator-list</I> ;
    ...
</PRE>
</BLOCKQUOTE>

<P>However, 9.1 [<A href="https://wg21.link/dcl.pre#2">dcl.pre</A>] paragraph 2 then refers to
a <I>simple-declaration</I> using a different producction:</P>

<BLOCKQUOTE>
A <I>simple-declaration</I> or <I>nodeclspec-function-declaration</I> of the form
<PRE>
    <I>attribute-specifier-seq<sub>opt</sub> decl-specifier-seq<sub>opt</sub> init-declarator-list<sub>opt</sub></I> ;
</PRE>
is divided into three parts...
</BLOCKQUOTE>

<P>It appears that the latter redefines the grammar
non-terminal <I>simple-declaration</I> in an inconsistent way.</P>

<P><B>Rationale (April, 2017):</B></P>

<P>The unification of the &#8220;in the form&#8221; pattern is confusing,
so the question was based on a misunderstanding of the text.</P>

<BR><BR><HR>
<A NAME="154"></A><H4>154.
  
Anonymous unions in unnamed namespaces
</H4>
<B>Section: </B>9.2.2&#160; [<A href="https://wg21.link/dcl.stc">dcl.stc</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Greg Comeau
 &#160;&#160;&#160;

 <B>Date: </B>9 Aug 1999<BR>





<P>11.5 [<A href="https://wg21.link/class.union#3">class.union</A>] paragraph 3
implies
that anonymous unions in unnamed namespaces need not be declared
<TT>static</TT> (it only places that restriction on anonymous unions
"declared in a named namespace or in the global namespace").</P>

<P>However, 9.2.2 [<A href="https://wg21.link/dcl.stc#1">dcl.stc</A>] paragraph 1
says
that "global anonymous unions... shall be declared <TT>static</TT>."
This could be read as prohibiting anonymous unions in unnamed
namespaces, which are the preferred alternative to the deprecated use
of static.</P>

<P>
<B>Rationale (10/99):</B> An anonymous union in an unnamed
namespace is not "a global anonymous union," i.e., it is not a
member of the global namespace.</P>
<BR><BR><HR>
<A NAME="2050"></A><H4>2050.
  
Consolidate specification of linkage
</H4>
<B>Section: </B>9.2.2&#160; [<A href="https://wg21.link/dcl.stc">dcl.stc</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

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


<P>9.2.2 [<A href="https://wg21.link/dcl.stc#7">dcl.stc</A>] paragraph 7 seems out of place in the
current organization of the Standard:</P>

<BLOCKQUOTE>

The linkages implied by successive declarations for a given
entity shall agree. That is, within a given scope, each
declaration declaring the same variable name or the same
overloading of a function name shall imply the same
linkage. Each function in a given set of overloaded
functions can have a different linkage, however.
[<I>Example:</I>...

</BLOCKQUOTE>

<P>The preceding two paragraphs on <TT>static</TT> and
<TT>extern</TT> simply defer to 6.7 [<A href="https://wg21.link/basic.link">basic.link</A>] to
describe their interaction with linkage, so it seems appropriate
for this paragraph to move there as well so that all the
information on linkage is in one place.</P>

<P><B>Rationale (May, 2015):</B></P>

<P>The material in 6.7 [<A href="https://wg21.link/basic.link">basic.link</A>] deals with linkage
concepts, while 9.2.2 [<A href="https://wg21.link/dcl.stc">dcl.stc</A>] is concerned with
the syntactic constructs in a program that result in the
linkages described in 6.7 [<A href="https://wg21.link/basic.link">basic.link</A>].  CWG felt that
the referenced paragraph falls more into the latter category
than the former. </P>

<BR><BR><HR>
<A NAME="376"></A><H4>376.
  
Class "definition" versus class "declaration"
</H4>
<B>Section: </B>9.2.3&#160; [<A href="https://wg21.link/dcl.fct.spec">dcl.fct.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Randy Maddox
 &#160;&#160;&#160;

 <B>Date: </B>28 August 2002<BR>


<P>In 9.2.3 [<A href="https://wg21.link/dcl.fct.spec">dcl.fct.spec</A>], para. 3, the following sentence</P>
<BLOCKQUOTE>
A function defined within a class <B>definition</B> is an inline
function.
</BLOCKQUOTE>
<P>should, if I am not mistaken, instead be:</P>
<BLOCKQUOTE>
A function defined within a class <B>declaration</B> is an inline
function."
</BLOCKQUOTE>

<P><B>Notes from October 2002 meeting:</B></P>

<P>This is not a defect.  Though there is a long history, going
back to the ARM, of use of the term "class declaration" to mean the
definition of the class, we believe "class definition" is clearer.
We have opened <A HREF="cwg_defects.html#379">issue 379</A> to deal
with changing all other uses of "class declaration" to "class
definition" where appropriate.</P>

<BR><BR><HR>
<A NAME="412"></A><H4>412.
  
Can a replacement allocation function be inline?
</H4>
<B>Section: </B>9.2.3&#160; [<A href="https://wg21.link/dcl.fct.spec">dcl.fct.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>23 Apr 2003<BR>




<P>A customer reports that when he attempts to replace
<TT>::operator new</TT> with
a user-defined function, the standard library calls the default
function by preference if the user-defined function is inline.  I
believe that our compiler is correct, and that such a replacement
function isn't allowed to be inline, but I'm not sure there's
sufficiently explicit language in the standard.</P>

<P>In general, of course, the definition of an inline function must be
present in every translation unit where the function is called.
(9.2.3 [<A href="https://wg21.link/dcl.fct.spec">dcl.fct.spec</A>],
par 4)  It could be argued that this requirement doesn't quite address
replacement functions: what we're dealing with is the odd case where
we've already got one definition and the user is supplying a different
one.  I'd like to see something specifically addressing the case of a
replacement function.</P>

<P>So what do we have?  I see discussion of requirement for a replacement
<TT>::operator new</TT> in three places:
16.4.5.6 [<A href="https://wg21.link/replacement.functions">replacement.functions</A>],
17.6.3.2 [<A href="https://wg21.link/new.delete.single">new.delete.single</A>] par 2, and
6.8.6.5 [<A href="https://wg21.link/basic.stc.dynamic">basic.stc.dynamic</A>] par
2-3.  I don't see anything explicitly saying that the replacement
function may not be inline.  The closest I can find is
17.6.3.2 [<A href="https://wg21.link/new.delete.single">new.delete.single</A>] par 2,
which says that "a C++ program may define a function with this function
signature that displaces the default version defined by the C++
Standard library".  One might argue that "with this function signature"
rules out inline, but that strikes me as a slight stretch.</P>

<P>Have I missed anything?</P>

<P>
<U>Andrew Koenig</U>:
I think you've turned up a problem in
9.2.3 [<A href="https://wg21.link/dcl.fct.spec#4">dcl.fct.spec</A>] paragraph 4.  Consider:</P>
<PRE>
  // Translation unit 1
  #include &lt;iostream&gt;

  extern void foo(void (*)());

  inline void bar() {
    std::cout &lt;&lt; "Hello, world!" &lt;&lt; std::endl;
  }

  int main() {
    foo(bar);
  }

  // Translation unit 2
  void foo(void (*f)()) { (*f)(); }
</PRE>

<P>Are you really trying to tell me that this program is ill-formed because
the definition of bar is not available in translation unit 2?</P>

<P>I think not.  The actual words in
9.2.3 [<A href="https://wg21.link/dcl.fct.spec">dcl.fct.spec</A>] par 4 are
<BLOCKQUOTE>
An inline function shall be defined in every translation unit in
which it is used...
</BLOCKQUOTE>
and I think at in this context, ``used'' should be interpreted to mean
that foo is used only in translation unit 1, where it is converted to
a value of type void(*)().</P>

<P><B>Notes from October 2003 meeting:</B></P>

<P>We don't think Andy Koenig's comment requires any action;
"used" is already defined appropriately.</P>

<P>We agree that this replacement should not be allowed, but
we think it's a library issue (in the rules for allowed
replacements).  Forwarded to library group; it's issue 404
on the library issues list.</P>

<BR><BR><HR>
<A NAME="422"></A><H4>422.
  
Is a typedef redeclaration allowed with a template type that might be the same?
</H4>
<B>Section: </B>9.2.4&#160; [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>18 June 2003<BR>


<P>Is the following valid?</P>
<PRE>
  template &lt;class T&gt; void f(T) {
    typedef int x;
    typedef T x;
  }
  int main() {
    f(1);
  }
</PRE>
<P>There is an instantiation where the function is valid.  Is an
implementation allowed to issue an error on the template declaration
because the types on the typedef are not the same
(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>])?</P>

<P>How about
<PRE>
  typedef T x;
  typedef T2 x;
</PRE>
?</P>

<P>It can be argued that these cases should be allowed because they
aren't necessarily wrong, but it can also be argued that there's no
reason to write things like the first case above, and if such
a case appears it's more likely to be a mistake than some kind
of intentional test that int and T are the same type.</P>

<P><B>Notes from the October 2003 meeting:</B></P>

<P>We believe that all these cases should be allowed, and that
errors should be required only when an instance of the template is
generated.  The current standard wording does not seem to
disallow such cases, so no change is required.</P>

<BR><BR><HR>
<A NAME="1964"></A><H4>1964.
  
<I>opaque-enum-declaration</I> in <I>alias-declaration</I>?
</H4>
<B>Section: </B>9.2.4&#160; [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Fedor Sergeev
 &#160;&#160;&#160;

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




<P>The grammar does not allow for a declaration of the form</P>

<PRE>
  using T = enum class E : int;
</PRE>

<P>However, it is widely accepted by current implementations.  Should
the rules be changed to accommodate this usage?</P>

<P><B>Rationale (November, 2014):</B></P>

<P>A <I>type-id</I> is intended as a reference to a type, but
the opaque enumeration syntax is intended as a declaration, not
a reference like an <I>elaborated-type-specifier</I>, so the
current rules are as intended.</P>

<BR><BR><HR>
<A NAME="1316"></A><H4>1316.
  
<TT>constexpr</TT> function requirements and class scope
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-0512<BR>




<P>A <TT>constexpr</TT> function is required to have literal argument
and return types.  Consider an example like:</P>

<PRE>
  template &lt;class T&gt; struct B {
    constexpr B(T) { }
  };

  struct A {
    B&lt;A&gt; b;
  };
</PRE>



<P>Whether <TT>B(A)</TT> is <TT>constexpr</TT> depends on whether
<TT>A</TT> is literal, which depends on whether <TT>B&lt;A&gt;</TT> is
literal, which depends on whether <TT>B(A)</TT> is <TT>constexpr</TT>.
</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The requirements apply to definitions, not declarations.</P>

<BR><BR><HR>
<A NAME="1637"></A><H4>1637.
  
Recursion in <TT>constexpr</TT> template default constructor
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-03-11<BR>


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

<PRE>
  struct A {
    template &lt;class T&gt; constexpr void* f(T) { return nullptr; }
    A* ap = (A*)f(A());
    template &lt;class ...T&gt; constexpr A() {}
  };
</PRE>

<P>A default constructor template instance would recurse infinitely
via the member initializer for <TT>A::ap</TT>.  However, since it's a
template, by 9.2.6 [<A href="https://wg21.link/dcl.constexpr#6">dcl.constexpr</A>] paragraph 6, that would just
mean that the instance shouldn't be treated as <TT>constexpr</TT>.</P>

<P>Is an implementation really expected to handle that? In effect, we have
to try to evaluate the expression and if that fails, nullify the
<TT>constexpr</TT>-ness of the <TT>A::A&lt;&gt;()</TT> instance, and
re-examine the initializer with the new understanding of that
instance?</P>

<P><B>Rationale (April, 2013):</B></P>

<P>In the cited example, the constructor is <TT>constexpr</TT>; it
simply cannot be used in a constant expression.  The error would be
detected at the time of such a use.</P>

<BR><BR><HR>
<A NAME="1688"></A><H4>1688.
  
Volatile <TT>constexpr</TT> variables
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-05-18<BR>




<P>There does not appear to be language in the current wording stating
that <TT>constexpr</TT> cannot be applied to a variable of
volatile-qualified type.  Also, the wording in 7.7 [<A href="https://wg21.link/expr.const#2">expr.const</A>] paragraph 2
referring to &#8220;a non-volatile object defined with
<TT>constexpr</TT>&#8221; might lead one to infer that the combination is
permitted but that such a variable cannot appear in a constant expression.
What is the intent?</P>

<P><B>Rationale (September, 2013):</B></P>

<P>The combination is intentionally permitted and could be used in
some circumstances to force constant initialization.</P>

<BR><BR><HR>
<A NAME="1745"></A><H4>1745.
  
<TT>thread_local constexpr</TT> variable
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-05<BR>


<P>Neither 9.2.6 [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>] nor 9.2.2 [<A href="https://wg21.link/dcl.stc">dcl.stc</A>]
forbids combining the <TT>thread_local</TT> and <TT>constexpr</TT>
specifiers in the declaration of a variable.  Should this combination
be permitted?</P>

<P><B>Rationale (January, 2014):</B></P>

<P>Such an object could have mutable subobjects. The <TT>constexpr</TT>
specifier guarantees static initialization.</P>

<BR><BR><HR>
<A NAME="2117"></A><H4>2117.
  
Explicit specializations and <TT>constexpr</TT> function templates
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-04-26<BR>


<P>[ The paragraph in question was removed by P2448R2, adopted at the July, 2022 meeting. ]</P>



<P>According to 9.2.6 [<A href="https://wg21.link/dcl.constexpr#6">dcl.constexpr</A>] paragraph 6,</P>

<BLOCKQUOTE>

If no specialization of the template would satisfy the
requirements for a constexpr function or constexpr
constructor when considered as a non-template function or
constructor, the template is ill-formed; no diagnostic
required.

</BLOCKQUOTE>

<P>This should say &#8220;instantiated template specialization&#8221;
instead of just &#8220;specialization&#8221; to clarify that
an explicit specialization is not in view here.</P>

<BR><BR><HR>
<A NAME="2217"></A><H4>2217.
  
<TT>constexpr</TT> constructors for non-literal types
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-12-21<BR>


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

<PRE>
  struct S {
    constexpr S(): i(42) {  }
    ~S();
    int i;
  };
  double x[S().i];  //<SPAN CLASS="cmnt"> Error</SPAN>
</PRE>

<P>such a <TT>constexpr</TT> constructor is completely useless, but
there doesn't appear to be anything in the current wording making it
ill-formed. Should it be?</P>

<P><B>Rationale (November, 2016):</B></P>

<P>Such constructors can be useful for guaranteeing static initialization
of namespace-scope objects.</P>

<BR><BR><HR>
<A NAME="643"></A><H4>643.
  
Use of <TT>decltype</TT> in a class <I>member-specification</I>
</H4>
<B>Section: </B>9.2.9.3&#160; [<A href="https://wg21.link/dcl.type.simple">dcl.type.simple</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>8 Aug 2007<BR>




<P>11.4 [<A href="https://wg21.link/class.mem#2">class.mem</A>] paragraph 2 says,</P>

<BLOCKQUOTE>

A class is considered a completely-defined object type (6.9 [<A href="https://wg21.link/basic.types">basic.types</A>]) (or complete type) at the closing <TT>}</TT> of the
<I>class-specifier</I>.  Within the class <I>member-specification</I>,
the class is regarded as complete within function bodies, default
arguments, and <I>exception-specification</I>s (including such things
in nested classes). Otherwise it is regarded as incomplete within its
own class <I>member-specification</I>.

</BLOCKQUOTE>

<P>In particular, the return type of a member function is not listed
as a context in which the class type is considered complete; instead,
that case is handled as an exception to the general rule in
9.3.4.6 [<A href="https://wg21.link/dcl.fct#6">dcl.fct</A>] paragraph 6 requiring a complete type in
the definition of a function:</P>

<BLOCKQUOTE>

The type of a parameter or the return type for a function definition
shall not be an incomplete class type (possibly cv-qualified) unless
the function definition is nested within
the <I>member-specification</I> for that class (including definitions
in nested classes defined within the class).

</BLOCKQUOTE>

<P>These rules have implications for the use of <TT>decltype</TT>.
(The following examples use the not-yet-accepted syntax for specifying
the return type of a function after its declarator, but the questions
apply to the current syntax as well.) Consider:</P>

<PRE>
    struct deduced {
      int test() { return 0; }
      auto eval( deduced&amp; d )-&gt;decltype( d.test() ) {
        return d.test();
      }
    };
</PRE>

<P>7.6.1.5 [<A href="https://wg21.link/expr.ref#1">expr.ref</A>] paragraph 1 requires that the class
type of the object or pointer expression in a class member access
expression be complete, so this usage is ill-formed.</P>

<P>A related issue is the use of <TT>this</TT> in a <TT>decltype</TT>
specifier:</P>

<PRE>
    struct last_one {
      int test() { return 0; }
      auto eval()-&gt;decltype( this-&gt;test() ) {
        return test();
      }
    };
</PRE>

<P>_N4868_.11.4.3.2 [<A href="https://wg21.link/class.this#1">class.this</A>] paragraph 1 allows use of <TT>this</TT>
only in the body of a non-static member function, and the return type
is not part of the <I>function-body</I>.</P>

<P>Do we want to change the rules to allow these kinds of
<TT>decltype</TT> expressions?</P>

<P><B>Rationale (February, 2008):</B></P>

<P>In the other cases where a class type is considered complete
within the definition of the class, it is possible to defer handling
the construct until the end of the definition.  That is not possible
for types, as the type may be needed immediately in subsequent
declarations.</P>

<P>It was also noted that the primary utility of <TT>decltype</TT> is
in generic contexts; within a single class definition, other
mechanisms are possible (e.g., use of a member typedef in both the
declaration of the operand of the <TT>decltype</TT> and to replace
the <TT>decltype</TT> itself).</P>

<BR><BR><HR>
<A NAME="669"></A><H4>669.
  
Confusing specification of the meaning of <TT>decltype</TT>
</H4>
<B>Section: </B>9.2.9.3&#160; [<A href="https://wg21.link/dcl.type.simple">dcl.type.simple</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vera Lychagina
 &#160;&#160;&#160;

 <B>Date: </B>17 December 2007<BR>


<P>The first bullet of 9.2.9.3 [<A href="https://wg21.link/dcl.type.simple#4">dcl.type.simple</A>] paragraph 4 says,</P>

<UL><LI>if <TT>e</TT> is an <I>id-expression</I> or a class member
access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]), <TT>decltype(e)</TT> is the type
of the entity named by <TT>e</TT>.</LI></UL>

<P>There are two clarifications to this specification that would
assist the reader.  First, it would be useful to have a note
highlighting the point that a parenthesized expression is neither
an <I>id-expression</I> nor a member access expression.</P>

<P>Second, the phrase &#8220;the type of the entity named
by <TT>e</TT>&#8221; is unclear as to whether cv-qualification in the
object or pointer expression is or is not part of that type.
Rephrasing this to read, &#8220;the <INS>declared</INS> type of the
entity,&#8221; or adding &#8220;(ignoring any cv-qualification in the
object expression or pointer expression),&#8221; would clarify the
intent.</P>

<P><B>Rationale (February, 2008):</B></P>

<P>The text is clear enough.  In particular, both of these points are
illustrated in the last two lines of the example contrasting
<TT>decltype(a-&gt;x)</TT> and <TT>decltype((a-&gt;x))</TT>: in the
former, the expression has no parentheses, thus satisfying the
requirements of the first bullet and yielding the declared type of
<TT>A::x</TT>, while the second has parentheses, falling into the
third bullet and picking up the <TT>const</TT> from the object
expression in the member access.</P>

<BR><BR><HR>
<A NAME="706"></A><H4>706.
  
Use of <TT>auto</TT> with rvalue references
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>1 Aug, 2008<BR>




<P>Because type deduction for the <TT>auto</TT> specifier is
described in 9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto#6">dcl.spec.auto</A>] paragraph 6 as
equivalent to the deduction that occurs in a call to a function
template, the adjustment of the argument type from <TT>A</TT> to
<TT>A&amp;</TT> specified in 13.10.3.2 [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>] paragraph
3 is performed when the initializer is an lvalue. As a result, in
the following example, <TT>ra</TT> has the type <TT>A&amp;</TT> and
not, as might be expected, <TT>A&amp;&amp;</TT>:</P>

<PRE>
    class A { };

    void f() {
       A a;
       auto&amp;&amp; ra = a;
    }
</PRE>

<P>It is unclear whether this is surprising enough, and potentially
widely-enough used, to warrant making an exception to the current
rules to handle this case differently.</P>

<P><B>Rationale (September, 2008):</B></P>

<P>It is important that the deduction rules be the same in the
function and <TT>auto</TT> cases.  The result of this example
might be surprising, but maintaining a consistent model for
deduction is more important.</P>

<BR><BR><HR>
<A NAME="1564"></A><H4>1564.
  
Template argument deduction from an initializer list
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-10-09<BR>




<P>An initializer list is treated differently in deducing the type of
an <TT>auto</TT> specifier and in a function call.  In
9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto#6">dcl.spec.auto</A>] paragraph 6, an initializer list is
given special treatment so that <TT>auto</TT> is deduced as a
specialization of <TT>std::initializer_list</TT>:</P>

<BLOCKQUOTE>

Once the type of a <I>declarator-id</I> has been determined according
to 9.3.4 [<A href="https://wg21.link/dcl.meaning">dcl.meaning</A>], the type of the declared variable using
the <I>declarator-id</I> is determined from the type of its
initializer using the rules for template argument deduction.  Let
<TT>T</TT> be the type that has been determined for a variable
identifier <TT>d</TT>.  Obtain <TT>P</TT> from <TT>T</TT> by replacing
the occurrences of <TT>auto</TT> with either a new invented type
template parameter <TT>U</TT> or, if the initializer is a
<I>braced-init-list</I> (9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]), with
<TT>std::initializer_list&lt;U&gt;</TT>.  The type deduced for the
variable <TT>d</TT> is then the deduced <TT>A</TT> determined using
the rules of template argument deduction from a function call
(13.10.3.2 [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]), where <TT>P</TT> is a function
template parameter type and the initializer for <TT>d</TT> is the
corresponding argument.

</BLOCKQUOTE>

<P>In a function call, however, an initializer-list argument is a
non-deduced context:</P>

<BLOCKQUOTE>

<P>Template argument deduction is done by comparing each function
template parameter type (call it <TT>P</TT>) with the type of the corresponding
argument of the call (call it <TT>A</TT>) as described below.  If removing
references and cv-qualifiers from <TT>P</TT> gives <TT>std::initializer_list&lt;<I>P'</I>&gt;</TT> for some <I>P'</I> and the argument is an initializer list
(9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]), then deduction is performed instead for
each element of the initializer list, taking <I>P'</I> as a function
template parameter type and the initializer element as its
argument. Otherwise, an initializer list argument causes the parameter
to be considered a non-deduced context (13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]). [<I>Example:</I>
</P>

<PRE>
  template&lt;class T&gt; void f(std::initializer_list&lt;T&gt;);
  f({1,2,3});          //<SPAN CLASS="cmnt"> </SPAN>T<SPAN CLASS="cmnt"> deduced to </SPAN>int
  f({1,"asdf"});       //<SPAN CLASS="cmnt"> error: </SPAN>T<SPAN CLASS="cmnt"> deduced to both </SPAN>int<SPAN CLASS="cmnt"> and </SPAN>const char*

  template&lt;class T&gt; void g(T);
  g({1,2,3});          //<SPAN CLASS="cmnt"> error: no argument deduced for </SPAN>T
</PRE>

</BLOCKQUOTE>

<P>This seems inconsistent, but it is not clear in which direction the
inconsistency should be resolved.  The use of an initializer list in
a range-based <TT>for</TT> is an argument in favor of the
9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>] treatment, but the utility of this
deduction in other contexts is not apparent.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>CWG felt that this language design question would be better
considered by EWG.</P>

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

<P>EWG has decided not to make a change in this area.  See EWG issue
109.</P>

<BR><BR><HR>
<A NAME="1725"></A><H4>1725.
  
Trailing return type with nested function declarator
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-08-01<BR>




<P>The treatment of a declaration like the following is not clear:</P>

<PRE>
   auto (*f())() -&gt; int; //<SPAN CLASS="cmnt"> #1</SPAN>
</PRE>

<P>9.3.4.6 [<A href="https://wg21.link/dcl.fct#2">dcl.fct</A>] paragraph 2 appears to require
determining the type of the nested declarator</P>

<PRE>
   auto (*f()); //<SPAN CLASS="cmnt"> #2</SPAN>
</PRE>

<P>which, because it does not have a <I>trailing-return-type</I>,
would be ill-formed by (C++11) 9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>].  (In
C++14, an <TT>auto</TT> return type without a
<I>trailing-return-type</I> is, of course, permitted.)</P>

<P><B>Rationale (September, 2013):</B></P>

<P>The intent of the C++11 wording is that the requirement for a
trailing return type applies only at the top level of the declarator
to which <TT>auto</TT> applies, not to each possible recursive
stage in the declarator processing.  Also, as noted, the issue becomes
moot with the changes enabling return type deduction.</P>

<BR><BR><HR>
<A NAME="1957"></A><H4>1957.
  
<TT>decltype(auto)</TT> with direct-list-initialization
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-06-30<BR>




<P>Paper N3922 changed the rules for deduction from a
<I>braced-init-list</I> containing a single <I>expression</I>
in a direct-initialization context. Should a corresponding
change be made for <TT>decltype(auto)</TT>?  E.g.,</P>

<PRE>
  auto x8a = { 1 };           //<SPAN CLASS="cmnt"> </SPAN>decltype(x8a)<SPAN CLASS="cmnt"> is </SPAN>std::initializer_list&lt;int&gt;
  decltype(auto) x8d = { 1 }; //<SPAN CLASS="cmnt"> ill-formed, a braced-init-list is not an expression</SPAN>
  auto x9a{ 1 };              //<SPAN CLASS="cmnt"> </SPAN>decltype(x9a)<SPAN CLASS="cmnt"> is </SPAN>int
  decltype(auto) x9d{ 1 };    //<SPAN CLASS="cmnt"> </SPAN>decltype(x9d)<SPAN CLASS="cmnt"> is </SPAN>int
</PRE>

<P>See also <A HREF="cwg_defects.html#1467">issue 1467</A>, which also
effectively ignores braces around a single <I>expression</I>,
this change would be parallel to that one, even though the primary
motivation for <TT>delctype(auto)</TT> is in the return type of a
forwarding function, where direct-initialization does not apply.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>CWG felt that this was a question of language design and thus more
properly dealt with by EWG.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a request for a new feature, which should be proposed in a
paper to EWG.</P>

<BR><BR><HR>
<A NAME="2060"></A><H4>2060.
  
Deduced return type for explicit specialization
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2014-12-15<BR>


<P>The Standard does not indicate whether an explicit specialization of
a function template can have a deduced return type.  It seems a bit too
much to require parsing the entire function body in order to tell which
template is being specialized.  In extreme cases, that could mean
deferring access checks for the entire body of the function.</P>

<P><B>Rationale (May, 2015):</B></P>

<P>An explicit specialization with a deduced return type can
only match a template declared with a deduced return type,
so the actual return type is not needed in order to match
the explicit specialization with the template being
specialized.</P>

<BR><BR><HR>
<A NAME="2453"></A><H4>2453.
  
Deduced return types and coroutine lambdas
</H4>
<B>Section: </B>9.2.9.7.1&#160; [<A href="https://wg21.link/dcl.spec.auto.general">dcl.spec.auto.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lewis Baker
 &#160;&#160;&#160;

 <B>Date: </B>2020-02-14<BR>


<P>According to 9.2.9.7.1 [<A href="https://wg21.link/dcl.spec.auto.general#15">dcl.spec.auto.general</A>] paragraph 15,</P>

<BLOCKQUOTE>

A function declared with a return type that uses a
placeholder type shall not be a coroutine
(9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]).

</BLOCKQUOTE>

<P>This should also apply to coroutine lambdas.</P>

<P><B>Rationale (July, 2020):</B></P>

<P>No change is needed. The restriction applies to functions, and
the lambda's <TT>operator()</TT> is a function.</P>

<BR><BR><HR>
<A NAME="736"></A><H4>736.
  
Is the <TT>&amp;</TT> <I>ref-qualifier</I> needed?
</H4>
<B>Section: </B>9.3&#160; [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alberto Ganesh Barbati
 &#160;&#160;&#160;

 <B>Date: </B>16 October, 2008<BR>




<P>Do we really need the <TT>&amp;</TT> <I>ref-qualifier</I>?  We
could get the same behavior without it if we relaxed the restriction
on ref-qualified and non-ref-qualified overloads in the same set:</P>

<UL>
<TABLE WIDTH="85%">
<TR>
<TD>
<B>with the <TT>&amp;</TT> <I>ref-qualifier</I></B>
</TD>
<TD>
<B>without the <TT>&amp;</TT> <I>ref-qualifier</I></B>
</TD>
</TR>
<TR>
<TD>
<PRE>
    struct S {
      void f();
    };
</PRE>
</TD>
<TD>
<PRE>
    struct S {
      void f();
    };
</PRE>
</TD>
</TR>
<TR>
<TD>
<PRE>
    struct S {
      void f() &amp;;
    };

</PRE>
</TD>
<TD>
<PRE>
    struct S {
      void f();
      void f() &amp;&amp; = delete;
    };
</PRE>
</TD>
</TR>
<TR>
<TD>
<PRE>
    struct S {
      void f() &amp;&amp;;
    };
</PRE>
</TD>
<TD>
<PRE>
    struct S {
      void f() &amp;&amp;;
    };
</PRE>
</TD>
</TR>
<TR>
<TD>
<PRE>
    struct S {
      void f() &amp;;
      void f() &amp;&amp;;
    };
</PRE>
</TD>
<TD>
<PRE>
    struct S {
      void f();
      void f() &amp;&amp;;
    };
</PRE>
</TD>
</TR>
</TABLE>
</UL>

<P>The main objection I can see to this change is that we would lose
the notational convenience of the <TT>&amp;</TT> <I>ref-qualifier</I>,
which would need to be replaced by a pair of declarations.  We might
overcome this by still allowing a single <TT>&amp;</TT> on a function
(although it would not be a <I>ref-qualifier</I>) as a synonym to a
non-ref-qualified declaration plus a deleted ref-qualified declaration.
</P>

<P>The biggest asymmetry between the implicit object parameter and
regular parameters is not in reference binding but in type deduction.
Consider:</P>

<PRE>
    template &lt;class R, class C, class A&gt; void f(R (C::*p)(A));
</PRE>

<P>With these members:</P>

<PRE>
    struct S {
       void mv(std::string);
       void mr(std::string&amp;);
       void ml(std::string&amp;&amp;);
    };
</PRE>

<P>then</P>

<PRE>
    f(&amp;S::mv); // deduces A = string
    f(&amp;S::mr); // deduces A = string&amp;
    f(&amp;S::ml); // deduces A = string&amp;&amp;
</PRE>

<P>On the other hand, with these members:</P>

<PRE>
    struct S {
       void mv(std::string);
       void mr(std::string) &amp;;
       void ml(std::string) &amp;&amp;
    };
</PRE>

<P>then</P>

<PRE>
  f(&amp;S::mv); // deduces C = S
  f(&amp;S::mr); // illegal
  f(&amp;S::ml); // illegal
</PRE>

<P>To make template <TT>f</TT> work with any pointer to member
function, I need three overloads of <TT>f</TT>.  Add cv-qualifiers
and it's twelve overloads!</P>

<P>And then there is the interaction with concepts.  Consider this
type:</P>

<PRE>
    struct Value {
        Value&amp; operator=(const Value&amp;) &amp;;
    };
</PRE>

<P>Is it, say, <TT>Regular</TT>?  If so, will the following compile,
and what is the outcome?</P>

<PRE>
    template &lt;Regular T&gt; void f() {
      T() = T();
    }

    void g() {
      f&lt;Value&gt;();
    }
</PRE>

<P>If <TT>Value</TT> is not <TT>Regular</TT>, that is a good
motivation to avoid ever using <TT>&amp;</TT> <I>ref-qualifier</I>s
on <TT>operator=</TT> (and probably on any member functions).</P>

<P>If <TT>Value</TT> is <TT>Regular</TT>, then either
<TT>f&lt;Value&gt;()</TT> doesn't compile, violating one of the
principal motivations for concepts, or it calls <TT>Value::operator=</TT>
on an rvalue, which was explicitly prohibited.</P>

<P><B>Rationale, March, 2009:</B></P>

<P>The CWG did not feel that the suggested change was a signficant
improvement over the existing specification.</P>

<BR><BR><HR>
<A NAME="2036"></A><H4>2036.
  
Refactoring <I>parameters-and-qualifiers</I>
</H4>
<B>Section: </B>9.3&#160; [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]
 &#160;&#160;&#160;

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

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

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


<P>The production for <I>parameters-and-qualifiers</I> is long and will
be even longer with the changes for the Transactional Memory TS.  It
might be beneficial to refactor it into more manageable chunks.</P>

<P><B>Rationale (May, 2015):</B></P>

<P>CWG felt that recent changes to the grammar are sufficient.</P>

<BR><BR><HR>
<A NAME="333"></A><H4>333.
  
Ambiguous use of "declaration" in disambiguation section
</H4>
<B>Section: </B>9.3.3&#160; [<A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Michiel Salters
 &#160;&#160;&#160;

 <B>Date: </B>14 Jan 2002<BR>


<P>In deciding whether a construct is an object declaration or
a function declaration, 9.3.3 [<A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>] contains the following
gem: "In that context, the choice is between a function declaration
[...] and an object declaration [...]
Just as for the ambiguities mentioned in 8.11 [<A href="https://wg21.link/stmt.ambig">stmt.ambig</A>],
the resolution is to
consider any construct that could possibly be a declaration
a declaration."</P>

<P>To what declaration do the last two "declarations" refer? Object,
function, or (following from the syntax) possibly parameter
declarations?</P>

<P><B>Notes from the 4/02 meeting:</B></P>

<P>This is not a defect.  Section 9.3.3 [<A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>] reads:</P>
<BLOCKQUOTE>
The ambiguity arising from the similarity between a function-style
cast and a declaration mentioned in 8.11 [<A href="https://wg21.link/stmt.ambig">stmt.ambig</A>]
can also occur in the context
of a declaration. In that context, the choice is between a function
declaration with a redundant set of parentheses around a parameter
name and an object declaration with a function-style cast as the
initializer. Just as for the ambiguities mentioned in
8.11 [<A href="https://wg21.link/stmt.ambig">stmt.ambig</A>], the
resolution is to consider any construct that could possibly be a
declaration a declaration.
</BLOCKQUOTE>
<P>The wording "any construct" in the last sentence is not limited
to top-level constructs.  In particular, the function declaration
encloses a parameter declaration, whereas the object declaration
encloses an expression.  Therefore, in case of ambiguity between
these two cases, the declaration is parsed as a function declaration.</P>

<BR><BR><HR>
<A NAME="340"></A><H4>340.
  
Unclear wording in disambiguation section </H4>
<B>Section: </B>9.3.3&#160; [<A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bart v Ingen Schenau
 &#160;&#160;&#160;

 <B>Date: </B>27 Feb 2002<BR>


<P>Consider the following program:</P>
<PRE>
  struct Point
  {
    Point(int){}
  };
  struct Lattice
  {
    Lattice(Point, Point, int){}
  };
  int main(void)
  {
    int a, b;
    Lattice latt(Point(a), Point(b), 3);   /* Line X */
  }
</PRE>

<P>The problem concerns the line marked <TT>/* Line X */</TT>, which is an
ambiguous declarations for either an object or a function.
The clause that governs this ambiguity is 9.3.3 [<A href="https://wg21.link/dcl.ambig.res#1">dcl.ambig.res</A>] paragraph 1,
 and reads:</P>
<BLOCKQUOTE>
The ambiguity arising from the similarity between a function-style
cast and a declaration mentioned in 8.11 [<A href="https://wg21.link/stmt.ambig">stmt.ambig</A>]
can also occur in the context
of a declaration. In that context, the choice is between a function
declaration with a redundant set of parentheses around a parameter
name and an object declaration with a function-style cast as the
initializer. Just as for the ambiguities mentioned in
8.11 [<A href="https://wg21.link/stmt.ambig">stmt.ambig</A>], the
resolution is to consider any construct that could possibly be a
declaration a declaration. [Note: a declaration can be explicitly
disambiguated by a nonfunction-style cast, by a <TT>=</TT> to indicate
initialization or by removing the redundant parentheses around the
parameter name. ]
</BLOCKQUOTE>

<P>Based on this clause there are two possible interpretations of the
declaration in line X:</P>
<OL>
<LI>
The declaration of latt declares a function with a return value of
the type Lattice and taking three arguments. The type of the first two
arguments is Point and each of these arguments is followed by a
parameter name in redundant parentheses. The type of the third
argument can not be determined, because it is a literal.
This will result in a syntax error.
</LI>
<LI>
The declaration of latt declares an object, because the other option
(a function declaration) would result in a syntax error.
</LI>
</OL>

<P>Note that the last sentence before the "[Note:" is not much help,
because both options are declarations.</P>

<P><I>Steve Adamczyk: a number of people replied to this posting
on comp.std.c++ saying that they did not see a problem.  The
original poster replied:</I></P>

<P>I can't do anything but agree with your argumentation.
So there is only one correct interpretation of
9.3.3 [<A href="https://wg21.link/dcl.ambig.res#1">dcl.ambig.res</A>] paragraph 1, but I
have to say that with some rewording, the clause can be made a lot
clearer, like stating explicitly that the entire declaration must be
taken into account and that function declarations are preferred over
object declarations.</P>

<P>I would like to suggest the following as replacement for the current
9.3.3 [<A href="https://wg21.link/dcl.ambig.res#1">dcl.ambig.res</A>] paragraph 1:</P>
<BLOCKQUOTE>
The ambiguity arising from the similarity between a functionstyle
cast and a declaration mentioned in
8.11 [<A href="https://wg21.link/stmt.ambig">stmt.ambig</A>] can also occur in the context
of a declaration. In that context, the choice is between a function
declaration with a redundant set of parentheses around a parameter
name and an object declaration with a function-style cast as the
initializer. The resolution is to consider any construct that could
possibly be a function declaration a function declaration. [Note: To
disambiguate, the whole declaration might have to be examined to
determine if it is an object or a function declaration.] [Note: a
declaration can be explicitly disambiguated by a nonfunction-style
cast, by a <TT>=</TT> to indicate initialization or by removing the redundant
parentheses around the parameter name. ]
</BLOCKQUOTE>

<P><B>Notes from the 4/02 meeting:</B></P>

<P>The working group felt that the current wording is clear enough.</P>

<BR><BR><HR>
<A NAME="1867"></A><H4>1867.
  
Function/expression ambiguity with qualified parameter name
</H4>
<B>Section: </B>9.3.3&#160; [<A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-02-12<BR>




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

<PRE>
  namespace N { enum E { X }; }
  struct S { S(N::E); };
  S s(S(N::X));
</PRE>

<P>the last line disambiguates as an (ill-formed) function declaration,
because the restriction requiring unqualified parameter names is
semantic, not syntactic.  Should the language be changed to use the
presence of a <I>qualified-id</I> in this case as disambiguation?
There is implementation divergence in the handling of this example.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>CWG noted that the grammar change to allow disambiguation based on
the parameter name being qualified is large, so the cost outweighs the
relatively small benefit for disambiguating this particular corner
case.</P>

<BR><BR><HR>
<A NAME="1970"></A><H4>1970.
  
Ambiguity resolution for <TT>(T())*x</TT>
</H4>
<B>Section: </B>9.3.3&#160; [<A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-07-15<BR>




<P>The disambiguation of a fragment like</P>

<PRE>
  (T())*x
</PRE>

<P>where <TT>T</TT> is a type and <TT>x</TT> is a variable, is
unclear.  Is it a cast to type <TT>T()</TT> of the expression
<TT>*x</TT>, or is it a binary operator <TT>*</TT> multiplying a
value-initialized <TT>T</TT> by <TT>x</TT>?  Current implementations
treat it as the former, which is not helpful since the specified
type is a function type and thus always ill-formed.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>According to 9.3.3 [<A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>], <TT>T()</TT> is to be
taken as a function type, so the cast interpretation is
correct, and one of the examples in this section is very nearly
exactly this case.</P>

<BR><BR><HR>
<A NAME="504"></A><H4>504.
  
Should use of a variable in its own initializer require a diagnostic?
</H4>
<B>Section: </B>9.3.4.3&#160; [<A href="https://wg21.link/dcl.ref">dcl.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>14 Apr 2005<BR>


<P> Split
off from <A HREF="cwg_defects.html#453">issue 453</A>.</P>

<P>It is in general not possible to determine at compile time whether
a reference is used before it is initialized.  Nevertheless, there is
some sentiment to require a diagnostic in the obvious cases that can
be detected at compile time, such as the name of a reference appearing
in its own initializer.  The resolution of <A HREF="cwg_defects.html#453">issue 453</A> originally made such uses ill-formed, but the CWG decided
that this question should be a separate issue.</P>

<P><B>Rationale (October, 2005):</B></P>

<P>The CWG felt that this error was not likely to arise very
often in practice.  Implementations can warn about such constructs,
and the resolution for <A HREF="cwg_defects.html#453">issue 453</A> makes
executing such code undefined behavior; that seemed to address the
situation adequately.</P>

<P><B>Note (February, 2006):</B></P>

<P>Recent discussions  have suggested that undefined behavior be
reduced.  One possibility (broadening the scope of this issue to
include object declarations as well as references) was to require a
diagnostic if the initializer uses the value, but not just the
address, of the object or reference being declared:</P>

<PRE>
    int i = i;        //<SPAN CLASS="cmnt"> Ill-formed, diagnostic required</SPAN>
    void* p = &amp;p;     //<SPAN CLASS="cmnt"> Okay</SPAN>
</PRE>

<P><B>Rationale (2023-05-12)</B></P>

<P>This is an extension whose detailed specification requires a paper
targeted at EWG.  Some implementations warn about the situation in
question.</P>

<BR><BR><HR>
<A NAME="478"></A><H4>478.
  
May a function parameter be an array of an abstract class type?
</H4>
<B>Section: </B>9.3.4.5&#160; [<A href="https://wg21.link/dcl.array">dcl.array</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>28 Sep 2004<BR>


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

<PRE>
    struct S {
      virtual void v() = 0;
    };

    void f(S sa[10]);     // permitted?
</PRE>

<P>9.3.4.5 [<A href="https://wg21.link/dcl.array#1">dcl.array</A>] paragraph 1 says that a
declaration like that of <TT>sa</TT> is ill-formed:</P>

<BLOCKQUOTE>

<TT>T</TT> is called the array <I>element type</I>; this type
shall not be a reference type, the (possibly cv-qualified) type
<TT>void</TT>, a function type or an abstract class type.

</BLOCKQUOTE>

<P>On the other hand, 9.3.4.6 [<A href="https://wg21.link/dcl.fct#3">dcl.fct</A>] paragraph 3
says that the type of <TT>sa</TT> is adjusted to <TT>S*</TT>,
which would be permitted:</P>

<BLOCKQUOTE>

The type of each parameter is determined from its own
<I>decl-specifier-seq</I> and <I>declarator</I>. After
determining the type of each parameter, any parameter of type
&#8220;array of <TT>T</TT>&#8221; or &#8220;function returning
<TT>T</TT>&#8221; is adjusted to be &#8220;pointer to
<TT>T</TT>&#8221; or &#8220;pointer to function returning
<TT>T</TT>,&#8221; respectively.

</BLOCKQUOTE>

<P>It is not clear whether the parameter adjustment trumps the
prohibition on declaring an array of an abstract class type or
not.  Implementations differ in this respect: EDG 2.4.2 and
MSVC++ 7.1 reject the example, while g++ 3.3.3 and Sun Workshop 8
accept it.</P>

<P><B>Rationale (April, 2005):</B></P>

<P>The prohibition in 9.3.4.5 [<A href="https://wg21.link/dcl.array">dcl.array</A>] is absolute
and does not allow for exceptions.  Even though such a type in a
parameter declaration would decay to an allowed type, the prohibition
applies to the type before the decay.</P>

<P>This interpretation is consistent with the resolution of
<A HREF="cwg_defects.html#337">issue 337</A>, which causes template type
deduction to fail if such types are deduced.  It was also observed
that pointer arithmetic on pointers to abstract classes is very
likely to fail, and the fact that the programmer used array notation
to declare the pointer type is a strong indication that he/she
expected to use subscripting.</P>

<BR><BR><HR>
<A NAME="1222"></A><H4>1222.
  
Unnecessary restriction on <TT>auto</TT> array types
</H4>
<B>Section: </B>9.3.4.5&#160; [<A href="https://wg21.link/dcl.array">dcl.array</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-08<BR>


<P>According to 9.3.4.5 [<A href="https://wg21.link/dcl.array#1">dcl.array</A>] paragraph 1,</P>

<BLOCKQUOTE>

<P>In a declaration <TT>T D</TT> where <TT>D</TT> has the form</P>

<UL>
<TT>D1 [</TT> <I>constant-expression<SUB>opt</SUB></I> <TT>]</TT> <I>attribute-specifier</I><SUB>opt</SUB>
</UL>

<P>and the type of the identifier in the declaration <TT>T D1</TT> is
&#8220;<I>derived-declarator-type-list</I> <TT>T</TT>&#8221;, then the
type of the identifier of <TT>D</TT> is an array type; if the type of
the identifier of <TT>D</TT> contains the <TT>auto</TT>
<I>type-specifier</I>, the program is ill-formed.</P>

</BLOCKQUOTE>

<P>This has the effect of prohibiting a declaration like</P>

<PRE>
    int v[1];
    auto (*p)[1] = &amp;v;
</PRE>

<P>This restriction is unnecessary and presumably unintentional.</P>

<P>Note also that the statement that &#8220;the type of the identifier
of <TT>D</TT> is an array type&#8221; is incorrect when the nested
declarator is not simply a <I>declarator-id</I>.  A similar problem
exists in the wording of 9.5.4 [<A href="https://wg21.link/dcl.init.ref#3">dcl.init.ref</A>] paragraph 3 for
function types.</P>

<P><B>Rationale (March, 2011):</B></P>

<P>The functionality of the <TT>auto</TT> specifier was intentionally
restricted to simple cases; supporting complex declarators like
this was explicitly discussed and rejected when the feature was
adopted.</P>

<BR><BR><HR>
<A NAME="1761"></A><H4>1761.
  
Runtime check on size of automatic array
</H4>
<B>Section: </B>9.3.4.5&#160; [<A href="https://wg21.link/dcl.array">dcl.array</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-09-23<BR><BR>


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

<P>The runtime check for violating the maximum size of a stack-based
array object is ill-advised.  Many implementations cannot easily
determine the available stack space, and checking against a fixed limit
is not helpful.</P>

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

<P>Change 9.3.4.5 [<A href="https://wg21.link/dcl.array#1">dcl.array</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<P>...The <I>expression</I> is erroneous if:</P>

<UL>
<LI><P>its value before converting...</P></LI>

<LI><P>its value is such that the size of the allocated object would exceed
the implementation-defined limit <INS>for the maximum size of an
object</INS> (Annex Clause Annex B [<A href="https://wg21.link/implimits">implimits</A>]);</P></LI>

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

</UL>

<P>...If the <I>expression</I> is erroneous, an exception of a type that
would match a handler (14.4 [<A href="https://wg21.link/except.handle">except.handle</A>]) of
type <TT>std::bad_array_length</TT> (_N3690_.18.6.2.2 [<A href="https://wg21.link/bad.array.length">bad.array.length</A>]) is
thrown <INS>[<I>Footnote:</I> Implementations are encouraged also to
throw such an exception if the size of the object would exceed the
remaining stack space. &#8212;<I>end footnote</I>]</INS>.</P>

</BLOCKQUOTE>

<P>This resolution also resolves <A HREF="cwg_closed.html#1675">issue 1675</A>.</P>

<BR><BR><HR>
<A NAME="1768"></A><H4>1768.
  
Zero-element array of runtime bound
</H4>
<B>Section: </B>9.3.4.5&#160; [<A href="https://wg21.link/dcl.array">dcl.array</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-09-24<BR><BR>


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

<P>C-style variable-length arrays (which have been widely implemented
as extensions to C++) permit a zero-length array.  Similarly, arrays
created by <I>new-expression</I>s can have a length of zero.  Forbidding
zero-length arrays of runtime bound is a gratuitous incompatibility.</P>

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

<OL>
<LI><P>Change 9.3.4.5 [<A href="https://wg21.link/dcl.array#1">dcl.array</A>] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>...The <I>expression</I> is erroneous if:</P>

<UL>
<LI><P>its value before converting to <TT>std::size_t</TT> or, in the
case of an expression of class type, before application of the second
standard conversion (12.2.4.2.3 [<A href="https://wg21.link/over.ics.user">over.ics.user</A>]) is less than <DEL>or
equal to</DEL> zero;</P></LI>

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

</UL>

<P>If the <I>expression</I>, after converting to <TT>std::size_t</TT>, is a
core constant expression and the expression is erroneous <INS>or its value
is zero</INS>, the program is ill-formed.  If the <I>expression</I>...
<TT>std::bad_array_length</TT> (_N3690_.18.6.2.2 [<A href="https://wg21.link/bad.array.length">bad.array.length</A>]) is thrown.
<DEL>An object of array type</DEL> <INS>If <TT>N</TT> is zero, an object of
array type has no elements.  Otherwise, it</INS> contains a contiguously
allocated non-empty set of <TT>N</TT> subobjects of type <TT>T</TT>. The
type...</P>

</BLOCKQUOTE>

</OL>

<P><B>Rationale (February, 2014):</B></P>

<P>The specification was removed from the WP and moved into a
Technical Specification.</P>

<BR><BR><HR>
<A NAME="18"></A><H4>18.
  
f(TYPE) where TYPE is void should be allowed
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>unknown<BR>





<P>9.3.4.6 [<A href="https://wg21.link/dcl.fct#2">dcl.fct</A>] paragraph 2
says:
<BLOCKQUOTE>If the <I>parameter-declaration-clause</I> is empty, the function
takes no arguments. The parameter list <TT>(void)</TT> is equivalent to
the empty parameter list.</BLOCKQUOTE>
Can a typedef to void be used instead of the type void in the parameter
list?</P>

<P>
<B>Rationale:</B>
The IS is already clear that this is not allowed.</P>
<BR><BR><HR>
<A NAME="1389"></A><H4>1389.
  
Recursive reference in <I>trailing-return-type</I>
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-09-04<BR>


<P>There doesn't appear to be an explicit prohibition of a function
declaration of the form</P>

<PRE>
    auto f() -&gt; decltype(f());
</PRE>

<P>Presumably there should be.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>As noted in <A HREF="cwg_closed.html#1433">issue 1433</A>, the point of
declaration of the function name is after the complete declarator, i.e.,
after the trailing return type, so the recursion posited in this issue
cannot occur.</P>

<BR><BR><HR>
<A NAME="66"></A><H4>66.
  
Visibility of default args vs overloads added after using-declaration
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>6 Oct 1998<BR>




<P>Paragraph 9 of says that extra default arguments added after a
<I>using-declaration</I> but before a call are usable in the call, while
9.10 [<A href="https://wg21.link/namespace.udecl#9">namespace.udecl</A>] paragraph 9
says that
extra function overloads are not. This seems inconsistent, especially
given the similarity of default arguments and overloads.</P>

<P>
<B>Rationale (10/99):</B> The Standard accurately reflects the
intent of the Committee.</P>
<BR><BR><HR>
<A NAME="1443"></A><H4>1443.
  
Default arguments and non-static data members
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-01-13<BR>




<P>Consider:</P>

<PRE>
    struct A {
       int i;
       A() { void foo(int=i); }
    };
</PRE>

<P>It's not clear whether that is well-formed or not.  It uses
<TT>this</TT>, which might be thought of as a kind of parameter or
local variable, which would make the default argument ill-formed.
On the other hand, there doesn't seem to be a good reason to ban
the code, either.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>] paragraphs 8-9 should be interpreted as
making the example ill-formed.</P>

<BR><BR><HR>
<A NAME="1339"></A><H4>1339.
  
Parenthesized <I>braced-init-list</I> and arrays
</H4>
<B>Section: </B>9.5&#160; [<A href="https://wg21.link/dcl.init">dcl.init</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-08-03<BR>




<P>The resolution of <A HREF="cwg_defects.html#1214">issue 1214</A> makes it
ill-formed to use an initializer of the form <TT>({...})</TT> with a
variable of a non-class type.  This can cause problems with a
<I>mem-initializer</I> of the form</P>

<PRE>
  constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
</PRE>

<P>If <TT>pthread_cond_t</TT> is an array,
<TT>PTHREAD_COND_INITIALIZER</TT> will be a <I>braced-init-list</I>
and the <I>mem-initializer</I> will be ill-formed.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>A non-static data member initializer can be used in this case.</P>

<BR><BR><HR>
<A NAME="1434"></A><H4>1434.
  
Parenthesized <I>braced-init-list</I>
</H4>
<B>Section: </B>9.5&#160; [<A href="https://wg21.link/dcl.init">dcl.init</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-12-21<BR>




<P>The semantics of a parenthesized <I>braced-init-list</I> are not
clear, whether appearing as a <I>mem-initializer</I> or standalone.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>CWG feels that the semantics are sufficiently clear without any
changes to the current wording.</P>

<BR><BR><HR>
<A NAME="1578"></A><H4>1578.
  
Value-initialization of aggregates
</H4>
<B>Section: </B>9.5&#160; [<A href="https://wg21.link/dcl.init">dcl.init</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-21<BR>


<P>The resolution of <A HREF="cwg_defects.html#1301">issue 1301</A> changed the
status of <TT>T{}</TT>, where <TT>T</TT> is an aggregate, from being
value-initialization to being aggregate initialization.  This change
breaks the description of <TT>DefaultConstructible</TT> in
16.4.4.2 [<A href="https://wg21.link/utility.arg.requirements">utility.arg.requirements</A>] Table 19.  LWG has opened an issue for
this (2170) but would like CWG to consider a core approach that would
categorize <TT>T{}</TT> as value initialization, even when <TT>T</TT>
is an aggregate.</P>

<P><B>Rationale (April, 2013):</B></P>

<P>There is a distinction in the core language between aggregate
initialization and value initialization.  For example, a class with
a deleted default constructor can be list-initialized via aggregate
initialization but not value-initialized.</P>

<BR><BR><HR>
<A NAME="2709"></A><H4>2709.
  
Parenthesized initialization of reference-to-aggregate
</H4>
<B>Section: </B>9.5.1&#160; [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-03-14
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>Paper P0960R3 enabled initialization of aggregates (including
arrays) from parenthesized expression lists.  The rather similar case
of initializating a reference to an aggregate was not addressed. For
example:</P>

<PRE>
  const int (&amp;ra)[2](1,2);
</PRE>

<P>There is no evidence in 9.5.1 [<A href="https://wg21.link/dcl.init.general#16">dcl.init.general</A>] paragraph 16 that
such support is intended, nor does 9.5.4 [<A href="https://wg21.link/dcl.init.ref#5">dcl.init.ref</A>] paragraph 5
admit an initializer other than a (single) expression for a
reference.</P>

<P>There is implementation divergence: gcc accepts, others reject.
Also, the parenthesized aggregate initialization paper P0960R3
apparently originally envisioned a textual transformation to a
braced-init-list, which presumably would have permitted the example.
It is not clear whether the reference case was intentionally or
accidentially dropped during the multiple revisions of the paper.</P>

<P><B>Additional notes (March, 2023)</B></P>

<P>Forwarded to EWG for consideration via
<A HREF="https://github.com/cplusplus/papers/issues/1494">cplusplus/papers#1494</A>
by decision of the CWG chair.</P>

<P><B>EWG 2023-05-11</B></P>

<P>It was noted that an attempt to initialize a reference-to-class
type using a parenthesized <I>expression-list</I> is also ill-formed
even if the class has a suitable constructor. Since parenthesized
aggregate initialization was modeled after a constructor invocation
for aspects such as temporary lifetimes, the status quo seems
consistent in that regard.</P>

<BR><BR><HR>
<A NAME="1097"></A><H4>1097.
  
Aggregate initialization of function parameters
</H4>
<B>Section: </B>9.5.2&#160; [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-07-29<BR>




<P>The current wording of the WP allows aggregate
initialization of parameters in function calls.  For example,
12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#4">over.ics.list</A>] paragraph 4 reads:</P>

<BLOCKQUOTE>

<P>Otherwise, if the parameter has an aggregate type which can
be initialized from the initializer list according to the
rules for aggregate initialization (9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]), the implicit conversion sequence is a
user-defined conversion sequence. [<I>Example:</I>
</P>

<PRE>
  struct A {
    int m1;
    double m2;
  };

  void f(A);
  f( {'a', 'b'} );  //<SPAN CLASS="cmnt"> OK: </SPAN>f(A(int,double))<SPAN CLASS="cmnt"> user-defined conversion</SPAN>
  f( {1.0} );       //<SPAN CLASS="cmnt"> error: narrowing</SPAN>
</PRE>

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

</BLOCKQUOTE>

<P>The rules for aggregate initialization in 9.5.2 [<A href="https://wg21.link/dcl.init.aggr#11">dcl.init.aggr</A>] paragraph 11
allow braces to be elided in the initializer</P>

<BLOCKQUOTE>

<P>In a declaration of the form</P>

<PRE>
  T x = { a };
</PRE>

</BLOCKQUOTE>

<P>It is not clear whether this phrasing should be interpreted
as allowing brace elision only in a <I>simple-declaration</I> and
thus not in a function argument or whether this restriction is
inadvertent and should be removed.</P>

<P><B>Rationale (November, 2010):</B></P>

<P>The restriction is intentional.  Support for aggregate initialization
is principally intended for legacy code and C compatibility, not for
code written using the new facilities of the language.</P>

<BR><BR><HR>
<A NAME="1497"></A><H4>1497.
  
Aggregate initialization with parenthesized string literal
</H4>
<B>Section: </B>9.5.2&#160; [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]
 &#160;&#160;&#160;

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

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

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


<P>Existing practice appears to be to allow C++03-style aggregate
initialization from a parenthesized string literal, e.g.,</P>

<PRE>
  struct S {
    char arr[4];
  } s = {("abc")};
</PRE>

<P>This should be standardized, to allow examples like</P>

<PRE>
  struct S {
    char arr[4];
  };
  void f(S);
  void g() {
    f({("abc")});
  }
</PRE>

<P><B>Rationale (October, 2012):</B></P>

<P>CWG agreed that this is already permitted by virtue of
_N4567_.5.1.1 [<A href="https://wg21.link/expr.prim.general#6">expr.prim.general</A>] paragraph 6.</P>

<BR><BR><HR>
<A NAME="1985"></A><H4>1985.
  
Unknown bound array member with <I>brace-or-equal-initializer</I>
</H4>
<B>Section: </B>9.5.2&#160; [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]
 &#160;&#160;&#160;

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

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

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




<P>The correct interpretation of an example like the following
is not clear:</P>

<PRE>
  struct A {
    int x[] = { 0 };
  };
</PRE>

<P>Should the initializer be considered as implicitly determining
the omitted array bound?</P>

<P><B>Rationale (November, 2014):</B></P>

<P>The requirement for determining an omitted bound in an
aggregate is that it be &#8220;initialized&#8221;
(9.5.5 [<A href="https://wg21.link/dcl.init.list#4">dcl.init.list</A>] paragraph 4); since the
<I>brace-or-equal-initializer</I> might, in fact, be
ignored in some or all uses of the class, it should not be
considered as definitively initializing the member and
thus does not determine the array bound.  Clarification of
this intent could be done editorially, but CWG felt that
no normative change was required.</P>

<BR><BR><HR>
<A NAME="2408"></A><H4>2408.
  
Temporaries and previously-initialized elements in aggregate initialization
</H4>
<B>Section: </B>9.5.2&#160; [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-03-13<BR>


<P>There is implementation divergence with respect to an
example like:</P>

<PRE>
  constexpr int f(int &amp;r) { r *= 9; return r - 12; }
  struct A { int &amp;&amp;temporary; int x; int y; };

  constexpr A a1 = { 6, f(a1.temporary), a1.temporary }; //<SPAN CLASS="cmnt"> #1 </SPAN>
</PRE>

<P>Some implementations accept this code and others say
that <TT>a1.temporary</TT> is not a constant expression
in the initializer at #1.</P>

<P><B>Rationale (July, 2019)</B></P>

<P>The example is valid; the constant evaluation is the entire
initialization <TT>constexpr A a1</TT>, thus the temporary bound
to <TT>a1.temporary</TT> started its lifetime within the constant
evaluation.</P>

<BR><BR><HR>
<A NAME="434"></A><H4>434.
  
Unclear suppression of standard conversions while binding reference to lvalue
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bronek Kozicki
 &#160;&#160;&#160;

 <B>Date: </B>14 September 2003<BR>


<P>In section 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>], paragraph 5, there is
following note:</P>
<BLOCKQUOTE>
Note: the usual lvalue-to-rvalue (4.1), array-to-pointer (4.2), and
function-to-pointer (4.3) standard conversions are not needed, and
therefore are suppressed, when such direct bindings to lvalues are done.
</BLOCKQUOTE>

<P>I believe that this note is misleading. There should be either:</P>
<UL>
<LI>no note, and leave this issue to be explained in section 4 only </LI>
<LI>explicit list of all suppressed conversions (including pointer
qualification conversion, as covered in section 4.4)</LI>
<LI>reminder that result of all standard conversions is never an lvalue,
thus these conversions are suppressed when binding reference to lvalue</LI>
</UL>

<P>The problem:</P>
<OL>
<LI>
under current wording it's unclear if following code is legal, or
not:
<PRE>
int main()
{
  const int ci = 10;
  int * pi = NULL;
  const int * &amp; rpci = pi;
  rpci = &amp;ci;
  *pi = 12; // circumvent constness of "ci"
}
</PRE>
</LI>
<LI>
it is also unclear what behaviour should following program expose:
<PRE>
int main()
{
  int * pi = NULL;
  const int * const &amp; rcpci = pi; // 1
  int i = 0;
  pi = &amp;i; // 2
  if (pi == rcpci)
    std::cout &lt;&lt; "bound to lvalue" &lt;&lt; std::endl;
  else
    std::cout &lt;&lt; "bound to temporary rvalue" &lt;&lt; std::endl;
}
</PRE>
</LI>
</OL>
<P>There has been discussion on this issue on comp.lang.c++.moderated month
ago, see
<A HREF="http://groups.google.pl/groups?threadm=9bed99bb.0308041153.1c79e882%40posting.google.com">
http://groups.google.pl/groups?threadm=9bed99bb.0308041153.1c79e882%40posting.google.com</A>
and there seems to be some confusion about it. I understand that note is
not normative, but apparently even some compiler writers are misled (try
above code snippets on few different compilers, and using different
compilation options - notably GCC 3.2.3 with -Wall -pedantic), thus it
should be cleared up.</P>

<P>My proposal is to change wording of discussed note to:</P>
<BLOCKQUOTE>
Note: result of every standard conversion is never an lvalue, and
therefore all standard conversions (clause 4) are suppressed, when such
direct bindings to lvalues are done.
</BLOCKQUOTE>

<P><B>Rationale (April, 2005):</B></P>

<P>As acknowledged in the description of the issue, the referenced
text is only a note and has no normative impact.  Furthermore, the
examples cited do not involve the conversions mentioned in the note,
and the normative text is already sufficiently clear that the types in
the examples are not reference-compatible.</P>

<BR><BR><HR>
<A NAME="1058"></A><H4>1058.
  
Reference binding of incompatible array types
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-03-20<BR>


<P>According to the logic in 9.5.4 [<A href="https://wg21.link/dcl.init.ref#5">dcl.init.ref</A>] paragraph 5,
the following example should create a temporary array and bind the
reference to that temporary:</P>

<PRE>
    const char (&amp;p)[10] = "123";
</PRE>

<P>That is presumably not intended (<A HREF="cwg_defects.html#450">issue 450</A>
calls a similar outcome for rvalue arrays &#8220;implausible&#8221;).
Current implementations reject this example.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>The Standard does not describe initialization of array temporaries, so
a program that requires such is ill-formed.</P>

<P><B>Note (October, 2010):</B></P>

<P>Although in general an object of array type cannot be initialized
from another object of array type, there is special provision in
9.5.3 [<A href="https://wg21.link/dcl.init.string">dcl.init.string</A>] for doing so when the source object is a
string literal, as in this example.  The issue is thus being reopened
for further consideration in this light.</P>

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

<P>The CWG agreed that the current wording appears to permit this
example but still felt that array temporaries are undesirable.
Wording should be added to disallow this usage.</P>

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

<P>Change 9.5.4 [<A href="https://wg21.link/dcl.init.ref#5">dcl.init.ref</A>] paragraph 5 as follows:</P>

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

<LI><P><INS>If the initializer expression is a string literal
(5.13.5 [<A href="https://wg21.link/lex.string">lex.string</A>]), the program is ill-formed.</INS></P></LI>

<LI><P>Otherwise, a temporary of type...</P></LI>

</UL>

<P>(See also <A HREF="cwg_defects.html#1232">issue 1232</A>, which argues in
favor of allowing array temporaries.)</P>

<P><B>Rationale (March, 2011):</B></P>

<P>In consideration of the arguments made in
<A HREF="cwg_defects.html#1232">issue 1232</A>, CWG agreed to allow array
temporaries and there is thus no reason to prohibit them in this
case.</P>

<BR><BR><HR>
<A NAME="1263"></A><H4>1263.
  
Mismatch between rvalue reference binding and overload resolution
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-03-18<BR>




<BR><BR><HR>
<A NAME="1650"></A><H4>1650.
  
Class prvalues in reference initialization
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR>




<P>As described in the &#8220;additional note, January, 2012&#8221; in
<A HREF="cwg_defects.html#1287">issue 1287</A>, questions were raised regarding the
treatment of class prvalues in the original proposed resolution and the
proposed resolution was revised (February, 2012) to address those concerns.
The revised resolution raised its own set of concerns with regard to
slicing and performance, however, and the issue was moved back to "review"
status to allow further discussion. 
</P>

<P>At the April, 2013 meeting, it was decided to proceed with the original
resolution of <A HREF="cwg_defects.html#1287">issue 1287</A> and split off the
concerns regarding class prvalues into this issue.</P>



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

<P>The resolution for <A HREF="cwg_defects.html#1604">issue 1604</A> results in
indirect binding to a subobject and will no longer cause slicing.</P>

<P><B>Rationale (November, 2013):</B></P>

<P>CWG determined that, in light of the resolution of
<A HREF="cwg_defects.html#1604">issue 1604</A>, no further change was necessary.</P>

<BR><BR><HR>
<A NAME="2111"></A><H4>2111.
  
Array temporaries in reference binding
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-04-02<BR>




<P>The current wording of the Standard appears to permit code like</P>

<PRE>
  void f(const char (&amp;)[10]);
  void g() {
    f("123");
    f({'a','b','c','\0'});
  }
</PRE>

<P>creating a temporary array of ten elements and binding the parameter
reference to it.  This is controversial and should be reconsidered.
(See issues <A HREF="cwg_closed.html#1058">1058</A> and
<A HREF="cwg_defects.html#1232">1232</A>.)</P>

<P><B>Rationale (March, 2016):</B></P>

<P>Whether to support creating a temporary array in such cases is
a question of language design and thus should be considered by
EWG.</P>

<P><B>EWG 2022-11-11</B></P>

<P>The intent is adequately expressed in the specification.</P>

<BR><BR><HR>
<A NAME="982"></A><H4>982.
  
Initialization with an empty initializer list
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>17 October, 2009<BR>




<P>The exposition of list initialization using an array in
9.5.5 [<A href="https://wg21.link/dcl.init.list#4">dcl.init.list</A>] paragraph 4 raises the question of whether
an empty initializer list is permitted, as declaration of an array
with a zero bound is ill-formed.</P>

<P><B>Rationale (October, 2009):</B></P>

<P>The description is intended as an aid to understanding the concepts,
not as a literal transformation that is performed.  An implementation
is permitted to allocate a zero-length array, even if such as array
cannot be decclared (e.g., via a <I>new-expression</I>).</P>

<BR><BR><HR>
<A NAME="1078"></A><H4>1078.
  
Narrowing and the usual arithmetic conversions
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-06-14<BR>




<P>Consider the example,</P>

<PRE>
    struct A { char c; };
    void f (char d) {
       A a = { d + 1 };
    }
</PRE>

<P>This code is now ill-formed because of the narrowing conversion
from the <TT>int</TT> result type of the addition, not because of
any real narrowing.  This seems like an embarrassment for C++0x.
It would be better not to get an error about any arithmetic
involving non-constant operands just because it might overflow with
some values.</P>

<P><B>Rationale (November, 2010):</B></P>

<P>The CWG agreed that this behavior is unfortunate but felt that
it would be too difficult to formulate a satisfactory set of rules
for handling complex expressions correctly for a small gain in
utility (the user can simply add a cast in order to avoid the
error).</P>

<BR><BR><HR>
<A NAME="1379"></A><H4>1379.
  
Is <TT>std::initializer_list</TT> an aggregate?
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-08-21<BR>




<P>The Standard does not specify whether
<TT>std::initializer_list</TT> may be an aggregate or not.
Strictly speaking, the order of the bullets in 9.5.5 [<A href="https://wg21.link/dcl.init.list#3">dcl.init.list</A>] paragraph 3 depends on the answer.  The existence
of a constructor declaration in 17.11 [<A href="https://wg21.link/support.initlist">support.initlist</A>]
suggests that it is not an aggregate but does not say so
definitively.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>The presence of the constructor declaration in 17.11 [<A href="https://wg21.link/support.initlist">support.initlist</A>]
is sufficient to establish that <TT>std::initializer_list</TT> is not an
aggregate.</P>

<BR><BR><HR>
<A NAME="1419"></A><H4>1419.
  
Evaluation order in aggregate initialization
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-11-22<BR>




<P>
<A HREF="cwg_defects.html#1030">Issue 1030</A> clarified that elements of an
initializer-list are evaluated in the order they are written, but does
that also apply to implied expressions?  That is, given:</P>

<PRE>
    struct A { A(); ~A(); };
    struct B { B(int, const A&amp; = A()); ~B(); };
    struct C { B b1, b2; };
    int main() { C{1,2}; }
</PRE>

<P>Do we know that the first <TT>B</TT> is constructed before the
second <TT>A</TT>?  I suppose that's what we want, even though it
complicates exception region nesting since the <TT>A</TT>s need
to live longer than the <TT>B</TT> subobject cleanups.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>Because this is an expression, not a declaration, the <TT>A</TT>s
live until the end of the full-expression.</P>

<BR><BR><HR>
<A NAME="1421"></A><H4>1421.
  
Full expressions and aggregate initialization
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-12-03<BR>




<P>Dealing with aggregate-initialized temporaries has been a bit of a
headache because unlike aggregate initialization of variables, each
element initialization is not a full-expression, so various things
behave differently because they are in the context of initializing a
temporary.</P>

<P>This can either be inconsistent with aggregate
initialization of a variable (in which each element is a
full-expression) or inconsistent with list-initialization via
constructor (in which each element is a subexpression).</P>

<P><B>Rationale (October, 2012):</B></P>

<P>The rules are acceptable as written; declaration and expression
contexts are different.</P>

<BR><BR><HR>
<A NAME="1461"></A><H4>1461.
  
Narrowing conversions to bit-fields
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-02-08<BR>


<P>The definition of a &#8220;narrowing conversion&#8221; in
9.5.5 [<A href="https://wg21.link/dcl.init.list#7">dcl.init.list</A>] paragraph 7 is couched in terms of the
type of the target.  A conversion to a too-small bit-field should
presumably also be categorized as a narrowing conversion.  (See also
<A HREF="cwg_defects.html#1449">issue 1449</A>.)</P>

<P><B>Additional note (August, 2012):</B></P>

<P>It was observed  that
the proposed narrowing error, unlike in other contexts, cannot be
circumvented by adding a cast.  The only way to avoid a narrowing
error would be to avoid using the brace syntax or to mask the value
to an appropriate width.  Even the latter approach could conceivably
require an implementation to track the maximum number of bits needed
by operations applied on top of the masked value, unless the masking
were required to be at the top level of the initializer expression.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>CWG felt that this was more of a language design question and would
be better considered by EWG.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>EWG determined that no action should be taken on this issue.</P>

<BR><BR><HR>
<A NAME="1501"></A><H4>1501.
  
Nested braces in list-initialization
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-05-04<BR>


<P>The specification of list-initialization in 9.5.5 [<A href="https://wg21.link/dcl.init.list#3">dcl.init.list</A>] paragraph 3
has a bullet that reads,</P>

<BLOCKQUOTE>

Otherwise, if the initializer list has a single element of type
<TT>E</TT> and either <TT>T</TT> is not a reference type or its
referenced type is reference-related to <TT>E</TT>, the object or
reference is initialized from that element

</BLOCKQUOTE>

<P>It is not clear what is meant by being &#8220; initialized from the
element.&#8221; If one assumes that it means &#8220;go back to
9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>] and follow the logic ladder there with the
element,&#8221; the logical result is that an initializer for a scalar
could be arbitrarily deeply nested in braces, with each trip through
the 9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>] / 9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>] recursion
peeling off one layer.  Presumably that is not intended.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>The wording &#8220;a single element of type <TT>E</TT>&#8221; excludes
the case of a nested braced initializer, because such an element has
no type.</P>

<BR><BR><HR>
<A NAME="1565"></A><H4>1565.
  
Copy elision and lifetime of <TT>initializer_list</TT> underlying array
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-10-10<BR>




<P>If an <TT>initializer_list</TT> object is copied and the copy
is elided, is the lifetime of the underlying array object extended?
E.g.,</P>

<PRE>
  void f() {
    std::initializer_list&lt;int&gt; L =
        std::initializer_list&lt;int&gt;{1, 2, 3}; //<SPAN CLASS="cmnt"> Lifetime of array extended?</SPAN>
  }
</PRE>

<P>The current wording is not clear.</P>

<P>(See also <A HREF="cwg_defects.html#1299">issue 1299</A>.)</P>

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

<P>The consensus of CWG was that the behavior should be the same,
regardless of whether the copy is elided or not.</P>

<P>
<B>Rationale (November, 2016):</B>
</P>

<P>With the adoption of paper P0135R1, there is no longer any copy
in this example to be elided.</P>

<BR><BR><HR>
<A NAME="1864"></A><H4>1864.
  
List-initialization of array objects
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>2014-02-15<BR>


<P>The resolution of <A HREF="cwg_defects.html#1467">issue 1467</A> now allows
for initialization of aggregate classes from an object of the same type.
Similar treatment should be afforded to array aggregates.</P>

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

<P>This is a request for extended language facilities and thus should
be evaluated by EWG.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a request for a new feature that should be proposed in a
paper to EWG.</P>

<BR><BR><HR>
<A NAME="1984"></A><H4>1984.
  
Lossless narrowing conversions
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

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




<P>According to 9.5.5 [<A href="https://wg21.link/dcl.init.list#7.3">dcl.init.list</A>] bullet 7.3, an
implicit conversion</P>

<BLOCKQUOTE>

from an integer type or unscoped enumeration type to a
floating-point type, except where the source is a constant
expression and the actual value after conversion will fit
into the target type and will produce the original value
when converted back to the original type

</BLOCKQUOTE>

<P>is a narrowing conversion.  There does not seem to be a
good reason why a conversion from, for example, an unsigned
char value to a floating point value should be considered
to be narrowing, since floating point types should be able
represent all the values.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>CWG felt that type-based (in contrast to value-based)
restrictions such as this should not depend on the
platform-specific characteristics of the type, so the
general rule should apply.</P>

<BR><BR><HR>
<A NAME="1574"></A><H4>1574.
  
Explicitly-defaulted <TT>constexpr</TT> functions in wrapper templates
</H4>
<B>Section: </B>9.6.2&#160; [<A href="https://wg21.link/dcl.fct.def.default">dcl.fct.def.default</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-10-16<BR>




<P>According to 9.6.2 [<A href="https://wg21.link/dcl.fct.def.default#2">dcl.fct.def.default</A>] paragraph 2,</P>

<BLOCKQUOTE>

An explicitly-defaulted function may be declared <TT>constexpr</TT> only if it
would have been implicitly declared as <TT>constexpr</TT>...

</BLOCKQUOTE>

<P>This is relevant for wrapper functions like</P>

<PRE>
  template&lt;class T&gt; struct wrap {
    T t;
    constexpr wrap() = default;
    constexpr wrap(const wrap&amp;) = default;
  };
</PRE>

<P>It is not clear how the new wording for <TT>constexpr</TT>
member functions of class templates in the proposed resolution
<A HREF="cwg_defects.html#1358">issue 1358</A> affects this:</P>

<BLOCKQUOTE>

If the instantiated template specialization of a <TT>constexpr</TT>
function template or member function of a class template would fail to
satisfy the requirements for a <TT>constexpr</TT> function or
<TT>constexpr</TT> constructor, that specialization is still a
<TT>constexpr</TT> function or <TT>constexpr</TT> constructor, even
though a call to such a function cannot appear in a constant
expression.

</BLOCKQUOTE>

<P><B>Rationale (April, 2013):</B></P>

<P>The specification is as intended.  The defaulted constructor will be
<TT>constexpr</TT> if it can be, so it should not be explicitly declared
<TT>constexpr</TT> in order to avoid the problems mentioned.</P>

<BR><BR><HR>
<A NAME="1217"></A><H4>1217.
  
Are deleted functions implicitly <TT>noexcept</TT>?
</H4>
<B>Section: </B>9.6.3&#160; [<A href="https://wg21.link/dcl.fct.def.delete">dcl.fct.def.delete</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-11-10<BR>




<P>It would seem intuitively that a deleted function cannot throw
an exception, but 9.6.3 [<A href="https://wg21.link/dcl.fct.def.delete">dcl.fct.def.delete</A>] does not mention that.
This could conceivably be useful in SFINAE contexts.</P>

<P><B>Rationale (November, 2010):</B></P>

<P>Any reference to a deleted function is ill-formed, so it doesn't
really matter whether they are <TT>noexcept</TT> or not.</P>

<BR><BR><HR>
<A NAME="2308"></A><H4>2308.
  
Structured bindings and lambda capture
</H4>
<B>Section: </B>9.7&#160; [<A href="https://wg21.link/dcl.struct.bind">dcl.struct.bind</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-07-23<BR>




<P>Whether or not structured bindings can be captured by a lambda and,
if so, with what semantics, is unclear from the current wording.</P>

<P><B>Rationale (March, 2018):</B></P>

<P>Paper P0588R1, adopted at the October, 2017 meeting, answers the
question by explicitly prohibiting such captures.</P>

<BR><BR><HR>
<A NAME="893"></A><H4>893.
  
Brace syntax for <I>enumerator-definition</I>s
</H4>
<B>Section: </B>9.8.1&#160; [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>8 May, 2009<BR>




<P>Although in most contexts &#8220;<TT>=</TT> <I>expression</I>&#8221;
can be replaced by &#8220;<TT>{</TT> <I>expression</I> <TT>}</TT>&#8221;,
<I>enumerator-definition</I>s accept only the &#8220;<TT>=</TT>&#8221;
form.  This could be surprising.</P>

<P><B>Additional note (October, 2009):</B></P>

<P>The Committee may wish to consider default arguments in this light
as well.  </P>

<P><B>Rationale (August, 2010):</B></P>

<P>This suggestion was considered and rejected by EWG.</P>

<BR><BR><HR>
<A NAME="1317"></A><H4>1317.
  
Unnamed scoped enumerations
</H4>
<B>Section: </B>9.8.1&#160; [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

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


<P>The text of 9.8.1 [<A href="https://wg21.link/dcl.enum#2">dcl.enum</A>] paragraph 2 explicitly forbids
unnamed scoped enumerations:</P>

<BLOCKQUOTE>

The optional <I>identifier</I> shall not be omitted in the declaration
of a scoped enumeration.

</BLOCKQUOTE>

<P>There does not appear to be a good rationale for this restriction
since a typedef name can be used to name the enumerators.  It is also
inconsistent with similar constructs.  For example,</P>

<PRE>
    typedef enum class { e } E;
    E x = E::e;
</PRE>

<P>is ill-formed, but</P>

<PRE>
    typedef struct { enum { s }; } S;
    int y = S::s;
</PRE>

<P>is well-formed.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The use of typedef names for linkage purposes is intended for
C compatibility and should not be extended to features that are not
part of the C subset of C++.</P>

<BR><BR><HR>
<A NAME="1917"></A><H4>1917.
  
decltype-qualified enumeration names
</H4>
<B>Section: </B>9.8.1&#160; [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-04-25<BR>


<P>9.3.4 [<A href="https://wg21.link/dcl.meaning#1">dcl.meaning</A>] paragraph 1 and Clause 11 [<A href="https://wg21.link/class#11">class</A>] paragraph 11
prohibit decltype-qualified declarators and class names,
respectively.  There is no such prohibition in 9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
for enumeration names.  Presumably that is an oversight that should be
rectified.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>The resolution of <A HREF="cwg_defects.html#2156">issue 2156</A>
includes the required prohibition.</P>

<BR><BR><HR>
<A NAME="311"></A><H4>311.
  
Using qualified name to reopen nested namespace
</H4>
<B>Section: </B>9.9.2&#160; [<A href="https://wg21.link/namespace.def">namespace.def</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>18 Sep 2001<BR>




<P>I received an inquiry/complaint that you cannot re-open a namespace using a
qualified name. For example, the following program is ok, but if you uncomment
the commented lines you get an error:</P>
<PRE>
namespace A {
    namespace N {
	int a;
    }
    int b;
    namespace M {
	int c;
    }
}

//namespace A::N {
//    int d;
//}

namespace A {
    namespace M {
        int e;
    }
}

int main()
{
    A::N::a = 1;
    A::b = 2;
    A::M::c = 3;
//  A::N::d = 4;
    A::M::e = 5;
}
</PRE>

<P>
<U>Andrew Koenig</U>:
There's a name lookup issue lurking here.  For example:</P>
<PRE>
    int x;

    namespace A {
	int x;
	namespace N {
	   int y;
	};
    }

    namespace A::N {
        int* y = &amp;x;  // which x?
    }
</PRE>

<P>
<U>Jonathan Caves</U>:
I would assume that any rule would state that:
<PRE>
namespace A::B {
</PRE>
would be equivalent to:
<PRE>
namespace A {
   namespace B {
</PRE>
so in your example 'x' would resolve to A::x</P>

<P>BTW: we have received lots of bug reports about this "oversight".</P>

<P>
<U>Lawrence Crowl</U>:
Even worse is
<PRE>
    int x;
    namespace A {
      int x;
    }
    namespace B {
      int x;
      namespace ::A {
         int* y = &amp;x;
      }
    }
</PRE>
I really don't think that the benefits of qualified names here is worth
the cost.</P>

<P><B>Notes from April 2003 meeting:</B></P>

<P>We're closing this because it's on the Evolution working group
list.</P>

<BR><BR><HR>
<A NAME="1976"></A><H4>1976.
  
Ambiguity of <I>namespace-alias</I>es
</H4>
<B>Section: </B>9.9.3&#160; [<A href="https://wg21.link/namespace.alias">namespace.alias</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-07-20<BR>




<P>Current implementations reject an example like:</P>

<PRE>
  namespace X { int n; }
  namespace A = X;
  namespace { namespace A = X; }
  int k = A::n;
</PRE>

<P>This seems curious, since a similar example with
<I>using-declaration</I>s or with <I>alias-declaration</I>s
is valid.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>The current wording of the Standard makes this example
ambiguous, and CWG did not find the similarities mentioned
compelling enough to warrant a change.</P>

<BR><BR><HR>
<A NAME="109"></A><H4>109.
  
Allowing <TT>::template</TT> in <I>using-declaration</I>s
</H4>
<B>Section: </B>9.10&#160; [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>6 Apr 1999<BR>



<P>
<I>Daveed Vandevoorde

:</I>
While reading <A HREF="cwg_defects.html#11">Core issue 11</A>
I thought it implied the following
possibility:</P>
<PRE>
    template&lt;typename T&gt;
    struct B {
       template&lt;int&gt; void f(int);
    };

    template&lt;typename T&gt;
    struct D: B&lt;T&gt; {
       using B&lt;T&gt;::template f;
       void g() { this-&gt;f&lt;1&gt;(0); } // OK, f is a template
    };
</PRE>
<P>However, the grammar for a <I>using-declaration</I> reads:</P>
<UL>
<TT>using typename<SUB>opt</SUB>&#160;::<SUB>opt</SUB>&#160;<I>nested-name-specifier&#160;unqualified-id</I> ;</TT>
</UL>
<P>and <I>nested-name-specifier</I> never ends in "<TT>template</TT>".</P>
<P>Is that intentional?</P>

<P><I>Bill Gibbons

:</I></P>
<P>It certainly appears to be, since we have:</P>
<UL>
<I>qualified-id</I>:
<UL><TT>::<SUB>opt</SUB> <I>nested-name-specifier</I> template<SUB>opt</SUB> <I>unqualified-id</I></TT></UL>
</UL>
so it would be easier to specify <I>using-declaration</I> as:
<UL>
<TT>using typename<SUB>opt</SUB> <I>qualified-id</I> ;</TT>
</UL>
if the "<TT>template</TT>" keyword were allowed.

There was a discussion about whether a dependent name specified in a
<I>using-declaration</I> could be given an "is a type" attribute through the
<TT>typename</TT> keyword; the decision was to allow this.  But I don't recall
if the "is a template" attribute was discussed.

<P>
<B>Rationale (04/99):</B> Any semantics associated with the
<TT>template</TT> keyword in <I>using-declaration</I>s should be considered an
extension.</P>

<P><B>Notes from the April 2003 meeting:</B></P>

<P>See also issues <A HREF="cwg_defects.html#96">96</A> and
<A HREF="cwg_defects.html#11">11</A>.</P>

<P>We decided to make no change and to close this issue as not-a-defect.
This is not needed functionality; the example above, for example, can
be written with <TT>-&gt;template</TT>.  This issue has been on the
issues list for years as an extension, and there has been no clamor
for it.</P>

<P>It was also noted that knowing that something is a template is
not enough; there's still the issue of knowing whether it is a
class or function template.</P>

<P><B>Additional note (February, 2011):</B></P>

<P>This issue is being reopened for further consideration after
additional discussion<committee-only>; see messages
<A href="http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&amp;msg=18492">18492</A> through <A href="http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&amp;msg=18499">18499</A></committee-only>.  It
was noted that, in addition to the workaround described above for
the member function template case, the new alias template facility
provides a workaround for the member class template case: instead
of</P>

<PRE>
    using T::template X;  //<SPAN CLASS="cmnt"> ill-formed</SPAN>
</PRE>

<P>for a class template member <TT>X</TT> of base class <TT>T</TT>,
one could write</P>

<PRE>
    template&lt;U&gt; using X = typename T::template X&lt;U&gt;;
</PRE>

<P>Rationale (March, 2011):</P>

<P>There was insufficient motivation for a change at this point.</P>

<BR><BR><HR>
<A NAME="169"></A><H4>169.
  
<I>template-id</I>s in <I>using-declaration</I>s
</H4>
<B>Section: </B>9.10&#160; [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Valentin Bonnard
 &#160;&#160;&#160;

 <B>Date: </B>16 Sep 1999<BR>



<P>9.10 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]s
ays,</P>

<BLOCKQUOTE>
A <I>using-declaration</I> shall not name a <I>template-id</I>.
</BLOCKQUOTE>

It is not clear whether this prohibition applies to the entity for
which the <I>using-declaration</I> is a synonym or to any name that
appears in the <I>using-declaration</I>.  For example, is the
following code well-formed?

<PRE>
    template &lt;typename T&gt;
    struct base {
	void bar ();
    };

    struct der : base&lt;int&gt;
    {
	using base&lt;int&gt;::bar; // ill-formed ?
    };
</PRE>

<P>
<B>Rationale (10/99):</B>
9.10 [<A href="https://wg21.link/namespace.udecl#1">namespace.udecl</A>] paragraph 1
says,
"A <I>using-declaration</I> introduces a name..."  It is the name
that is thus introduced that cannot be a <I>template-id</I>.</P>
<BR><BR><HR>
<A NAME="1960"></A><H4>1960.
  
Visibility of entity named in class-scope <I>using-declaration</I>
</H4>
<B>Section: </B>9.10&#160; [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]
 &#160;&#160;&#160;

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

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

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




<P>According to 9.10 [<A href="https://wg21.link/namespace.udecl#17">namespace.udecl</A>] paragraph 17,</P>

<BLOCKQUOTE>

The base class members mentioned by
a <I>using-declaration</I> shall be visible in the scope of
at least one of the direct base classes of the class where
the <I>using-declaration</I> is specified.

</BLOCKQUOTE>

<P>The rationale for this restriction is not clear and should be
reconsidered.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>The rule was introduced because the hiding of a base class member
by an intermediate derived class is potentially intentional and
should not be capable of circumvention by a <I>using-declaration</I>
in a derived class.  The consensus of CWG preferred not to change
the restriction.</P>

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

<P>The changes in P1787R6, adopted at the November, 2020 meeting,
removes the quoted wording, affirming the rationale in a different
manner.</P>

<BR><BR><HR>
<A NAME="461"></A><H4>461.
  
Make <TT>asm</TT> conditionally-supported
</H4>
<B>Section: </B>9.11&#160; [<A href="https://wg21.link/dcl.asm">dcl.asm</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Clark Nelson
 &#160;&#160;&#160;

 <B>Date: </B>24 May 2004<BR>


<P>Now that the concept of "conditionally-supported" is available (see
N1564), perhaps <TT>asm</TT> should not be required of every
implementation.</P>

<P><B>Rationale (October, 2004):</B></P>

<P>This is covered in paper N1627.  We would like to keep
<TT>asm</TT> as a keyword for all implementations, however, to
enhance portability by preventing programmers from inadvertently
using it as an identifier.</P>

<BR><BR><HR>
<A NAME="13"></A><H4>13.
  
extern "C" for Parameters of Function Templates
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>



<P>How can we write a function template, or member function of a class
template that takes a C linkage function as a parameter when the function
type depends on one of the template parameter types?</P>
<PRE>
    extern "C" void f(int);
    void g(char);

    template &lt;class T&gt; struct A {
        A(void (*fp)(T));
    };

    A&lt;char&gt; a1(g);  // okay
    A&lt;int&gt; a2(f);   // error
</PRE>
Another variant of the same problem is:
<PRE>
    extern "C" void f(int);
    void g(char);

    template &lt;class T&gt; void h( void (*fp)(T) );

    int main() {
        h(g);  // okay
        h(f);  // error
    }
</PRE>

<BR><B>Suggested resolution:</B> (John Spicer)

<P>Somehow permit a language linkage to be specified as part of a function
parameter declaration. i.e.</P>
<PRE>
    template &lt;class T&gt; struct A {
        A( extern "C" void (*fp)(T) );
    };

    template &lt;class T&gt; void h( extern "C" void (*fp)(T) );
</PRE>
<B>Suggested resolution:</B> (Bill Gibbons)

<P>The whole area of linkage needs revisiting.  Declaring calling
convention as a storage class was incorrect to begin
with; it should be a function qualifier, as in:</P>
<PRE>
    void f( void (*pf)(int) c_linkage );
</PRE>
instead of the suggested:
<PRE>
    void f( extern "C" void (*pf)(int) );
</PRE>
I would like to keep calling convention on the "next round" issues list,
including the alternative of using function qualifiers.

<P>And to that end, I suggest that the use of linkage specifiers to specify
calling convention be deprecated - which would make any use of linkage
specifiers in a parameter declaration deprecated.</P>

<P>
<U>Martin Sebor</U>:

9.12 [<A href="https://wg21.link/dcl.link">dcl.link</A>], paragraph 4 says that "A
linkage-specification shall occur only in namespace scope..." I'm
wondering why this restriction is necessary since it prevents, among
other things, the use of the functions defined <TT>&lt;cmath&gt;</TT>
in generic code that involves function objects. For example, the
program below is ill-formed since
<TT>std::pointer_to_binary_function&lt;&gt;</TT> takes a pointer to a
function with extern "C++" linkage which is incompatible with the type
of the <TT>double</TT> overload of <TT>std::pow</TT>.</P>

<P>Relaxing the restriction to allow linkage specification in
declarations of typedefs in class scope would allow
<TT>std::pointer_to_binary_function&lt;&gt;</TT> ctor to be overloaded
on both types (i.e., extern "C" and extern "C++"). An alternative
would be to allow for the linkage specification to be deduced along
with the type.</P>

<PRE>
    #include &lt;cmath&gt;
    #include &lt;functional&gt;
    #include &lt;numeric&gt;

    int main () {
      double a[] = { 1, 2, 3 };
      return std::accumulate (a, a + 3, 2.0,
        std::pointer_to_binary_function&lt;double, double, double&gt;(std::pow));
    }
</PRE>

<P><B>Rationale (February, 2014):</B></P>

<P>EWG determined that no action should be taken on this issue.</P>

<BR><BR><HR>
<A NAME="14"></A><H4>14.
  
extern "C" functions and declarations in different namespaces
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Erwin Unruh
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>





<P><B><U>Issue 1</U></B></P>

<P>9.12 [<A href="https://wg21.link/dcl.link">dcl.link</A>]

paragraph 6 says the following:</P>
<UL>extern "C" functions in multiple namespaces refer to the same function.</UL>
Is this only for linkage purposes or for both name look up and linkage
purposes:
<PRE>
    extern "C" int f(void);
    namespace A {
         extern "C" int f(void);
    };
    using namespace A;

    int i = f(); // Ok because only one function f() or
                 // ill-formed
</PRE>
For name lookup, both declarations of f are visible and overloading cannot
distinguish between them. Has the compiler to check that these functions
are really the same function or is the program in error?

<P>
<B>Rationale:</B> These are the same function for all purposes.</P>

<P><B><U>Issue 2</U></B></P>

<P>A similar question may arise with typedefs:</P>
<PRE>
    // vendor A
    typedef unsigned int size_t;
    // vendor B
    namespace std {
            typedef unsigned int size_t;
    }
    using namespace std;
    size_t something(); // error?
</PRE>
Is this valid because the typedef <TT>size_t</TT> refers to the same type in both
namespaces?

<P>
<B>Rationale (04/99):</B>
In
9.9.4 [<A href="https://wg21.link/namespace.udir">namespace.udir</A>]

paragraph 4:
<BLOCKQUOTE>If name lookup finds a declaration for a name in two different
namespaces, and the declarations do not declare the same entity and do
not declare functions, the use of the name is ill-formed.</BLOCKQUOTE>
The term <I>entity</I> applied to typedefs refers to the underlying type
or class (6.1 [<A href="https://wg21.link/basic.pre#3">basic.pre</A>] paragraph 3); therefore
both declarations of <TT>size_t</TT> declare the same entity and
the above example is well-formed.</P>
<BR><BR><HR>
<A NAME="107"></A><H4>107.
  
Linkage of operator functions
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>21 Apr 1999<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>



<P>
<U>Steve Clamage:</U>
I can't find anything in the standard that prohibits a language
linkage on an operator function.  For example:</P>
<BLOCKQUOTE><PRE>
extern "C" int operator+(MyInt, MyInt) { ... }
</PRE></BLOCKQUOTE>
<P>Clearly it is a bad idea, you could have only one <TT>operator+</TT>
with "C" linkage in the entire program, and you can't call the function
from C code.</P>

<P>
<U>Mike Miller:</U>
Well, you can't <I>name</I> an operator function in C code, but if
the arguments are compatible (e.g., not references), you <I>can</I>
call it from C code via a pointer.  In fact, because the language
linkage is part of the function type, you couldn't pass the
address of an operator function into C code unless you could
declare the function to be extern "C".</P>

<P>
<U>Fergus Henderson:</U>
In the general case, for linkage to languages other than C,
this could well make perfect sense.</P>

<P><U>Steve Clamage:</U></P>
<P>But is it disallowed (as opposed to being stupid), and if so, where
in the standard does it say so?</P>

<P>
<U>Mike Miller:</U>
I don't believe there's a restriction.  Whether that is because
of the (rather feeble) justification of being able to call an
operator from C code via a pointer, or whether it was simply
overlooked, I don't know.</P>

<P>
<U>Fergus Henderson:</U>
I don't think it is disallowed.  I also don't think there is any need
to explicitly disallow it.</P>

<P>
<U>Steve Clamage</U>:
I don't think the standard is clear enough on this point.  I'd
like to see a clarification.</P>

<P>I think either of these two clarifications would be appropriate:</P>

<OL>
<LI>
A linkage specification on an operator function is ill-formed.</LI>

<LI>
A linkage specification on an operator function is
well-formed, but the semantics (e.g.  name mangling) are
implementation-defined.  In addition, the rule about multiple
functions with the same name having "C" linkage applies.</LI>

<PRE>
    extern "C" T operator+(T,T); // ok
    extern "C" T operator-(T,T); // ok
    extern "C" U operator-(U);   // error, two extern "C" operator-
</PRE>
</OL>

<P>
<U>Mike Miller</U>:
I think the point here is that something like</P>

<PRE>
    extern "xyzzy" bool operator&lt;(S&amp;,S&amp;)
</PRE>

could well make sense, if language xyzzy is sufficiently compatible with
C++, and the one-function rule only applies to extern "C", not to other
language linkages.  Given that it might make sense to have general
language linkages for operators, is it worthwhile to make an exception
to the general rule by saying that you can have any language linkage
on an operator function except "C" linkage?  I don't like exceptions to
general rules unless they're very well motivated, and I don't see
sufficient motivation to make one here.

<P>Certainly this capability isn't very useful.  There are lots
of things in C++ that aren't very useful but just weren't
worth special-casing out of the language.  I think this falls
into the same category.</P>

<P>
<U>Mike Ball</U>:
I DON'T want to forbid operator functions within an
extern "C".  Rather I want to add operator functions to that sentence
in paragraph 4 of
9.12 [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 which reads</P>

<BLOCKQUOTE>
A C language linkage is ignored for the names of class members and
the member function type of class member functions.
</BLOCKQUOTE>

My reason is simple:  C linkage makes a total hash of scope. Any "C" functions
declared with the same name in any namespace scope are the same function.
In other words, namespaces are totally ignored.

<P>This provision was added in toward the end of the standardization process,
and was, I thought, primarily to make it possible to put the C library
in namespace <TT>std</TT>.  Otherwise, it seems an unwarrented attack on the
very concept of scope.  We (wisely) didn't force this on static member
functions, since it would essentially promote them to the global scope.</P>

<P>Now I think that programmers think of operator functions as essentially
part of a class.  At least for one very common design pattern they are
treated as part of the class interface.  This pattern is the reason we
invented Koenig lookup for operator functions.</P>

<P>What happens when such a class definition is included, deliberately or
not, in an extern "C" declaration?  The member operators continue to
work, but the non-member operators can suddenly get strange and
hard to understand messages.  Quite possibly, they get the messages
only when combined with other classes in other compilation units.
You can argue that the programmer shouldn't put the class header
in a linkage delaration in the first place, but I can still find books
that recommend putting `extern "C"' around entire header files,
so it's going to happen.</P>

<P>I think that including operator functions in the general exclusion from
extern "C" doesn't remove a capability, rather it ensurs a capability
that programmers already think they have.</P>

<P><B>Rationale (10/00):</B></P>

<P>The benefits of creating an exception for operator functions
were outweighed by the complexity of adding another special case
to the rules.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group recommended closing this issue with
no further consideration.  See paper J16/07-0033 = WG21 N2173.</P>
<BR><BR><HR>
<A NAME="168"></A><H4>168.
  
C linkage for static member functions
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Darin Adler
 &#160;&#160;&#160;

 <B>Date: </B>9 Sep 1999<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>

<P>9.12 [<A href="https://wg21.link/dcl.link#4">dcl.link</A>] paragraph 4
says,</P>

<BLOCKQUOTE>
A C language linkage is
ignored for the names of class members and the member function types of
class member functions.
</BLOCKQUOTE>

This makes good sense, since C linkage names
typically aren't compatible with the naming used for member functions at
link time, nor is C language linkage function type necessarily compatible
with the calling convention for passing <TT>this</TT> to a non-static member
function.

<P>But C language linkage type (not name) for a static member function is
invaluable for a common programming idiom. When calling a C function that
takes a pointer to a function, it's common to use a private static member
function as a "trampoline" which retrieves an object reference (perhaps by
casting) and then calls a non-static private member function. If a static
member function can't have a type with C language linkage, then a global or
friend function must be used instead. These alternatives expose more of a
class's implementation than a static member function; either the friend
function itself is visible at namespace scope alongside the class definition
or the private member function must be made public so it can be called by a
non-friend function.</P>

<P>Suggested Resolution: Change the sentence cited above
to:</P>

<BLOCKQUOTE>
A C language linkage is ignored for the names of class members and the
member function types of <INS>non-static</INS> class member functions.
</BLOCKQUOTE>

The example
need not be changed because it doesn't involve a static member function.

<P>The following workaround accomplishes the goal of not exposing
the class's implementation, but at the cost of significant
superstructure and obfuscation:</P>

<PRE>
    // foo.h
    extern "C" typedef int c_func(int);
    typedef int cpp_func(int);
    class foo
    {
    private:
      c_func* GetCallback();
      static int Callback(int);
    };

    // foo.cpp
    #include "foo.h"

    // A local pointer to the static member that will handle the callback.
    static cpp_func* cpp_callback=0;

    // The C function that will actually get registered.
    extern "C" int CFunk(int i)
    {
      return cpp_callback(i);
    }

    c_func* foo::GetCallback()
    {
      cpp_callback = &amp;Callback;    // Only needs to be done once.
      return &amp;CFunk;
    }
</PRE>

<P>
<B>Rationale (10/99):</B> The Standard correctly reflects the
intent of the Committee.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group recommended closing this issue with no
further consideration.  See paper J16/07-0033 = WG21 N2173.</P>
<BR><BR><HR>
<A NAME="358"></A><H4>358.
  
Namespaces and extern "C"
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>28 May 2002<BR>




<P>Is this code valid:</P>
<PRE>
  extern "C" void f();

  namespace N
  {
    int var;
    extern "C" void f(){ var = 10; }
  }
</PRE>
<P>
The two declarations of f refer to the same external function,
but is this a valid way to declare and define f?</P>

<P>And is the definition of f considered to be in namespace N
or in the global namespace?</P>

<P><B>Notes from October 2002 meeting:</B></P>

<P>Yes, this example is valid.  See 9.12 [<A href="https://wg21.link/dcl.link#6">dcl.link</A>] paragraph 6,
 which contains a similar example with the definition in
the global namespace instead.
There is only one f, so the question of whether the definition
is in the global namespace or the namespace N is not meaningful.
The same function is found by name lookup whether it is found
from the declaration in namespace N or the declaration in
the global namespace, or both (9.9.4 [<A href="https://wg21.link/namespace.udir#4">namespace.udir</A>] paragraph 4)
.</P>

<BR><BR><HR>
<A NAME="1703"></A><H4>1703.
  
Language linkage of names of functions with internal linkage
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-06-17<BR>




<P>
<A HREF="cwg_defects.html#4">Issue 4</A> separated the concepts of language
linkage for names and language linkage for types; since the names of
functions with internal linkage are not visible outside their (C++)
translation unit, there is no need to restrict overloading of
extern "C" functions with internal linkage, e.g.,</P>

<PRE>
  extern "C" {
    static void f();
    static void f(int);
  }
</PRE>

<P>although the types of such functions still have C language linkage
and thus can be called via a function pointer from C code.</P>

<P>The change permitting such overloading, however, has not been widely
implemented since the resolution of <A HREF="cwg_defects.html#4">issue 4</A>,
leading some to suggest that the unnecessary restriction on function
overloading of such functions should be reimposed.</P>

<P>If it is decided to keep the resolution of <A HREF="cwg_defects.html#4">issue 4</A>, 9.12 [<A href="https://wg21.link/dcl.link#6">dcl.link</A>] paragraph 6 should be clarified:</P>

<BLOCKQUOTE>

At most one function with a particular name can have C language linkage.

</BLOCKQUOTE>

<P>Presumably this was overlooked in implementing the intent of the
resolution for the issue and is a likely explanation for the reason
it is not more widely implemented.</P>

<P><B>Rationale (September, 2013):</B></P>

<P>There was no consensus in CWG for a change to the current rules.
9.12 [<A href="https://wg21.link/dcl.link#6">dcl.link</A>] paragraph 6 should be read as applying to
the C language linkage of the name, not the function type.</P>

<BR><BR><HR>
<A NAME="1869"></A><H4>1869.
  
<TT>thread_local</TT> vs <I>linkage-specification</I>s
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-02-14<BR>




<P>According to 9.12 [<A href="https://wg21.link/dcl.link#7">dcl.link</A>] paragraph 7,</P>

<BLOCKQUOTE>

A declaration directly contained in a <I>linkage-specification</I> is
treated as if it contains the <TT>extern</TT> specifier
(9.2.2 [<A href="https://wg21.link/dcl.stc">dcl.stc</A>]) for the purpose of determining the linkage of
the declared name and whether it is a definition.  Such a declaration shall
not specify a storage class.

</BLOCKQUOTE>

<P>This prohibits a declaration like</P>

<PRE>
  extern "C++" thread_local int n;
</PRE>

<P>Should this be changed?</P>

<P><B>Rationale (June, 2014):</B></P>

<P>This restriction is the same for <TT>static</TT> and simply
requires that the braced form of <I>linkage-specification</I>
be used.</P>

<BR><BR><HR>
<A NAME="1323"></A><H4>1323.
  
Nonexistent nonterminal in <I>alignment-specifier</I> grammar
</H4>
<B>Section: </B>9.13.1&#160; [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>2011-05-19<BR>


<P>The grammar for <I>alignment-specifier</I> in 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#1">dcl.attr.grammar</A>] paragraph 1
is:</P>

<UL>
<I>alignment-specifier:</I>
<UL>
<TT>alignas (</TT><I> type-id </I><TT>...</TT><I><SUB>opt</SUB></I> <TT>)</TT><BR>
<TT>alignas (</TT><I> alignment-expression </I><TT>...</TT><I><SUB>opt</SUB></I> <TT>)</TT>
</UL>
</UL>

<P>There is no such nonterminal as <I>alignment-expression</I>; it
should be <I>assignment-expression</I> instead.</P>

<P><B>Rationale (August, 2011)</B></P>

<P>This is an editorial issue that has been transmitted to the project
editor.</P>

<BR><BR><HR>
<A NAME="2279"></A><H4>2279.
  
Multiple <I>attribute-specifier</I>s in one <I>attribute-list</I>
</H4>
<B>Section: </B>9.13.1&#160; [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-06-27<BR>




<P>P0028R4 contains this example:</P>

<PRE>
  [[ using CC: opt(1), debug ]] void f() {} //<SPAN CLASS="cmnt"> Same as </SPAN>[[ CC::opt(1), CC::debug ]] void f() {}
  [[ using CC: opt(1)]][[ CC::debug ]] void g() {} //<SPAN CLASS="cmnt"> Okay (same effect as above).</SPAN>
</PRE>

<P>However, there appears to be no normative justification for the
claim that these two <I>attribute-list</I>s have the same effect.</P>

<P><B>Rationale (February, 2017):</B></P>

<P>The effects of such attributes are implementation-defined.</P>

<BR><BR><HR>
<A NAME="2388"></A><H4>2388.
  
Applicability of <I>contract-attribute-specifier</I>s
</H4>
<B>Section: </B>9.13.1&#160; [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2018-10-24<BR>


<P>According to 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#5">dcl.attr.grammar</A>] paragraph 5,</P>

<BLOCKQUOTE>

Each <I>attribute-specifier-seq</I> is said to appertain to some entity or
statement, identified by the syntactic context where it appears (
Clause 8 [<A href="https://wg21.link/stmt">stmt</A>], 9.1 [<A href="https://wg21.link/dcl.pre">dcl.pre</A>],
9.3 [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]). If an <I>attribute-specifier-seq</I> that
appertains to some entity or statement contains an <I>attribute</I>
or <I>alignment-specifier</I> that is not allowed to apply to that entity
or statement, the program is ill-formed.

</BLOCKQUOTE>

<P>This does not, but presumably should,
mention <I>contract-attribute-specifier</I>s.</P>

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

<P>Change 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#5">dcl.attr.grammar</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

Each <I>attribute-specifier-seq</I> is said to appertain to
some entity or statement, identified by the syntactic
context where it appears (Clause 8 [<A href="https://wg21.link/stmt">stmt</A>],
9.1 [<A href="https://wg21.link/dcl.pre">dcl.pre</A>], 9.3 [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]). If
an <I>attribute-specifier-seq</I> that appertains to some
entity or statement contains an <I>attribute</I><INS>,
<I>contract-attribute-specifier</I>,</INS>
or <I>alignment-specifier</I> that is not allowed to apply
to that entity or statement, the program is ill-formed. If
an <I>attribute-specifier-seq</I> appertains to a friend
declaration (11.8.4 [<A href="https://wg21.link/class.friend">class.friend</A>]), that declaration
shall be a definition. No <I>attribute-specifier-seq</I>
shall appertain to an explicit instantiation
(13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]).

</BLOCKQUOTE>

<P><B>Rationale (July, 2019):</B></P>

<P>With the adoption of paper P1823R0, removing contracts from
C++20, this issue is moot.</P>

<BR><BR><HR>
<A NAME="1627"></A><H4>1627.
  
Agreement of dependent <TT>alignas</TT> specifiers
</H4>
<B>Section: </B>9.13.2&#160; [<A href="https://wg21.link/dcl.align">dcl.align</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-02-22<BR>




<P>Although 9.13.2 [<A href="https://wg21.link/dcl.align#6">dcl.align</A>] paragraph 6 requires that all
declarations of a given entity must have the same alignment, enforcing
that requirement for class templates would require instantiating all
declarations of the template, a process not otherwise needed.  For
example:</P>

<PRE>
   template&lt;int M, int N&gt; struct alignas(M) X;
   template&lt;int M, int N&gt; struct alignas(N) X {};
</PRE>

<P>The same problem would presumably afflict any attribute applied
to a class template.</P>

<P><B>Rationale (April, 2013):</B></P>

<P>9.13.2 [<A href="https://wg21.link/dcl.align#6">dcl.align</A>] paragraph 6 requires that the alignments
be &#8220;equivalent,&#8221; which in a dependent context is specified
by 13.7.7.2 [<A href="https://wg21.link/temp.over.link#5">temp.over.link</A>] paragraph 5.  The expressions in this
example are not equivalent.</P>

<BR><BR><HR>
<A NAME="836"></A><H4>836.
  
<TT>[[noreturn]]</TT> applied to function types
</H4>
<B>Section: </B>9.13.10&#160; [<A href="https://wg21.link/dcl.attr.noreturn">dcl.attr.noreturn</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Joseph Myers
 &#160;&#160;&#160;

 <B>Date: </B>7 March, 2009<BR>




<P>The <TT>[[noreturn]]</TT> attribute, as specified in
9.13.10 [<A href="https://wg21.link/dcl.attr.noreturn">dcl.attr.noreturn</A>], applies to function declarations and is
not integrated with the type system.  This is incompatible with
existing practice (as in gcc) and should be reconsidered.</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The CWG reaffirmed the previous decisions not to have attributes
apply to types and did not believe that the benefits were sufficient
for this case to make an exception to the general rule.</P>

<BR><BR><HR>
<A NAME="1132"></A><H4>1132.
  
Keyword vs attribute for <TT>noreturn</TT>
</H4>
<B>Section: </B>9.13.10&#160; [<A href="https://wg21.link/dcl.attr.noreturn">dcl.attr.noreturn</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#GB32">N3092 comment
  GB&#160;32<BR></A>

<P>C has rejected the notion of attributes, and introduced
the noreturn facility as a keyword. To continue writing
clean, portable code we should replace the <TT>[[noreturn]]</TT>
attribute with a <TT>noreturn</TT> keyword, following the usual
convention that while C obfuscates new keywords with
_Capital and adds a macro to map to the comfortable
spelling, C++ simply adopts the all-lowercase spelling.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>CWG felt that an attribute was a more appropriate representation
for this feature.</P>

<BR><BR><HR>
<A NAME="2527"></A><H4>2527.
  
Non-class potentially-overlapping objects
</H4>
<B>Section: </B>9.13.11&#160; [<A href="https://wg21.link/dcl.attr.nouniqueaddr">dcl.attr.nouniqueaddr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2022-01-29<BR>


<P>The definition of a &#8220;potentially-overlapping
subobject&#8221; in 6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>] paragraph
7 does not exclude non-class subobjects; in particular,
9.13.11 [<A href="https://wg21.link/dcl.attr.nouniqueaddr">dcl.attr.nouniqueaddr</A>] makes no restrictions on
the types of members declared with the
<TT>no_unique_address</TT> attribute. It is not clear that a
potentially-overlapping scalar member or array of scalar
elements is useful. Should there be a restriction on the type
of potentially-overlapping subjects?</P>

<P><B>CWG 2022-11-11</B></P>

<P>Restricting the type of a potentially-overlapping subobject would
make it difficult to use <TT>no_unique_address</TT> on a subobject of
dependent type, which may be a non-class type in some, but not all,
specializations.  Compilers can warn about non-sensical uses in
non-dependent contexts.</P>

<BR><BR><HR>
<A NAME="1141"></A><H4>1141.
  
Non-static data member initializers have not been implemented
</H4>
<B>Section: </B>11.4&#160; [<A href="https://wg21.link/class.mem">class.mem</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US51">N3092 comment
  US&#160;51<BR></A>

<P>Non-static data member initializers should not be part of C++0x
unless they have implementation experience.</P>

<P><B>Notes from the August, 2010 meeting:</B></P>

<P>The C++/CLI dialect has a very similar feature that has been
implemented.</P>

<P><B>Rationale (March, 2011):</B></P>

<P>The full Committee voted not to remove this feature.</P>

<BR><BR><HR>
<A NAME="1341"></A><H4>1341.
  
Bit-field initializers
</H4>
<B>Section: </B>11.4&#160; [<A href="https://wg21.link/class.mem">class.mem</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-08-10<BR>




<P>The grammar for <I>member-declarator</I> (11.4 [<A href="https://wg21.link/class.mem">class.mem</A>])
does not, but should, allow for a <I>brace-or-equal-initializer</I> on
a bit-field declarator.</P>

<P><B>Rationale (October, 2015):</B></P>

<P>Such a change would introduce a new syntactic ambiguity.  CWG
also felt uncomfortable with a construct that is visually</P>

<PRE>
  expression = expression
</PRE>

<P>not being an assignment expression.</P>

<BR><BR><HR>
<A NAME="2208"></A><H4>2208.
  
<I>static_assert-declaration</I> does not declare a member
</H4>
<B>Section: </B>11.4&#160; [<A href="https://wg21.link/class.mem">class.mem</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Stephan Bergmann
 &#160;&#160;&#160;

 <B>Date: </B>2015-12-02<BR>


<P>[Detailed description pending.]</P>

<P><B>Rationale (November, 2016):</B></P>

<P>The reported issue is no longer relevant to the current working paper.</P>

<BR><BR><HR>
<A NAME="2510"></A><H4>2510.
  
<I>noexcept-specifier</I> of friend function vs class completeness
</H4>
<B>Section: </B>11.4.1&#160; [<A href="https://wg21.link/class.mem.general">class.mem.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2021-10-26<BR>


<P>According to 11.4.1 [<A href="https://wg21.link/class.mem.general#7">class.mem.general</A>] paragraph 7,
a <I>noexcept-specifier</I> is a complete-class
context. This raises an issue when the function is a friend
function; for example, consider:</P>

<PRE>
  using T = int;
  struct B {
    friend void g(B b) noexcept(sizeof(b.m) &gt;= 4) { }
    T m = T();
  };
  int main() {
    B b;
    g(b);
  }
</PRE>

<P>For friend declarations you need to be able to decide
at the point of declaration whether it matches a prior
declaration, and you can't do that if you treat the
<I>noexcept-specifier</I> as a complete-class context.</P>

<P>There is implementation divergence in the treatment of
this example.</P>

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

<P>CWG questioned why the declaration matching couldn't be
deferred until the end of the class.</P>

<P><B>CWG 2022-11-10</B></P>

<P>CWG believes that, in general, a "when needed" approach to parsing
complete-class contexts is superior.  In the present case, the
existing wording clearly requires that the <I>noexcept-specifier</I>
be delayed-parsed, which implies that matching the declaration of a
friend function to declarations at namespace scope is also
delayed.</P>

<BR><BR><HR>
<A NAME="1005"></A><H4>1005.
  
Qualified name resolution in member functions of class templates
</H4>
<B>Section: </B>11.4.3&#160; [<A href="https://wg21.link/class.mfct.non.static">class.mfct.non.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>2009-11-19<BR>




<P>It's not clear how lookup of a non-dependent qualified name
should be handled in a non-static member function of a class
template.  For example,</P>

<PRE>
    struct A {
      int f(int);
      static int f(double);
    };

    struct B {};

    template&lt;typename T&gt; struct C : T {
      void g() {
        A::f(0);
      }
    };
</PRE>

<P>The call to <TT>A::f</TT> inside <TT>C::g()</TT> appears
non-dependent, so one might expect that it would be bound at
template definition time to <TT>A::f(double)</TT>.  However, the
resolution for <A HREF="cwg_defects.html#515">issue 515</A> changed
11.4.3 [<A href="https://wg21.link/class.mfct.non.static#3">class.mfct.non.static</A>] paragraph 3 to transform an
<I>id-expression</I> to a member access expression using
<TT>(*this).</TT> if lookup resolves the name to a non-static
member of <I>any</I> class, making the reference dependent.  The
result is that if <TT>C</TT> is instantiated with <TT>A</TT>,
<TT>A::f(int)</TT> is called; if <TT>C</TT> is instantiated with
<TT>B</TT>, the call is ill-formed (the call is transformed to
<TT>(*this).A::f(0)</TT>, and there is no <TT>A</TT> subobject in
<TT>C&lt;B&gt;</TT>).  Both these results seem unintuitive.</P>

<P>(See also <A HREF="cwg_defects.html#1017">issue 1017</A>.)</P>

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

The CWG agreed that the resolution of <A HREF="cwg_defects.html#515">issue 515</A>
was ill-advised and should be reversed.

<P><B>Rationale (March, 2011):</B></P>

<P>The analysis is incorrect; whether the reference is dependent or
not, overload resolution chooses <TT>A::f(int)</TT> because of the
rules in 12.2.2.2.2 [<A href="https://wg21.link/over.call.func#3">over.call.func</A>] paragraph 3 dealing with
contrived objects for static member functions.</P>

<BR><BR><HR>
<A NAME="1143"></A><H4>1143.
  
Move semantics for <TT>*this</TT> have not been implemented
</H4>
<B>Section: </B>11.4.3&#160; [<A href="https://wg21.link/class.mfct.non.static">class.mfct.non.static</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US53">N3092 comment
  US&#160;53<BR></A>

<P>Move semantics for <TT>*this</TT> should not be part of C++0x
unless they have implementation experience.</P>

<P><B>Rationale (March, 2011):</B></P>

<P>The full Committee voted not to remove this feature.</P>

<BR><BR><HR>
<A NAME="819"></A><H4>819.
  
Access control and deleted implicitly-declared special member functions
</H4>
<B>Section: </B>11.4.4&#160; [<A href="https://wg21.link/special">special</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#US50">N2800 comment
  US&#160;50<BR></A>

<P>An implicitly-declared special member function is defined as deleted
(11.4.5 [<A href="https://wg21.link/class.ctor#5">class.ctor</A>] paragraph 5, 11.4.7 [<A href="https://wg21.link/class.dtor#3">class.dtor</A>] paragraph 3,
 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>] paragraphs 5 and 10) if any of
the corresponding functions it would call from base classes is
inaccessible. This is inconsistent with the treatment of access control
in overload resolution and template argument deduction, where
accessibility is ignored (but may result in an ill-formed program).
This should be made consistent.</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The current treatment is sufficiently useful to warrant the inconsistency
with the other handling of access control.  In particular, it enables such
cases to be detected by SFINAE.</P>

<BR><BR><HR>
<A NAME="1427"></A><H4>1427.
  
Default constructor and deleted or inaccessible destructors
</H4>
<B>Section: </B>11.4.5&#160; [<A href="https://wg21.link/class.ctor">class.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-12-08<BR>




<P>The list of causes for a defaulted default constructor to be defined
as deleted, given in 11.4.5 [<A href="https://wg21.link/class.ctor#5">class.ctor</A>] paragraph 5, should have
a case for subobjects of a type with a destructor that is deleted or
inaccessible from the defaulted constructor.</P>

<P><B>Rationale (January, 2012):</B></P>

<P>The supposedly-missing text is actually already present.</P>

<BR><BR><HR>
<A NAME="26"></A><H4>26.
  
Copy constructors and default arguments
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>22 Sep 1997<BR>





<P>The working paper is quite explicit about</P>
<PRE>
    struct X {
         X(X, X const&amp; = X());
    };
</PRE>
being illegal (because of the chicken &amp; egg problem wrt copying.)

<P>Shouldn't it be as explicit about the following?</P>
<PRE>
    struct Y {
        Y(Y const&amp;, Y = Y());
    };
</PRE>
<B>Rationale:</B>
There is no need for additional wording. This example leads to
a program which either fails to compile (due to resource limits on recursive
inlining) or fails to run (due to unterminated recursion). In either case
the implementation may generate an error when the program is compiled.
<BR><BR><HR>
<A NAME="111"></A><H4>111.
  
Copy constructors and cv-qualifiers
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jack Rouse
 &#160;&#160;&#160;

 <B>Date: </B>4 May 1999<BR>





<P>
<U>Jack Rouse:</U>
In 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#8">class.copy.ctor</A>] paragraph 8,

the standard includes
the following about the copying of class subobjects in such a
constructor:</P>
<UL>
<LI>if the subobject is of class type, the copy constructor for
the class is used;</LI>
</UL>

But there can be multiple copy constructors declared by the user with
differing cv-qualifiers on the source parameter.  I would assume
overload resolution would be used in such cases.  If so then the
passage above seems insufficient.

<P>
<B>Mike Miller:</B>
I'm more concerned about
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#7">class.copy.ctor</A>] paragraph 7,

which lists the situations in
which an implicitly-defined copy constructor can render a
program ill-formed.  Inaccessible and ambiguous copy
constructors are listed, but not a copy constructor with a
cv-qualification mismatch.  These two paragraphs taken together
could be read as requiring the calling of a copy constructor
with a non-const reference parameter for a const data member.</P>

<P><B>Proposed Resolution (November, 2006):</B></P>

<P>This issue is resolved by the proposed resolution for
<A HREF="cwg_defects.html#535">issue 535</A>.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>These concerns have been addressed by other changes.</P>

<BR><BR><HR>
<A NAME="356"></A><H4>356.
  
Wording of behavior of generated copy constructor for scalar members
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>25 May 2002<BR>




<P>Section 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#8">class.copy.ctor</A>] paragraph 8 says the
compiler-generated copy constructor copies
scalar elements via the built-in assignment operator.
Seems inconsistent. Why not the built-in initialization?</P>

<P><B>Notes from October 2002 meeting:</B></P>

<P>The Core Working Group believes this should not be changed.  The
standard already mentions <I>built-in operators</I> and the
assignment operator does clearly define what must be done for
scalar types.  There is currently no concept of
<I>built-in initialization</I>.</P>

<BR><BR><HR>
<A NAME="992"></A><H4>992.
  
Inheriting explicitness
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lawrence Crowl
 &#160;&#160;&#160;

 <B>Date: </B>24 October, 2009<BR>


<P>Paper N2987 suggests that an implicitly-declared copy or move
constructor should be explicit if the corresponding constructor of any
of its subobjects is explicit.  During the discussion at the October,
2009 meeting, the CWG deemed this a separable question from the major
emphasis of that paper, and this issue was opened as a placeholder for
that discussion.</P>

<P>See also <A HREF="cwg_defects.html#1051">issue 1051</A>.</P>

<P><B>Rationale (November, 2010):</B></P>

<P>The CWG did not see a correlation between the explicitness of a
base class constructor and that of an implicitly-declared derived
class constructor.</P>

<BR><BR><HR>
<A NAME="1084"></A><H4>1084.
  
Conditions for a deleted move function
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-06-22<BR>




<P>11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#12">class.copy.ctor</A>] paragraph 12 says that a defaulted move
constructor is defined as deleted if the class has a non-static data
member or direct or virtual base class with a type that does not have
a move constructor and is not trivially copyable.  This seems more
strict than is necessary; the subobject need not be trivially copyable,
it should be enough for the selected constructor not to throw.  In any
case, the wording should be phrased in terms of the function selected
by overload resolution rather than properties of the subobject type,
and similarly for move assignment.</P>

<P><B>Rationale (November, 2010):</B></P>

<P>The CWG felt that the current specification was consistent and
not overly problematic; users can add their own move constructor
if needed.</P>

<BR><BR><HR>
<A NAME="1731"></A><H4>1731.
  
<TT>is_trivially_</TT><I>X</I> and definitions of special member functions
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-08-07<BR>




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

<PRE>
  struct A {
    A() = default;
    A(A&amp;) = default;
    A(const A&amp;) = default;
  };
  static_assert(!__is_trivially_copyable(A),"");

  struct B {
    A a;
    B() = default;
    B(const B&amp;) = default;
  };
  static_assert(__is_trivially_copyable(B),"");

  struct C {
    mutable A a;
    C() = default;
    C(const C&amp;) = default;
  };
  static_assert(!__is_trivially_copyable(C),"");
</PRE>

<P>Presumably, all <TT>static_assert()</TT> conditions above are desired to
evaluate <TT>true</TT>. Implementations diverge on this.</P>

<P>To decide whether a class is trivially copyable (Clause 11 [<A href="https://wg21.link/class#6">class</A>] paragraph 6)
, we need to see whether it has a non-trivial copy
constructor. So eventually we hit 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>] paragraph
12:</P>

<BLOCKQUOTE>

<P>A copy/move constructor for class <TT>X</TT> is trivial if it is not
user-provided, its declared parameter type is the same as if it had been
implicitly declared, and if</P>

<UL>
<LI><P>class <TT>X</TT> has no virtual functions
(11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]) and no virtual base classes
(11.7.2 [<A href="https://wg21.link/class.mi">class.mi</A>]), and</P></LI>

<LI><P>the constructor selected to copy/move each direct base class
subobject is trivial, and</P></LI>

<LI><P>for each non-static data member of <TT>X</TT> that is of class type
(or array thereof), the constructor selected to copy/move that member is
trivial;</P></LI>

</UL>

<P>otherwise the copy/move constructor is <I>non-trivial</I>.</P>

</BLOCKQUOTE>

<P>which seem to imply that the copy constructor needs to have been
implicitly defined before we consider this rule. But copy ctors are not
odr-used in this example, so they're not implicitly-defined (paragraph
13).</P>

<P>The same considerations apply to copy/move assignment operators.</P>

<P>It might be sufficient to clarify this specification by replacing
&#8220;selected to&#8221; with &#8220;that would be selected to.&#8221;</P>

<P><B>Rationale (September, 2013):</B></P>

<P>CWG felt that the existing wording was clear enough.</P>

<BR><BR><HR>
<A NAME="1831"></A><H4>1831.
  
Explicitly vs implicitly deleted move constructors
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-01-13<BR>




<P>According to 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#11">class.copy.ctor</A>] paragraph 11,</P>

<BLOCKQUOTE>

A defaulted move constructor that is defined as deleted is
ignored by overload resolution (12.2 [<A href="https://wg21.link/over.match">over.match</A>],
12.3 [<A href="https://wg21.link/over.over">over.over</A>]).  [<I>Note:</I> A deleted move
constructor would otherwise interfere with initialization
from an rvalue which can use the copy constructor
instead. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>Limiting this provision to defaulted move constructors
introduces an unfortunate distinction between implicitly and
explicitly deleted move constructors.  For example, given</P>

<PRE>
  #include &lt;iostream&gt;
  #include &lt;memory&gt;
  using namespace std;

  struct Expl {
    Expl() = default;
    Expl(const Expl &amp;) {
      cout &lt;&lt; " Expl(const Expl &amp;)" &lt;&lt; endl;
   }
   Expl(Expl &amp;&amp;) = delete;
  };

  struct Impl : Expl {
    Impl() = default;
    Impl(const Impl &amp;) {
      cout &lt;&lt; " Impl(const Impl &amp;)" &lt;&lt; endl;
    }
    Impl(Impl &amp;&amp;) = default;
  };

  struct Moveable {
    Moveable() { }
    Moveable(const Moveable &amp;) {
      cout &lt;&lt; " Moveable(const Moveable &amp;)" &lt;&lt; endl;
    }
    Moveable(Moveable &amp;&amp;) {
      cout &lt;&lt; " Moveable(Moveable &amp;&amp;)" &lt;&lt; endl;
    }
  };

  template&lt;typename T&gt; struct Container {
    Moveable moveable[2];
    T t;
  };

  int main() {
    cout &lt;&lt; "Expl:" &lt;&lt; endl;
    Container&lt;Expl&gt; c1(move(Container&lt;Expl&gt;()));
    cout &lt;&lt; "Impl:" &lt;&lt; endl;
    Container&lt;Impl&gt; c2(move(Container&lt;Impl&gt;()));
  }
</PRE>

<P>The output of this program is</P>

<PRE>
  Expl:
   Moveable(const Moveable &amp;)
   Moveable(const Moveable &amp;)
   Expl(const Expl &amp;)
  Impl:
   Moveable(Moveable &amp;&amp;)
   Moveable(Moveable &amp;&amp;)
   Impl(const Impl &amp;)
</PRE>

<P>Should the specification be changed to allow overload resolution
to ignore all deleted move constructors instead of only the defaulted
ones?</P>

<P>From one perspective, at least, the principal reason to delete a
move constructor explicitly is to elicit an error if a move is
attempted, and such a change would violate that intent.  On the
other hand, minimizing the difference between explicit default and
implicit default seems like an important goal.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>The specification is as intended.</P>

<BR><BR><HR>
<A NAME="1928"></A><H4>1928.
  
Triviality of deleted special member functions
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-05-15<BR>




<P>The current wording of the Standard does not make clear whether
a special member function that is defaulted and implicitly deleted is
trivial.  Triviality is visible in various ways that don't involve
invoking the function, such as determining whether a type is
trivially copyable and determining the result of various type traits.
It also factors into some ABI specifications.</P>

<P>(See also <A HREF="cwg_defects.html#1734">issue 1734</A>.)</P>

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

<P>CWG felt that deleted functions should be trivial.  See also
<A HREF="cwg_defects.html#1590">issue 1590</A>.  </P>

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

<P>See paper N4148.</P>

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

<P>Moved from "extension" status to "open" to allow consideration
by CWG.  See the additional discussion in
<A HREF="cwg_defects.html#1734">issue 1734</A> for further details.  See also
<A HREF="cwg_defects.html#1496">issue 1496</A>.</P>

<P><B>Rationale (October, 2015):</B></P>

<P>CWG feels that the triviality of a deleted function should
be irrelevant.  Any cases in which the triviality of a deleted
function is observable should be amended to remove that
dependency.</P>

<BR><BR><HR>
<A NAME="2132"></A><H4>2132.
  
Deprecated default generated copy constructors
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nico Josuttis
 &#160;&#160;&#160;

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




<P>EWG has indicated that they are not currently in favor of
removing the implicitly declared defaulted copy constructors
and assignment operators that are deprecated in
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>] paragraphs 7 and 18.  Should this
deprecation be removed?</P>

<P><B>EWG 2022-11-11</B></P>

<P>EWG expressed no interest to remove the deprecation.</P>

<BR><BR><HR>
<A NAME="444"></A><H4>444.
  
Overriding and the generated copy assignment operator
</H4>
<B>Section: </B>11.4.6&#160; [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Kerch Holt
 &#160;&#160;&#160;

 <B>Date: </B>26 Nov 2003<BR>


<P>EDG (and g++, for that matter) picks the explicit copy assignment
operator, which we think is wrong in this case:</P>
<PRE>
#include &lt;stdio.h&gt;
struct D;   // fwd declaration
struct B {
    D&amp; operator=(D&amp;);
};
struct D : B {
    D() {}
    D(int ii) { s = ii; }
    using B::operator=;
    int s;
};
int main() {
    D od, od1(10);
    od = od1; // implicit D::operator=(D&amp;) called, not BASE::operator=(D&amp;)
}
D&amp; B::operator=(D&amp; d) {
    printf("B::operator called\n");
    return d;
}
</PRE>

<P>If you look at 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#10">class.copy.ctor</A>] paragraph 10 it
explicitly states that
in such a case the "using B::operator=" will not be considered.</P>

<P>
<U>Steve Adamczyk:</U>
The fact that the operator= you declared is (D&amp;) and not (const D&amp;)
is fooling you.  As the standard says, the operator= introduced
by the using-declaration does not suppress the generation of
the implicit operator=.  However, the generated operator= has the
(const D&amp;) signature, so it does not hide B::operator=;
it overloads it.</P>

<P>
<U>Kerch Holt:</U>
I'm not sure this is correct. Going by 12.8 P10 first paragraph
we think that the other form "operator=(D&amp;)" is generated because
the two conditions mentioned were not met in this case.
1) there is no direct base with a "const [volatile] B&amp;" or "B" operator
2) And no member has a operator= either.
This implies the implicit operator is "operator=(D&amp;)".
So, if that is the case the "hiding" should happen.</P>

<P>Also, in the last paragraph it seems to state that operators
brought in from "using", no matter what the parameter is, are
always hidden.</P>

<P>
<U>Steve Adamczyk:</U>
Not really.  I think this section is pretty clear about the fact that
the implicit copy assignment operator is generated.  The question is whether it
hides or overloads the one imported by the using-declaration.</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>(a) Class B does get an implicitly-generated
<TT>operator=(const B&amp;)</TT>; (b) the using-declaration brings in
two <TT>operator=</TT> functions from B, the explicitly-declared
one and the implicitly-generated one; (c) those two functions overload
with the implicitly-generated <TT>operator=(const D&amp;)</TT> in
the derived class, rather than being hidden by the derived-class
function, because it does not match either of their signatures;
(d) overload resolution picks the explicitly-declared
function from the base class because it's the best match in this
case.  We think the standard wording says this clearly enough.</P>
<BR><BR><HR>
<A NAME="574"></A><H4>574.
  
Definition of &#8220;copy assignment operator&#8221;
</H4>
<B>Section: </B>11.4.6&#160; [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>15 April 2006<BR>


<P>Is the following a &#8220;copy assignment operator?&#8221;</P>

<PRE>
    struct A {
        const A&amp; operator=(const A&amp;) volatile;
    };
</PRE>

<P>11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#9">class.copy.ctor</A>] paragraph 9 doesn't say one way or the
other whether cv-qualifiers on the function are allowed.  (A similar
question applies to the <TT>const</TT> case, but I avoided that example
because it seems so wrong one tends to jump to a conclusion before
seeing what the standard says.)</P>

<P>Since the point of the definition of &#8220;copy assignment
operator&#8221; is to control whether the compiler generates a default
version if the user doesn&#8217;t, I suspect the correct answer is
that neither <TT>const</TT> nor <TT>volatile</TT> cv-qualification
on <TT>operator=</TT> should be allowed for a &#8220;copy assignment
operator.&#8221; A user can write an <TT>operator=</TT> like that, but
it doesn't affect whether the compiler generates the default one.</P>

<P><B>Proposed Resolution (November, 2006):</B></P>

<P>Change 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#9">class.copy.ctor</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

A user-declared <I>copy</I> assignment operator <TT>X::operator=</TT>
is a non-static non-template <INS>non-volatile non-const</INS> member
function of class <TT>X</TT> with exactly one parameter of
type <TT>X</TT>, <TT>X&amp;</TT>, <TT>const X&amp;</TT>, <TT>volatile
X&amp;</TT> or <TT>const volatile X&amp;</TT>.

</BLOCKQUOTE>

<P><I>[Drafting note: If a user-declared volatile <TT>operator=</TT>
prevented the implicit declaration of the copy assignment operator,
all assignments for objects of the given class (even to non-volatile
objects) would pay the penalty for volatile write accesses in the
user-declared <TT>operator=</TT>, despite not needing it.]</I></P>

<P><B>Additional note (December, 2008):</B></P>



<P>The proposed resolution addresses only cv-qualified assignment
operators and is silent on ref-qualified versions.  However, it would
seem that the spirit of the resolution would indicate that a ref-qualified
assignment operator would not be considered a copy assignment operator.</P>

<P>There appears to be an emerging idiom that relies on the idea that
providing an lvalue-only assignment operator would prevent assignment
to rvalues:</P>

<PRE>
    struct A {
      A&amp; operator=(const A&amp;) &amp;; // disable assignemt to rvalue
    };
</PRE>

<P>The resolution should also be reconsidered in light of the use of
a const-qualified assignment operator as part of the implementation
of a proxy class, where the proxy object itself is constant and should
not be changed, but the copy assignment operator would apply to the
object to which the proxy object refers.</P>

<P><B>Rationale (March, 2009):</B></P>

<P>It was decided that cv-qualified and ref-qualified assignment
operators should be considered copy assignment operators if they
have the required parameter type.</P>

<BR><BR><HR>
<A NAME="733"></A><H4>733.
  
Reference qualification of copy assignment operators
</H4>
<B>Section: </B>11.4.6&#160; [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alberto Ganesh Barbati
 &#160;&#160;&#160;

 <B>Date: </B>9 October, 2008<BR>




<P>For increased regularity between built-in types and class types,
the copy assignment operator can be qualified with <TT>&amp;</TT>,
preventing assignment to an rvalue.  The LWG is making that change in
the Standard Library.  It would seem a good idea to make a similar
change, where possible, in the specification of implicitly-declared
assignment operators. This would be the case when all subobjects of
class type have a non-deleted copy assignment operator that is
<TT>&amp;</TT>-qualified.</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The LWG decided not to add reference qualifiers in the library,
which reduces the motivation for making this change to implicit
assignment operators.</P>

<P>See also
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">LWG issue 941</A>
and paper
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</A>.</P>

<BR><BR><HR>
<A NAME="1085"></A><H4>1085.
  
Move assignment operators and virtual bases
</H4>
<B>Section: </B>11.4.6&#160; [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-06-22<BR>




<P>In 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#25">class.copy.ctor</A>] paragraph 25, a move assignment operator
is defined as deleted if it has any direct or indirect virtual base class.
This could be relaxed to apply only if a virtual base is derived from
more than once in the DAG.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>CWG felt that there was insufficient motivation to change this
at this time.</P>

<BR><BR><HR>
<A NAME="2415"></A><H4>2415.
  
<I>using-declaration</I>s vs copy assignment operators
</H4>
<B>Section: </B>11.4.6&#160; [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-05-29<BR>


<P>It is not clear whether a <I>using-declaration</I> naming an
assignment operator from a base class can be considered to
declare a copy assignment operator or not. For example:</P>

<PRE>
  struct A;

  struct B {
    constexpr A &amp; operator= (const A &amp;);
  };

  struct A : B {
    using B::operator=;
  } a { a = a };
</PRE>

<P>There is implementation divergence on the treatment of
this code: should the <I>using-declaration</I> suppress or
conflict with the implicit declaration
of <TT>A::operator=</TT>?</P>

<P><B>Rationale (June, 2019):</B></P>

<P>This question is addressed explicitly by 9.10 [<A href="https://wg21.link/namespace.udecl#4">namespace.udecl</A>] paragraph 4:
</P>

<BLOCKQUOTE>

If a constructor or assignment operator brought from a base class into a
derived class has the signature of a copy/move constructor or assignment
operator for the derived class (11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>],
11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]), the <I>using-declaration</I> does not by
itself suppress the implicit declaration of the derived class member; the
member from the base class is hidden or overridden by the
implicitly-declared copy/move constructor or assignment operator of the
derived class, as described below.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1586"></A><H4>1586.
  
Naming a destructor via <TT>decltype</TT>
</H4>
<B>Section: </B>11.4.7&#160; [<A href="https://wg21.link/class.dtor">class.dtor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-11-14<BR>




<P>Use of a <I>decltype-specifier</I> to name a destructor in an
explicit destructor call is explicitly permitted in
11.4.7 [<A href="https://wg21.link/class.dtor#13">class.dtor</A>] paragraph 13.  However, the most
straightforward attempt to do so, e.g.,</P>

<PRE>
  p-&gt;~decltype(*p)()
</PRE>

<P>does not work, because <TT>*p</TT> is an lvalue and thus
<TT>decltype(*p)</TT> is a reference type, not a class type.
Even simply eliminating the reference is not sufficient, because
<TT>p</TT> could be a pointer to a cv-qualified class type.</P>

<P>Either the provision for <I>decltype-specifier</I>s in explicit
destructor calls should be removed or the specification should be
expanded to allow reference and cv-qualified types to be considered as
&#8220;denot[ing] the destructor's class type.&#8221;</P>

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

<P>CWG favored replacing the existing syntax with something more flexible,
for example, <TT>p-&gt;~auto()</TT>. This new syntax would also apply to
pseudo destructors.</P>

<P><B>Rationale (November, 2013):</B></P>

<P>CWG felt that the suggested change should be considered by EWG
before the issue is resolved.</P>

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

<P>EWG has decided not to make a change in this area.  See EWG issue
112.</P>

<BR><BR><HR>
<A NAME="1783"></A><H4>1783.
  
Why are virtual destructors non-trivial?
</H4>
<B>Section: </B>11.4.7&#160; [<A href="https://wg21.link/class.dtor">class.dtor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jeffrey Yasskin
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-26<BR>


<P>According to 11.4.7 [<A href="https://wg21.link/class.dtor#5">class.dtor</A>] paragraph 5,</P>

<BLOCKQUOTE>

<P>A destructor is trivial if it is not user-provided and if:</P>

<UL>
<LI><P>the destructor is not <TT>virtual</TT>,</P></LI>

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

</UL>

</BLOCKQUOTE>

<P>It is not clear why this restriction is needed, and it should be
removed if it is not needed.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>A trivial destructor is known to perform no actions and thus need
not be invoked.  A virtual destructor, however, might be member of a
base class of an unknown derived class; it must therefore be called
virtually in case an overriding virtual function performs some actions.</P>

<BR><BR><HR>
<A NAME="395"></A><H4>395.
  
Conversion operator template syntax
</H4>
<B>Section: </B>11.4.8.3&#160; [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>18 Dec 2002<BR>




<P>A posting in comp.lang.c++.moderated prompted me to
try the following code:</P>
<PRE>
  struct S {
    template&lt;typename T, int N&gt; (&amp;operator T())[N];
  };
</PRE>
<P>The goal is to have a (deducible) conversion operator
template to a reference-to-array type.</P>

<P>This is accepted by several front ends (g++, EDG), but
I now believe that 11.4.8.3 [<A href="https://wg21.link/class.conv.fct#1">class.conv.fct</A>] paragraph 1
actually prohibits this.
The issue here is that we do in fact specify (part of)
a return type.</P>

<P>OTOH, I think it is legitimate to expect that this is
expressible in the language (preferably not using the
syntax above ;-).  Maybe we should extend the syntax
to allow the following alternative?</P>
<PRE>
  struct S {
    template&lt;typename T, int N&gt; operator (T(&amp;)[N])();
  };
</PRE>

<P>
<U>Eric Niebler</U>:
If the syntax is extended to support this, similar constructs should also be
considered.  For instance, I can't for the life of me figure out how to
write a conversion member function template to return a member function
pointer.  It could be useful if you were defining a null_t type.  This is
probably due to my own ignorance, but getting the syntax right is tricky.</P>

<P>Eg.</P>
<PRE>
  struct null_t {
    // null object pointer. works.
    template&lt;typename T&gt; operator T*() const { return 0; }
    // null member pointer. works.
    template&lt;typename T,typename U&gt; operator T U::*() const { return 0; }
    // null member fn ptr.  doesn't work (with Comeau online).  my error?
    template&lt;typename T,typename U&gt; operator T (U::*)()() const { return 0; }
  };
</PRE>

<P>
<U>Martin Sebor</U>:
Intriguing question. I have no idea how to do it in a single
declaration but splitting it up into two steps seems to work:</P>
<PRE>
  struct null_t {
    template &lt;class T, class U&gt;
    struct ptr_mem_fun_t {
      typedef T (U::*type)();
    };

    template &lt;class T, class U&gt;
    operator typename ptr_mem_fun_t&lt;T, U&gt;::type () const {
      return 0;
    }
  };
</PRE>

<P>
<I>Note:</I> In the April 2003 meeting, the core working group
noticed that the above doesn't actually work.</P>

<P><B>Note (June, 2010):</B></P>

<P>It has been suggested  that template aliases effectively
address this issue.  In particular, an identity alias like</P>

<PRE>
    template&lt;typename T&gt; using id = T;
</PRE>

<P>provides the necessary syntactic sugar to be able to specify
types with trailing declarator elements as a <I>conversion-type-id</I>.
For example, the two cases discussed above could be written as:</P>

<PRE>
    struct S {
        template&lt;typename T, int N&gt;
          operator id&lt;T[N]&gt;&amp;();
        template&lt;typename T, typename U&gt;
          operator id&lt;T (U::*)()&gt;() const;
    };
</PRE>

<P>This issue should thus be closed as now NAD.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>As given in the preceding note.</P>

<BR><BR><HR>
<A NAME="315"></A><H4>315.
  
Is call of static member function through null pointer undefined?
</H4>
<B>Section: </B>11.4.9.2&#160; [<A href="https://wg21.link/class.static.mfct">class.static.mfct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>7 Oct 2001<BR>




<P>Another instance to consider is that of invoking a member function from a
null pointer:</P>
<PRE>
  struct A { void f () { } };
  int main ()
  {
    A* ap = 0;
    ap-&gt;f ();
  }
</PRE>
<P>Which is explicitly noted as undefined in 11.4.3 [<A href="https://wg21.link/class.mfct.non.static">class.mfct.non.static</A>],
even though one could argue that since <TT>f()</TT> is empty, there is no
lvalue-&gt;rvalue conversion.</P>

<P>If <TT>f</TT> is static, however, there seems to be no such rule, and
the call is only undefined if the dereference implicit in the <TT>-&gt;</TT>
operator is undefined.  IMO it should be.</P>

<P>Incidentally, another thing that ought to be cleaned up is the inconsistent
use of "indirection" and "dereference".  We should pick one. <I>(This
terminology issue has been broken out as
<A HREF="cwg_defects.html#342">issue 342</A>.)</I>
</P>

<P>This is related to <A HREF="cwg_closed.html#232">issue 232</A>.</P>

<P><B>Rationale (October 2003):</B></P>

<P>We agreed the example should be allowed.  <TT>p-&gt;f()</TT>
is rewritten as <TT>(*p).f()</TT> according to 7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>].
<TT>*p</TT> is not an error when <TT>p</TT> is null unless the
lvalue is converted to an rvalue (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]), which it
isn't here.</P>

<P><B>Additional notes (June, 2024)</B></P>

<P>
<A HREF="cwg_defects.html#2823">Issue 2823</A> represents the current
language rules; the example has undefined behavior.</P>

<BR><BR><HR>
<A NAME="902"></A><H4>902.
  
In-class initialization of non-constant static data members
</H4>
<B>Section: </B>11.4.9.3&#160; [<A href="https://wg21.link/class.static.data">class.static.data</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>21 May, 2009<BR>




<P>The current wording of 11.4.9.3 [<A href="https://wg21.link/class.static.data">class.static.data</A>] only allows a
static data member to be initialized within the class definition if it
is <TT>const</TT>.  This restriction should be removed.</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The consensus of the CWG was that there is insufficient motivation
for such a change.  A non-const static data member must still be
defined outside the class if it is used, and the value of such a
member cannot be used in a constant expression, unlike a constant
static data member, so there is no real advantage to putting the
initializer inside the class definition instead of in the definition
of the static data member.  The apparent parallel with non-static data
member initialization is also not compelling; for example, the
initializer for a non-static data member can contain forward
references to members declared later in the class, while the same is
not true of static data member initializers.</P>

<BR><BR><HR>
<A NAME="1272"></A><H4>1272.
  
Implicit definition of static data member of const literal type
</H4>
<B>Section: </B>11.4.9.3&#160; [<A href="https://wg21.link/class.static.data">class.static.data</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-18<BR>




<P>The Standard requires that a const static data member that is initialized
in the class definition must still be defined in namespace scope if it is
odr-used. This seems unnecessary.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>This is a request for an extension.</P>

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

<P>EWG has decided not to make a change in this area. See EWG issue 100.</P>

<BR><BR><HR>
<A NAME="1987"></A><H4>1987.
  
<TT>constexpr</TT> static data members across translation units
</H4>
<B>Section: </B>11.4.9.3&#160; [<A href="https://wg21.link/class.static.data">class.static.data</A>]
 &#160;&#160;&#160;

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

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

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




<P>Given an example like</P>

<PRE>
  struct X {
    static constexpr const char *p = "foo";
  };
  static const char *q = X::p;
</PRE>

<P>if this appears in more than one translation unit, must the
value of <TT>q</TT> be the same in each?  The implication of
the one-definition rule would be that it must be, but current
implementations do not give that result.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>The interpretation is correct and the implementations are
incorrect.</P>

<BR><BR><HR>
<A NAME="2375"></A><H4>2375.
  
Multiple redeclarations of <TT>constexpr</TT> static data members
</H4>
<B>Section: </B>11.4.9.3&#160; [<A href="https://wg21.link/class.static.data">class.static.data</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2018-02-21<BR>


<P>According to 11.4.9.3 [<A href="https://wg21.link/class.static.data#3">class.static.data</A>] paragraph 3,</P>

<BLOCKQUOTE>

An inline static data member may be defined in the class
definition and may specify
a <I>brace-or-equal-initializer</I>.  If the member is
declared with the <TT>constexpr</TT> specifier, it may be
redeclared in namespace scope with no initializer (this
usage is deprecated; see _N4778_.D.4 [<A href="https://wg21.link/depr.static_constexpr">depr.static_constexpr</A>]).

</BLOCKQUOTE>

<P>The out-of-class declaration of a static data member was
formerly a definition and thus limited to occurring only once.
This limitation was lost when the in-class declaration of inline
static data members became the definition; the current
specification has no apparent prohibition against multiple
out-of-class declarations of a <TT>constexpr</TT> static data
member. Should the restriction be reinstated?</P>

<P><B>Rationale (November, 2018):</B></P>

<P>Current implementations support this usage and it does not
appear to cause any problems.</P>

<BR><BR><HR>
<A NAME="347"></A><H4>347.
  
Use of derived class name in defining base class nested class
</H4>
<B>Section: </B>11.4.12&#160; [<A href="https://wg21.link/class.nest">class.nest</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>21 March 2002<BR>




<P>11.4.2 [<A href="https://wg21.link/class.mfct#5">class.mfct</A>] paragraph 5 says this about member
functions defined lexically outside the class:</P>
<BLOCKQUOTE>
the member function name shall be qualified by its class name using
the :: operator
</BLOCKQUOTE>

<P>11.4.9.3 [<A href="https://wg21.link/class.static.data#2">class.static.data</A>] paragraph 2 says this about static
data members:</P>
<BLOCKQUOTE>
In the definition at namespace scope, the name of the static data
member shall be qualified by its class name using the :: operator
</BLOCKQUOTE>

<P>I would have expected similar wording in 11.4.12 [<A href="https://wg21.link/class.nest#3">class.nest</A>] paragraph 3
for nested classes. Without such wording, the following
seems to be legal (and is allowed by all the compilers I have):</P>
<PRE>
  struct base {
    struct nested;
  };

  struct derived : base {};
  struct derived::nested {};
</PRE>

<P>Is this just an oversight, or is there some rationale for this behavior?</P>

<P><B>Rationale (July, 2008):</B></P>

<P>The wording in Clause 11 [<A href="https://wg21.link/class#10">class</A>] paragraph 10 (added by the
resolution of <A HREF="cwg_defects.html#284">issue 284</A>, which was approved
after this issue was raised) makes the example ill-formed:</P>

<BLOCKQUOTE>

If a <I>class-head</I> contains a <I>nested-name-specifier</I>, the
<I>class-specifier</I> shall refer to a class that was previously
declared directly in the class or namespace to which
the <I>nested-name-specifier</I> refers (i.e., neither inherited nor
introduced by a <I>using-declaration</I>), and
the <I>class-specifier</I> shall appear in a namespace enclosing the
previous declaration.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="359"></A><H4>359.
  
Type definition in anonymous union
</H4>
<B>Section: </B>11.5&#160; [<A href="https://wg21.link/class.union">class.union</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Al Grant
 &#160;&#160;&#160;

 <B>Date: </B>31 May 2002<BR>


<P>Is this legal?  Should it be?</P>
<PRE>
  struct E {
    union {
      struct { int x; } s;
    } v;
  };
</PRE>
<P>One compiler faults a type definition (i.e. of the anonymous
struct) since it is in an anonymous union [11.5 [<A href="https://wg21.link/class.union#2">class.union</A>] paragraph 2:

"The <I>member-specification</I> of an anonymous union shall only define
non-static data members."].</P>

<P>I would suggest that compiler B is correctly interpreting the
standard but that this is a defect in the standard.  There is
no reason to disallow definition of anonymous structs.</P>

<P>Furthermore, is it really necessary to disallow definition of
named types in anonymous unions in general, as long as the
types do not need fully qualified names for external linkage?
Why should this be illegal?</P>
<PRE>
  struct E {
    union {
      typedef int Int;
      struct X { X *next; Int n; } list;
    } v;
  };
</PRE>

<P><B>Notes from October 2002 meeting:</B></P>

<P>There was agreement that the standard says such declarations
are invalid; therefore this must be considered as an extension.
There was general feeling that this extension would not
be too useful, though
Jason Merrill was sympathetic to the argument.  It was also
agreed that if this were to be changed it would require careful
wording so as not to allow too many cases.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group recommended closing this issue with no
further consideration.  See paper J16/07-0033 = WG21 N2173.</P>

<BR><BR><HR>
<A NAME="512"></A><H4>512.
  
Union members with user-declared non-default constructors
</H4>
<B>Section: </B>11.5&#160; [<A href="https://wg21.link/class.union">class.union</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>19 Mar 2005<BR>


<P>Can a member of a union be of a class that has a user-declared
non-default constructor?  The restrictions on union membership in
11.5 [<A href="https://wg21.link/class.union#1">class.union</A>] paragraph 1 only mention default and
copy constructors:</P>

<BLOCKQUOTE>

An object of a class with a non-trivial default constructor
(11.4.5 [<A href="https://wg21.link/class.ctor">class.ctor</A>]), a non-trivial copy constructor
(11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]), a non-trivial destructor (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]), or a non-trivial copy assignment operator
(12.4.3.2 [<A href="https://wg21.link/over.assign">over.assign</A>], 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]) cannot be
a member of a union...

</BLOCKQUOTE>

<P>(11.4.5 [<A href="https://wg21.link/class.ctor#11">class.ctor</A>] paragraph 11 does say,
&#8220;a non-trivial constructor,&#8221; but it's not clear whether
that was intended to refer only to default and copy constructors
or to any user-declared constructor.  For example,
6.8.7 [<A href="https://wg21.link/class.temporary#3">class.temporary</A>] paragraph 3 also speaks of a
&#8220;non-trivial constructor,&#8221; but the cross-references
there make it clear that only default and copy constructors are
in view.)</P>

<P><B>Note (March, 2008):</B></P>

<P>This issue was resolved by the adoption of paper J16/08-0054 =
WG21 N2544 (&#8220;Unrestricted Unions&#8221;) at the Bellevue meeting.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>As given in the preceding note.</P>

<BR><BR><HR>
<A NAME="1714"></A><H4>1714.
  
odr-use of <TT>this</TT> from a local class
</H4>
<B>Section: </B>11.6&#160; [<A href="https://wg21.link/class.local">class.local</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-07-10<BR>


<P>According to 11.6 [<A href="https://wg21.link/class.local#1">class.local</A>] paragraph 1,</P>

<BLOCKQUOTE>

Declarations in a local class shall not odr-use (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>])
a variable with automatic storage duration from an enclosing scope.

</BLOCKQUOTE>

<P>This restriction should apply as well to the <TT>this</TT> pointer
when the class is local to a non-static member function.</P>

<P><B>Rationale (January, 2014):</B></P>

<P>The restrictions in _N4567_.5.1.1 [<A href="https://wg21.link/expr.prim.general">expr.prim.general</A>] limiting the locations
in which <TT>this</TT> may appear already prevent uses of the containing
member function's <TT>this</TT> where the local class's <TT>this</TT>
does not hide it.</P>

<BR><BR><HR>
<A NAME="2119"></A><H4>2119.
  
Disambiguation of multi-level covariant return type
</H4>
<B>Section: </B>11.7.3&#160; [<A href="https://wg21.link/class.virtual">class.virtual</A>]
 &#160;&#160;&#160;

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

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

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


<P>In an example like</P>

<PRE>
  struct W {};
  struct X : W {};
  struct Y : W {};
  struct Z : X, Y {}; //<SPAN CLASS="cmnt"> </SPAN>Z<SPAN CLASS="cmnt"> has two </SPAN>W<SPAN CLASS="cmnt"> subobjects</SPAN>

  struct A {
    virtual W *f();
  };
  struct B : A {
    virtual X *f();
  };
  struct C : B {
    virtual Z *f();   //<SPAN CLASS="cmnt"> </SPAN>C::f<SPAN CLASS="cmnt"> overrides </SPAN>A::f<SPAN CLASS="cmnt"> and </SPAN>B::f
  };
</PRE>

<P>it is not clear whether the return type of <TT>C::f()</TT>
satisfies the requirement of 11.7.3 [<A href="https://wg21.link/class.virtual#7.2">class.virtual</A>] bullet 7.2
that the return type in the base class of the function be an
unambiguous base of the return type in the derived class.  Should
the conversion from <TT>Z*</TT> to <TT>X*</TT> in overriding
<TT>B::f()</TT> be considered to disambiguate the conversion from
<TT>Z*</TT> to <TT>W*</TT> in overriding <TT>A::f()</TT>?  There
is implementation divergence on this question.</P>

<P><B>Rationale (May, 2015):</B></P>

<P>CWG determined that the current wording of the Standard is
correct: <TT>C::f()</TT> overrides both <TT>B::f()</TT> and
<TT>A::f()</TT>, and the latter overriding is ill-formed because
of the ambiguity.</P>

<BR><BR><HR>
<A NAME="230"></A><H4>230.
  
Calls to pure virtual functions
</H4>
<B>Section: </B>11.7.4&#160; [<A href="https://wg21.link/class.abstract">class.abstract</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim Hill
 &#160;&#160;&#160;

 <B>Date: </B>4 May 2000<BR>


<P>According to 11.7.4 [<A href="https://wg21.link/class.abstract#6">class.abstract</A>] paragraph 6,</P>

<BLOCKQUOTE>

Member functions can be called from a constructor (or destructor) of
an abstract class; the effect of making a virtual call (11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]) to a pure virtual function directly or indirectly for
the object being created (or destroyed) from such a constructor (or
destructor) is undefined.

</BLOCKQUOTE>

<P>This prohibition is unnecessarily restrictive.  It should not apply
to cases in which the pure virtual function has been defined.</P>

<P>Currently the "pure" specifier for a virtual member function has
two meanings that need not be related:</P>

<OL>

<LI>A pure virtual function need not be defined.</LI>

<LI>A pure virtual function must be overridden in any concrete derived
class.</LI>

</OL>

<P>The prohibition of virtual calls to pure virtual functions arises
from the first meaning and unnecessarily penalizes those who only need
the second.</P>

<P>For example, consider a scenario such as the following.  A class
<TT>B</TT> is defined containing a (non-pure) virtual function
<TT>f</TT> that provides some initialization and is thus called from
the base class constructor.  As time passes, a number of classes are
derived from <TT>B</TT> and it is noticed that each needs to override
<TT>f</TT>, so it is decided to make <TT>B::f</TT> pure to enforce
this convention while still leaving the original definition of
<TT>B::f</TT> to perform its needed initialization.  However, the act
of making <TT>B::f</TT> pure means that every reference to <TT>f</TT>
that might occur during the execution of one of <TT>B</TT>'s
constructors must be tracked down and edited to be a qualified
reference to <TT>B::f</TT>.  This process is tedious and error-prone:
needed edits might be overlooked, and calls that actually should be
virtual when the containing function is called other than during
construction/destruction might be incorrectly changed.</P>

<P>
<B>Suggested resolution:</B> Allow virtual calls to pure virtual
functions if the function has been defined.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>In light of the nontrivial implementation issues such a change
would raise, as well as the fact that this restriction has been
accepted into the C++ design lexicon for many years, CWG decided not
to make a change at this point.  Further consideration, if any,
should occur within EWG.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>EWG determined that no action should be taken on this issue.</P>

<BR><BR><HR>
<A NAME="1420"></A><H4>1420.
  
Abstract final classes
</H4>
<B>Section: </B>11.7.4&#160; [<A href="https://wg21.link/class.abstract">class.abstract</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-11-30<BR>


<P>An abstract class is permitted to be a final class.  Such classes
are very nearly useless and should probably be made ill-formed.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>Such classes could be used for static members and for access
control.  CWG saw no need to prohibit them.</P>

<BR><BR><HR>
<A NAME="7"></A><H4>7.
  
Can a class with a private virtual base class be derived from?
</H4>
<B>Section: </B>11.8.3&#160; [<A href="https://wg21.link/class.access.base">class.access.base</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>unknown<BR>





<PRE>
    class Foo { public: Foo() {}  ~Foo() {} };
    class A : virtual private Foo { public: A() {}  ~A() {} };
    class Bar : public A { public: Bar() {}  ~Bar() {} };
</PRE>
<TT>~Bar()</TT> calls <TT>~Foo()</TT>, which is ill-formed due to access
violation, right? (<TT>Bar</TT>'s constructor has the same problem since it
needs to call <TT>Foo</TT>'s constructor.) There seems to be some disagreement
among compilers. Sun, IBM and g++ reject the testcase, EDG and HP
accept it. Perhaps this case should be clarified by a note in the
draft.

<P>In short, it looks like a class with a virtual private base can't be
derived from.</P>

<P>
<B>Rationale:</B> This is what was intended.</P>
<BR><BR><HR>
<A NAME="17"></A><H4>17.
  
Footnote 99 should discuss the naming class when describing members that can be accessed from friends
</H4>
<B>Section: </B>11.8.3&#160; [<A href="https://wg21.link/class.access.base">class.access.base</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>unknown<BR>





<P>Footnote 98 says:</P>
<BLOCKQUOTE>As specified previously in 11.8 [<A href="https://wg21.link/class.access">class.access</A>]
, private members
of a base class remain inaccessible even to derived classes unless friend
declarations within the base class declaration are used to grant access
explicitly.</BLOCKQUOTE>
This footnote does not fit with the algorithm provided in
11.8.3 [<A href="https://wg21.link/class.access.base#4">class.access.base</A>] paragraph 4
because
it does not take into account the naming class concept introduced in this
paragraph.

<P>(See also paper J16/99-0002 = WG21 N1179.)</P>

<P>
<B>Rationale (10/99):</B> The footnote should be read as referring
to immediately-derived classes, and is accurate in that context.</P>
<BR><BR><HR>
<A NAME="471"></A><H4>471.
  
Conflicting inherited access specifications
</H4>
<B>Section: </B>11.8.3&#160; [<A href="https://wg21.link/class.access.base">class.access.base</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>14 Jun 2004<BR>


<P>The Standard does not appear to specify how to handle cases in
which conflicting access specifications for a member are
inherited from different base classes.  For example,</P>

<PRE>
    struct A {
    public:
      int i;
    };
    struct B : virtual public A {
    protected:
      using A::i;
    };
    struct C : virtual public A, public B {
      // "i" is protected from B, public from A
    };
</PRE>

<P>This question affects both the existing wording of
11.8.3 [<A href="https://wg21.link/class.access.base#4">class.access.base</A>] paragraph 4 (&#8220;<I>m</I> as a
member of <I>N</I> is public ... <I>m</I> as a member of <I>N</I>
is private ... <I>m</I> as a member of <I>N</I> is
protected&#8221;) and the proposed wording for <A HREF="cwg_defects.html#385">issue 385</A> (&#8220;when a nonstatic data member or
nonstatic member function is a protected member of its naming
class&#8221;).</P>

<P>One possible definition of &#8220;is public&#8221; would be
something like, &#8220;if any visible declaration of the entity
has public access.&#8221; One could also plausibly define the
access of <TT>m</TT> in <TT>N</TT> to be the minimum of all the
visible declarations, or even an error if the visible
declarations are inconsistent.</P>

<P>11.8.3 [<A href="https://wg21.link/class.access.base#1">class.access.base</A>] paragraph 1 describes the access of
inherited members, so a clarifying statement resolving this issue
might plausibly be inserted at the end of that paragraph.</P>

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

<P>Add the following text as a new paragraph after 11.8.3 [<A href="https://wg21.link/class.access.base#1">class.access.base</A>] paragraph 1:</P>

<BLOCKQUOTE>

<P>If a given base class can be reached along more than one path
through a derived class's sub-object lattice (11.7.2 [<A href="https://wg21.link/class.mi">class.mi</A>]), a member of that base class could have different
accessibility in the derived class along different paths.  In
such cases, the most permissive access
prevails. [<I>Example:</I>
</P>

<PRE>
    struct B { static int i; };
    class I: protected B { };
    class D1: public B, public I { };
    class D2: public I, private B { };
</PRE>

<P>
<TT>i</TT> is accessible as a public member of <TT>D1</TT> and
as a protected member of <TT>D2</TT>. &#8212;<I>end
example</I>]</P>

</BLOCKQUOTE>

<P>
<B>Rationale (03/2005):</B> This question is already covered, in
almost identical words, in 11.8.7 [<A href="https://wg21.link/class.paths">class.paths</A>].
</P>

<BR><BR><HR>
<A NAME="2030"></A><H4>2030.
  
Access of injected-class-name with template arguments
</H4>
<B>Section: </B>11.8.3&#160; [<A href="https://wg21.link/class.access.base">class.access.base</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-10-27<BR>


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

<PRE>
  template &lt;typename T&gt; struct S1 { };
  struct S2 : private S1&lt;int&gt; { };
  struct S3 : S2 {
    void f() {
      S1&lt;int&gt; s1;   //<SPAN CLASS="cmnt"> #1</SPAN>
    }
  };
</PRE>

<P>The reference in #1 to <TT>S1</TT> finds the
injected-class-name of <TT>S1&lt;int&gt;</TT>, which is private
in <TT>S2</TT> and thus inaccessible in <TT>S3</TT>.  However,
there is implementation divergence on the treatment of this
reference, with many accepting the declaration without error,
presumably because of the use of the name in a
<I>template-id</I>.  Should the Standard give special treatment
to this usage?</P>

<P><B>Rationale (November, 2014):</B></P>

<P>The specification is as intended, and the example is ill-formed.</P>

<BR><BR><HR>
<A NAME="209"></A><H4>209.
  Must friend declaration names be
accessible?</H4>
<B>Section: </B>11.8.4&#160; [<A href="https://wg21.link/class.friend">class.friend</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Judy Ward
 &#160;&#160;&#160;

 <B>Date: </B>1 Mar 2000<BR>



<P>
11.8.4 [<A href="https://wg21.link/class.friend">class.friend</A>], paragraph 7, says

<BLOCKQUOTE>

A name nominated by a friend declaration shall be accessible in the
scope of the class containing the friend declaration.

</BLOCKQUOTE>
</P>
<P>
Does that mean the following should be illegal?
</P>

<PRE>
    class A { void f(); };
    class B { friend void A::f(); }; // Error: A::f not accessible from B
</PRE>

<P>
I discussed this with Bjarne in email, and he thinks it was an
editorial error and this was not the committee's intention. The
paragraph seems to have been added in the pre-Kona (24 Sept 1996)
mailing, and I could not find anything in the previous meeting's
(Stockholm) mailings which led me to believe this was intentional. The
only compiler vendor which I think currently implements it is the
latest release (2.43) of the EDG front end.
</P>

<P>
<B>Proposed resolution (10/00):</B>
</P>
<P>
Remove the first sentence of 11.8.4 [<A href="https://wg21.link/class.friend">class.friend</A>], paragraph 7.
</P>

<P><B>Rationale (04/01):</B></P>

<P>After the 10/00 vote to accept this issue as a DR with the
proposed resolution, it was noted that the first two sentences
of 11.8 [<A href="https://wg21.link/class.access#3">class.access</A>] paragraph 3 cause the proposed change
to have no effect:</P>

<BLOCKQUOTE>

Access control is applied uniformly to all names, whether the names
are referred to from declarations or expressions. [<I>Note:</I> access
control applies to names nominated by <TT>friend</TT> declarations
(11.8.4 [<A href="https://wg21.link/class.friend">class.friend</A>]) and <I>using-declaration</I>s
(9.10 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]). ]

</BLOCKQUOTE>

<P>In addition to the obvious editing to the text of the note,
an exception to the blanket statement in the first sentence
would also be required.  However, discussion during the 04/01
meeting failed to produce consensus on exactly <I>which</I> names
in the <TT>friend</TT> declaration should be exempted from the
requirements of access control.</P>

<P>One possibility would be that only the name nominated as
<TT>friend</TT> should be exempt.  However, that approach
would make it impossible to name a function as a friend if it
used private types in its parameters or return type.  Another
suggestion was to ignore access for every name used in a
<TT>friend</TT> declaration.  That approach raised a question
about access within the body of a <TT>friend</TT> function
defined inline in the class body &#8212; the body is part of
the declaration of a function, but references within the body
of a <TT>friend</TT> function should still be subject to the
usual access controls.</P>

<P>Other possibilities were raised, such as allowing the
declaration of a <TT>friend</TT> member function if the
declaration were permissible in its containing class, or
taking the union of the access within the befriending class
and the befriended entity.  However, these suggestions would
have been complex and difficult to specify correctly.</P>

<P>Ultimately it was decided that the original perceived
defect was not sufficiently serious as to warrant the degree
of complexity required to resolve it satisfactorily and the
issue was consequently declared not to be a defect.  It was
observed that most of the problems involved with the current
state of affairs result from inability to declare a
particular member function as a <TT>friend</TT>; in such cases,
an easy workaround is simply to befriend the entire class
rather than the specific member function.</P>

<BR><BR><HR>
<A NAME="445"></A><H4>445.
  
Wording issue on friend declarations
</H4>
<B>Section: </B>11.8.4&#160; [<A href="https://wg21.link/class.friend">class.friend</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Risto Lankinen
 &#160;&#160;&#160;

 <B>Date: </B>5 Dec 2003<BR>


<P>
Thus says the section
11.8.4 [<A href="https://wg21.link/class.friend">class.friend</A>]/7 in ISO 14882 C++ standard:</P>
<BLOCKQUOTE>
A name nominated by a friend declaration shall be accessible
<U>in the scope of the class</U> containing the friend declaration.
</BLOCKQUOTE>

<P>The obvious intention of this is to allow a friend declaration to
specify a function (or nested class, enum, etc.) that is declared
"private" or "protected" in its enclosing class.  However, literal
interpretation seems to allow a broader access to the befriended
function by the whole class that is declaring the friendship.</P>

<P>If the rule were interpreted literally as it is currently written, this
would compile (when it, of course, shouldn't be allowed at all):</P>
<PRE>
class C
{
private:
  static void f();
};

class D
{
  friend void C::f();  // A name nominated by friend declaration...

  D()
  {
   C::f();  // ... shall be accessible in scope of class declaring friendship
  }
};
</PRE>

<P>Suggested fix is to reword "in the scope of the class containing
the friend declaration" to exclude all other references from the
scope of the declaring class, except the friend-declaration itself.</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>We considered this and concluded that the standard is clear enough.</P>

<BR><BR><HR>
<A NAME="501"></A><H4>501.
  
Visibility of friend declarations within the befriending class
</H4>
<B>Section: </B>11.8.4&#160; [<A href="https://wg21.link/class.friend">class.friend</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>25 Jan 2005<BR>




<P>I just received a query from a user of why line #1 in the following
snippet is ill-formed:</P>

<PRE>
    void g(int (*)(int));

    template&lt;class T&gt;
    class A {
       friend int f(int) { return 0; }

       void h() {
           g(f);          // #1
       }
    };
</PRE>

<P>I believe that the special invisibility rule about friends is too
complicated and makes life too complicated, especially considering
that friends in templates are not templates, nor can they be
conveniently rewritten with a &#8220;first declare at the namespace
scope&#8221; rule.  I can understand the rules when they make
programming easier or prevent some obvious &#8220;silly&#8221;
mistakes; but that does not seem to be the case here.
</P>

<P>
<U>John Spicer</U>: See two papers that discuss this issue: N0878
by Bill Gibbons, which ultimately gave rise to our current rules, and
N0913 by me as an alternative to N0878.</P>

<P><B>Rationale (April, 2005):</B></P>

<P>The Standard is clear and consistent; this rule is the result of an
explicit decision by the Committee.</P>

<BR><BR><HR>
<A NAME="585"></A><H4>585.
  
Friend template template parameters
</H4>
<B>Section: </B>11.8.4&#160; [<A href="https://wg21.link/class.friend">class.friend</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>15 June 2006<BR>




<P>After the adoption of the wording for extended friend declarations,
we now have this new paragraph in 11.8.4 [<A href="https://wg21.link/class.friend">class.friend</A>]:</P>

<BLOCKQUOTE>

<P>A <TT>friend</TT> declaration that does not declare a function shall
have one of the following forms:</P>

<UL>
<TT>friend</TT> <I>elaborated-type-specifier</I> <TT>;</TT><BR>
<TT>friend</TT> <I>simple-type-specifier</I> <TT>;</TT><BR>
<TT>friend</TT> <I>typename-specifier</I> <TT>;</TT><BR>
</UL>

</BLOCKQUOTE>

<P>But what about friend class templates?  Should the following examples
compile in C++0x?</P>

<PRE>
    template&lt; template &lt;class&gt; class T &gt;
         struct A{ friend T; };

    template&lt; class &gt; struct C;
    struct B{ friend C; };
</PRE>

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

<P>Change 11.8.4 [<A href="https://wg21.link/class.friend#3">class.friend</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P>A <TT>friend</TT> declaration that does not declare a function shall have
one of the following forms:</P>

<UL>

<P>
<TT>friend</TT> <I>elaborated-type-specifier</I> <TT>;</TT>
</P>

<P>
<TT>friend</TT> <I>simple-type-specifier</I> <TT>;</TT>
</P>

<P>
<TT>friend</TT> <I>typename-specifier</I> <TT>;</TT>
</P>

<P><INS><TT>friend</TT> <TT>::</TT><I><SUB>opt</SUB> nested-name-specifier<SUB>opt</SUB> template-name</I> <TT>;</TT></INS></P>

<P><INS><TT>friend</TT> <I>identifier</I> <TT>;</TT></INS></P>

</UL>

<P>
<INS>In the last alternative, the <I>identifier</I> shall name a template
<I>template-parameter</I>.</INS> [<I>Note:</I> a <TT>friend</TT>
declaration may be the <I>declaration</I> in a
<I>template-declaration</I> (Clause 13 [<A href="https://wg21.link/temp">temp</A>],
13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]). &#8212;<I>end note</I>] If the <DEL>type
specifier in a</DEL> <TT>friend</TT> declaration designates a (possibly
cv-qualified) class type <INS>or a class template</INS>, that class <INS>or
template</INS> is declared as a friend; otherwise, the <TT>friend</TT>
declaration is ignored. [Example:...</P>

</BLOCKQUOTE>

<P><B>Rationale (September, 2008):</B></P>

<P>The proposed extension is not needed.  The template case can be
handled simply by providing a template header:</P>

<PRE>
    template &lt;typename T&gt; friend class X&lt;T&gt;;
</PRE>

<BR><BR><HR>
<A NAME="718"></A><H4>718.
  
Non-class, non-function friend declarations
</H4>
<B>Section: </B>11.8.4&#160; [<A href="https://wg21.link/class.friend">class.friend</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>18 September, 2008
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>With the change from a scope-based to an entity-based definition
of friendship (see issues <A HREF="cwg_defects.html#372">372</A> and
<A HREF="cwg_defects.html#580">580</A>), it could well make sense to
grant friendship to enumerations and variables, for example:</P>

<PRE>
    enum E: int;
    class C {
      static const int i = 5;  //<SPAN CLASS="cmnt"> Private</SPAN>
      friend E;
      friend int x;
    };
    enum E { e = C::i; };      //<SPAN CLASS="cmnt"> OK: </SPAN>E<SPAN CLASS="cmnt"> is a friend</SPAN>
    int x = C::i;              //<SPAN CLASS="cmnt"> OK: </SPAN>x<SPAN CLASS="cmnt"> is a friend</SPAN>
</PRE>

<P>According to the current wording of 11.8.4 [<A href="https://wg21.link/class.friend#3">class.friend</A>] paragraph 3,
 the friend declaration of <TT>E</TT> is well-formed
but ignored, while the friend declaration of <TT>x</TT> is
ill-formed.</P>

<P><B>Additional notes (February, 2023)</B></P>

<P>Forwarding to EWG for review of this extension, per decision of the
CWG chair. 

See <A HREF="https://github.com/cplusplus/papers/issues/1466">cplusplus/papers#1466</A>.</P>

<P><B>EWG 2023-05-11</B></P>

<P>This is an extension that needs a well-motivated paper to EWG.</P>

<BR><BR><HR>
<A NAME="1833"></A><H4>1833.
  
<TT>friend</TT> declarations naming implicitly-declared member functions
</H4>
<B>Section: </B>11.8.4&#160; [<A href="https://wg21.link/class.friend">class.friend</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-01-13<BR>


<P>It appears that naming an implicitly-declared member function in
a friend declaration requires the full set of decorations to be
specified.  For example,</P>

<PRE>
  struct A { };
  struct B { friend constexpr A::A() noexcept; };
</PRE>

<P>There is implementation variation regarding the enforcement of this
requirement, however.  Should the Standard provide default treatment
for such cases, allowing the simpler</P>

<PRE>
    friend A::A();
</PRE>

<P>?</P>

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

<P>EWG has decided not to make a change in this area.</P>

<BR><BR><HR>
<A NAME="2363"></A><H4>2363.
  
Opaque enumeration friend declarations
</H4>
<B>Section: </B>11.8.4&#160; [<A href="https://wg21.link/class.friend">class.friend</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2017-10-26<BR>


<P>According to 11.8.4 [<A href="https://wg21.link/class.friend#3">class.friend</A>] paragraph 3,</P>

<BLOCKQUOTE>

<P>A friend declaration that does not declare a function shall have one of
the following forms:</P>

<UL>
<TT>friend</TT> <I>elaborated-type-specifier</I> <TT>;</TT><BR>
<TT>friend</TT> <I>simple-type-specifier</I> <TT>;</TT><BR>
<TT>friend</TT> <I>typename-specifier</I> <TT>;</TT>
</UL>

</BLOCKQUOTE>

<P>However, many implementations accept</P>

<PRE>
  friend enum E;
</PRE>

<P>even though that form is explicitly not allowed by
9.2.9.5 [<A href="https://wg21.link/dcl.type.elab#1">dcl.type.elab</A>] paragraph 1 (which only permits
<I>class-key</I> and not <I>enum-key</I> in <TT>friend</TT> declarations).
Some implementations also accept opaque enumeration declarations like</P>

<PRE>
  friend enum E : int;
</PRE>

<P>The latter form could plausibly be used in an example like:</P>

<PRE>
  class C {
    constexpr static int priv = 15;
    friend enum class my_constants;
  };
  enum class my_constants {
    pub = C::priv;                //<SPAN CLASS="cmnt"> OK because of friend decl</SPAN>
  };
</PRE>

<P>(See also <A HREF="cwg_active.html#2131">issue 2131</A>.)</P>

<P><B>Notes from the October, 2018 teleconference:</B></P>

<P>The suggested plausible use for the feature would require
additional wording, because the effect of friendship is currently
only described for classes and functions, not for enumerations.
There does not appear to be a demand for the change.</P>

<BR><BR><HR>
<A NAME="19"></A><H4>19.
  
Clarify protected member access
</H4>
<B>Section: </B>11.8.5&#160; [<A href="https://wg21.link/class.protected">class.protected</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>unknown<BR>





<P>11.8.5 [<A href="https://wg21.link/class.protected#1">class.protected</A>] paragraph 1
says:
<BLOCKQUOTE>When a friend or a member function of a derived class references
a protected nonstatic member of a base class, an access check applies in
addition to ...</BLOCKQUOTE>
Instead of saying "references a protected nonstatic member of a base class",
shouldn't this be rewritten to use the concept of naming class as
11.8.3 [<A href="https://wg21.link/class.access.base">class.access.base</A>]

paragraph 4 does?</P>

<P>
<B>Rationale (04/99):</B> This rule is orthogonal to the specification
in 11.8.3 [<A href="https://wg21.link/class.access.base#4">class.access.base</A>] paragraph 4.
</P>
<BR><BR><HR>
<A NAME="1007"></A><H4>1007.
  
Protected access and pointers to members
</H4>
<B>Section: </B>11.8.5&#160; [<A href="https://wg21.link/class.protected">class.protected</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2009-11-24<BR>




<P>The restrictions on protected access in 11.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>]
apply only to forming pointers to members and to member access
expressions.  It should be considered whether to extend these
restrictions to pointer-to-member expressions as well.  For example,</P>

<PRE>
   struct base {
       protected: int x;
   };

   struct derived : base {
       void foo(base* b) {
          b-&gt;x = 123; // not ok
          (b-&gt;*(&amp;derived::x)) = 123; // ok?!
       }
   };
</PRE>

<P><B>Rationale (August, 2010):</B></P>

<P>Access applies to use of names, so the check must be done at the
point at which the pointer-to-member is formed.  It is not possible
to tell from the pointer to member at runtime what the access was.</P>

<BR><BR><HR>
<A NAME="363"></A><H4>363.
  
Initialization of class from self
</H4>
<B>Section: </B>11.9.2&#160; [<A href="https://wg21.link/class.expl.init">class.expl.init</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Sergey P. Derevyago
 &#160;&#160;&#160;

 <B>Date: </B>11 July 2002<BR>


<P>Is the following code well-formed?</P>
<PRE>
 struct A { /* */ };

 int main()
 {
  A a=a;
 }
</PRE>
<P>Note, that { int a=a; } is pretty legal.</P>

<P>And if so, what is the semantics of the self-initialization of UDT? For
example</P>
<PRE>
 #include &lt;stdio.h&gt;

 struct A {
        A()           { printf("A::A() %p\n",            this);     }
        A(const A&amp; a) { printf("A::A(const A&amp;) %p %p\n", this, &amp;a); }
        ~A()          { printf("A::~A() %p\n",           this);     }
 };

 int main()
 {
  A a=a;
 }
</PRE>
<P>can be compiled and prints:</P>
<PRE>
A::A(const A&amp;) 0253FDD8 0253FDD8
A::~A() 0253FDD8
</PRE>
<P>(on some implementations).</P>

<P><B>Notes from October 2002 meeting:</B></P>

<P>6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 indicates that the
references here are valid.  It's permitted to take the address
of a class object before it is fully initialized, and it's
permitted to pass it as an argument to a reference parameter
as long as the reference can bind directly.
Except for the failure to cast the pointers
to <TT>void *</TT> for the <TT>%p</TT> in the <TT>printf</TT>s,
these examples are standard-conforming.</P>

<BR><BR><HR>
<A NAME="1641"></A><H4>1641.
  
Assignment in member initializer
</H4>
<B>Section: </B>11.9.3&#160; [<A href="https://wg21.link/class.base.init">class.base.init</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-15<BR>


<P>There appears to be no prohibition of assignments in member
initializer expressions (neither <I>mem-initializer</I>s nor
<I>brace-or-equal-initializer</I>s):</P>

<PRE>
  struct A {
    int x;
    int y = x = 37;
  };
</PRE>

<P>This seems surprising.  Should it be allowed?</P>

<P><B>Rationale (April, 2013):</B></P>

<P>CWG saw no problems with the example.  It did note, however, that
the assignment to <TT>x</TT> is not an initialization, so <TT>x</TT>
would not be considered to have been initialized by this example.</P>

<BR><BR><HR>
<A NAME="2135"></A><H4>2135.
  
<I>mem-initializer</I>s for virtual bases of abstract classes
</H4>
<B>Section: </B>11.9.3&#160; [<A href="https://wg21.link/class.base.init">class.base.init</A>]
 &#160;&#160;&#160;

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

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

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




<P>According to 11.9.3 [<A href="https://wg21.link/class.base.init#7">class.base.init</A>] paragraph 7,</P>

<BLOCKQUOTE>

A <I>mem-initializer</I> where the <I>mem-initializer-id</I>
denotes a virtual base class is ignored during execution of
a constructor of any class that is not the most derived
class.

</BLOCKQUOTE>

<P>Presumably &#8220;ignored&#8221; here means that there
will be no runtime effect but that semantic restrictions
such as access checking and the ODR must still be applied,
but this is not completely clear.</P>

<P><B>Rationale (October, 2015):</B></P>

<P>The fact that &#8220;ignored&#8221; applies only to
runtime effects is indicated by the phrase &#8220;during
execution&#8221; in the existing wording.  This seems clear
enough.</P>

<BR><BR><HR>
<A NAME="2204"></A><H4>2204.
  
Naming delegated constructors
</H4>
<B>Section: </B>11.9.3&#160; [<A href="https://wg21.link/class.base.init">class.base.init</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-11-25<BR>




<P>11.9.3 [<A href="https://wg21.link/class.base.init#3">class.base.init</A>] paragraph 3 singles out base classes when
indicating the allowance of typedefs, etc. for the naming of types in
a <I>mem-initializer-list</I>. It appears that the omission of the
class of the constructor is unintentional.</P>

<P>
<B>Rationale (November, 2016):</B>

<P>There was no actual issue; the question was based on a misunderstanding
of the current specification.</P>
</P>

<BR><BR><HR>
<A NAME="307"></A><H4>307.
  
Initialization of a virtual base class subobject
</H4>
<B>Section: </B>11.9.5&#160; [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>31 Aug 2001<BR>


<P>The second paragraph of section 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>] contains the
following text:</P>
<BLOCKQUOTE>
To explicitly or implicitly convert a pointer (an
lvalue) referring to an object of class X to a pointer (reference) to
a direct or indirect base class B of X, the construction of X and the
construction of all of its direct or indirect bases that directly or
indirectly derive from B shall have started and the destruction of
these classes shall not have completed, otherwise the conversion
results in undefined behavior.
</BLOCKQUOTE>

<P>Now suppose we have the following piece of code:</P>
<PRE>
    struct  a  {
       a() :  m_a_data(0)  {   }
       a(const a&amp; rhsa) :  m_a_data(rhsa.m_a_data)  {   }
       int   m_a_data;
    };

    struct  b :  virtual a  {
       b() :  m_b_data(0)  {   }
       b(const b&amp; rhsb) :  a(rhsb),  m_b_data(rhsb.m_b_data)  {   }
       int   m_b_data;
    };

    struct  c :  b  {
       c() :  m_c_data(0)  {   }
       c(const c&amp; rhsc) :  a(rhsc),// Undefined behaviour when constru-
                                   // cting an object of type 'c'
                           b(rhsc),  m_c_data(rhsc.m_c_data)  {   }
       int   m_c_data;
    };

    int  main()
    {   c   ac1,   ac2(ac1);   }
</PRE>
<P> The problem with the above snippet is that when the value '<TT>ac2</TT>' is
being created and its construction gets started, <TT>c</TT>'s copy constructor
has first to initialize the virtual base class subobject '<TT>a</TT>'. Which
requires that the lvalue expression '<TT>rhsc</TT>' be converted to the type of
the parameter of <TT>a</TT>'s copy constructor,
which is 'const a&amp;'. According
to the wording quoted above, this can be done without undefined
behaviour if and only if <TT>b</TT>'s construction has already started, which
is not possible since '<TT>a</TT>', being a virtual base class, has to be
initialized first by a constructor of the most derived object
(11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).</P>

<P>The issue could in some cases be alleviated when '<TT>c</TT>' has a
user-defined copy constuctor. The constructor could default-initialize
its '<TT>a</TT>' subobject and then initialize <TT>a</TT>'s members
as needed taking
advantage of the latitude given in paragraph 2 of
11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>].</P>

<P>But if '<TT>c</TT>' ends up having the implicitly-defined copy constuctor,
there's no way to evade undefined behaviour.</P>
<PRE>
    struct  c :  b  {
       c() :  m_c_data(0)  {   }
       int   m_c_data;
    };

    int  main()
    {   c   ac1,   ac2(ac1);   }
</PRE>
<P>Paragraph 8 of 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>] states</P>
<BLOCKQUOTE>
The
implicitly-defined copy constructor for class X performs a memberwise
copy of its subobjects. The order of copying is the same as the order
of initialization of bases and members in a user-defined constructor
(see 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).
Each subobject is copied in the manner appropriate to
its type:
<UL>
<LI>
if the subobject is of class type, the copy constructor for the
class is used;
</LI>
</UL>
</BLOCKQUOTE>
<P>Which effectively means that the implicitly-defined copy constructor
for '<TT>c</TT>' will have to initialize its '<TT>a</TT>'
base class subobject first and
that must be done with <TT>a</TT>'s copy constructor, which will always require
a conversion of an lvalue expression of type '<TT>const c</TT>' to an lvalue of
type '<TT>const a&amp;</TT>'. The situation would be the same if all the three
classes shown had implicitly-defined copy constructors.</P>

<P><B>Suggested resolution:</B></P>
<P>Prepend to paragraph 2 of 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>] the following:
<BLOCKQUOTE>
Unless the conversion happens in a mem-initializer whose
mem-initializer-id designates a virtual base class of X, to explicitly
or implicitly convert ...
</BLOCKQUOTE>
</P>

<P><B>Notes from the 10/01 meeting:</B></P>

<P>There is no problem in this example.  <TT>ac1</TT> is fully initialized
before it is used in the initialization of <TT>ac2</TT>.</P>

<BR><BR><HR>
<A NAME="6"></A><H4>6.
  
Should the optimization that allows a class object to alias another object also allow the case of a parameter in an inline function to alias its argument?
</H4>
<B>Section: </B>11.9.6&#160; [<A href="https://wg21.link/class.copy.elision">class.copy.elision</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>unknown<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>



(See also paper J16/99-0005 = WG21 N1182.)

<P>At the London meeting,
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#31">class.copy.ctor</A>] paragraph 31
was changed to
limit the optimization described to only the following cases:</P>
<UL>
<LI>
the source is a temporary object</LI>

<LI>
the return value optimization</LI>
</UL>
One other case was deemed desirable as well:
<UL>
<LI>
aliasing a parameter in an inline function call to the function call argument.</LI>
</UL>
However, there are cases when this aliasing was deemed undesirable and,
at the London meeting, the committee was not able to clearly delimit which
cases should be allowed and which ones should be prohibited.

<P>Can we find an appropriate description for the desired cases?</P>

<P>
<B>Rationale (04/99):</B> The absence of this optimization does
not constitute a defect in the Standard,
although the proposed resolution in the paper
should be considered when the Standard is revised.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group has accepted the intent of this issue and
referred it to CWG for action (not for C++0x).  See paper J16/07-0033 =
WG21 N2173.</P>

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

<P>The CWG decided to take no action on this issue until an interested
party produces a paper with analysis and a proposal.</P>

<P><B>Rationale (2023-05-12):</B></P>

<P>This is an extension that needs a paper targeted at EWG.</P>

<BR><BR><HR>
<A NAME="2125"></A><H4>2125.
  
Copy elision and comma operator
</H4>
<B>Section: </B>11.9.6&#160; [<A href="https://wg21.link/class.copy.elision">class.copy.elision</A>]
 &#160;&#160;&#160;

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

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

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




<P>Currently, 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>] paragraphs 31-32 apply only to
the name of a local variable in determining whether a return expression
is a candidate for copy elision or move construction.  Would it make
sense to extend that to include the right operand of a comma operator?</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a request for a new feature, which should be proposed in a
paper to EWG.</P>

<BR><BR><HR>
<A NAME="102"></A><H4>102.
  
Operator lookup rules do not work well with parts of the library
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>15 Oct 1998<BR>





<P>
The following example does not work as one might expect:</P>
<PRE>
    namespace N { class C {}; }
    int operator +(int i, N::C) { return i+1; }

    #include &lt;numeric&gt;
    int main() {
        N::C a[10];
        std::accumulate(a, a+10, 0);
    }
</PRE>
According to
6.5.3 [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>]

paragraph 6, I would expect that the "+" call inside
<TT>std::accumulate</TT> would find the global <TT>operator+</TT>.
Is this true, or am I
missing a rule? Clearly, the <TT>operator+</TT> would be found by Koenig lookup
if it were in namespace <TT>N</TT>.
<P>
<U>Daveed Vandevoorde</U>:

But doesn't unqualified lookup of
the <TT>operator+</TT> in the definition
of <TT>std::accumulate</TT> proceed in the namespace where the implicit
specialization is generated; i.e., in namespace <TT>std</TT>?</P>
<P>
In that case, you may find a non-empty overload set for <TT>operator+</TT>
in namespace <TT>std</TT> and the surrounding (global) namespace is no longer
considered?</P>
<P>
<U>Nathan Myers</U>:

Indeed, <TT>&lt;string&gt;</TT> defines <TT>operator+</TT>,
as do <TT>&lt;complex&gt;</TT>, <TT>&lt;valarray&gt;</TT>,
and <TT>&lt;iterator&gt;</TT>.  Any of these might hide the global operator.</P>
<P>
<U>Herb Sutter</U>:

These examples fail for the same reason:</P>
<PRE>
    struct Value { int i; };

    typedef map&lt;int, Value &gt; CMap;
    typedef CMap::value_type CPair;

    ostream &amp; operator&lt;&lt; ( ostream &amp;os, const CPair &amp;cp )
      { return os &lt;&lt; cp.first &lt;&lt; "/" &lt;&lt; cp.second.i; }

    int main() {
      CMap courseMap;
      copy( courseMap.begin(), courseMap.end(),
            ostream_iterator&lt;CPair&gt;( cout, "\n" ) );
    }

    template&lt;class T, class S&gt;
    ostream&amp; operator&lt;&lt; (ostream&amp; out, pair&lt;T,S&gt; pr)
      { return out &lt;&lt; pr.first &lt;&lt; " : " &lt;&lt; pr.second &lt;&lt; endl; }

    int main() {
      map &lt;int, string&gt; pl;
      copy( pl.begin(), pl.end(),
            ostream_iterator &lt;places_t::value_type&gt;( cout, "\n" ) );
    }
</PRE>
This technique (copying from a map to another container or stream)
should work. If it really cannot be made to work, that would seem broken
to me. The reason is does not work is that <TT>copy</TT> and <TT>pair</TT> are in
namespace <TT>std</TT> and the name lookup rules do not permit the global
<TT>operator&lt;&lt;</TT> to be found because the other <TT>operator&lt;&lt;</TT>'s
in namespace <TT>std</TT>
hide the global operator. (Aside: FWIW, I think most programmers don't
realize that a typedef like <TT>CPair</TT> is actually in namespace <TT>std</TT>, and not
the global namespace.)
<P>
<U>Bill Gibbons</U>: It looks like part of this problem is that the library
is referring to names which it requires the client to declare in the global namespace
(the operator names) while also declaring those names in namespace <TT>std</TT>.
This would be considered very poor design for plain function names; but the
operator names are special.</P>
<P>
There is a related case in the lookup of operator conversion functions.  The
declaration of a conversion function in a derived class does not hide any
conversion functions in a base class unless they convert to the same type.
Should the same thing be done for the lookup of operator function names,
e.g. should an operator name in the global namespace be visible in namespace
<TT>std</TT> unless there is a matching declaration in <TT>std</TT>?</P>
<P>
Because the operator function names are fixed, it it much more likely that
a declaration in an inner namespace will accidentally hide a declaration
in an outer namespace, and the two declarations are much less likely to
interfere with each other if they are both visible.</P>
<P>The lookup rules for operator names (when used implicitly) are already
quite different from those for ordinary function names.  It might be worthwhile
to add one more special case.</P>

<P>
<U>Mike Ball</U>

:  The original SGI proposal said that non-transitive points of
instantiation were also considered. Why, when, and by whom was it added?</P>

<P>
<B>Rationale (10/99):</B> This appears to be mainly a program
design issue.  Furthermore, any attempt to address it in the core
language would be beyond the scope of what can be done in a
Technical Corrigendum.</P>
<BR><BR><HR>
<A NAME="423"></A><H4>423.
  
Can a conversion be done on the left operand of a compound assignment?
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Gennaro Prota
 &#160;&#160;&#160;

 <B>Date: </B>19 Jun 2003<BR>


<P>Is the following well-formed?</P>
<PRE>
  template &lt;typename T&gt;
  class test
  {
  public:
    operator T&amp; (){ return m_i; }
  private:
    T m_i;
  };
  int main()
  {
    test&lt;int*&gt; t2;
    t2 += 1;  // Allowed?
  }
</PRE>
<P>Is it possible that by "assignment operators"
(12.2.2.3 [<A href="https://wg21.link/over.match.oper#4">over.match.oper</A>] paragraph 4) only the built-in
candidates for operator= (i.e. excluding +=, *=, etc.) were meant? On one hand
the plural ("operators") seems to imply that all the assignment operators are
considered. OTOH, there has already been a core DR (221) about a missing
distinction between "assignment operator" and "compound assignment operators".
Is there a similar defect here?</P>

<P>
<U>Steve Adamczyk:</U>
The standard is ambiguous.  However,
I think the ARM was fairly clear about "assignment operators" meaning only
"=", and I find that Cfront 3.0.1 accepts the test case (with typename
changed to class).  I don't know whether that's good or bad, but it's
at least a precedent.  Given the change of
<A HREF="cwg_defects.html#221">Core Issue 221</A>, if we do nothing
further conversions are valid on += and therefore this case is valid.</P>

<P>Note that "<TT>t2++;</TT>" is unquestionably valid, so one could
also argue for the status quo (post-221) on the basis of consistency.</P>

<P><B>Notes from the October 2003 meeting:</B></P>

<P>We believe the example is well-formed, and no change other than
that in issue 221 is needed.</P>

<BR><BR><HR>
<A NAME="1228"></A><H4>1228.
  
Copy-list-initialization and <TT>explicit</TT> constructors
</H4>
<B>Section: </B>12.2.2.8&#160; [<A href="https://wg21.link/over.match.list">over.match.list</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-12-03<BR>




<P>The rules for selecting candidate functions in copy-list-initialization
(12.2.2.8 [<A href="https://wg21.link/over.match.list">over.match.list</A>]) differ from those of regular
copy-initialization (12.2.2.5 [<A href="https://wg21.link/over.match.copy">over.match.copy</A>]): the latter specify
that only the converting (non-<TT>explicit</TT>) constructors are
considered, while the former include all constructors but state that
the program is ill-formed if an <TT>explicit</TT> constructor is
selected by overload resolution.  This is counterintuitive and can
lead to surprising results.  For example, the call to the function
object <TT>p</TT> in the following example is ambiguous because the
<TT>explicit</TT> constructor is a candidate for the initialization of
the operator's parameter:</P>

<PRE>
    struct MyList {
      explicit MyStore(int initialCapacity);
    };

    struct MyInt {
      MyInt(int i);
    };

    struct Printer {
      void operator()(MyStore const&amp; s);
      void operator()(MyInt const&amp; i);
    };

    void f() {
      Printer p;
      p({23});
    }
</PRE>

<P><B>Rationale (March, 2011):</B></P>

<P>The current rules are as intended.</P>

<BR><BR><HR>
<A NAME="2377"></A><H4>2377.
  
Explicit copy constructor vs function viability
</H4>
<B>Section: </B>12.2.3&#160; [<A href="https://wg21.link/over.match.viable">over.match.viable</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Xiang Fan
 &#160;&#160;&#160;

 <B>Date: </B>2018-06-05<BR>




<P>According to 12.2.3 [<A href="https://wg21.link/over.match.viable#4">over.match.viable</A>] paragraph 4,</P>

<BLOCKQUOTE>

Third, for <TT>F</TT> to be a viable function, there shall
exist for each argument an implicit conversion sequence
(12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>]) that converts that argument
to the corresponding parameter of <TT>F</TT>. If the
parameter has reference type, the implicit conversion
sequence includes the operation of binding the reference,
and the fact that an lvalue reference to non-<TT>const</TT>
cannot be bound to an rvalue and that an rvalue reference
cannot be bound to an lvalue can affect the viability of the
function (see 12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>]).

</BLOCKQUOTE>

<P>The description of an implicit conversion sequence in
12.2.4.2 [<A href="https://wg21.link/over.best.ics#6">over.best.ics</A>] paragraph 6 only discusses the
relationship of the types. For example, for a class type, it
says,</P>

<BLOCKQUOTE>

When the parameter has a class type and the argument
expression has the same type, the implicit conversion
sequence is an identity conversion.

</BLOCKQUOTE>

<P>This ignores whether the conversion can actually be
performed, considering <TT>explicit</TT> qualification of
constructors and conversion functions. There is implementation
divergence in the handling of an example like:</P>

<PRE>
  template&lt;typename T&gt; void f(T);
  template&lt;typename T&gt; void f(const T &amp;);

  struct Woof {
    explicit Woof() = default;
    explicit Woof(const Woof&amp;) = default;
    explicit Woof(Woof&amp;&amp;) = default;
    Woof&amp; operator=(const Woof&amp;) = default;
    Woof&amp; operator=(Woof&amp;&amp;) = default;
  };

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

<P>If <TT>f(Woof)</TT> is viable, the call is ambiguous, even
though calling <TT>f(Woof)</TT> would be ill-formed because of
the explicit copy constructor.</P>

<P>This seems to be consistent with the general approach
described in 12.2.4.2 [<A href="https://wg21.link/over.best.ics#2">over.best.ics</A>] paragraph 2, even
though explicitness is not explicitly mentioned:</P>

<BLOCKQUOTE>

Implicit conversion sequences are concerned only with the
type, cv-qualification, and value category of the argument
and how these are converted to match the corresponding
properties of the parameter. Other properties, such as the
lifetime, storage class, alignment, accessibility of the
argument, whether the argument is a bit-field, and whether a
function is deleted (9.6.3 [<A href="https://wg21.link/dcl.fct.def.delete">dcl.fct.def.delete</A>]), are
ignored. So, although an implicit conversion sequence can be
defined for a given argument-parameter pair, the conversion
from the argument to the parameter might still be ill-formed
in the final analysis.

</BLOCKQUOTE>

<P><B>Rationale (November, 2018):</B></P>

<P>The intent is that the example should be ambiguous. As an
editorial matter, the &#8220;such as&#8221; and &#8220;so&#8221;
remarks should be turned into notes.</P>

<BR><BR><HR>
<A NAME="455"></A><H4>455.
  
Partial ordering and non-deduced arguments
</H4>
<B>Section: </B>12.2.4&#160; [<A href="https://wg21.link/over.match.best">over.match.best</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Rani Sharoni
 &#160;&#160;&#160;

 <B>Date: </B>19 Jan 2004<BR>


<P>
It's not clear how overloading and partial ordering handle non-deduced pairs
of corresponding arguments. For example:</P>
<PRE>
template&lt;typename T&gt;
struct A { typedef char* type; };

template&lt;typename T&gt; char* f1(T, typename A&lt;T&gt;::type);  // #1
template&lt;typename T&gt; long* f1(T*, typename A&lt;T&gt;::type*); // #2

long* p1 = f1(p1, 0); // #3
</PRE>
<P>I thought that #3 is ambiguous but different compilers disagree on that.
Comeau C/C++ 4.3.3 (EDG 3.0.3) accepted the code, GCC 3.2 and BCC 5.5
selected #1 while VC7.1+ yields ambiguity.</P>

<P>I intuitively thought that the second pair should prevent overloading from
triggering partial ordering since both arguments are non-deduced and has
different types - (char*, char**). Just like in the following:</P>
<PRE>
template&lt;typename T&gt; char* f2(T, char*);   // #3
template&lt;typename T&gt; long* f2(T*, char**); // #4

long* p2 = f2(p2, 0); // #5
</PRE>
<P>In this case all the compilers I checked found #5 to be ambiguous.
The standard and DR <A HREF="cwg_defects.html#214">214</A> is not clear
about how partial ordering handle such
cases.</P>

<P>I think that overloading should not trigger partial ordering (in step
12.2.4 [<A href="https://wg21.link/over.match.best">over.match.best</A>]/1/5) if some candidates have
non-deduced pairs with different
(specialized) types. In this stage the arguments are already adjusted so no
need to mention it (i.e. array to pointer). In case that one of the
arguments is non-deuced then partial ordering should only consider the type
from the specialization:</P>
<PRE>
template&lt;typename T&gt; struct B { typedef T type; };

template&lt;typename T&gt; char* f3(T, T);                   // #7
template&lt;typename T&gt; long* f3(T, typename B&lt;T&gt;::type); // #8

char* p3 = f3(p3, p3); // #9
</PRE>
<P>According to my reasoning #9 should yield ambiguity since second pair is (T,
long*). The second type (i.e. long*) was taken from the specialization
candidate of #8.
EDG and GCC accepted the code. VC and BCC found an ambiguity.</P>

<P>
<U>John Spicer:</U>
There may (or may not) be an issue concerning whether nondeduced
contexts are handled properly in the partial ordering rules.  In
general, I think nondeduced contexts work, but we should walk through
some examples to make sure we think they work properly.</P>

<P>Rani's description of the problem suggests that he believes that
partial ordering is done on the specialized types.  This is not
correct.  Partial ordering is done on the templates themselves,
independent of type information from the specialization.</P>

<P><B>Notes from October 2004 meeting:</B></P>

<P>John Spicer will investigate further to see if any action is
required.</P>

<P>(See also <A HREF="cwg_closed.html#885">issue 885</A>.)</P>



<P><B>CWG 2022-11-11</B></P>

<P>The second function parameter contains template parameters not
deducible in its context, thus that parameter does not contribute to
partial ordering.  There is no implementation divergence.  Close as
NAD.</P>

<BR><BR><HR>
<A NAME="2304"></A><H4>2304.
  
Incomplete type vs overload resolution
</H4>
<B>Section: </B>12.2.4.2&#160; [<A href="https://wg21.link/over.best.ics">over.best.ics</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2016-07-05<BR>


<P>It is not clear whether the current treatment of an example like
the following is what we want:</P>

<PRE>
  template&lt;typename T&gt; void foo(T, int);
  template&lt;typename T&gt; void foo(T&amp;, ...);
  struct Q;
  void fn1(Q &amp;data_vectors) { foo(data_vectors, 0); }
</PRE>

<P>According to 12.2.4.2 [<A href="https://wg21.link/over.best.ics#8">over.best.ics</A>] paragraph 8,</P>

<BLOCKQUOTE>

If no conversions are required to match an argument to a parameter type,
the implicit conversion sequence is the standard conversion sequence
consisting of the identity conversion (12.2.4.2.2 [<A href="https://wg21.link/over.ics.scs">over.ics.scs</A>]).

</BLOCKQUOTE>

<P>This would select the first overload and then fail in attempting
to call it because of the incomplete type. On the other hand, it is
ill-formed to define or call a function with an incomplete parameter
type, although it can be declared, so it might be reasonable to take
completeness of the parameter type into consideration for SFINAE
purposes. 13.10.3 [<A href="https://wg21.link/temp.deduct#8.11">temp.deduct</A>] bullet 8.11 says,</P>

<BLOCKQUOTE>

<P>[<I>Note:</I> Type deduction may fail for the following reasons:</P>

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

<LI><P>Attempting to create a function type in which a parameter type or
the return type is an abstract class type
(11.7.4 [<A href="https://wg21.link/class.abstract">class.abstract</A>]).</P></LI>

</UL>

</BLOCKQUOTE>

<P>If a definition of <TT>Q</TT> were available, we would need to
instantiate it to see if it is abstract.</P>

<P>It would seem reasonable for an incomplete type to be invalid as
well. That would be consistent with the other rules and general desire
not to select functions you can't call based on the template argument
types.</P>

<P><B>Rationale (July, 2017):</B></P>

<P>CWG determined that no change was needed.</P>

<BR><BR><HR>
<A NAME="243"></A><H4>243.
  
Weighting of conversion functions in direct-initialization
</H4>
<B>Section: </B>12.2.4.2.3&#160; [<A href="https://wg21.link/over.ics.user">over.ics.user</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>5 Sep 2000<BR>




<P>There is a moderately serious problem with
the definition of overload resolution.  Consider this example:</P>

<PRE>
    struct B;
    struct A {
        A(B);
    };
    struct B {
        operator A();
    } b;
    int main() {
        (void)A(b);
    }
</PRE>

<P>This is pretty much the definition of "ambiguous," right?  You want
to convert a <TT>B</TT> to an <TT>A</TT>, and there are two equally
good ways of doing that: a constructor of <TT>A</TT> that takes a
<TT>B</TT>, and a conversion function of <TT>B</TT> that returns an
<TT>A</TT>.</P>

<P>What we discover when we trace this through the standard,
unfortunately, is that the constructor is favored over the conversion
function.  The definition of direct-initialization (the parenthesized
form) of a class considers only constructors of that class.  In this
case, the constructors are the <TT>A(B)</TT> constructor and the
(implicitly-generated) <TT>A(const A&amp;)</TT> copy constructor.
Here's how they are ranked on the argument match:</P>

<TABLE BORDER="1" CELLSPACING="0" CELLPADDING="4">
<TR>
<TD><TT>A(B)</TT></TD>
<TD>exact match (need a <TT>B</TT>, have a <TT>B</TT>)</TD>
</TR>
<TR>
<TD><TT>A(const A&amp;)</TT></TD>
<TD>user-defined conversion (<TT>B::operator A</TT> used to
convert <TT>B</TT> to <TT>A</TT>)</TD>
</TR>
</TABLE>

<P>In other words, the conversion function does get considered, but
it's operating with, in effect, a handicap of one user defined
conversion.  To put that a different way, this problem is a problem of
weighting, not a problem that certain conversion paths are not
considered.</P>

<P>I believe the reason that the
standard's approach doesn't yield the "intuitive" result is
that programmers expect copy constructor elision
to be done whenever reasonable, so the intuitive cost of using
the conversion function in the example above is simply the cost
of the conversion function, not the cost of the conversion function
plus the cost of the copy constructor (which is what the standard
counts).</P>

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

<P>In a direct-initialization overload
resolution case, if the candidate function being called is a copy
constructor and its argument (after any implicit conversions) is a
temporary that is the return value of a conversion function, and the
temporary can be optimized away, the cost of the argument match for
the copy constructor should be considered to be the cost of the
argument match on the conversion function argument.</P>

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

<P>It turns out that there is existing practice both ways on this
issue, so it's not clear that it is "broken". There is some reason to
feel that something that looks like a "constructor call" should call a
constructor if possible, rather than a conversion function.
The CWG decided to leave it alone.</P>

<BR><BR><HR>
<A NAME="1950"></A><H4>1950.
  
Restructuring description of ranks of conversion sequences
</H4>
<B>Section: </B>12.2.4.3&#160; [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
 &#160;&#160;&#160;

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

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

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


<P>The structure of 12.2.3 [<A href="https://wg21.link/over.match.viable#3">over.match.viable</A>] paragraph 3 is of the
form</P>

<UL>
<LI><P>
<TT>X</TT> is better than <TT>Y</TT> if</P></LI>

<UL>
<LI><P>condition 1, or, if not that,</P></LI>

<LI><P>condition 2, or, if not that,</P></LI>

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

</UL>

</UL>

<P>It would be better to de-bullet this description, define the
conditions, and then say, &#8220;<TT>X</TT> is better than <TT>Y</TT>
if condition 1, condition 2, ...&#8221;  This would also avoid the
awkward &#8220;or, if not that,&#8221; phrasing.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>CWG expressed a preference for the existing structure of this
paragraph over the suggested rewrite.  The change from &#8220;or,
if not that,&#8221; to &#8220;otherwise&#8221; can be handled
editorially, if desired.</P>

<BR><BR><HR>
<A NAME="2524"></A><H4>2524.
  
Distinguishing user-defined conversion sequences by <I>ref-qualifier</I>
</H4>
<B>Section: </B>12.2.4.3&#160; [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hani Deek
 &#160;&#160;&#160;

 <B>Date: </B>2021-09-09<BR>


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

<PRE>
  struct S  {
      operator int() const &amp; { return 0; }
      operator char() &amp;&amp; { return 0; }
  };

  void foo(int) {}
  void foo(char) {}

  int main() {
    foo(S{}); //<SPAN CLASS="cmnt">OK, calls </SPAN>foo(char)
  }
</PRE>

<P>Here, the ICS for each function is a user-defined
conversion involving the same user-defined conversion
function, <TT>operator char() &amp;&amp;</TT>, because of
12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3.2.3">over.ics.rank</A>] bullet 3.2.3:</P>

<BLOCKQUOTE>

<TT>S1</TT> and <TT>S2</TT> include reference bindings
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) and neither refers to an
implicit object parameter of a non-static member function
declared without a <I>ref-qualifier</I>, and <TT>S1</TT>
binds an rvalue reference to an rvalue and <TT>S2</TT> binds
an lvalue reference

</BLOCKQUOTE>

<P>
<TT>foo(int)</TT> is a promotion,
while <TT>foo(char)</TT> is an exact match, so the latter is
chosen.</P>

<P>Replacing <TT>int</TT> and <TT>char</TT> in this example
with non-interconvertible types results in a different
outcome:</P>

<PRE>
  class A{};
  class B{};

  struct S {
    operator A() const &amp; { return A{}; }
    operator B() &amp;&amp; { return B{}; }
  };

  void foo(A) {}
  void foo(B) {}

  int main() {
    foo(S{}); //<SPAN CLASS="cmnt">error: call to </SPAN>foo<SPAN CLASS="cmnt"> is ambiguous</SPAN>
  }
</PRE>

<P>Here, only one of the two user-defined conversion
operators is viable for each overload. Consequently,
12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3.3">over.ics.rank</A>] bullet 3.3,</P>

<BLOCKQUOTE>

User-defined conversion sequence <TT>U1</TT> is a better
conversion sequence than another user-defined conversion
sequence <TT>U2</TT> if they contain the same user-defined
conversion function or constructor or they initialize the
same class in an aggregate initialization and in either case
the second standard conversion sequence of <TT>U1</TT> is
better than the second standard conversion sequence
of <TT>U2</TT>.

</BLOCKQUOTE>

<P>does not apply, unlike the earlier case, because
different user-defined conversion functions appear in
each conversion sequence and thus the sequences are
indistinghishable.</P>

<P>This seems inconsistent.</P>

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

<P>Change 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3.3">over.ics.rank</A>] bullet 3.3 as
follows:</P>

<BLOCKQUOTE>

<UL>
<LI><P>User-defined conversion sequence <TT>U1</TT> is a better
conversion sequence than another user-defined conversion
sequence <TT>U2</TT> if</P></LI>

<UL>
<LI><P><INS>the initial standard conversion sequence of
<TT>U1</TT> is better than the initial standard conversion
sequence of <TT>U2</TT>, or</INS></P></LI>

<LI>
<P>they contain the same user-defined conversion
function or constructor or they initialize the same class in
an aggregate initialization and in either case the second
standard conversion sequence of <TT>U1</TT> is better than
the second standard conversion sequence of <TT>U2</TT>.</P>
</LI>

</UL>

</UL>

</BLOCKQUOTE>

<P><B>CWG 2022-11-11</B></P>

<P>This is an extension that is best addressed by a paper to EWG.</P>

<BR><BR><HR>
<A NAME="61"></A><H4>61.
  
Address of static member function "<TT>&amp;p-&gt;f</TT>"
</H4>
<B>Section: </B>12.3&#160; [<A href="https://wg21.link/over.over">over.over</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>13 Oct 1998<BR>



<P>Can <TT>p-&gt;f</TT>, where <TT>f</TT> refers to a set of overloaded functions
all of which are static member functions, be used as an expression in an
address-of-overloaded-function context? A strict reading of this
section suggests "no", because "<TT>p-&gt;f</TT>" is not the name of an overloaded
function (it's an expression). I'm happy with that, but the core
group should decide and should add an example to document the decision,
whichever way it goes.</P>

<P>
<B>Rationale (10/99):</B> The "strict reading" correctly reflects
the intent of the Committee, for the reason given, and no clarification
is required.</P>
<BR><BR><HR>
<A NAME="247"></A><H4>247.
  
Pointer-to-member casts and function overload resolution
</H4>
<B>Section: </B>12.3&#160; [<A href="https://wg21.link/over.over">over.over</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>22 Sep 2000<BR>




<P>It is unclear whether the following code is well-formed or not:</P>

<PRE>
    class A { };

    struct B : public A
    {
	void foo ();
	void foo (int);
    };

    int main ()
    {
	void (A::*f)() = (void (A::*)())&amp;B::foo;
    }
</PRE>

<P>12.3 [<A href="https://wg21.link/over.over#1">over.over</A>] paragraph 1 says,</P>

<BLOCKQUOTE>

The function selected is the one whose type matches the target
type required in the context.  The target can be

<UL>

<LI><B>...</B></LI>

<LI>an explicit type conversion (7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>],
7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>], 7.6.3 [<A href="https://wg21.link/expr.cast">expr.cast</A>]).</LI>

</UL>

</BLOCKQUOTE>

<P>This would appear to make the program ill-formed, since the
type in the cast is different from that of either interpretation
of the address-of-member expression (its class is <TT>A</TT>,
while the class of the address-of-member expression is <TT>B</TT>)</P>

<P>However, 12.3 [<A href="https://wg21.link/over.over#3">over.over</A>] paragraph 3 says,</P>

<BLOCKQUOTE>

Nonstatic member functions match targets of type
"pointer-to-member-function;" the function type of the pointer
to member is used to select the member function from the set
of overloaded member functions.

</BLOCKQUOTE>

<P>The class of which a function is a member is <B>not</B> part of the
"function type" (9.3.4.6 [<A href="https://wg21.link/dcl.fct#4">dcl.fct</A>] paragraph 4).
Paragraph 4 is thus either a misuse of the phrase "function type," a
contradiction of paragraph 1, or an explanation of what "matching
the target type" means in the context of a pointer-to-member
target.  By the latter interpretation, the example is well-formed
and <TT>B::foo()</TT> is selected.</P>

<P>
<U>Bill Gibbons</U>: I think this is an accident due to vague
wording.  I think the intent was</P>

<BLOCKQUOTE>

The function selected is the one which will make the effect of
the cast be that of the identity conversion.

</BLOCKQUOTE>

<P>
<U>Mike Miller</U>: The "identity conversion" reading seems
to me to be overly restrictive.  It would lead to the following:</P>

<PRE>
    struct B {
        void f();
        void f(int);
    };
    struct D: B { };
    void (D::* p1)() = &amp;D::f;                  // ill-formed
    void (D::* p2)() = (void (B::*)()) &amp;D::f;  // okay
</PRE>

<P>I would find the need for an explicit cast here surprising, since
the downcast is a standard conversion and since the declaration of
<TT>p1</TT> certainly has enough information to disambiguate the
overload set.  (See also <A HREF="cwg_closed.html#203">issue 203</A>.)</P>

<P>
<U>Bill Gibbons</U>: There is an interesting situation with
<I>using-declaration</I>s.  If a base class member function is present
in the overload set in a derived class due to a
<I>using-declaration</I>, it is treated as if it were a derived class
member function for purposes of overload resolution in a call
(12.2.2 [<A href="https://wg21.link/over.match.funcs#4">over.match.funcs</A>] paragraph 4):</P>

<BLOCKQUOTE>

For non-conversion functions introduced by a <I>using-declaration</I>
into a derived class, the function is considered to be a member of the
derived class for the purpose of defining the type of the implicit
object parameter

</BLOCKQUOTE>

<P>There is no corresponding rule for casts. Such a rule would be
practical, but if the base class member function were selected it
would not have the same class as that specified in the cast.  Since
base-to-derived pointer to member conversions are implicit
conversions, it would seem reasonable to perform this conversion
implicitly in this case, so that the result of the cast has the right
type.  The usual ambiguity and access restrictions on the
base-to-derived conversion would not apply since they do not apply to
calling through the <I>using-declaration</I> either.</P>

<P>On the other hand, if there is no special case for this, we end up with
the bizarre case:</P>

<PRE>
    struct A {
        void foo();
    };
    struct B : A {
        using A::foo;
        void foo(int);
    }
    int main() {
        // Works because "B::foo" contains A::foo() in its overload set.
        (void (A::*)())&amp;B::foo;
        // Does not work because "B::foo(int)" does not match the cast.
        (void (A::*)(int))&amp;B::foo;
    }
</PRE>

<P>I think the standard should be clarified by either:</P>

<UL>

<LI><P>Adding a note to 12.3 [<A href="https://wg21.link/over.over">over.over</A>] saying that
<I>using-declaration</I>s do not participate
in this kind of overload resolution; or</P></LI>

<LI><P>Modifying 12.3 [<A href="https://wg21.link/over.over">over.over</A>] saying that
<I>using-declaration</I>s are treated as members of the derived class
for matching purposes, and if selected, the resulting pointer to
member is implicitly converted to the derived type with no access or
ambiguity errors.  (The <I>using-declaration</I> itself has already
addressed both of these areas.)</P></LI>

</UL>

<P>
<B>Rationale (10/00):</B> The cited example is well-formed.
The function type, ignoring the class specification, is used to
select the matching function from the overload set as specified
in 12.3 [<A href="https://wg21.link/over.over#3">over.over</A>] paragraph 3.  If the target
type is supplied by an explicit cast, as here, the conversion is
then performed on the selected pointer-to-member value, with the
usual restrictions on what can and cannot be done with the
converted value (7.6.1.9 [<A href="https://wg21.link/expr.static.cast#9">expr.static.cast</A>] paragraph 9,
7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast#9">expr.reinterpret.cast</A>] paragraph 9).</P>

<BR><BR><HR>
<A NAME="27"></A><H4>27.
  
Overload ambiguities for builtin ?: prototypes
</H4>
<B>Section: </B>12.5&#160; [<A href="https://wg21.link/over.built">over.built</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>25 Sep 1997<BR>





<P>I understand that the lvalue-to-rvalue conversion was removed in London.
I generally agree with this, but it means that <TT>?:</TT> needs to be
fixed:</P>

<P>Given:</P>
<PRE>
    bool test;
    Integer a, b;
    test ? a : b;
</PRE>
What builtin do we use? The candidates are
<PRE>
    operator ?:(bool, const Integer &amp;, const Integer &amp;)
    operator ?:(bool, Integer, Integer)
</PRE>
which are both perfect matches.

<P>(Not a problem in the C++11 FDIS, but misleading.)</P>

<P>
<B>Rationale:</B>
The description of the conditional operator in
7.6.16 [<A href="https://wg21.link/expr.cond">expr.cond</A>]

handles the lvalue case before the prototype is considered.</P>
<BR><BR><HR>
<A NAME="728"></A><H4>728.
  
Restrictions on local classes
</H4>
<B>Section: </B>Clause 13&#160; [<A href="https://wg21.link/temp">temp</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>5 October, 2008<BR>


<P>Now that the restriction against local classes being used as
template arguments has been lifted, they are more useful, yet they are
still crippled.  For some reason or oversight, the restriction against
local classes being templates or having member templates was not
lifted.  Allowing local classes to have member templates facilitates
generic programming (the reason for lifting the other restriction),
especially when it comes to the visitor-pattern (see the
<TT>boost::variant</TT> documentation and the following example) as
implemented in boost and the <TT>boost::MPL</TT> library (since
functors have to be template classes in mpl, and higher-order functors
have to have member templates to be useful).  A local class with a
member template would allow this desirable solution:</P>

<PRE>
    #include &lt;boost/variant.hpp&gt;
    int main() {
      struct times_two_generic: public boost::static_visitor&lt;&gt; {
        template &lt;typename T&gt; void operator()(T&amp; operand) const {
            operand += operand;
        }
      };

      std::vector&lt;boost::variant&lt;int, std::string&gt;&gt; vec;
      vec.push_back(21);
      vec.push_back("hello ");

      times_two_generic visitor;
      std::for_each(vec.begin(), vec.end(), boost::apply_visitor(visitor));
    }
</PRE>

<P>Is there any compelling reason not to allow this code?  Is there
any compelling reason not to allow local classes to be templates, have
friends, or be able to define their static data members at function
scope?  Wouldn't this symmetry amongst local and non-local classes
make the language more appealing and less embarrassing?</P>

<P><B>Rationale (June, 2021):</B></P>

<P>EWG resolved to pursue this topic with paper P2044.
It is no longer tracked as a core issue.
See <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1018r11.html#CWG728">vote</A>.</P>

<BR><BR><HR>
<A NAME="822"></A><H4>822.
  
Additional contexts for template aliases
</H4>
<B>Section: </B>Clause 13&#160; [<A href="https://wg21.link/temp">temp</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK117">N2800 comment
  UK&#160;117<BR></A>

<P>
It would be nice
to allow template alias within a function scope, and
possibly a scoped concept map. As these affect name lookup
and resolution, rather than defining new callable code,
they are not seen to present the same problems that
prevented class and function templates in the past.
</P>

<P><B>Rationale (July, 2009):</B></P>

<P>This suggestion needs a paper and discussion in EWG before CWG can
consider it.</P>

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

<P>EWG has decided not to make a change in this area.  See EWG issue 95.</P>

<BR><BR><HR>
<A NAME="1303"></A><H4>1303.
  
C language linkage for template with internal linkage
</H4>
<B>Section: </B>Clause 13&#160; [<A href="https://wg21.link/temp">temp</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-04-23<BR>




<P>There doesn't seem to be a good reason for prohibiting C language
linkage for function templates with internal linkage, and that could
be useful in implementations where the calling convention of a function
is determined by its language linkage.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The specification is as desired.</P>

<BR><BR><HR>
<A NAME="1179"></A><H4>1179.
  
Cv-qualification of non-type template parameters
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-19<BR>




<P>Given an example like</P>

<PRE>
    template&lt;const int I&gt; struct S {
        decltype(I) m;
    };
</PRE>

<P>what is the type of <TT>m</TT>?  13.2 [<A href="https://wg21.link/temp.param#5">temp.param</A>] paragraph 5
is clear on the question:</P>

<BLOCKQUOTE>

The top-level <I>cv-qualifier</I>s on the <I>template-parameter</I>
are ignored when determining its type.

</BLOCKQUOTE>

<P>It's not clear that this is the desired outcome, however,
particularly in light of the resolution of <A HREF="cwg_defects.html#1130">issue 1130</A>. (This does not make any difference for the current
language, as a non-type template parameter is a prvalue and
non-class prvalues are never cv-qualified. It would have an impact,
however, if a future revision of the language were to allow literal
class types as non-type template parameters, so if a change is needed,
it might be a good idea to do it now.)</P>

<P><B>Rationale (November, 2010):</B></P>

<P>As noted, the treatment of cv-qualification of the type of
non-type template parameters is irrelevant because they are currently
always non-class prvalues.  If the language is extended to allow
literal class types, a change to the handling of cv-qualification would
be upwardly compatible, so nothing needs to be done now.</P>

<BR><BR><HR>
<A NAME="1319"></A><H4>1319.
  
Error in pack expansion example
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-05-17<BR>


<P>The example in 13.2 [<A href="https://wg21.link/temp.param#15">temp.param</A>] paragraph 15 contains the
line</P>

<PRE>
    template&lt;T... Values&gt; apply { };   //<SPAN CLASS="cmnt"> </SPAN>Values<SPAN CLASS="cmnt"> is a non-type template parameter pack</SPAN>
                                       //<SPAN CLASS="cmnt"> and a pack expansion</SPAN>
</PRE>

<P>This should presumably be <TT>struct apply</TT> or some such.</P>

<P><B>Rationale (August, 2011)</B></P>

<P>This is an editorial issue that has been transmitted to the project
editor.</P>

<BR><BR><HR>
<A NAME="1643"></A><H4>1643.
  
Default arguments for template parameter packs
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-03-17<BR>




<P>Although 13.2 [<A href="https://wg21.link/temp.param#9">temp.param</A>] paragraph 9 forbids default
arguments for template parameter packs, allowing them would make
some program patterns easier to write.  Should this restriction be
removed?</P>

<P><B>Rationale (April, 2013):</B></P>

<P>CWG felt that removing the restriction was an extension best
considered by EWG.</P>

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

<P>See EWG issue 15.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a request for a possibly desirable feature, which should be
proposed in a paper to EWG.</P>

<BR><BR><HR>
<A NAME="1904"></A><H4>1904.
  
Default template arguments for members of class templates
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2014-03-27<BR>


<P>According to 13.2 [<A href="https://wg21.link/temp.param#9">temp.param</A>] paragraph 9,</P>

<BLOCKQUOTE>

A default <I>template-argument</I> shall not be specified in
the <I>template-parameter-list</I>s of the definition of a member of a
class template that appears outside of the member's class.

</BLOCKQUOTE>

<P>This presumably is intended to apply to the parameters of the
containing class template, not to the parameters of a member
template, but the wording should be clarified.  (Default arguments
are permitted for a template member of a non-template class, and
there does not appear to be a good rationale for treating members
of a class template differently in this regard.)</P>

<P><B>Rationale (June, 2014):</B></P>

<P>CWG felt that the existing wording os clear enough.</P>

<BR><BR><HR>
<A NAME="2178"></A><H4>2178.
  
Substitution of dependent template arguments in default template arguments
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

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

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




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

<PRE>
   template&lt;typename T, T V, int n = sizeof(V)&gt; using X = int[n];
   template&lt;typename T&gt; void f(X&lt;T, 0&gt;*) {}
   void g() { f&lt;char&gt;(0); }
</PRE>

<P>Current implementations get confused here because they
substitute <TT>V=0</TT> into the default argument of <TT>X</TT>
before knowing the type <TT>T</TT> and end up with
<TT>f</TT> having type <TT>void (int (*)[sizeof(0)])</TT>,
that is, the array bound does not depend on <TT>T</TT>.  It's
not clear what should happen here.</P>

<P><B>Rationale (March, 2016):</B></P>

<P>There is no problem with the specification, only with the
implementations; the default argument for <TT>n</TT> is
dependent because <TT>V</TT> has a dependent type.</P>

<BR><BR><HR>
<A NAME="2383"></A><H4>2383.
  
Variadic member functions of variadic class templates
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2018-07-18<BR>


<P>The intended treatment of an example like the following is not
clear:</P>

<PRE>
  template&lt;class ...Types&gt; struct Tuple_ { //<SPAN CLASS="cmnt"> _VARIADIC_TEMPLATE</SPAN>
    template&lt;Types ...T&gt; int f() {
      return sizeof...(Types);
    }
  };

  int main() {
    Tuple_&lt;char,int&gt; a;
    int b = a.f();
  }
</PRE>

<P>According to 13.2 [<A href="https://wg21.link/temp.param#19">temp.param</A>] paragraph 19,</P>

<BLOCKQUOTE>

If a <I>template-parameter</I> is a <I>type-parameter</I> with an ellipsis
prior to its optional <I>identifier</I> or is
a <I>parameter-declaration</I> that declares a pack
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]), then the <I>template-parameter</I> is a
template parameter pack (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]).  A template
parameter pack that is a <I>parameter-declaration</I> whose type contains
one or more unexpanded packs is a pack expansion. Similarly, a template
parameter pack that is a <I>type-parameter</I> with
a <I>template-parameter-list</I> containing one or more unexpanded packs is
a pack expansion. A template parameter pack that is a pack expansion shall
not expand a template parameter pack declared in the
same <I>template-parameter-list</I>.

</BLOCKQUOTE>

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

<PRE>
  template &lt;class... T&gt;
    struct value_holder {
      template &lt;T... Values&gt; struct apply { }; //<SPAN CLASS="cmnt"> </SPAN>Values<SPAN CLASS="cmnt"> is a non-type template parameter pack</SPAN>
  };                                           //<SPAN CLASS="cmnt"> and a pack expansion</SPAN>
</PRE>

<P>There is implementation divergence on the treatment of the example, with
some rejecting it on the basis that the arguments for <TT>Tuple_::f</TT>
cannot be deduced, while others accept it.</P>

<P><B>Rationale (December, 2018):</B></P>

<P>The example is ill-formed because the packs have different
sizes: <TT>Types</TT> has 2, <TT>T</TT> has 0 (from the call).</P>

<BR><BR><HR>
<A NAME="552"></A><H4>552.
  
Use of <TT>typename</TT> in the type in a non-type <I>parameter-declaration</I>
</H4>
<B>Section: </B>13.3&#160; [<A href="https://wg21.link/temp.names">temp.names</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andre Morozov
 &#160;&#160;&#160;

 <B>Date: </B>15 December 2005<BR>


<P>The discussion in of the use of <TT>typename</TT> with a
<I>qualified-id</I> in a template <I>parameter-declaration</I> in
13.3 [<A href="https://wg21.link/temp.names#2">temp.names</A>] paragraph 2 is confusing:</P>

<BLOCKQUOTE>

<TT>typename</TT> followed by an <I>unqualified-id</I> names a
template type parameter. <TT>typename</TT> followed by
a <I>qualified-id</I> denotes the type in a non-type
<I>parameter-declaration</I>.

</BLOCKQUOTE>

<P>This rule would be clearer if the <I>unqualified-id</I> case were
described in terms of resolving the ambiguity of declaring a
template parameter name versus referring to a <I>type-name</I>
from the enclosing scope, and if the <I>qualified-id</I> case
referred to the use of the <TT>typename</TT> keyword with
dependent types in 13.8 [<A href="https://wg21.link/temp.res">temp.res</A>].  An example would
also be helpful.</P>

<P><B>Rationale (April, 2006):</B></P>

<P>The CWG felt that the wording was already clear enough.</P>

<BR><BR><HR>
<A NAME="440"></A><H4>440.
  
Allow implicit pointer-to-member conversion on nontype template argument
</H4>
<B>Section: </B>13.4&#160; [<A href="https://wg21.link/temp.arg">temp.arg</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>13 Nov 2003<BR>


<P>None of my compilers accept this, which surprised me a little.  Is
the base-to-derived member function conversion considered to be a
runtime-only thing?</P>
<PRE>
  template &lt;class D&gt;
  struct B
  {
      template &lt;class X&gt; void f(X) {}
      template &lt;class X, void (D::*)(X) = &amp;B&lt;D&gt;::f&lt;X&gt; &gt;
      struct row {};
  };
  struct D : B&lt;D&gt;
  {
      void g(int);
      row&lt;int,&amp;D::g&gt; r1;
      row&lt;char*&gt; r2;
  };
</PRE>
<P>
<U>John Spicer</U>:
This is not among the permitted conversions listed in 14.3.</P>

<P>I'm not sure there is a terribly good reason for that.  Some of the
template argument rules for external entities were made conservatively
because of concerns about issues of mangling template argument names.</P>

<P>
<U>David Abrahams</U>:
I'd really like to see that restriction loosened.  It is a serious
inconvenience because there appears to be no way to supply a usable
default in this case.  Zero would be an OK default if I could use the
function pointer's equality to zero as a compile-time switch to
choose an empty function implementation:</P>
<PRE>
  template &lt;bool x&gt; struct tag {};

  template &lt;class D&gt;
  struct B
  {
      template &lt;class X&gt; void f(X) {}

      template &lt;class X, void (D::*pmf)(X) = 0 &gt;
      struct row {
          void h() { h(tag&lt;(pmf == 0)&gt;(), pmf); }
          void h(tag&lt;1&gt;, ...) {}
          void h(tag&lt;0&gt;, void (D::*q)(X)) { /*something*/}
      };
  };

  struct D : B&lt;D&gt;
  {
      void g(int);
      row&lt;int,&amp;D::g&gt; r1;
      row&lt;char*&gt; r2;
  };
</PRE>

<P>But there appears to be no way to get that effect either.  The result
is that you end up doing something like:</P>
<PRE>
      template &lt;class X, void (D::*pmf)(X) = 0 &gt;
      struct row {
          void h() { if (pmf) /*something*/ }
      };
</PRE>

<P>which invariably makes compilers warn that you're switching on a
constant expression.</P>

<P><B>Additional notes (February, 2023)</B></P>

<P>Even the following simple case fails on all major implementations:</P>

<PRE>
  struct B { void f(); };
  struct D : B {};

  template&lt;void (D::*)()&gt;
  int g();

  int x = g&lt;&amp;D::f&gt;();
</PRE>

<P>Subclause 7.7 [<A href="https://wg21.link/expr.const#12">expr.const</A>] paragraph 12 is unambiguous that
the code is ill-formed, but that seems unfortunate.</P>

<P><B>CWG 2023-06-15</B></P>

<P>CWG noted that the derived-to-base conversion is also not allowed
for arguments for non-type template parameters.  Permitting such
conversions is an extension, not a defect.</P>

<BR><BR><HR>
<A NAME="114"></A><H4>114.
  
Virtual overriding by template member function specializations
</H4>
<B>Section: </B>13.7.3&#160; [<A href="https://wg21.link/temp.mem">temp.mem</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bill Gibbons
 &#160;&#160;&#160;

 <B>Date: </B>7 May 1999<BR>





<P>According to 13.7.3 [<A href="https://wg21.link/temp.mem#4">temp.mem</A>] paragraph 4,
</P>
<BLOCKQUOTE>
A specialization of a member function template does not override
a virtual function from a base class.
</BLOCKQUOTE>

<B>Bill Gibbons:</B>
I think that's sufficiently surprising behavior that it should be ill-formed
instead.

<P>As I recall, the main reason why a member function template cannot be
virtual is that you can't easily construct reasonable vtables for an
infinite set of functions.  That doesn't apply to overrides.</P>

<P>Another problem is that you don't know that a specialization overrides
until the specialization exists:</P>
<PRE>
    struct A {
        virtual void f(int);
    };
    struct B : A {
        template&lt;class T&gt; void f(T);  // does this override?
    };
</PRE>
But this could be handled by saying:
<UL>
<LI>If deduction using the type of an overridable function in
a base class succeeds, the template is implicitly specialized
to provide the override.</LI>

<LI>If this yields more than one override for a function, the program
is ill-formed.</LI>

<LI>If a specialization due to explicit template arguments creates
an override that did not previously exist, the program is
ill-formed.  (Or alternatively, it is not an override.)</LI>
</UL>

The last case might only involve non-deducible contexts, e.g.
<PRE>
    template&lt;int I&gt; struct X;
    struct A {
        virtual void f(A&lt;5&gt;);
    };
    struct B : A {
        template&lt;int I, int J&gt; void f(A&lt;I+J&gt;);  // does not overrride
    };

    void g(B *b) {
        X&lt;t&gt; x;
        b-&gt;f&lt;3,2&gt;(x);  // specialization B::f(A&lt;5&gt;) makes program ill-formed
    }
</PRE>
So I think there are reasonable semantics.  But is it useful?

<P>If not, I think the creation of a specialization that would have been
an override had it been declared in the class should be an error.</P>

<P>
<B>Daveed Vandevoorde:</B>
There is real code out there that is written with this rule
in mind. Changing the standard on them would not be good
form, IMO.</P>

<P>
<B>Mike Ball:</B>
Also, if you allow template functions to be specialized outside
of the class you introduce yet another non-obvious ordering constraint.</P>

<P>Please don't make such a change after the fact.</P>

<P>
<B>John Spicer:</B> This is the result of an explicit committee
decision.  The reason for this rule is that it is too easy to
unwittingly override a function from a base class, which was probably
not what was intended when the template was written.  Overriding
should be a conscious decision by the class writer, not something done
accidentally by a template.</P>

<P>
<B>Rationale (10/99):</B> The Standard correctly reflects the
intent of the Committee.</P>

<P><B>Notes from October 2002 meeting:</B></P>

<P>
This was reopened because of a discussion while reviewing possible
extensions.</P>



<P><B>Notes from April 2003 meeting:</B></P>

<P>This was discussed again, and the consensus was that we did
not want to make a change, and in particular we did not want to
make it an error and risk breaking existing code.
</P>

<BR><BR><HR>
<A NAME="1002"></A><H4>1002.
  
Pack expansion for function arguments
</H4>
<B>Section: </B>13.7.4&#160; [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2009-11-16<BR>


<P>The list of contexts in which pack expansions can occur, in
13.7.4 [<A href="https://wg21.link/temp.variadic#4">temp.variadic</A>] paragraph 4, does not include a
function call, in spite of the comments in the example there
that assume that a function call is such a context.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>
<I>initializer-list</I>, mentioned in 13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>],
is used in the argument list of a function call.</P>

<BR><BR><HR>
<A NAME="1519"></A><H4>1519.
  
Conflicting default and variadic constructors
</H4>
<B>Section: </B>13.7.4&#160; [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-07-09<BR>




<P>A specialization of a variadic function template can produce the same
function signature as a non-variadic one; in particular, a class can
end up with multiple default constructors if a pack expansion is empty.
It would be helpful if such a specialization could be suppressed so
that the non-variadic function were preferred.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>It can be argued that this is not a defect in the language but
simply something that must be considered by the programmer: if the
default constructor and the empty-pack-expansion constructor do the
same thing, the default constructor is superfluous, while if they do
different things there may be a logic error in one or the other.  EWG
should resolve the policy question of whether this situation should
receive special treatment in the language to make it well-formed.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>EWG determined that no action should be taken on this issue. There is
an existing workaround for the problem, and it will also be addressed by
the Concepts Lite proposal.</P>

<BR><BR><HR>
<A NAME="47"></A><H4>47.
  
Template friend issues
</H4>
<B>Section: </B>13.7.5&#160; [<A href="https://wg21.link/temp.friend">temp.friend</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John H. Spicer
 &#160;&#160;&#160;

 <B>Date: </B>7 Nov 1997<BR>




<P><U>Issue 1</U></P>

<P>Paragraph 1 says that a friend of a class template can be a template.
Paragraph 2 says: A friend template may be declared within a non-template
class. A friend function template may be defined within a non-template
class.</P>

<P>I'm not sure what this wording implies about friend template definitions
within template classes. The rules for class templates and normal classes
should be the same: a function template can be declared or defined, but
a class template can only be declared in a friend declaration.</P>

<P><U>Issue 2</U></P>

<P>Paragraph 4 says: When a function is defined in a friend function declaration
in a class template, the function is defined when the class template is
first instantiated. I take it that this was intended to mean that a function
that is defined in a class template is not defined until the first instantiation.
I think this should say that a function that is defined in a class template
is defined each time the class is instantiated. This means that a function
that is defined in a class template must depend on all of the template
parameters of the class template, otherwise multiple definition errors
could occur during instantiations. If we don't have a rule like this, compilers
would have to compare the definitions of functions to see whether they
are the same or not. For example:</P>
<PRE>
    template &lt;class T&gt; struct A {
            friend int f() { return sizeof(T); }
    };

    A&lt;int&gt; ai;
    A&lt;long&gt; ac;
</PRE>
I hope we would all agree that this program is ill-formed, even if long
and int have the same size.

<P><U>From Bill Gibbons:</U></P>

<P>[1] That sounds right.</P>

<P>[2] Whenever possible, I try to treat instantiated class templates as
if they were ordinary classes with funny names. If you write:</P>
<PRE>
    struct A_int {
        friend int f() { return sizeof(int); }
    };
    struct A_long {
        friend int f() { return sizeof(long); }
    };
</PRE>
it is a redefinition (which is not allowed) and an ODR violation. And if
you write:
<PRE>
    template &lt;class T, class U&gt; struct A {
                friend int f() { return sizeof(U); }
    };

    A&lt;int,float&gt; ai;
    A&lt;long,float&gt; ac;
</PRE>
the corresponding non-template code would be:
<PRE>
    struct A_int_float {
        friend int f() { return sizeof(float); }
    };
    struct A_long_float {
        friend int f() { return sizeof(float); }
    };
</PRE>
then the two definitions of "<TT>f</TT>" are identical so there is no ODR
violation, but it is still a redefinition. I think this is just an editorial
clarification.

<P>
<B>Rationale (04/99):</B> The first sub-issue reflects wording that was
changed to address the concern before the IS was issued.  A close and
careful reading of the Standard already leads to the conclusion that the
example in the second sub-issue is ill-formed, so no change is needed.</P>
<BR><BR><HR>
<A NAME="1545"></A><H4>1545.
  
<TT>friend</TT> function templates defined in class templates
</H4>
<B>Section: </B>13.7.5&#160; [<A href="https://wg21.link/temp.friend">temp.friend</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-08-25<BR>




<P>The status of an example like the following is not clear:</P>

<PRE>
   template&lt;class&gt; struct x {
     template&lt;class T&gt;
     friend bool operator==(x&lt;T&gt;, x&lt;T&gt;) { return false; }
  };

  int main() {
    x&lt;int&gt; x1;
    x&lt;double&gt; x2;
    x1 == x1;
    x2 == x2;
  }
</PRE>

<P>Such a <TT>friend</TT> definition is permitted by
13.7.5 [<A href="https://wg21.link/temp.friend#2">temp.friend</A>] paragraph 2:</P>

<BLOCKQUOTE>

A friend function template may be defined within a class or class
template...

</BLOCKQUOTE>

<P>Paragraph 4 appears to be related, but deals only with friend functions,
not friend function templates:</P>

<BLOCKQUOTE>

When a function is defined in a friend function declaration in a class
template, the function is instantiated when the function is
odr-used. The same restrictions on multiple declarations and
definitions that apply to non-template function declarations and
definitions also apply to these implicit definitions.

</BLOCKQUOTE>

<P><B>Rationale (February, 2021):</B></P>

The resolution of <A HREF="cwg_defects.html#2174">issue 2174</A> deleted
the paragraph in question and makes clear the treatment of friend
function templates.

<BR><BR><HR>
<A NAME="2306"></A><H4>2306.
  
Nested friend templates of class templates
</H4>
<B>Section: </B>13.7.5&#160; [<A href="https://wg21.link/temp.friend">temp.friend</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2016-07-17<BR>


<P>The current wording is not clear how to declare that a nested
class template of a class template is a friend of its containing
template. For example, is</P>

<PRE>
  template &lt;class T&gt; struct C {
    template &lt;bool b&gt; class Foo;
    template &lt;bool b&gt; friend class Foo;
  };
</PRE>

<P>correct, or should it be</P>

<PRE>
  template &lt;class T&gt; struct C {
    template &lt;bool b&gt; class Foo;
    template &lt;class X&gt; template &lt;bool b&gt; friend class C&lt;X&gt;::Foo;
  };
</PRE>

<B><P>Rationale (June, 2018)</P></B>

<P>The submitter asked that the issue be withdrawn.</P>

<BR><BR><HR>
<A NAME="229"></A><H4>229.
  
Partial specialization of function templates
</H4>
<B>Section: </B>13.7.6&#160; [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dave Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>1 Apr 2000<BR>


<P>Library issue 225 poses the following questions:</P>

<OL>

<LI>How can a 3rd party library implementor (lib1) write a version of
a standard algorithm which is specialized to work with his own class
template? </LI>

<LI>How can another library implementor (lib2) write a generic
algorithm which will take advantage of the specialized algorithm in
lib1?</LI>

</OL>

<P>For example, a programmer might want to provide a version of
<TT>std::swap</TT> that would be used for any specialization of a
particular class template.  It is possible to do that for specific
types, but not for all specializations of a template.</P>

<P>The problem is due to the fact that programmers are forbidden to
add overloads to namespace <TT>std</TT>, although specializations are
permitted.  One suggested solution would be to allow partial
specialization of function templates, analogous to partial
specialization of class templates.</P>

<P>Library issue 225 contains a detailed proposal for adding partial
specialization of function templates (not reproduced here in the
interest of space and avoiding multiple-copy problems).  This Core
issue is being opened to provide for discussion of the proposal within
the core language working group.</P>

<P><B>Notes from 10/00 meeting:</B></P>

<P>A major concern over the idea of partial specialization of
function templates is that function templates can be overloaded,
unlike class templates.  Simply naming the function template in
the specialization, as is done for class specialization, is not
adequate to identify the template being specialized.</P>

<P>In view of this problem, the library working group is exploring
the other alternative, permitting overloads to be added to functions
in namespace <TT>std</TT>, as long as certain restrictions (to be
determined) are satisfied.</P>

<P>(See also documents N1295 and N1296 and
<A HREF="cwg_closed.html#285">issue 285</A>.)</P>

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

<P> The Core Working Group decided to ask the Library Working Group
for guidance on whether this feature is still needed to resolve a
library issue.  The answer at present is "we don't know."</P>

<P><B>Rationale (October, 2004):</B></P>

<P>The Core Working Group decided that the Evolution Working Group is
the appropriate forum in which to explore the desirability and form of
this feature.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group recommended closing this issue with no
further consideration.  See paper J16/07-0033 = WG21 N2173.</P>

<BR><BR><HR>
<A NAME="1754"></A><H4>1754.
  
Declaration of partial specialization of static data member template
</H4>
<B>Section: </B>13.7.6&#160; [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-09-19<BR>




<P>There does not appear to be a way to declare (not define) a partial
specialization of a static data member template outside its
class.  The rule for explicit specializations (13.9.4 [<A href="https://wg21.link/temp.expl.spec#13">temp.expl.spec</A>] paragraph 13)
 is that the presence or absence of an initializer determines
whether the explicit specialization is a definition or not.  Applying
this rule to the partial specialization case, however, would conflict with
being able to provide an initializer on the declaration within the class.</P>

<P>Do we need to support declaring partial specializations of static
data member templates outside their class?</P>

<P><B>Rationale (February, 2014):</B></P>

<P>CWG felt that this issue is more appropriately considered by EWG.</P>

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

<P>EWG has decided not to make a change in this area.  See EWG issue
132.</P>

<BR><BR><HR>
<A NAME="1577"></A><H4>1577.
  
Unnecessary restrictions on partial specializations
</H4>
<B>Section: </B>13.7.6.1&#160; [<A href="https://wg21.link/temp.spec.partial.general">temp.spec.partial.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jeremiah Wilcox
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-19<BR>


<P>One of the restrictions on partial specializations found in
13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#9">temp.spec.partial.general</A>] paragraph 9 is:</P>

<BLOCKQUOTE>

The template parameter list of a specialization shall not contain
default template argument values. [<I>Footnote:</I> There is no way in
which they could be used. &#8212;<I>end footnote</I>]

</BLOCKQUOTE>

<P>The rationale for this restriction is incorrect, since default
template argument values can be used to trigger SFINAE and thus
control whether a particular partial specialization is used.  An
example of this use is:</P>

<PRE>
    template &lt;typename T&gt; struct a;
    template &lt;typename T,
         typename = typename std::enable_if&lt;some property&gt;::type&gt;
    struct a&lt;std::vector&lt;T&gt;&gt; { ... };
</PRE>

<P>which is forbidden by this point.  Note also that an example like</P>

<PRE>
    template &lt;typename T&gt; struct b;
    template &lt;typename T,
         typename = typename std::enable_if&lt;some property&gt;::type&gt;
    struct b&lt;T&gt; { ... };
</PRE>

<P>is likely forbidden by the previous bullet:</P>

<BLOCKQUOTE>

The argument list of the specialization shall not be identical to the
implicit argument list of the primary template.

</BLOCKQUOTE>

<P>This restriction may also need to be weakened.</P>

<P><B>Rationale (April, 2013)</B></P>

<P>CWG felt that consideration of these suggestions was more appropriately
done by EWG.</P>

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

<P>EWG has decided not to make a change in this area.  See EWG issue
110.</P>

<BR><BR><HR>
<A NAME="1644"></A><H4>1644.
  
Equivalent <I>exception-specification</I>s in function template declarations
</H4>
<B>Section: </B>13.7.7.2&#160; [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-03-17<BR>




<P>Although 14.5 [<A href="https://wg21.link/except.spec#3">except.spec</A>] paragraph 3 says,</P>

<BLOCKQUOTE>

<P>Two <I>exception-specification</I>s are <I>compatible</I> if:</P>

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

<LI><P>both have the
form <TT>noexcept(</TT><I>constant-expression</I><TT>)</TT>
and the <I>constant-expression</I>s are equivalent,
or</P></LI>

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

</UL>

</BLOCKQUOTE>

<P>it is not clear whether &#8220;equivalent&#8221; in this context
should be taken as a reference to the definition of
<I>equivalent</I> given in 13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>] paragraph
5:</P>

<BLOCKQUOTE>

Two expressions involving template parameters are considered
<I>equivalent</I> if two function definitions containing the
expressions would satisfy the one definition rule
(6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]), except that the tokens used to
name the template parameters may differ as long as a token
used to name a template parameter in one expression is
replaced by another token that names the same template
parameter in the other expression.

</BLOCKQUOTE>

<P>since the context there is expressions that appear in function
template parameters and return types.</P>

<P>There is implementation variance on this question.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>The text in question no longer appears in the Standard.</P>

<BR><BR><HR>
<A NAME="23"></A><H4>23.
  
Some questions regarding partial ordering of function templates
</H4>
<B>Section: </B>13.7.7.3&#160; [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>unknown<BR>





<P><U><B>Issue 1:</B></U></P>

<P>13.7.7.3 [<A href="https://wg21.link/temp.func.order#2">temp.func.order</A>] paragraph 2
says:
<BLOCKQUOTE>Given two overloaded function templates, whether one is more
specialized than another can be determined by transforming each template
in turn and using argument deduction (13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
) to compare it to the other.</BLOCKQUOTE>
13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 now has 4 subsections describing argument deduction in different
situations. I think this paragraph should point to a subsection of
13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
.</P>

<P><B>Rationale:</B></P>

<P>This is not a defect; it is not necessary to pinpoint cross-references
to this level of detail.</P>

<P><B><U>Issue 2:</U></B></P>

<P>13.7.7.3 [<A href="https://wg21.link/temp.func.order#4">temp.func.order</A>] paragraph 4
says:</P>
<BLOCKQUOTE>Using the transformed function parameter list, perform argument
deduction against the other function template. The transformed template
is at least as specialized as the other if, and only if, the deduction
succeeds and the deduced parameter types are an exact match (so the deduction
does not rely on implicit conversions).</BLOCKQUOTE>
In "the deduced parameter types are an exact match", the terms exact match
do not make it clear what happens when a type T is compared to the reference
type T&amp;. Is that an exact match?



<P><B><U>Issue 3:</U></B></P>

<P>13.7.7.3 [<A href="https://wg21.link/temp.func.order#5">temp.func.order</A>] paragraph 5
says:</P>
<BLOCKQUOTE>A template is more specialized than another if, and only if,
it is at least as specialized as the other template and that template is
not at least as specialized as the first.</BLOCKQUOTE>
What happens in this case:
<PRE>
    template&lt;class T&gt; void f(T,int);
    template&lt;class T&gt; void f(T, T);
    void f(1,1);
</PRE>
For the first function template, there is no type deduction for the second
parameter. So the rules in this clause seem to imply that the second function
template will be chosen.

<P><B>Rationale:</B></P>

<P>This is not a defect; the standard unambiguously makes the above example
ill-formed due to ambiguity.</P>

<P><B>Additional note (April, 2011):</B></P>

<P>These points appear to have been addressed by previous resolutions,
so presumably the issue is now NAD.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>As given in the preceding note.</P>

<BR><BR><HR>
<A NAME="1520"></A><H4>1520.
  
Alias template specialization vs pack expansion
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Eric Niebler
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-09<BR>




<P>The relative order of template parameter pack expansion and
alias template substitution is not clear in the current wording.  For
example, in</P>

<PRE>
  template&lt;typename T&gt; using Int = int;

  template&lt;typename ...Ts&gt; struct S {
    typedef S&lt;Int&lt;Ts&gt;...&gt; other;
  };
</PRE>

<P>it is not clear whether <TT>int</TT> is substituted for
<TT>Int&lt;Ts&gt;</TT> first, leaving the ellipsis with no parameter
pack to expand, or whether the pack expansion is to be applied first,
producing a list of specializations of <TT>Int&lt;T&gt;</TT>.</P>

<P>(See also <A HREF="cwg_defects.html#1558">issue 1558</A>.)</P>

<P><B>Rationale (October, 2012):</B></P>

<P>The latter interpretation (a list of specializations) is the correct
interpretation; a parameter pack can't be substituted into anything,
including an alias template specialization.  CWG felt that this is
clear enough in the current wording.</P>

<BR><BR><HR>
<A NAME="560"></A><H4>560.
  
Use of the <TT>typename</TT> keyword in return types
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Greg Comeau
 &#160;&#160;&#160;

 <B>Date: </B>11 February 2006<BR>


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

<PRE>
    template &lt;class T&gt; struct Outer {
        struct Inner {
            Inner* self();
        };
    };
    template &lt;class T&gt; Outer&lt;T&gt;::Inner*
        Outer&lt;T&gt;::Inner::self() { return this; }
</PRE>

<P>According to 13.8 [<A href="https://wg21.link/temp.res#3">temp.res</A>] paragraph 3 (before the
salient wording was inadvertently removed, see
<A HREF="cwg_defects.html#559">issue 559</A>),</P>

<BLOCKQUOTE>

A <I>qualified-id</I> that refers to a type and in which the
<I>nested-name-specifier</I> depends on a <I>template-parameter</I>
(13.8.3 [<A href="https://wg21.link/temp.dep">temp.dep</A>]) but does not refer to a member of the
current instantiation (13.8.3.2 [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]) shall be
prefixed by the keyword <TT>typename</TT> to indicate that
the <I>qualified-id</I> denotes a type, forming
a <I>typename-specifier</I>.

</BLOCKQUOTE>

<P>Because <TT>Outer&lt;T&gt;::Inner</TT> is a member of the current
instantiation, the Standard does not currently require that it be
prefixed with <TT>typename</TT> when it is used in the return type of
the definition of the <TT>self()</TT> member function.  However, it is
difficult to parse this definition correctly without knowing that the
return type is, in fact, a type, which is what the <TT>typename</TT>
keyword is for.  Should the Standard be changed to require
<TT>typename</TT> in such contexts?</P>



<P><B>Rationale (February, 2021):</B></P>

<P>The current wording of 13.8.1 [<A href="https://wg21.link/temp.res.general">temp.res.general</A>]
bullet 5.2.1 makes clear that the <TT>typename</TT> keyword
is not required for the given example.</P>

<BR><BR><HR>
<A NAME="1162"></A><H4>1162.
  
Dependent <I>elaborated-type-specifier</I>s in non-deduced contexts
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#CA6">N3092 comment
  CA&#160;6<BR></A>

<P>The following appears to be well-formed, with templates
<TT>foo()</TT> being distinct since any type <TT>T</TT> will
produce an invalid type for the second parameter for at
least one <TT>foo()</TT> when <TT>T</TT> is replaced within
the non-deduced context:</P>

<PRE>
    template &lt;typename T&gt;
      bool *foo(T *, enum T::u_type * = 0) { return 0; }
    template &lt;typename T&gt;
      char *foo(T *, struct T::u_type * = 0) { return 0; }
    struct A { enum u_type { I }; };
    int main(void) { foo((A*)0); }
</PRE>

<P>In particular, while determining the signature
for the function templates <TT>foo()</TT>, an
<I>elaborated-type-specifier</I> qualifies as part of the
<I>decl-specifier-seq</I> under 9.3.4.6 [<A href="https://wg21.link/dcl.fct#5">dcl.fct</A>] paragraph 5
in determining the type of a parameter in the
parameter-type-list (absent additional wording).  Also, the
return type is included in the signature of a function
template.</P>

<P>Implementations do not appear to support this case and
the ability to do so brings little value since type traits
such as <TT>is_enum</TT> and <TT>is_class</TT> cannot be
defined using this and equivalent functionality can be
achieved using the aforementioned type traits.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>The specification is as intended; compilers should handle
cases like these.</P>

<BR><BR><HR>
<A NAME="1483"></A><H4>1483.
  
Non-dependent <I>static_assert-declaration</I>s
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-03-23<BR>


<P>Recently a customer sent us code of the form,</P>

<PRE>
  template&lt;typename T&gt; void f();
  template&lt;&gt; void f&lt;int&gt;() { }
  template&lt;typename T&gt; void f() {
    static_assert(false, "f() instantiated with non-int type.");
  }
</PRE>

<P>The intent, obviously, was to do compile-time diagnosis of
specializations of the template that were not supported, and code of
this form is supported by at least some implementations. However,
the current wording of 13.8 [<A href="https://wg21.link/temp.res#8">temp.res</A>] paragraph 8,
appears to invalidate this approach:</P>

<BLOCKQUOTE>

If no valid specialization can be generated for a template, and that
template is not instantiated, the template is ill-formed, no
diagnostic required.

</BLOCKQUOTE>

<P>In this example, the <TT>static_assert</TT> will fail for every
generated specialization of <TT>f()</TT>, so an implementation can
issue the error, regardless of whether <TT>f()</TT> is ever
instantiated with a non-<TT>int</TT> type or not.</P>

<P>A relatively straightforward but somewhat ugly workaround is to
define a template like</P>

<PRE>
  template&lt;typename&gt; struct always_false {
    static const bool val = false;
  };
</PRE>

<P>and replace the use of <TT>false</TT> in the <TT>static_assert</TT>
with <TT>always_false&lt;T&gt;::val</TT>, making the <TT>static_assert</TT>
dependent.</P>

<P>Considering the fact that a non-dependent
<I>static_assert-declaration</I> in a template is otherwise pretty
useless, however, it might be worth considering whether to support
this usage somehow, especially in light of the fact that it is
supported by some implementations, perhaps by treating
<I>static_assert-declaration</I>s as always dependent, even if the
condition is not otherwise dependent.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>Although this usage is supported by some implementations and used
in some libraries, CWG felt that <TT>=delete</TT> is the appropriate
mechanism for making a function template or member function of a class
template unavailable for specialization.</P>

<BR><BR><HR>
<A NAME="1547"></A><H4>1547.
  
<TT>typename</TT> keyword in <I>alias-declaration</I>s
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-09-01<BR>




<P>Given that the <I>type-id</I> in an <I>alias-declaration</I> is
unambiguously a type, is there a reason to require the <TT>typename</TT>
keyword for dependent types appearing there?  In other contexts where a
dependent name can only be a type (e.g., in a <I>base-specifier</I>),
the keyword can/must be omitted.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>CWG felt that having a simple rule (advising use of <TT>typename</TT>
with all dependent nested types wherever syntactically permitted) was
more important than reducing the number of contexts in which the
requirement applied.</P>

<BR><BR><HR>
<A NAME="1785"></A><H4>1785.
  
Conflicting diagnostic requirements for template definitions
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-09-28<BR>


<P>According to 13.8 [<A href="https://wg21.link/temp.res#8">temp.res</A>] paragraph 8,</P>

<BLOCKQUOTE>

No diagnostic shall be issued for a template for which a valid
specialization can be generated.

</BLOCKQUOTE>

<P>One sentence later, it says,</P>

<BLOCKQUOTE>

If every valid specialization of a variadic template requires an empty
template parameter pack, the template is ill-formed, no diagnostic
required.

</BLOCKQUOTE>

<P>This appears to be a contradiction: in the latter case, there is
postulated to exist a &#8220;valid&#8221; specialization (with an empty
pack expansion), for which a diagnostic might or might not be issued.  The
first quoted sentence, however, forbids issuing a diagnostic for a template
that has at least one valid specialization.</P>



<P><B>Rationale (February, 2017):</B></P>

<P>The text in question was revised editorially and the issue is now
moot.</P>

<BR><BR><HR>
<A NAME="1974"></A><H4>1974.
  
Redundant specification of non-type <I>typename-specifier</I>
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-07-17<BR>




<P>Paragraphs 3-4 of 13.8 [<A href="https://wg21.link/temp.res">temp.res</A>] read, in part,</P>

<BLOCKQUOTE>

<P>When a <I>qualified-id</I> is intended to refer to a type
that is not a member of the current instantiation
(13.8.3.2 [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]) and
its <I>nested-name-specifier</I> refers to a dependent type,
it shall be prefixed by the keyword <TT>typename</TT>, forming
a <I>typename-specifier</I>. If the <I>qualified-id</I> in
a <I>typename-specifier</I> does not denote a type, the
program is ill-formed.</P>

<P>If a specialization of a template is instantiated for a set
of <I>template-argument</I>s such that
the <I>qualified-id</I> prefixed by typename does not denote
a type, the specialization is ill-formed.</P>

</BLOCKQUOTE>

<P>The former requirement is intended to apply to the definition
and the latter to an instantiation of a template, but that intent
is not completely clear, leading to the perception that they are
redundant.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>The specification, now found in 13.8.1 [<A href="https://wg21.link/temp.res.general">temp.res.general</A>],
particularly in bullet 8.5, is clearer in this regard.</P>

<BR><BR><HR>
<A NAME="316"></A><H4>316.
  
Injected-class-name of template used as template template parameter
</H4>
<B>Section: </B>13.8.2&#160; [<A href="https://wg21.link/temp.local">temp.local</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>14 Oct 2001<BR>




<P>A gcc hacker recently sent in a patch to make the compiler give an error on
code like this:
<PRE>
  template &lt;template &lt;typename&gt; class T&gt; struct A { };

  template &lt;typename U&gt; struct B
  {
    A&lt;B&gt; *p;
  };
</PRE>
presumably because the DR from <A HREF="cwg_defects.html#176">issue 176</A>
says that we decide whether or not
B is to be treated as a template depending on whether a
template-argument-list is supplied.  I think this is a drafting oversight,
and that B should also be treated as a template when passed as a template
template parameter.  The discussion in the issue list only talks about
making the name usable both as a class and as a template.</P>

<P>
<U>John Spicer</U>:
This case was explicitly discussed and it was agreed that to use the injected
name as a template template parameter you need to use the non-injected
name.</P>

<P>A (possibly unstated) rule that I've understood about template
arguments is that
the form of the argument (type/nontype/template) is based only on the
argument and not on the kind of template parameter.  An example is that
"<TT>int()</TT>" is always "function taking no arguments returning int"
and never a convoluted way of saying zero.</P>

<P>In a similar way, we now decide whether or not something is a template based
only on the form of the argument.</P>

<P>I think this rule is important for two kinds of cases.  The first case
involves explicit arguments of function templates:</P>
<PRE>
  template &lt;template &lt;typename&gt; class T&gt; void f(){} // #1
  template &lt;class T&gt; void f(){}  // #2

  template &lt;typename U&gt; struct B {
	void g() {
		f&lt;B&gt;();
	}
  };

  int main() {
	B&lt;int&gt; b;
	b.g();
  }
</PRE>
<P>With the current rules, this uses B as a type argument to template #2.</P>

<P>The second case involves the use of a class template for which the template
parameter list is unknown at the point where the argument list is scanned:</P>
<PRE>
  template &lt;class T&gt; void f(){}

  template &lt;typename U&gt; struct B {
	void g() {
		f&lt; U::template X&lt;B&gt; &gt;();  // what is B?
	}
  };

  struct Z1 {
	template &lt;class T&gt; struct X {};
  };

  struct Z2 {
	template &lt;template &lt;class&gt; class T&gt; struct X {};
  };

  int main() {
	B&lt;Z1&gt; b1;
	b1.g();

	B&lt;Z2&gt; b2;
	b2.g();
  }
</PRE>
<P>If B could be used as a template name we would be
unable to decide how to treat
B at the point that it was scanned in the template argument list.</P>

<P>So, I think it is not an oversight and that it should be
left the way it is.</P>

<P><B>Notes from the 4/02 meeting:</B></P>

It was agreed that this is Not a Defect.

<BR><BR><HR>
<A NAME="459"></A><H4>459.
  
Hiding of template parameters by base class members
</H4>
<B>Section: </B>13.8.2&#160; [<A href="https://wg21.link/temp.local">temp.local</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2 Feb 2004<BR>


<P>Currently, member of nondependent base classes hide
references to template parameters in the definition
of a derived class template.</P>

<P>Consider the following example:</P>
<PRE>
   class B {
      typedef void *It;    // (1)
      // ...
    };

    class M: B {};

    template&lt;typename&gt; X {};

    template&lt;typename It&gt; struct S   // (2)
        : M, X&lt;It&gt; {   // (3)
      S(It, It);   // (4)
      // ...
    };
</PRE>
<P>As the C++ language currently stands, the name "It"
in line (3) refers to the template parameter declared
in line (2), but the name "It" in line (4) refers to
the typedef in the private base class (declared in
line (1)).</P>

<P>This situation is both unintuitive and a hindrance
to sound software engineering.  (See also the Usenet
discussion at http://tinyurl.com/32q8d .)  Among
other things, it implies that the private section
of a base class may change the meaning of the derived
class, and (unlike other cases where such things
happen) there is no way for the writer of the derived
class to defend the code against such intrusion (e.g.,
by using a qualified name).</P>

<P>Changing this can break code that is valid today.
However, such code would have to:
<OL>
<LI>
name a template parameter and not use it
         after the opening brace, and
</LI>
<LI>
use that same name to access a base-class
         name within the braces.
</LI>
</OL>
I personally have no qualms breaking such a program.</P>

<P>It has been suggested to make situations like these
ill-formed.  That solution is unattractive however
because it still leaves the writer of a derived class
template without defense against accidental name
conflicts with base members.  (Although at least the
problem would be guaranteed to be caught at compile
time.)  Instead, since just about everyone's intuition
agrees, I would like to see the rules changed to
make class template parameters hide members of the
same name in a base class.</P>

<P>See also <A HREF="cwg_defects.html#458">issue 458</A>.</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>We have some sympathy for a change, but the current rules fall
straightforwardly out of the lookup rules, so they're not
&#8220;wrong.&#8221; Making private members invisible also would solve
this problem.  We'd be willing to look at a paper proposing that.</P>

<P><B>Additional discussion (April, 2005):</B></P>



<P>
<U>John Spicer</U>: Base class members are more-or-less treated as
members of the class, [so] it is only natural that the base [member]
would hide the template parameter.</P>

<P>
<U>Daveed Vandevoorde</U>: Are base class members really
&#8220;more or less&#8221; members of the class from a lookup
perspective?  After all, derived class members can hide base class
members of the same name.  So there is some pretty definite
boundary between those two sets of names.  IMO, the template
parameters should either sit between those two sets, or they
should (for lookup purposes) be treated as members of the class
they parameterize (I cannot think of a practical difference
between those two formulations).</P>

<P>
<U>John Spicer</U>: How is [hiding template parameters]
different from the fact that namespace members can be hidden
by private parts of a base class?  The addition of <TT>int C</TT>
to <TT>N::A</TT> breaks the code in namespace <TT>M</TT> in this
example:</P>

<PRE>
    namespace N {
       class A {
    private:
         int C;
       };
    }

    namespace M {
       typedef int C;
       class B : public N::A {
         void f() {
             C c;
         }
       };
    }
</PRE>

<P>
<U>Daveed Vandevoorde</U>: C++ has a mechanism in place to handle
such situations: qualified names.  There is no such mechanism in place
for template parameters.</P>

<P>
<U>Nathan Myers</U>: What I see as obviously incorrect ... is
simply that a name defined right where I can see it, and directly
attached to the textual scope of <TT>B</TT>'s class body, is ignored
in favor of something found in some other file.  I don't care that
<TT>C1</TT> is defined in <TT>A</TT>, I have a <TT>C1</TT> right
here that I have chosen to use.  If I want <TT>A::C1</TT>, I can
say so.</P>

<P>I doubt you'll find any regular C++ coder who doesn't find the
standard behavior bizarre.  If the meaning of any code is changed
by fixing this behavior, the overwhelming majority of cases will
be mysterious bugs magically fixed.</P>

<P>
<U>John Spicer</U>: I have not heard complaints that this is
actually a cause of problems in real user code.  Where is the
evidence that the status quo is actually causing problems?</P>

<P>In this example, the <TT>T2</TT> that is found is the one from
the base class.  I would argue that this is natural because base
class members are found as part of the lookup in class <TT>B</TT>:</P>

<PRE>
    struct A {
             typedef int T2;
    };
    template &lt;class T2&gt; struct B : public A {
             typedef int T1;
             T1 t1;
             T2 t2;
    };
</PRE>

<P>This rule that base class members hide template parameters was
formalized about a dozen years ago because it fell out of the
principle that base class members should be found at the same
stage of lookup as derived class members, and that to do otherwise
would be surprising.</P>

<P>
<U>Gabriel Dos Reis</U>: The bottom line is that:</P>

<OL>

<LI>the proposed change is a <B>silent</B> change of meaning;</LI>

<LI>the proposed change does not make the language any more regular;
the current behavior is consistent with everything else, however
&#8220;surprising&#8221; that might be;</LI>

<LI>the proposed change does have its own downsides.</LI>

</OL>

<P>Unless presented with real major programming problems the current
rules exhibit, I do not think the simple rule &#8220;scopes
nest&#8221; needs a change that silently mutates program meaning.</P>

<P>
<U>Mike Miller</U>: The rationale for the current specification is
really very simple:</P>

<OL>

<LI>&#8220;Unless redeclared in the derived class, members of a base
class are also considered to be members of the derived class.&#8221;
(11.7 [<A href="https://wg21.link/class.derived#2">class.derived</A>] paragraph 2)</LI>

<LI>In class scope, members hide nonmembers.</LI>

</OL>

<P>That's it.  Because template parameters are not members, they
are hidden by member names (whether inherited or not).  I don't find
that &#8220;bizarre,&#8221; or even particularly surprising.</P>

<P>I believe these rules are straightforward and consistent, so I
would be opposed to changing them.  However, I am not unsympathetic
toward Daveed's concern about name hijacking from base classes.  How
about a rule that would make a program ill-formed if a direct or
inherited member hides a template parameter?</P>

<P>Unless this problem is a lot more prevalent than I've heard so
far, I would not want to change the lookup rules; making this kind of
collision a diagnosable error, however, would prevent hijacking
without changing the lookup rules.</P>

<P>
<U>Erwin Unruh</U>: I have a different approach that is consistent
and changes the interpretation of the questionable code.  At present
lookup is done in this sequence:</P>

<UL>
block scope<BR>
derived class scope<BR>
base class scope<BR>
template parameters<BR>
namespace scope
</UL>

<P>If we change this order to</P>

<UL>
template parameters<BR>
block scope<BR>
derived class scope<BR>
base class scope<BR>
namespace scope<BR>
</UL>

<P>it is still consistent in that no lookup is placed between the base
class and the derived class.  However, it introduces another
inconsistency: now scopes do not nest the same way as curly braces
nest &#8212; but base classes are already inconsistent this way.</P>

<P>
<U>Nathan Myers</U>: This looks entirely satisfactory.  If even this
seems like too big a change, it would suffice to say that finding a
different name by this search order makes the program ill-formed.
Of course, a compiler might issue only a portability warning in that
case and use the name found Erwin's way, anyhow.</P>

<P>
<U>Gabriel Dos Reis</U>: It is a simple fact, even without
templates, that a writer of a derived class cannot protect himself
against declaration changes in the base class.</P>

<P>
<U>Richard Corden</U>: If a change is to be made, then making it
ill-formed is better than just changing the lookup rules.</P>

<PRE>
    struct B
    {
      typedef int T;
      virtual void bar (T const &amp; );
    };

    template &lt;typename T&gt;
    struct D : public B
    {
      virtual void bar (T const &amp; );
    };

    template class D&lt;float&gt;;
</PRE>

<P>I think changing the semantics of the above code silently would
result in very difficult-to-find problems.</P>

<P>
<U>Mike Miller</U>: Another case that may need to be considered in
deciding on Erwin's suggestion or the &#8220;ill-formed&#8221;
alternative is the treatment of <TT>friend</TT> declarations
described in 6.5.3 [<A href="https://wg21.link/basic.lookup.unqual#10">basic.lookup.unqual</A>] paragraph 10:</P>

<PRE>
    struct A {
        typedef int T;
        void f(T);
    };
    template&lt;typename T&gt; struct B {
        friend void A::f(T);  //<SPAN CLASS="cmnt"> Currently </SPAN>T<SPAN CLASS="cmnt"> is </SPAN>A::T
    };
</PRE>

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

<P>The CWG decided not to consider a change to the existing rules at
this time without a paper exploring the issue in more detail.</P>

<P><B>CWG 2023-12-01</B></P>

<P>CWG has no consensus to pursue a change in this area, without prejudice to a potential future paper addressed to EWG.</P>

<BR><BR><HR>
<A NAME="544"></A><H4>544.
  
Base class lookup in explicit specialization
</H4>
<B>Section: </B>13.8.3&#160; [<A href="https://wg21.link/temp.dep">temp.dep</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>01 November 2005<BR>


<P>There is some question as to whether 13.8.3 [<A href="https://wg21.link/temp.dep#3">temp.dep</A>] paragraph 3
applies to the definition of an explicitly-specialized
member of a class template:</P>

<BLOCKQUOTE>

In the definition of a class template or a member of a class template,
if a base class of the class template depends on
a <I>template-parameter</I>, the base class scope is not examined
during unqualified name lookup either at the point of definition of
the class template or member or during an instantiation of the class
template or member.

</BLOCKQUOTE>

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

<PRE>
    template &lt;class T&gt;
    struct A {
     void foo() {}
    };

    template &lt;class T&gt;
    struct B: A&lt;T&gt; {
     int bar();
    };

    int foo() { return 0; }

    template &lt;&gt;
    int B&lt;int&gt;::bar() { return foo(); }

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

<P>Does <TT>foo</TT> in the definition of <TT>B&lt;int&gt;::bar()</TT>
refer to <TT>::foo()</TT> or to <TT>A&lt;int&gt;::foo()</TT>?</P>

<P><B>Rationale (April, 2006):</B></P>

<P>An explicitly-specialized member of a class template is not, in
fact, a member of a class template but a member of a particular
specialization of that template.  The special treatment of lookup
vis-a-vis dependent base classes in 13.8.3 [<A href="https://wg21.link/temp.dep">temp.dep</A>]
thus does not apply, and base class members are found by unqualified
name lookup.</P>

<BR><BR><HR>
<A NAME="1281"></A><H4>1281.
  
Virtual and dependent base classes
</H4>
<B>Section: </B>13.8.3.2&#160; [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-03-28<BR>




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

<PRE>
  struct A {
   virtual void f() { /* base */ }
  };

  struct B : virtual A {
   virtual void f() { /* derived */ }
  };

  template&lt;typename T&gt;
  struct C : virtual A, T {
   void g() {
    this-&gt;f();
   }
  };

  int main() {
   C&lt;B&gt; c;
   c.g();
  }

</PRE>

<P>This is reasonable C++03 code that is invalidated by the resolution
of <A HREF="cwg_defects.html#1043">issue 1043</A>. In the presence of virtual
non-dependent base classes and other dependent base classes, one
cannot rely on something being found for real when doing the lookup in
the instantiation context (therefore, one cannot know whether a
"typename" is actually valid or not, without knowing all dependent
base classes).</P>

<P><B>Rationale (August, 2011):</B></P>

<P>This example is not sufficient motivation to revisit the outcome of
<A HREF="cwg_defects.html#1043">issue 1043</A>.  <TT>((T*)this)-&gt;f()</TT> can
be used to allow lookup in a dependent base.</P>

<BR><BR><HR>
<A NAME="1289"></A><H4>1289.
  
Can an alias template name the current instantiation?
</H4>
<B>Section: </B>13.8.3.2&#160; [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-04-06<BR>




<P>It does not appear to be possible to use the name of an alias template
(without a template argument list) to refer to the current instantiation.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The rules are as intended.</P>

<BR><BR><HR>
<A NAME="1905"></A><H4>1905.
  
Dependent types and injected-class-names
</H4>
<B>Section: </B>13.8.3.2&#160; [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-03-29<BR>




<P>According to 13.8.2 [<A href="https://wg21.link/temp.local#1">temp.local</A>] paragraph 1, when the
injected-class-name of a class template is not followed by a
<I>template-argument-list</I> or otherwise used as a
<I>template-name</I>,</P>

<BLOCKQUOTE>

it is equivalent to the <I>template-name</I> followed by
the <I>template-parameter</I>s of the class template enclosed
in <TT>&lt;&gt;</TT>.

</BLOCKQUOTE>

<P>This use of the <I>template-parameter</I>s of the class template
should make the injected-class-name a dependent type; however, the
definition of dependent types in 13.8.3.2 [<A href="https://wg21.link/temp.dep.type#8">temp.dep.type</A>] paragraph 8
applies to the injected-class-name only when it appears
in a <I>simple-template-id</I>.  An additional case is needed for
the bare injected-class-name.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>The fact that the use of the bare injected-class-name is
described as &#8220;equivalent&#8221; to
the <I>simple-template-id</I> is sufficiently clear regarding its
status that no additional entry is needed in the list of
dependent types.</P>

<BR><BR><HR>
<A NAME="334"></A><H4>334.
  
Is a comma-expression dependent if its first operand is?
</H4>
<B>Section: </B>13.8.3.3&#160; [<A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>10 Jan 2002<BR>


<P>Is the comma expression in the following dependent?</P>
<PRE>
  template &lt;class T&gt; static void f(T)
  {
  }
  template &lt;class T&gt; void g(T)
  {
    f((T::x, 0));
  }
  struct A {
    static int x;
  };
  void h()
  {
    g(A());
  }
</PRE>
<P>According to the standard, it is, because 13.8.3.3 [<A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>]
says that an expression is dependent if any of its sub-expressions is
dependent, but there is a question about whether the language should
say something different.  The type and value of the expression are not really
dependent, and similar cases (like casting <TT>T::x</TT>
to <TT>int</TT>) are not dependent.</P>

<P>
<U>Mark Mitchell:</U> If the first operand is dependent, how
do we know it does not have an overloaded comma operator?</P>

<P><B>Rationale (October, 2004):</B></P>

<P>CWG agreed that such comma expressions are and ought to be
dependent, for the reason expressed in Mark Mitchell's
comment.</P>

<BR><BR><HR>
<A NAME="34"></A><H4>34.
  
Argument dependent lookup and points of instantiation
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>15 Jul 1998<BR>





<P>Does Koenig lookup create a point of instantiation for class types?
I.e., if I say:</P>
<PRE>
    TT&lt;int&gt; *p;
    f(p);
</PRE>
The namespaces and classes associated with <TT>p</TT> are those associated with
the type pointed to, i.e., <TT>TT&lt;int&gt;</TT>. However, to determine those
I need to know <TT>TT&lt;int&gt;</TT> bases and its friends, which requires
instantiation.

<P>Or should this be special cased for templates?</P>

<P>
<B>Rationale:</B>
The standard already specifies that this creates a point of instantiation.</P>
<BR><BR><HR>
<A NAME="489"></A><H4>489.
  
Must member function templates be instantiated during overload resolution?
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>24 Nov 2004<BR>


<P>A related question to that raised in <A HREF="cwg_defects.html#488">issue 488</A> is whether member function templates must be
instantiated if the compiler can determine that they will not be
needed by the function selected by overload resolution.  That is
explicitly specified for class templates in 13.9.2 [<A href="https://wg21.link/temp.inst#5">temp.inst</A>] paragraph 5:</P>

<BLOCKQUOTE>

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

</BLOCKQUOTE>

<P>Should the same be true for member function templates?  In the
example from <A HREF="cwg_defects.html#488">issue 488</A>,</P>

<PRE>
    struct S {
        template &lt;typename T&gt; S(const T&amp;);
    };
    void f(const S&amp;);
    void f(int);
    void g() {
        enum E { e };
        f(e);    // ill-formed?
    }
</PRE>

<P>a compiler could conceivably determine that <TT>f(int)</TT>
would be selected by overload resolution (because it involves
only an integral promotion, while the alternative requires a
user-defined conversion) without instantiating the declaration of
the <TT>S</TT> constructor.  Should the compiler have that
freedom?</P>

<P><B>Rationale (April, 2005):</B></P>

<P>In order for this question to come up, there would need to be a
&#8220;gap&#8221; between the the normal rules and the rules for
template argument deduction failure.  The resolution for
<A HREF="cwg_defects.html#488">issue 488</A> will close the only such
gap of which the CWG is aware.  The issue can be reopened if other
such cases turn up.</P>

<BR><BR><HR>
<A NAME="2655"></A><H4>2655.
  
Instantiation of default arguments in <I>lambda-expression</I>s
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Tom Honermann
 &#160;&#160;&#160;

 <B>Date: </B>2022-08-16<BR>


<P>Subclause 7.5.6.2 [<A href="https://wg21.link/expr.prim.lambda.closure#2">expr.prim.lambda.closure</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

The closure type is declared in the smallest block scope, class scope,
or namespace scope that contains the
corresponding <I>lambda-expression</I>.

</BLOCKQUOTE>

<P>This means the closure type is a local class if
the <I>lambda-expression</I> appears at function scope.  A note in
13.9.2 [<A href="https://wg21.link/temp.inst#2">temp.inst</A>] paragraph 2 claims that default arguments
inside local classes are not separately instantiated:</P>

<BLOCKQUOTE>

[<I>Note 3:</I> Within a template declaration, a local class
(11.6 [<A href="https://wg21.link/class.local">class.local</A>]) or enumeration and the members of a local
class are never considered to be entities that can be separately
instantiated (this includes their default
arguments, <I>noexcept-specifier</I> s, and non-static data member
initializers, if any, but not their <I>type-constraint</I>s
or <I>requires-clause</I>s). As a result, the dependent names are
looked up, the semantic constraints are checked, and any templates
used are instantiated as part of the instantiation of the entity
within which the local class or enumeration is declared. &#8212;<I>end
note</I>]

</BLOCKQUOTE>

<P>However, 13.9.2 [<A href="https://wg21.link/temp.inst#3">temp.inst</A>] paragraph 3 is not in harmony
with the note:</P>

<BLOCKQUOTE>

The implicit instantiation of a class template specialization does not
cause the implicit instantiation of default arguments
or <I>noexcept-specifier</I> s of the class member functions.

</BLOCKQUOTE>

<P>Example:</P>

<PRE>
  template&lt;typename T&gt;
  void ft() {
   [](T p = T::value) {}; //<SPAN CLASS="cmnt"> error even though the lambda is never called</SPAN>
  }
  template void ft&lt;int&gt;();
</PRE>

<P>Even for a lambda declared at namespace scope is an unused default
argument instantiated by major implementations:</P>

<PRE>
  template&lt;typename T&gt;
  using ta = decltype([](T p = T::value) { //<SPAN CLASS="cmnt"> error</SPAN>
	     return p;
	    });
  auto g = ta&lt;int&gt;{}(0);
</PRE>

<P><B>CWG 2023-11-11</B></P>

<P>The behavior is as intended.  Note that 13.9.2 [<A href="https://wg21.link/temp.inst#3">temp.inst</A>] paragraph 3 applies to a class template specialization and its member
functions.  The examples do not involve class templates, but merely
templated classes.</P>


<BR><BR><HR>
<A NAME="2893"></A><H4>2893.
  
Instantiations in discarded <TT>if constexpr</TT> substatements
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2024-05-09<BR>




<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/535">#535</A>.)</P>

<P>Consider:</P>

<PRE>
  void g() {
    auto f = [](auto s) {
      s.x = 0;
    };
    if constexpr (false) {
      f(0);   //<SPAN CLASS="cmnt"> well-formed?</SPAN>
    }
  }
</PRE>

<P>Note that the lambda has a deduced return type, yet per the current
wording, <TT>f</TT> is not instantiated here.</P>

<P><U>Possible resolution:</U></P>

<P>Add a new paragraph before 13.9.2 [<A href="https://wg21.link/temp.inst#9">temp.inst</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

<P class="ins">The existence of a definition of a function is
considered to affect the semantics of the program if the function is
named by an expression (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) and the function's
declared return type is a placeholder type
(9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]).
[ Example:
</P>

<PRE class="ins">
  void g() {
    auto f = [](auto s) {
      s.x = 0;  // <SPAN CLASS="cmnt">#1</SPAN>
    };
    if constexpr (false) {
      f(0);     //<SPAN CLASS="cmnt"> error at #1: type </SPAN>int<SPAN CLASS="cmnt"> has no member named </SPAN>x
    }
  }
</PRE>
<P class="ins"> -- end example ]</P>

<P>If the function selected by overload resolution
(12.2 [<A href="https://wg21.link/over.match">over.match</A>]) can be determined without ...</P>

</BLOCKQUOTE>

<P><B>CWG 2024-06-14</B></P>

<P>The original example involving a deduced return type of the lambda
is ill-formed, because the semantics of the program are affected by
its return type, and thus an instantion is required
(13.9.2 [<A href="https://wg21.link/temp.inst#5">temp.inst</A>] paragraph 5): If the lambda returned a class
type with a private destructor, the program would be ill-formed.</P>

<P>The modified example with a <TT>void</TT> return type of the lambda
is well-formed; clang's implementation divergence is believed to be a
bug.</P>

<P>As a side note, odr-use is not affected by discarded statements;
just some of the effects of odr-use do not materialize
(6.3 [<A href="https://wg21.link/basic.def.odr#12">basic.def.odr</A>] paragraph 12).</P>

<BR><BR><HR>
<A NAME="46"></A><H4>46.
  
Explicit instantiation of member templates
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John H. Spicer
 &#160;&#160;&#160;

 <B>Date: </B>28 Jan 1998<BR>



<P>Is the second explicit instantiation below well-formed?</P>
<PRE>
    template &lt;class T&gt; struct A {
        template &lt;class T2&gt; void f(T2){}
    };

    template void A&lt;int&gt;::f(char); // okay

    template template void A&lt;int&gt;::f(float); // ?
</PRE>
Since multiple "<TT>template&lt;&gt;</TT>" clauses are permitted in an explicit
specialization, it might follow that multiple "<TT>template</TT>" keywords
should also be permitted in an explicit instantiation. Are multiple "<TT>template</TT>"
keywords not allowed in an explicit instantiation? The grammar permits
it, but the grammar permits <B>lots</B> of stuff far weirder than that.
My opinion is that, in the absence of explicit wording permitting that
kind of usage (as is present for explicit specializations) that such usage
is not permitted for explicit instantiations.

<P>
<B>Rationale (04/99):</B> The Standard does not describe the meaining
of multiple <TT>template</TT> keywords in this context, so the example
should be considered as resulting in undefined behavior according to
Clause 3 [<A href="https://wg21.link/intro.defs">intro.defs</A>] &#8220;<B>undefined behavior</B>.&#8221;</P>
<BR><BR><HR>
<A NAME="1045"></A><H4>1045.
  
Requiring explicit instantiation declarations
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-05<BR>




<P>The current language specification allows suppression of implicit
instantiations of templates via an explicit instantiation declaration;
if all uses of a particular specialization follow an explicit
instantiation declaration for that specialization, and there is one
explicit instantiation definition in the program, there will be only
a single copy of that instance.  However, the Standard does not require
the presence of an explicit instantiation declaration prior to use, so
implementations must still be prepared (using weak symbols, for example)
to handle multiple copies of the instance at link time.  This can be
a significant overhead, particularly in shared libraries where weak
symbols must be resolved at load time.  Requiring the presence of an
explicit instantiation declaration in every translation unit in which
the specialization is used would allow the compiler to emit strong
symbols for the explicit instantiation definition and reduce the
overhead.</P>

<P>On the other hand, the current definition allows use of multiple
independent libraries with explicit instantiation directives of the
same specializations (from a common third-party library, for instance),
as well as incremental migration of libraries to use of explicit
instantiation declarations rather than requiring all libraries to
be updated at once.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>CWG prefers the current specification.</P>

<BR><BR><HR>
<A NAME="1163"></A><H4>1163.
  
<TT>extern template</TT> prevents inlining functions not marked <TT>inline</TT>
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US76">N3092 comment
  US&#160;76<BR></A>

<P>According to 13.9.3 [<A href="https://wg21.link/temp.explicit#9">temp.explicit</A>] paragraph 9,</P>

<BLOCKQUOTE>

Except for inline functions and class template
specializations, explicit instantiation declarations have
the effect of suppressing the implicit instantiation of the
entity to which they refer.

</BLOCKQUOTE>

<P>This means that an implementation cannot do inline expansion
of an <TT>extern template</TT> function or member function,
because that would require its instantiation.  As a result, adding
an explicit instantiation declaration can affect performance, even
though the user only intended to suppress out-of-line copies of
functions.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>If implementations are allowed to do speculative instantiation
for the purpose of inlining, there could be silent changes of
meaning depending on whether the instantiation is done or not.</P>

<BR><BR><HR>
<A NAME="2161"></A><H4>2161.
  
Explicit instantiation declaration and &#8220;preceding initialization&#8221;
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-07-22<BR>




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

<PRE>
  template &lt;typename T&gt; extern const decltype(sizeof 0) Sz = sizeof(T);
  extern template const decltype(sizeof 0) Sz&lt;int&gt;;

  constexpr decltype(sizeof 0) x = Sz&lt;int&gt;;
</PRE>

<P>C++14 allows this, exempting &#8220;const variables of
literal type" from the effects of an explicit instantiation
declaration:</P>

<BLOCKQUOTE>

Except for inline functions, declarations with types deduced
from their initializer or return value
(9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]), const variables of literal
types, variables of reference types, and class template
specializations, explicit instantiation declarations have
the effect of suppressing the implicit instantiation of the
entity to which they refer. [<I>Note:</I> The intent is that
an inline function that is the subject of an explicit
instantiation declaration will still be implicitly
instantiated when odr-used (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) so
that the body can be considered for inlining, but that no
out-of-line copy of the inline function would be generated
in the translation unit. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>Should there be a DR against C++11 for the similar case of
a static data member of a class template?</P>

<P><B>Rationale (October, 2015):</B></P>

<P>CWG agreed that this was a defect in C++11, but it is
addressed in C++14.</P>

<BR><BR><HR>
<A NAME="2270"></A><H4>2270.
  
Non-inline functions and explicit instantiation declarations
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-06-10<BR>




<P>Consider:</P>

<PRE>
  template &lt;class F&gt; F foo() { return 1; }
  template &lt;class F&gt; struct S { F foo() { return 1; } };
  extern template int foo&lt;int&gt;();
  extern template struct S&lt;int&gt;;
  int bar() { return foo&lt;int&gt;() + S&lt;int&gt;().foo(); }
</PRE>

<P>An implementation is permitted to instantiate (and thus locally
inline) <TT>S&lt;int&gt;::foo</TT>, but not <TT>S&lt;int&gt;</TT>, because
13.9.2 [<A href="https://wg21.link/temp.inst#10">temp.inst</A>] paragraph 10 states:</P>

<BLOCKQUOTE>

Except for inline functions, declarations with types deduced from
their initializer or return value (9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]),
const variables of literal types, variables of reference types, and
class template specializations, explicit instantiation declarations
have the effect of suppressing the implicit instantiation of the
entity to which they refer.

</BLOCKQUOTE>

<P><B>Additional note (February, 2022):</B></P>

<P>The paragraph in question was removed by P1815R2
(Translation-unit-local entities) (adopted 2020-02).</P>

<P><B>EWG 2022-11-11</B></P>

<P>Any change would require a paper.</P>

<BR><BR><HR>
<A NAME="3"></A><H4>3.
  
The template compilation model rules render some explicit specialization declarations not visible during instantiation
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bill Gibbons
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>





<P>[N1065 issue 1.19] An explicit specialization declaration may not be
visible during instantiation under the template compilation model rules,
even though its existence must be known to perform the instantiation correctly.
For example:</P>

<P>translation unit #1</P>
<PRE>
      template&lt;class T&gt; struct A { };
      export template&lt;class T&gt; void f(T) { A&lt;T&gt; a; }
</PRE>
translation unit #2
<PRE>
      template&lt;class T&gt; struct A { };
      template&lt;&gt; struct A&lt;int&gt; { }; // not visible during instantiation
      template&lt;class T&gt; void f(T);
      void g() { f(1); }
</PRE>
<B>Rationale:</B>
This issue was addressed in the C++11 FDIS and should have been closed.
<BR><BR><HR>
<A NAME="88"></A><H4>88.
  
Specialization of member constant templates
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>20 Jan 1999<BR>



<P>Is this valid C++?
The question is whether a member constant can be specialized.
My inclination is to say no.</P>
<PRE>
    template &lt;class T&gt; struct A {
        static const T i = 0;
    };

    template&lt;&gt; const int A&lt;int&gt;::i = 42;

    int main () {
        return A&lt;int&gt;::i;
    }
</PRE>
<U>John Spicer</U>: This is ill-formed because
11.4.9.3 [<A href="https://wg21.link/class.static.data">class.static.data</A>]

paragraph 4 prohibits an initializer on a definition of a static data member
for which an initializer was provided in the class.

<P>The program would be valid if the initializer were removed from the
specialization.</P>

<P>
<U>Daveed Vandevoorde</U>: Or at least, the specialized member should
not be allowed in constant-expressions.</P>

<P>
<U>Bill Gibbons</U>: Alternatively, the use of a member constant within
the definition could be treated the same as the use of "sizeof(<I>member
class</I><TT>)</TT>". For example:</P>
<PRE>
    template &lt;class T&gt; struct A {
        static const T i = 1;
        struct B { char b[100]; };
        char x[sizeof(B)];     // specialization can affect array size
        char y[i];             // specialization can affect array size
    };

    template&lt;&gt; const int A&lt;int&gt;::i = 42;
    template&lt;&gt; struct A&lt;int&gt;::B { char z[200] };

    int main () {
        A&lt;int&gt; a;
        return sizeof(a.x)   // 200  (unspecialized value is 100)
             + sizeof(a.y);  // 42   (unspecialized value is 1)
    }
</PRE>
For the member template case, the array size "<TT>sizeof(B)</TT>" cannot
be evaluated until the template is instantiated because <TT>B</TT> might
be specialized. Similarly, the array size "<TT>i</TT>" cannot be evaluated
until the template is instantiated.

<P>
<B>Rationale (10/99):</B> The Standard is already sufficiently clear
on this question.</P>
<BR><BR><HR>
<A NAME="182"></A><H4>182.
  
Access checking on explicit specializations
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>8 Nov 1999<BR>





<P>
<U>John Spicer</U>:
Certain access checks are suppressed on explicit instantiations.
13.9.3 [<A href="https://wg21.link/temp.explicit#8">temp.explicit</A>] paragraph 8

says:</P>

<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify
explicit instantiations. [<I>Note:</I> In particular, the template arguments
and names used in the function declarator (including parameter types,
return types and exception specifications) may be private types or
objects which would normally not be accessible and the template may be
a member template or member function which would not normally be
accessible. ]
</BLOCKQUOTE>

I was surprised that similar wording does not exist (that I could find) for
explicit specializations.  I believe that the two cases should be handled
equivalently in the example below (i.e., that the specialization should be
permitted).

<PRE>
    template &lt;class T&gt; struct C {
    void f();
    void g();
    };

    template &lt;class T&gt; void C&lt;T&gt;::f(){}
    template &lt;class T&gt; void C&lt;T&gt;::g(){}

    class A {
    class B {};
    void f();
    };

    template void C&lt;A::B&gt;::f();    // okay
    template &lt;&gt; void C&lt;A::B&gt;::g(); // error - A::B inaccessible

    void A::f() {
    C&lt;B&gt; cb;
    cb.f();
    }
</PRE>

<P>
<U>Mike Miller</U>:
According to the note in
13.4 [<A href="https://wg21.link/temp.arg#3">temp.arg</A>] paragraph 3,
</P>

<BLOCKQUOTE>
if the name of a <I>template-argument</I> is accessible
at the point where it is used as a <I>template-argument</I>,
there is no further access restriction in the
resulting instantiation where the corresponding
<I>template-parameter</I> name is used.
</BLOCKQUOTE>

<P>(Is this specified anywhere in the normative text?  Should
it be?)</P>

<P>In the absence of text to the contrary, this blanket
permission apparently applies to explicitly-specialized
templates as well as to implicitly-generated ones (is that
right?).  If so, I don't see any reason that an explicit
instantiation should be treated differently from an explicit
specialization, even though the latter involves new program
text and the former is just a placement instruction to the
implementation.</P>

<P><B>Proposed Resolution (4/02):</B></P>

<P>In 13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>] delete paragraph 8:</P>
<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify explicit
instantiations. [Note: In particular, the template arguments and names used in
the function declarator (including parameter types, return types and exception
specifications) may be private types or objects which would normally not be
accessible and the template may be a member template or member function which
would not normally be accessible. ]
</BLOCKQUOTE>

<P>In 13.9 [<A href="https://wg21.link/temp.spec">temp.spec</A>] add the paragraph deleted above as
paragraph 7 with the changes highlighted below:</P>

<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify explicit
instantiations <INS>or explicit specializations</INS>. <DEL>[Note: In
particular, t</DEL><INS>T</INS>he template arguments and names used in the
function declarator (including parameter types, return types and exception
specifications) may be private types or objects which would normally not be
accessible and the template may be a member template or member function
which would not normally be accessible. <DEL>]</DEL>
</BLOCKQUOTE>

<P><B>Rationale (October 2002):</B></P>

<P>We reconsidered this and decided that the difference between the
two cases (explicit specialization and explicit instantiation) is
appropriate.  The access rules are sometimes bent when necessary to
allow naming something, as in an explicit instantiation, but
explicit specialization requires not only naming the entity but
also providing a definition somewhere.</P>

<BR><BR><HR>
<A NAME="285"></A><H4>285.
  
Identifying a function template being specialized
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Erwin Unruh
 &#160;&#160;&#160;

 <B>Date: </B>01 May 2001<BR>


<P>The Standard does not describe how to handle an example
like the following:</P>

<PRE>
    template &lt;class T&gt; int f(T, int);
    template &lt;class T&gt; int f(int, T);

    template&lt;&gt; int f&lt;int&gt;(int, int) { /*...*/ }
</PRE>

<P>It is impossible to determine which of the function templates
is being specialized.  This problem is related to the discussion
of <A HREF="cwg_closed.html#229">issue 229</A>, in which one of the objections
raised against partial specialization of function templates is
that it is not possible to determine which template is being
specialized.</P>

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

<P>It was decided that while this is true, it's not a problem.  You
can't call such functions anyway; the call would be ambiguous.</P>

<BR><BR><HR>
<A NAME="1727"></A><H4>1727.
  
Type of a specialization of a variable template
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Larisse Voufo
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-05<BR>




<P>It is not clear whether there is any necessary relationship between
the type specified in a primary variable template declaration and the
type in an explicit or partial specialization.  For example:</P>

<PRE>
  template&lt;typename T&gt; T var = T();
  template&lt;&gt; char var&lt;char&gt; = 'a';           //<SPAN CLASS="cmnt"> #1.</SPAN>
  template&lt;typename T&gt; T* var&lt;T&gt; = new T();  //<SPAN CLASS="cmnt"> #2.</SPAN>
  template&lt;&gt; float var&lt;int&gt; = 1.5;           //<SPAN CLASS="cmnt"> #3.</SPAN>
</PRE>

<P><B>Rationale (September, 2013):</B></P>

<P>CWG affirmed that there is no required relationship between the type
of the template and the type of a partial or explicit specialization of
that template.</P>

<BR><BR><HR>
<A NAME="1792"></A><H4>1792.
  
Incorrect example of explicit specialization of member enumeration
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-01<BR>


<P>The example in 13.9.4 [<A href="https://wg21.link/temp.expl.spec#6">temp.expl.spec</A>] paragraph 6 reads, in
part,</P>

<PRE>
  template&lt;class T&gt; struct A {
    enum E : T;
    enum class S : T;
  };
  template&lt;&gt; enum A&lt;int&gt;::E : int { eint };         //<SPAN CLASS="cmnt"> OK</SPAN>
  template&lt;&gt; enum class A&lt;int&gt;::S : int { sint };   //<SPAN CLASS="cmnt"> OK</SPAN>
  template&lt;class T&gt; enum A&lt;T&gt;::E : T { eT };
  template&lt;class T&gt; enum class A&lt;T&gt;::S : T { sT };
  template&lt;&gt; enum A&lt;char&gt;::E : int { echar };       //<SPAN CLASS="cmnt"> ill-formed, </SPAN>A&lt;char&gt;::E<SPAN CLASS="cmnt"> was instantiated</SPAN>
                                                    //<SPAN CLASS="cmnt"> when </SPAN>A&lt;char&gt;<SPAN CLASS="cmnt"> was instantiated</SPAN>
  template&lt;&gt; enum class A&lt;char&gt;::S : int { schar }; //<SPAN CLASS="cmnt"> OK</SPAN>
</PRE>

<P>The <TT>int</TT> <I>enum-base</I> in the last two lines appears to
be incorrect; the reference to <TT>A&lt;char&gt;</TT> in the
<I>nested-name-specifier</I> will have instantiated the declarations
of <TT>E</TT> and <TT>S</TT> with an <I>enum-base</I> of <TT>char</TT>,
and the explicit specializations must agree.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>The problem was fixed editorially in N3797.</P>

<BR><BR><HR>
<A NAME="1876"></A><H4>1876.
  
Preventing explicit specialization
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2014-02-19<BR>


<P>A desire has been expressed for a mechanism to prevent explicitly
specializing a given class template, in
particular <TT>std::initializer_list</TT> and perhaps some others in the
standard library.  It is not clear whether simply adding a prohibition to
the description of the templates in the library clauses would be
sufficient or whether a core language mechanism is required.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>This request for a new language feature should be considered by
EWG before any action is taken.</P>

<P><B>EWG 2022-11-11</B></P>

<P>The library clauses already prohibit user specializations of
standard library templates.  This is a request for new feature, which
should be proposed in a paper to EWG.</P>

<BR><BR><HR>
<A NAME="2138"></A><H4>2138.
  
Explicit member specialization vs implicit instantiation
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-06-11<BR>




<P>It is not clear whether the following common practice is valid
by the current rules:</P>

<PRE>
   //<SPAN CLASS="cmnt"> foo.h</SPAN>
   template&lt;typename T&gt; struct X {
    int f(); //<SPAN CLASS="cmnt"> never defined</SPAN>
   };

   //<SPAN CLASS="cmnt"> foo.cc</SPAN>
   #include "foo.h"
   template&lt;&gt; int X&lt;int&gt;::f() { return 123; }

   //<SPAN CLASS="cmnt"> main.cc</SPAN>
   #include "foo.h"
   int main() { return X&lt;int&gt;().f(); }
</PRE>

<P>Relevant rules include Clause 13 [<A href="https://wg21.link/temp#6">temp</A>] paragraph 6,</P>

<BLOCKQUOTE>

A function template, member function of a class template,
variable template, or static data member of a class template
shall be defined in every translation unit in which it is
implicitly instantiated (13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>]) unless
the corresponding specialization is explicitly instantiated
(13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]) in some translation unit; no
diagnostic is required.

</BLOCKQUOTE>

<P>13.9.2 [<A href="https://wg21.link/temp.inst#2">temp.inst</A>] paragraph 2,</P>

<BLOCKQUOTE>

Unless a member of a class template or a member template has
been explicitly instantiated or explicitly specialized, the
specialization of the member is implicitly instantiated when
the specialization is referenced in a context that requires
the member definition to exist...

</BLOCKQUOTE>

<P>and 13.9.4 [<A href="https://wg21.link/temp.expl.spec#6">temp.expl.spec</A>] paragraph 6:

<BLOCKQUOTE>

If a template, a member template or a member of a class
template is explicitly specialized then that specialization
shall be declared before the first use of that
specialization that would cause an implicit instantiation to
take place, in every translation unit in which such a use
occurs; no diagnostic is required. If the program does not
provide a definition for an explicit specialization and
either the specialization is used in a way that would cause
an implicit instantiation to take place or the member is a
virtual member function, the program is ill-formed, no
diagnostic required. An implicit instantiation is never
generated for an explicit specialization that is declared
but not defined.

</BLOCKQUOTE>
</P>

<P>The intent appears to be that the reference in
<TT>main.cc</TT> violates two rules: it implicitly instantiates
something for which no definition is provided and that is not
explicitly instantiated elsewhere, and it also causes an
implicit instantiation of something explicitly specialized
in another translation unit without a declaration of the
explicit specialization.</P>

<P><B>Rationale (March, 2016):</B></P>

<P>As stated in the analysis, the intent is for the example to be
ill-formed, no diagnostic required.</P>

<BR><BR><HR>
<A NAME="1386"></A><H4>1386.
  
Explicitly-specified partial argument list with multiple parameter packs
</H4>
<B>Section: </B>13.10.2&#160; [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-09-01<BR>




<P>Given</P>

<PRE>
    template&lt;class T, class U&gt; struct A { };
    template&lt;class... T, class ... U&gt; void f( A&lt;T,U&gt;...p);

    void g() {
        f&lt;int&gt;(
            A&lt;int,unsigned&gt;(),
            A&lt;short,unsigned short&gt;()
            );
    }
</PRE>

<P>I would expect this to work, but all the recent compilers I tried
reject it, indicating deduction failure.</P>

<P><B>Rationale (April, 2013):</B></P>

<P>This is well-formed.</P>

<BR><BR><HR>
<A NAME="1982"></A><H4>1982.
  
Deduction extending parameter pack
</H4>
<B>Section: </B>13.10.2&#160; [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Filip Ros&#233;en
 &#160;&#160;&#160;

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


<P>According to 13.10.2 [<A href="https://wg21.link/temp.arg.explicit#9">temp.arg.explicit</A>] paragraph 9,</P>

<BLOCKQUOTE>

Template argument deduction can extend the sequence of
template arguments corresponding to a template parameter
pack, even when the sequence contains explicitly specified
template arguments.

</BLOCKQUOTE>

<P>However, it is not clear how to handle an example like:</P>

<PRE>
  template&lt;class...&gt; struct Z {
    Z (int);
  };

  template&lt;class... Ts&gt; void f (Z&lt;Ts...&gt;);

  int main () {
    f&lt;void, void&gt; (0);
  }
</PRE>

<P><B>Rationale (November, 2014):</B></P>

<P>CWG was not convinced that such cases are sufficiently useful
to warrant the additional complexity in the rules required to
support them.</P>

<BR><BR><HR>
<A NAME="2200"></A><H4>2200.
  
Conversions in template argument deduction
</H4>
<B>Section: </B>13.10.2&#160; [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-11-14<BR>




<P>Consider:</P>

<PRE>
  struct S
  {
   operator int();
  };

  template&lt;int N&gt;
  void f(const int (&amp;)[N]);

  int main()
  {
   S s;
   f&lt;2&gt;({s, s}); //<SPAN CLASS="cmnt"> #1</SPAN>
   f({s, s});  //<SPAN CLASS="cmnt"> #2</SPAN>
  }
</PRE>

<P>Since the array element type is not deduced, implicit conversions
ought to be permitted in #2 but other implementations disagree.  Is
there a compelling reason to disallow them?</P>

<P>For comparison:</P>

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

  struct S
  {
   operator int();
  };

  template&lt;typename T&gt;
  void f(std::initializer_list&lt;T&gt;);

  int main()
  {
   S s;
   f&lt;int&gt;({s, s});
  }
</PRE>

<P>Because T is not deduced, implicit conversions are allowed, and the
number of elements in the underlying temporary array is determined
from the number of elements in the initializer list.  It seems that
the intention of <A HREF="cwg_defects.html#1591">issue 1591</A> was to allow
the underlying temporary array to be deduced directly, so the fact
that the array bounds are deduced in the case above shouldn't inhibit
implicit conversions.</P>

<P><B>Rationale (November, 2016):</B></P>

<P>Although there is an argument to be made for the suggested
direction, the current rule is simple and easy to explain, so there
was no consensus for a change.</P>

<BR><BR><HR>
<A NAME="297"></A><H4>297.
  
Which template does an explicit specialization specialize?
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>7 Jul 2001<BR>


<P>Andrei Iltchenko points out that the standard has no wording that
defines how to determine which template is specialized by an
explicit specialization of a function template.
He suggests "template argument deduction
in such cases proceeds in the same way as when taking the address
of a function template,
which is described in 13.10.3.3 [<A href="https://wg21.link/temp.deduct.funcaddr">temp.deduct.funcaddr</A>]."</P>

<P>John Spicer points out that the same problem exists for all
similar declarations, i.e., friend declarations and explicit
instantiation directives.  Finding a corresponding placement
<TT>operator delete</TT> may have a similar problem.</P>

<P>
<U>John Spicer</U>:
There are two aspects of "determining which template" is referred to by
a declaration: determining the function template associated with the
named specialization, and determining the values of the template arguments
of the specialization.</P>
<PRE>
    template &lt;class T&gt; void f(T);  #1
    template &lt;class T&gt; void f(T*); #2
    template &lt;&gt; void f(int*);
</PRE>

<P>In other words, which <TT>f</TT> is being specialized (#1 or #2)?
And then, what are the deduced template arguments?</P>

<P>13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>] does say that partial ordering is
done in contexts such as this.
Is this sufficient, or do we need to say more about the selection of the
function template to be selected? </P>

<P>13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>] probably needs a new section to cover
argument deduction for cases like this.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>The missing specification was added by C++11; see
13.10.3.7 [<A href="https://wg21.link/temp.deduct.decl">temp.deduct.decl</A>].</P>

<BR><BR><HR>
<A NAME="662"></A><H4>662.
  
Forming a pointer to a reference type
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>28 November 2007<BR>


<P>The Standard currently specifies (9.2.4 [<A href="https://wg21.link/dcl.typedef#9">dcl.typedef</A>] paragraph 9,
13.4.2 [<A href="https://wg21.link/temp.arg.type#4">temp.arg.type</A>] paragraph 4) that an attempt to create a
reference to a reference (via a typedef or template type
parameter) is effectively ignored.  The same is not true of an attempt
to form a pointer to a reference; that is, assuming that <TT>T</TT> is
specified to be a reference type,</P>

<PRE>
    template &lt;typename T&gt; void f(T t) {
        T&amp; tr = t;   //<SPAN CLASS="cmnt"> OK</SPAN>
        T* tp = &amp;t;  //<SPAN CLASS="cmnt"> error</SPAN>
    }
</PRE>

<P>It would be more consistent to allow pointers to references to
collapse in the same way that references to references do.</P>

<P><B>Rationale (February, 2008):</B></P>

<P>In the absence of a compelling need, the CWG felt that it was
better not to change the existing rules.  Allowing this case could
cause a quiet change to the meaning of a program, because attempting
to create a pointer to a reference type is currently a deduction
failure.</P>

<P><B>Additional discussion (May, 2009):</B></P>

<P>Consider the following slightly extended version of the example
above:</P>

<PRE>
    template &lt;typename T&gt; void f(T t) {
        T&amp; tr = t;   // OK
        T* tp = &amp;t;  // error
        auto * ap = &amp;t; // OK!
    }
</PRE>

<P>This means that a template that expects a reference type will need
to use <TT>auto</TT> just to work around the failure to collapse
pointer-to-reference types.  The result might, in fact, be subtly
different with <TT>auto</TT>, as well, in case there is an overloaded
<TT>operator&amp;</TT> function that doesn't return exactly
<TT>T*</TT>.  This contradicts one of the main goals of C++0x, to make
it simpler, more consistent, and easier to teach.</P>

<P><B>Rationale (July, 2009):</B></P>

<P>The CWG reaffirmed its early decision.  In general, templates will
need to be written differently for reference and non-reference type
parameters.  Also, the Standard library provides a facility,
<TT>std::remove_reference</TT>, that can be used easily for such
cases.</P>

<BR><BR><HR>
<A NAME="1273"></A><H4>1273.
  
Accessibility and function signatures
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-03-24<BR>




<P>With the resolution of <A HREF="cwg_defects.html#1170">issue 1170</A>, which
takes access into account in template argument deduction, it is now
possible to have instantiation-dependent expressions (see
<A HREF="cwg_active.html#1172">issue 1172</A>) that do not directly involve a
template parameter.  For example:</P>

<PRE>
  template &lt;class T&gt; struct C;

  class A
  {
    int i;
    friend struct C&lt;int&gt;;
  } a;

  class B
  {
    int i;
    friend struct C&lt;float&gt;;
  } b;

  template &lt;class T&gt;
  struct C
  {
    template &lt;class U&gt; decltype (a.i) f() { } //<SPAN CLASS="cmnt"> #1</SPAN>
    template &lt;class U&gt; decltype (b.i) f() { } //<SPAN CLASS="cmnt"> #2</SPAN>
  };

  int main()
  {
    C&lt;int&gt;().f&lt;int&gt;();   //<SPAN CLASS="cmnt"> calls #1</SPAN>
    C&lt;float&gt;().f&lt;float&gt;(); //<SPAN CLASS="cmnt"> calls #2</SPAN>
  }
</PRE>

<P><B>Rationale (August, 2011):</B></P>

<P>The specification is as intended. To the extent that there is an
issue here, it is covered by <A HREF="cwg_active.html#1172">issue 1172</A>.</P>

<BR><BR><HR>
<A NAME="1546"></A><H4>1546.
  
Errors in function template default arguments
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-08-27<BR>




<P>Given an example like</P>

<PRE>
  template &lt;class T&gt; void f (T, int = T());
  template &lt;class T&gt; auto g(T t) -&gt; decltype (f(t));
  void g(int);

  struct A { A(int); operator int(); };

  int main() {
    g(A(42));
  }
</PRE>

<P>it seems that since the default argument is treated as a separate
template, its ill-formedness causes a hard error, rather than a
substitution failure for <TT>g</TT>.  Is this what we want?</P>

<P><B>Rationale (October, 2012):</B></P>

<P>CWG felt that this was acceptable; also, there is discussion in
EWG regarding changes to the SFINAE rules that could affect this
case.</P>

<BR><BR><HR>
<A NAME="99"></A><H4>99.
  
Partial ordering, references and cv-qualifiers
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>5 Mar 1999<BR>



<P>Consider:</P>
<PRE>
    template &lt;class T&gt; void f(T&amp;);
    template &lt;class T&gt; void f(const T&amp;);
    void m() {
        const int p = 0;
        f(p);
    }
</PRE>
Some compilers treat this as ambiguous; others prefer <TT>f(const T&amp;)</TT>.

The question turns out to revolve around whether
13.10.3.2 [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]

paragraph 2 says what it ought to regarding the removal of cv-qualifiers
and reference modifiers from template function parameters in
doing type deduction.
<P>
<U>John Spicer</U>:
The partial ordering rules as originally proposed specified that, for
purposes of comparing parameter types, you remove a top level reference,
and after having done that you remove top level qualifiers.  This is not
what is actually in the IS however.  The IS says that you remove top
level qualifiers and then top level references.</P>
<P>
The original rules were intended to prefer <TT>f(A&lt;T&gt;)</TT> over <TT>f(const T&amp;)</TT>.</P>

<P>
<B>Rationale (10/99):</B> The Standard correctly reflects the intent
of the Committee.</P>

<P>
<B>(October 2002)</B>
This is resolved by <A HREF="cwg_defects.html#214">issue 214</A>.</P>

<BR><BR><HR>
<A NAME="1014"></A><H4>1014.
  
Overload resolution between <TT>const T&amp;</TT> and <TT>T&amp;&amp;</TT>
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2009-12-17<BR>


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

<PRE>
    template&lt;typename T&gt; void f(const T&amp;);  // #1
    template&lt;typename T&gt; void f(T&amp;&amp;);       // #2
    void g() {
        const int x = 5;
        f(x);
    }
</PRE>

<P>the call <TT>f(x)</TT> is ambiguous by the current rules.  For #1,
<TT>T</TT> is deduced as <TT>int</TT>, giving</P>

<PRE>
    f&lt;int&gt;(const int&amp;)
</PRE>

<P>For #2, because of the special case for <TT>T&amp;&amp;</TT> in
13.10.3.2 [<A href="https://wg21.link/temp.deduct.call#3">temp.deduct.call</A>] paragraph 3, <TT>T</TT> is deduced as
<TT>const int&amp;</TT>; application of the reference-collapsing
rules in 9.3.4.3 [<A href="https://wg21.link/dcl.ref#6">dcl.ref</A>] paragraph 6 to the substituted
parameter type yields</P>

<PRE>
    f&lt;const int&amp;&gt;(const int&amp;)
</PRE>

<P>These are indistinguishable in overload resolution, resulting in
an ambiguity.  It's not clear how this might be addressed.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>The two functions are distinguished by partial ordering, so the
call is not actually ambiguous.</P>

<BR><BR><HR>
<A NAME="1671"></A><H4>1671.
  
Unclear rules for deduction with cv-qualification
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-04-26<BR>




<OL>
<LI><P>Simple pointer:</P></LI>

<P>Template argument: <TT>const T*</TT><BR>

Actual argument: <TT>char*</TT><BR>

We deduce <TT>T</TT> to be <TT>char</TT>, and by compatibility of
cv-qualifiers, this deduction works.</P>

<P>Now suppose that (somehow) we deduced <TT>T</TT> to be <TT>const
char</TT>. We fold the resulting <TT>const const char*</TT> into <TT>const
char*</TT>, and again the deduction works. Does the standard disallow this
deduction? The reason for this question is in the next example.</P>

<LI><P>Pointer to member:</P></LI>

<P>Template argument: <TT>const T A&lt;T&gt;::*</TT>, where <TT>A</TT> is a class template<BR>

Actual argument: <TT>char A&lt;const char&gt;::*</TT><BR>

Compilers reject this case, because if we deduce the first <TT>T</TT> to
be <TT>char</TT>, we cannot match <TT>A&lt;T&gt;::*</TT>. But suppose we
look first at the second <TT>T</TT>, deducing it to be <TT>const
char</TT>. Then we get <TT>const char A&lt;const char&gt;::*</TT>, which is
OK. Alternatively, as in the hypothetical case in example 1, suppose we
deduce the first <TT>T</TT> to be <TT>const char</TT>, again we get a
match.</P>

<P>Arbitrarily adding extra cv-qualifiers in looking for a match, or trying
different matching orders to find one that works, seems wrong. But are
these approaches disallowed?</P>

</OL>

<P>For completeness, here is a code example:</P>

<PRE>
  template &lt;typename Q&gt;
  struct A {
    int i;
  };

  template &lt;typename T&gt;
  void foo(const T A&lt;T&gt;::*) { }

  int main() {
    A&lt;const int&gt; a;
    int A&lt;const int&gt;::*p = &amp;A&lt;const int&gt;::i;
    foo(p);  //<SPAN CLASS="cmnt"> rejected by all compilers, but why?</SPAN>
  }
</PRE>

<P><B>Rationale (September, 2013):</B></P>

<P>There are no rules that would result in deducing <TT>const char</TT>
in the specified example.</P>

<BR><BR><HR>
<A NAME="1700"></A><H4>1700.
  
Does the special rvalue-reference deduction apply to alias templates?
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-06-14<BR>


<P>An rvalue reference type involving a template parameter receives
special treatment in template argument deduction in
13.10.3.2 [<A href="https://wg21.link/temp.deduct.call#3">temp.deduct.call</A>] paragraph 3:</P>

<BLOCKQUOTE>

If <TT>P</TT> is an rvalue reference to a cv-unqualified template parameter
and the argument is an lvalue, the type &#8220;lvalue reference
to <TT>A</TT>&#8221; is used in place of <TT>A</TT> for type deduction.

</BLOCKQUOTE>

<P>Does this rule apply when the parameter type involves an alias
template instead of using a template parameter directly?  For
example:</P>

<PRE>
    template&lt;class T&gt; using RR = T&amp;&amp;;

    template&lt;class T&gt; struct X {};
    template&lt;class T&gt; struct X&lt;T&amp;&amp;&gt;; //<SPAN CLASS="cmnt"> Leave incomplete to possibly trigger an error</SPAN>

    template&lt;class T&gt; void g(RR&lt;T&gt; p) {
      X&lt;decltype(p)&gt; x;
    }

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

<P>There is implementation variance on the treatment of this example.</P>

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

<P>It was observed  that
the type of the parameter would be the same whether written as
<TT>T&amp;&amp;</TT> or as <TT>RR&lt;T&gt;</TT>, which would require
that deduction be performed the same, regardless of how the type was
written.</P>

<P><B>Rationale (September, 2013):</B></P>

<P>Because the types of the function parameters are the same, regardless
of whether written directly or via an alias template, deduction must be
handled the same way in both cases.</P>

<BR><BR><HR>
<A NAME="885"></A><H4>885.
  
Partial ordering of function templates with unordered parameter pairs
</H4>
<B>Section: </B>13.10.3.5&#160; [<A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>1 May, 2009<BR>




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

<PRE>
    template &lt;typename T&gt; void f(T** p, void (*)());  // #1
    template &lt;typename T&gt; void f(T* p, void (&amp;)());   // #2
    void x();
    void g(int** p) {
      f(p, x);    // #3
    }
</PRE>

<P>The question is whether the call at #3 is ambiguous or not.</P>

<P>The synthesized declarations for overload resolution are:</P>

<PRE>
    void f&lt;int&gt;(int**, void(*)());   // From #1
    void f&lt;int*&gt;(int**, void(&amp;)());  // From #2
</PRE>

<P>Neither of these is a better match on the basis of conversion
sequences (the function-to-pointer conversion and the reference
binding have &#8220;exact match&#8221; rank), and both are function
template specializations, so the tiebreaker in 12.2.4 [<A href="https://wg21.link/over.match.best#1">over.match.best</A>] paragraph 1 comes down to whether #1 is more
specialized than #2 or vice versa.</P>

<P>The determination of whether one of these templates is more
specialized than the other is done (as described in 13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]) by synthesizing a type for the template parameter of
each function template (call them <TT>@1</TT> and <TT>@2</TT>,
respectively), substituting that synthesized type for each occurrence
of the template parameter in the function type of the template, and
then performing deduction on each pair of corresponding function
parameters as described in 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>].</P>

<P>For the first function parameter, #1 is more specialized: deduction
succeeds with <TT>P=T*</TT> and <TT>A=@1**</TT>, giving
<TT>T=@1*</TT>, but it fails with <TT>P=T**</TT> and <TT>A=@2*</TT>.
For the second parameter, deduction fails in both directions, with
<TT>P=void(*)()</TT> and <TT>A=void()</TT> as well as with
<TT>P=void()</TT> and <TT>A=void(*)()</TT> (the reference is dropped
from both the parameter and argument types, as described in
13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#5">temp.deduct.partial</A>] paragraph 5).  This means that neither
parameter type is at least as specialized as the other (paragraph
8).</P>

<P>According to 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#10">temp.deduct.partial</A>] paragraph 10,</P>

<BLOCKQUOTE>

If for each type being considered a given template is at
least as specialized for all types and more specialized
for some set of types and the other template is not more
specialized for any types or is not at least as
specialized for any types, then the given template is more
specialized than the other template.  Otherwise,
neither template is more specialized than the other.

</BLOCKQUOTE>

<P>According to this rule, #1 is not more specialized than #2
because it is not &#8220;at least as specialized&#8221; for the second
parameter type, so the call at #3 is ambiguous.</P>

<P>Results vary among implementations, with some rejecting the
call as ambiguous and others resolving it to #1.</P>

<P>Would it be better to say that a function template F1 is more
specialized than F2 if at least one of F1's types is more
specialized than the corresponding F2 type and none of F2's
types is more specialized than the corresponding F1 type?  That
would be simpler and, for examples like this, arguably more
intuitive.  The rationale for this change would be that if,
for a given parameter pair, neither is more specialized than the
other, then that parameter pair simply says nothing about whether
one of the templates is more specialized than the other, rather
than indicating that the templates cannot be ordered.</P>

<P>(See also <A HREF="cwg_closed.html#455">issue 455</A>.)</P>

<P><B>Rationale (October, 2009):</B></P>

<P>The consensus of the CWG is that this issue, in which corresponding
parameters cannot be compared but the functions are equivalent in
terms of overload resolution, arises so infrequently in practice that
no change is warranted at this time.</P>

<BR><BR><HR>
<A NAME="2350"></A><H4>2350.
  
Forwarding references and deduction guides
</H4>
<B>Section: </B>13.10.3.5&#160; [<A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Barry Revzin
 &#160;&#160;&#160;

 <B>Date: </B>2017-06-03<BR>


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

<PRE>
  template&lt;typename T&gt;
  struct A {
    A(const T&amp;);        //<SPAN CLASS="cmnt"> #1</SPAN>
    A(T&amp;&amp;);             //<SPAN CLASS="cmnt"> #2</SPAN>
  };


  template&lt;typename U&gt;
  A(U&amp;&amp;)-&gt;A&lt;double&gt;;    //<SPAN CLASS="cmnt"> #3</SPAN>


  int main(){
    int i =0;
    const int ci =0;

    A a1(0);
    A a2(i);
    A a3(ci);
  }
</PRE>

<P>This example is covered by 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#9">temp.deduct.partial</A>] paragraph 9:</P>

<BLOCKQUOTE>

<P>If, for a given type, deduction succeeds in both directions (i.e., the
types are identical after the transformations above) and both P and A were
reference types (before being replaced with the type referred to
above):</P>

<UL>
<LI><P>if the type from the argument template was an lvalue reference
and the type from the parameter template was not, the parameter type is not
considered to be at least as specialized as the argument type;
otherwise,</P></LI>

<LI><P>if the type from the argument template is more cv-qualified than the
type from the parameter template (as described above), the parameter type
is not considered to be at least as specialized as the argument
type.</P></LI>

</UL>

</BLOCKQUOTE>

<P>For <TT>a2(i)</TT>, the deduction guide is the best match, so this is
an <TT>A&lt;double&gt;</TT>.</P>

<P>For <TT>a3(ci)</TT>, the first bullet applies, which prefers #1 to #3
since #1 comes from an lvalue reference and #3 does not, resulting in an
<TT>A&lt;int&gt;</TT>.</P>

<P>For <TT>a1(0)</TT>, the case is not covered by partial ordering, so
12.2.4 [<A href="https://wg21.link/over.match.best#1.10">over.match.best</A>] bullet 1.10 applies and prefers #3 to #2, which
is again an <TT>A&lt;double&gt;</TT>.</P>

<P>It seems inconsistent to prefer #1 to #3 (<TT>T const &amp;</TT> to
<TT>U&amp;&amp;</TT>), but to prefer #3 to #2 (<TT>U&amp;&amp;</TT> to
<TT>T&amp;&amp;</TT>). Should the rules be expanded to basically prefer
any non-forwarding-reference to a forwarding reference?</P>

<P><B>Rationale (June, 2018):</B></P>

<P>There was no consensus to make a change at this point; the behavior is
as intended.</P>

<BR><BR><HR>
<A NAME="469"></A><H4>469.
  
Const template specializations and reference arguments
</H4>
<B>Section: </B>13.10.3.6&#160; [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>19 Mar 2004<BR>




<P>Consider the following:</P>
<PRE>
	template &lt;typename T&gt; struct X {};  // #1
	template &lt;typename T&gt; struct X&lt;const T&gt;; //#2
	template struct X&lt;int&amp;&gt;; //#3
</PRE>

<P>Which specialization are we instantiating in #3?  The "obvious" answer
is #1, because "int&amp;" doesn't have a top level cv-qualification.
However, there's also an argument saying that we should actually be
instantiating #2.  The argument is: int&amp; can be taken as a match for
either one (top-level cv-qualifiers are ignored on references, so
they're equally good), and given two equally good matches we must
choose the more specialized one.</P>

<P>Is this a valid argument?  If so, is this behavior intentional?</P>

<P>
<U>John Spicer:</U>
I don't see the rationale for any choice other than #1.  While it is
true that if you attempt to apply const to a reference type it just
gets dropped, that is very different from saying that a reference type
is acceptable where a const-qualified type is required.</P>

<P>
<I>If</I> the type matched both templates, the const one would be
more specialized, but "int&amp;" does not match "const T".</P>

<P>
<U>Nathan Sidwell:</U>
thanks for bringing this one to the committee.  However this is
resolved, I'd like clarification on the followup questions in the
gcc bug report regarding deduced and non-deduced contexts and
function templates.  Here're those questions for y'all,</P>
<PRE>
template &lt;typename T&gt; void Foo (T *); // #1
template &lt;typename T&gt; void Foo (T const *); // #2
void Baz ();
Foo (Baz); // which?

template &lt;typename T&gt; T const *Foo (T *); // #1
void Baz ();
Foo (Baz); // well formed?

template &lt;typename T&gt; void Foo (T *, T const * = 0);
void Baz ();
Foo (Baz); // well formed?
</PRE>
<P>BTW, I didn't go trying to break things, I implemented the cv-qualifier
ignoring requirements and fell over this.  I could find nothing in the
standard saying 'don't do this ignoring during deduction'.</P>



<BR><BR><HR>
<A NAME="586"></A><H4>586.
  
Default <I>template-argument</I>s and template argument deduction
</H4>
<B>Section: </B>13.10.3.6&#160; [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>20 June 2006<BR>




<P>
<A HREF="cwg_defects.html#226">Issue 226</A> removed the original
prohibition on default <I>template-argument</I>s for function
templates.  However, the note in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#19">temp.deduct.type</A>] paragraph 19
still reflects that prohibition.  It should be revised
or removed.</P>

<P><B>Rationale (February, 2010):</B></P>

<P>The problematic note was removed as a by-product of the changes
for variadic templates, document N2284.</P>

<BR><BR><HR>
<A NAME="1371"></A><H4>1371.
  
Deduction from <TT>T&amp;&amp;</TT> in return types
</H4>
<B>Section: </B>13.10.3.6&#160; [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-15<BR>


<P>The special rule in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#10">temp.deduct.type</A>] paragraph 10 for
handling <TT>T&amp;&amp;</TT> in template argument deduction applies
only to function parameters.  It also needs to apply to function return
types (including for conversion function templates,
13.10.3.4 [<A href="https://wg21.link/temp.deduct.conv">temp.deduct.conv</A>]).</P>

<P><B>Rationale (February, 2012):</B></P>

<P>The specification is as intended: the special treatment of lvalue
arguments in deduction is to make &#8220;perfect forwarding&#8221; work
and should not be applied in other contexts.</P>

<BR><BR><HR>
<A NAME="947"></A><H4>947.
  
Deducing type template arguments from default function arguments
</H4>
<B>Section: </B>13.10.4&#160; [<A href="https://wg21.link/temp.over">temp.over</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dave Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>27 July, 2009<BR>




<P>It would be useful to be able to deduce the type of a function
template argument from a corresponding default function argument
expression, for example:</P>

<PRE>
    template &lt;class T&gt; int f(T = 0);
    int x = f();
</PRE>

<P>A more realistic use case would be</P>

<PRE>
    template &lt;class T, class U&gt;
    int f(T x, U y = pair&lt;T, T&gt;());
</PRE>

<P>Ideally one would also like</P>

<PRE>
    template &lt;class T, class U&gt;
    int f(T x, U y = g(x));
</PRE>

<P>These capabilities are part of the Boost parameter library,
so there should not be issues of implementability.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>EWG determined that no action should be taken on this issue.</P>

<BR><BR><HR>
<A NAME="211"></A><H4>211.
  
Constructors should not be allowed to return normally after an exception
</H4>
<B>Section: </B>Clause 14&#160; [<A href="https://wg21.link/except">except</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bruce Mellows
 &#160;&#160;&#160;

 <B>Date: </B>8 Mar 2000<BR>


<P>The grammar should be changed so that constructor
<I>function-try-block</I>s must end with a
<I>throw-expression</I>.</P>

<P><B>Rationale (04/00):</B></P>

<P>No change is needed.  It is already the case that flowing off the
end of a <I>function-try-block</I> of a constructor rethrows the
exception, and <TT>return</TT> statements are prohibited in
constructor <I>function-try-block</I>s
(14.4 [<A href="https://wg21.link/except.handle">except.handle</A>] paragraphs 15-16.</P>

<BR><BR><HR>
<A NAME="104"></A><H4>104.
  
Destroying the exception temp when no handler is found
</H4>
<B>Section: </B>14.2&#160; [<A href="https://wg21.link/except.throw">except.throw</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>21 Mar 1999<BR>





<P>Questions regarding when a throw-expression temporary object is destroyed.</P>
<P>
Section 14.2 [<A href="https://wg21.link/except.throw">except.throw</A>]

paragraph 4 describes when the temporary is destroyed when a handler is found.
But what if no handler is found:</P>
<PRE>
    struct A {
        A() { printf ("A() \n"); }
        A(const A&amp;) { printf ("A(const A&amp;)\n"); }
        ~A() { printf ("~A() \n"); }
    };

    void t() { exit(0); }

    int main() {
        std::set_terminate(t);
        throw A();
    }
</PRE>
Does <TT>A::~A()</TT> ever execute here?
(Or, in case two constructions are done,
are there two destructions done?)  Is it implementation-defined, analogously
to whether the stack is unwound before <TT>terminate()</TT> is called
(14.4 [<A href="https://wg21.link/except.handle#9">except.handle</A>] paragraph 9)
?
<P>
Or what if an exception specification is violated?  There are several
different scenarios here:</P>
<PRE>
    int glob = 0; // or 1 or 2 or 3

    struct A {
        A() { printf ("A() \n"); }
        A(const A&amp;) { printf ("A(const A&amp;)\n"); }
        ~A() { printf ("~A() \n"); }
    };

    void u() {
        switch (glob) {
        case 0:  exit(0);
        case 1:  throw "ok";
        case 2:  throw 17;
        default: throw;
        }
    }

    void foo() throw(const char*, std::bad_exception) {
        throw A();
    }

    int main() {
        std::set_unexpected(u);
        try {
            foo();
        }
        catch (const char*) { printf("in handler 1\n"); }
        catch (std::bad_exception) { printf("in handler 2\n"); }
    }
</PRE>
The case where <TT>u()</TT> exits is presumably similar to the <TT>terminate()</TT> case.
But in the cases where the program goes on, <TT>A::~A()</TT> should be called
for the thrown object at some point.  But where does this happen?
The standard doesn't really say.  Since an exception is defined to
be "finished" when the <TT>unexpected()</TT> function exits, it seems to me that
is where <TT>A::~A()</TT> should be called &#8212; in this case, as the throws of
new (or what will become new) exceptions are made out of <TT>u()</TT>.
Does this make sense?

<P>
<B>Rationale (10/99):</B> Neither <TT>std::exit(int)</TT> nor
<TT>std::abort()</TT> destroys temporary objects, so the exception
temporary is not destroyed when no handler is found.  The original
exception object is destroyed when it is replaced by an
<TT>unexpected()</TT> handler.  The Standard is sufficiently clear
on these points.</P>
<BR><BR><HR>
<A NAME="1667"></A><H4>1667.
  
Function exiting via exception called by destructor during unwinding
</H4>
<B>Section: </B>14.2&#160; [<A href="https://wg21.link/except.throw">except.throw</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Ryou Ezoe
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-25<BR>




<P>According to 14.2 [<A href="https://wg21.link/except.throw#7">except.throw</A>] paragraph 7,</P>

<BLOCKQUOTE>

If the exception handling mechanism, after completing the initialization of
the exception object but before the activation of a handler for the
exception, calls a function that exits via an
exception, <TT>std::terminate</TT> is called (14.6.2 [<A href="https://wg21.link/except.terminate">except.terminate</A>]).

</BLOCKQUOTE>

<P>This could be read as indicating that the following example results
in calling <TT>std::terminate</TT>:</P>

<PRE>
  //<SPAN CLASS="cmnt"> function that exits via an exception</SPAN>
  void f() {
    //<SPAN CLASS="cmnt"> </SPAN>std::uncaught_exception()<SPAN CLASS="cmnt"> returns </SPAN>true<SPAN CLASS="cmnt"> here</SPAN>
    throw 0;
  }

  struct X {
    ~X() {
  //<SPAN CLASS="cmnt"> calls a function that exits via an exception</SPAN>
      try { f(); }
      catch( ... ) { }
    }
  };

  int main() {
    try {
      X x;
      throw 0; //<SPAN CLASS="cmnt"> calls </SPAN>X<SPAN CLASS="cmnt">'s destructor while exception is still uncaught.</SPAN>
    }
    catch( ... ) { }
  }
</PRE>

<P>This seems undesirable, and current implementations do not call
<TT>std::terminate</TT>.  Presumably the intention is that the cited
text only applies to functions that are called directly by the
exception handling mechanism, which is not true of <TT>f()</TT> in
this example, but this could be stated more clearly.</P>

<P><B>Rationale (September, 2013):</B></P>

<P>The intent of the wording in 14.2 [<A href="https://wg21.link/except.throw#7">except.throw</A>] paragraph 7
is to call <TT>std::terminate</TT> if an exception is propagated into
the exception-handling mechanism; &#8220;If the exception handling
mechanism... calls a function that exits via an exception&#8221; is
thus intended to refer to functions that are directly called by
the exception handling mechanism.  In the given example, <TT>f()</TT>
is not called by the exception handling mechanism, it is called by
<TT>X::~X()</TT>.  The exception handling mechanism calls <TT>X::~X()</TT>,
but it does not exit via an exception, so <TT>std::terminate</TT> should
not be called.</P>

<BR><BR><HR>
<A NAME="1624"></A><H4>1624.
  
Destruction of union members with member initializers
</H4>
<B>Section: </B>14.3&#160; [<A href="https://wg21.link/except.ctor">except.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-02-15<BR>




<P>According to 14.3 [<A href="https://wg21.link/except.ctor#2">except.ctor</A>] paragraph 2,</P>

<BLOCKQUOTE>

An object of any storage duration whose initialization or destruction is
terminated by an exception will have destructors executed for all of its
fully constructed subobjects (excluding the variant members of a union-like
class)...

</BLOCKQUOTE>

<P>The restriction for variant members does not appear to be necessary when
there is a <I>mem-initializer</I> or non-static data member initializer for
a union member, as that determines which union member is active during the
execution of the constructor.</P>

<P><B>Rationale (April, 2013):</B></P>

<P>Although the active member in a member union is determined by an
initializer, it could change during the execution of the constructor's
<I>compound=statement</I>.</P>

<BR><BR><HR>
<A NAME="2209"></A><H4>2209.
  
Destruction of constructed array elements
</H4>
<B>Section: </B>14.3&#160; [<A href="https://wg21.link/except.ctor">except.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-12-03<BR>


<P>[Detailed description pending.]</P>

<P><B>Rationale (November, 2016):</B></P>

<P>The reported issue is no longer relevant after the adoption of paper
P0490R0 at the November, 2016 meeting.</P>

<BR><BR><HR>
<A NAME="2210"></A><H4>2210.
  
Principal/target constructor confusion
</H4>
<B>Section: </B>14.3&#160; [<A href="https://wg21.link/except.ctor">except.ctor</A>]
 &#160;&#160;&#160;

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

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

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


<P>[Detailed description pending.]</P>

<P><B>Rationale (November, 2016):</B></P>

<P>The reported issue is no longer relevant after the adoption of paper
P0490R0 at the November, 2016 meeting.</P>

<BR><BR><HR>
<A NAME="308"></A><H4>308.
  
Catching exceptions with ambiguous base classes
</H4>
<B>Section: </B>14.4&#160; [<A href="https://wg21.link/except.handle">except.handle</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Sergey P. Derevyago
 &#160;&#160;&#160;

 <B>Date: </B>04 Sep 2001<BR>


<P>14.4 [<A href="https://wg21.link/except.handle#3">except.handle</A>] paragraph 3 contains the following text:</P>
<BLOCKQUOTE>
A handler is a match for a throw-expression with an object of type E if
<UL>
<LI>
The handler is of type cv T or cv T&amp; and E and T are the same type
(ignoring the top-level cv- qualifiers), or
</LI>
<LI>
the handler is of type cv T or cv T&amp; and T is an unambiguous public base
class of E, or
</LI>
<LI>
the handler is of type cv1 T* cv2 and E is a pointer type that can be
converted to the type of the handler by either or both of
<UL>
<LI>
a standard pointer conversion (7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]) not involving
conversions to pointers to private or protected or ambiguous classes
</LI>
<LI>
a qualification conversion
</LI>
</UL>
</LI>
</UL>
</BLOCKQUOTE>

<P>I propose to alter this text to allow to catch exceptions with ambiguous
public base classes by some of the public subobjects. I'm really sure that
if someone writes:
<PRE>
    try {
        // ...
    }
    catch (Matherr&amp; m) {
        // ...
    }
</PRE>
he really wants to catch <I>all</I> <TT>Matherrs</TT> rather than to allow
some of the <TT>Matherrs</TT> to escape:
<PRE>
    class SomeMatherr : public Matherr { /* */ };
    struct TrickyBase1 : public SomeMatherr { /* */ };
    struct TrickyBase2 : public SomeMatherr { /* */ };
    struct TrickyMatherr : public TrickyBase1, TrickyBase2 { /* */ };
</PRE>
</P>

<P>According to the standard <TT>TrickyMatherr</TT>
will leak through the catch
<TT>(Matherr&amp; m)</TT> clause. For example:</P>
<PRE>
    #include &lt;stdio.h&gt;

    struct B {};
    struct B1 : B {};
    struct B2 : B {};
    struct D : B1, B2 {};  // D() has two B() subobjects

    void f() { throw D(); }

    int main()
    {
     try { f(); }
     catch (B&amp; b) { puts("B&amp;"); }  // passed
     catch (D&amp; d) { puts("D&amp;"); }  // really works _after_ B&amp;!!!
    }
</PRE>
<P>Also I see one more possible solution: to forbid objects with ambiguous
base classes to be "exceptional objects" (for example Borland C++ goes this
way) but it seems to be unnecessary restrictive.</P>

<P><B>Notes from the 10/01 meeting:</B></P>

<P>The Core Working Group did not feel this was a significant problem.
Catching either of the ambiguous base classes would be surprising, and
giving an error on throwing an object that has an ambiguous base class
would break existing code.</P>

<BR><BR><HR>
<A NAME="593"></A><H4>593.
  
Falling off the end of a destructor's <I>function-try-block</I> handler
</H4>
<B>Section: </B>14.4&#160; [<A href="https://wg21.link/except.handle">except.handle</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>30 August 2006<BR>


<P>If control reaches the end of handler in a
destructor's <I>function-try-block</I>, the exception is rethrown
(14.4 [<A href="https://wg21.link/except.handle#15">except.handle</A>] paragraph 15).  Because of the danger
of destructors that throw exceptions, would it be better to
treat this case as an implicit <TT>return;</TT> statement, as in
a function body?  There could be a transitional period, perhaps
using conditionally-supported behavior or the like, before
mandating the change.</P>

<P><B>Rationale (October, 2006):</B></P>

<P>The CWG felt that the current behavior is clearly specified and
reflects the intention of the Committee at the time the rules were
adopted.  Possible changes to these rules should be pursued through
the Evolution Working Group.</P>

<BR><BR><HR>
<A NAME="346"></A><H4>346.
  
Typo in 15.4
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lois Goldthwaite
 &#160;&#160;&#160;

 <B>Date: </B>18 March 2002<BR>


<P>14.5 [<A href="https://wg21.link/except.spec#13">except.spec</A>] paragraph 13 contains the following text.
I believe 'implicitLY' marked below should be replaced with
'implicit.'</P>
<BLOCKQUOTE>
<P>An implicitly declared special member
 function (11.4.4 [<A href="https://wg21.link/special">special</A>])
shall have an exception-specification. If f is an implicitly
declared default constructor, copy constructor, destructor, or copy
assignment operator, its implicit exception-specification
specifies the <I>type-id</I> T if and only if T is allowed by the
exception-specification of a function directly invoked
by f's <INS>implicitly</INS> definition;
f shall allow all exceptions if any function it directly invokes
allows all exceptions, and f shall allow no exceptions if
every function it directly invokes allows no exceptions. [Example: </P>
<PRE>
    struct A {
        A();
        A(const A&amp;) throw();
        ~A() throw(X);
    };
    struct B {
        B() throw();
        B(const B&amp;) throw();
        ~B() throw(Y);
    };
    struct D : public A, public B {
            //  Implicit declaration of  D::D();
            //  Implicit declaration of  D::D(const   D&amp;)   throw();
            //  Implicit declaration of  D::~D()   throw   (X,Y);
    };
</PRE>

<P>Furthermore, if A::~A() or B::~B() were virtual, D::~D() would not be as
restrictive as that of A::~A, and the program would
be ill-formed since a function that overrides a virtual function from a
base class shall have an exception-specification at least as
restrictive as that in the base class. ] </P>
</BLOCKQUOTE>

<P>The example code shows structs whose destructors have exception
specifications which throw certain types. There is no defect here, but
it doesn't sit well with our general advice elsewhere that destructors
should not throw. I wish I could think of some other way to illustrate
this section.</P>

<P><B>Notes from October 2002 meeting:</B></P>

<P>This was previously resolved by an editorial change.</P>

<BR><BR><HR>
<A NAME="829"></A><H4>829.
  
At what point is <TT>std::unexpected</TT> called?
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK135">N2800 comment
  UK&#160;135<BR></A>

<P>It is unclear whether <TT>std::unexpected</TT> is called before
or after the destruction of function arguments, partially-constructed
bases and members (when called from a constructor or destructor), etc.</P>

<P><B>Rationale (October, 2009):</B></P>

<P>The point at which <TT>std::unexpected</TT> is called is specified
in _N4606_.15.5.2 [<A href="https://wg21.link/except.unexpected#1">except.unexpected</A>] paragraph 1:</P>

<BLOCKQUOTE>

If a function with an <I>exception-specification</I> throws
an exception that is not listed in the
<I>exception-specification</I>, the function
<TT>std::unexpected()</TT> is called (_N4606_.D.6 [<A href="https://wg21.link/exception.unexpected">exception.unexpected</A>])
immediately after completing the stack unwinding for the former
function.

</BLOCKQUOTE>

<P>That is, it will be called after any local automatic objects and
temporaries are destroyed and before any other objects, such as
function arguments, are destroyed.  (See 7.6.1.3 [<A href="https://wg21.link/expr.call#4">expr.call</A>] paragraph 4:
 &#8220;The initialization and destruction of each
parameter occurs within the context of the calling
function.&#8221;)</P>

<BR><BR><HR>
<A NAME="1053"></A><H4>1053.
  
Terminate vs undefined behavior for noexcept violation
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dave Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-12<BR>


<P>The consensus at the Pittsburgh (March, 2010) meeting, as reflected in
the adoption of paper N3050, was that it was preferable for violation of
a <TT>noexcept</TT> guarantee to call <TT>std::terminate</TT>; previous
versions of the paper had called for undefined behavior in this case.
Not everyone was convinced that this was a good decision, however; this
issue is intended to facilitate further investigation and discussion of
the question with the benefit of more time and resources than were
available during the deliberations at the meeting.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>CWG reaffirmed the explicit decision of the Committee.</P>

<BR><BR><HR>
<A NAME="1798"></A><H4>1798.
  
<I>exception-specification</I>s of template arguments
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-10-16<BR>




<P>Although 14.5 [<A href="https://wg21.link/except.spec">except.spec</A>] paragraphs 5-6 require
that overriding a virtual function and initializing or
assigning to a function pointer not
weaken <I>exception-specification</I>s, the same is not true
of providing a template argument for a template parameter.
For example,</P>

<PRE>
  template&lt;void (*FP)() noexcept&gt; void x() { }
  void f() noexcept(false);
  template void x&lt;f&gt;();
</PRE>

<P>is currently well-formed, which seems inconsistent.  (Note that
if <I>exception-specification</I>s become part of the type system,
as proposed in <A HREF="cwg_defects.html#92">issue 92</A>, this issue will
become moot.)</P>

<P>See also issues <A HREF="cwg_defects.html#2010">2010</A>,
<A HREF="cwg_defects.html#1995">1995</A>,
<A HREF="cwg_defects.html#1975">1975</A>, and <A HREF="cwg_defects.html#1946">1946</A>.
</P>

<P><B>Rationale (February, 2014):</B></P>

<P>Are template declarations that differ only in the
<I>exception-specification</I> of the parameter redeclarations or
separate templates distinguished, presumably, by deduction failure?
This seems like a question more appropriate for consideration by EWG.</P>

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

<P>EWG has decided not to make a change in this area.  See EWG issue
133.</P>

<BR><BR><HR>
<A NAME="1934"></A><H4>1934.
  
Relaxing <I>exception-specification</I> compatibility requirements
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-06-03<BR>




<P>According to 14.5 [<A href="https://wg21.link/except.spec#4">except.spec</A>] paragraph 4,</P>

<BLOCKQUOTE>

If any declaration of a function has an <I>exception-specification</I> that
is not a <I>noexcept-specification</I> allowing all exceptions, all
declarations, including the definition and any explicit specialization, of
that function shall have a compatible <I>exception-specification</I>.

</BLOCKQUOTE>

<P>This seems excessive for explicit specializations, considering that
paragraph 6 applies a looser requirement for virtual functions:</P>

<BLOCKQUOTE>

If a virtual function has an <I>exception-specification</I>, all
declarations, including the definition, of any function that overrides that
virtual function in any derived class shall only allow exceptions that are
allowed by the <I>exception-specification</I> of the base class virtual
function.

</BLOCKQUOTE>

<P>The rule in paragraph 3 is also problematic in regard to
explicit specializations of destructors and defaulted special member
functions, as the implicit <I>exception-specification</I> of the
template member function cannot be determined.</P>

<P>There is also a related problem with defaulted special
member functions and <I>exception-specification</I>s.
According to 9.6.2 [<A href="https://wg21.link/dcl.fct.def.default#3">dcl.fct.def.default</A>] paragraph 3,</P>

<BLOCKQUOTE>

<P>If a function that is explicitly defaulted has an
explicit <I>exception-specification</I> that is not
compatible (14.5 [<A href="https://wg21.link/except.spec">except.spec</A>]) with
the <I>exception-specification</I> on the implicit
declaration, then</P>

<UL>
<LI><P>if the function is explicitly defaulted on its first
declaration, it is defined as deleted;</P></LI>

<LI>

<P>otherwise, the program is ill-formed.</P>
</LI>

</UL>

</BLOCKQUOTE>

<P>This rule precludes defaulting a virtual base class
destructor or copy/move functions if the derived class function
will throw an exception not allowed by the implicit base class
member function.</P>

<PP><B>Rationale (June, 2014):</B></PP>

<P>This request for a language extension should be evaluated by
EWG before any action is taken.</P>

<P><B>Additional note, November, 2020:</B></P>

<P>This request applied to full exception specifications and
is no longer relevant in the current language, where only
<I>noexcept-specifier</I>s are permitted.</P>

<P><B>EWG 2022-11-11</B></P>

<P>Close as NAD.</P>

<BR><BR><HR>
<A NAME="2183"></A><H4>2183.
  
Problems in description of potential exceptions
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-10-21<BR>


<P>The description of the &#8220;set of potential exceptions of an
expression&#8221; in 14.5 [<A href="https://wg21.link/except.spec#15">except.spec</A>] paragraph 15 does
not appear to be fully recursive, so it can miss the effect of, e.g.,
a <I>throw-expression</I> as a subexpression.  In addition,
bullet 15.1.1, which reads,</P>

<UL><LI><P>If its <I>postfix-expression</I> is a (possibly
parenthesized) <I>id-expression</I>
(_N4567_.5.1.1 [<A href="https://wg21.link/expr.prim.general">expr.prim.general</A>]), class member access
(7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]), or pointer-to-member operation
(7.6.4 [<A href="https://wg21.link/expr.mptr.oper">expr.mptr.oper</A>]) whose <I>cast-expression</I> is
an <I>id-expression</I>, <I>S</I> is the set of potential
exceptions of the entity selected by the
contained <I>id-expression</I> (after overload resolution,
if applicable).</P></LI></UL>

<P>omits the case where the <I>postfix-expression</I> is a
function call whose return type is a function pointer with an
exception specification.</P>

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

<P>This text will be replaced by the removal of dynamic exception
specifications (P0003) and thus does not need to be changed at this
time. The issue is placed in "review" status until document P0003 is
adopted.</P>
<P><B>Rationale (February, 2017):</B></P>

<P>The issue is moot after the adoption of paper P0003.</P>

<BR><BR><HR>
<A NAME="2216"></A><H4>2216.
  
Exception specifications in unevaluated contexts
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-12-21<BR>




<P>Consider:</P>

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

  template&lt;class T&gt;
  T foo(T) noexcept(std::is_nothrow_move_constructible&lt;T&gt;::value);

  int main()
  {
   sizeof(foo(0));
  }
</PRE>

According to 14.5 [<A href="https://wg21.link/except.spec#13">except.spec</A>] paragraph 13:

<BLOCKQUOTE>

An exception specification is considered to be needed when:
<UL>
<LI>
in an expression, the function is
selected by overload resolution (12.2 [<A href="https://wg21.link/over.match">over.match</A>],
12.3 [<A href="https://wg21.link/over.over">over.over</A>]);</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>Is it intended that the exception specification is needed for the
example? The function call is never evaluated and the exception
specification is not queried.</P>

<P><B>Rationale (November, 2016):</B></P>

<P>The type of the function is needed to know how to call it, and the
exception specification is part of the function type.</P>

<BR><BR><HR>
<A NAME="219"></A><H4>219.
  
Cannot defend against destructors that throw exceptions
</H4>
<B>Section: </B>14.6.2&#160; [<A href="https://wg21.link/except.terminate">except.terminate</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>31 Mar 2000<BR>




<P>Destructors that throw can easily cause programs to terminate,
with no possible defense.  Example: Given</P>

<PRE>
    struct XY { X x; Y y; };
</PRE>

<P>Assume that <TT>X::~X()</TT> is the only destructor in the entire
program that can throw. Assume further that <TT>Y</TT> construction is
the only other operation in the whole program that can throw. Then
<TT>XY</TT> cannot be used safely, in any context whatsoever, period
&#8212; even simply declaring an <TT>XY</TT> object can crash the
program:</P>

<PRE>
    XY xy; // construction attempt might terminate program:
	   //   1. construct x -- succeeds
	   //   2. construct y -- fails, throws exception
	   //   3. clean up by destroying x -- fails, throws exception,
	   //      but an exception is already active, so call
	   //      std::terminate() (oops)
	   // there is no defense
</PRE>

So it is highly dangerous to have even one destructor that could throw.

<P>Suggested Resolution:</P>

<P>Fix the above problem in one of the following two ways. I prefer
the first.</P>

<OL>

<LI>We already have text that specifies that any destructor operation in
the standard library (presumably including the destructors of UDTs used in
containers or as predicates, etc.) may not throw. There is good reason to
widen this injunction to specify that destructors may never throw at all.
(I realize this would render existing programs nonconforming if they did
do this, but it's unsafe anyway.)</LI>

<LI>Specify what happens in the above case so that
<TT>std::terminate()</TT> won't be called.</LI>

</OL>

<P>
<U>Fergus Henderson</U>: I disagree.  Code using <TT>XY</TT> may
well be safe, if <TT>X::~X()</TT> only throws if
<TT>std::uncaught_exception()</TT> is <TT>false</TT>.</P>

<P>I think the current exception handling scheme in C++ is certainly
flawed, but the flaws are IMHO design flaws, not minor technical
defects, and I don't think they can be solved by minor tweaks to the
existing design.  I think that at this point it is probably better to
keep the standard stable, and learn to live with the existing flaws,
rather than trying to solve them via TC.</P>

<P>
<U>Bjarne Stroustrup</U>: I strongly prefer to have the call to
<TT>std::terminate()</TT> be conforming. I see <TT>std::terminate()</TT> as a
proper way to blow away "the current mess" and get to the next level
of error handling. I do not want that escape to be non-conforming
&#8212; that would imply that programs relying on a error handling
based on serious errors being handled by terminating a process (which
happens to be a C++ program) in <TT>std::terminate()</TT> becomes
non-conforming. In many systems, there are &#8212; and/or should be
&#8212; error-handling and recovery mechanisms beyond what is offered
by a single C++ program.</P>

<P>
<U>Andy Koenig</U>: If we were to prohibit writing a destructor
that can throw, how would I solve the following problem?</P>

<P>I want to write a class that does buffered output.  Among the
other properties of that class is that destroying an object of
that class writes the last buffer on the output device before
freeing memory.</P>

<P>What should my class do if writing that last buffer indicates a
hardware output error?  My user had the option to flush the last
buffer explicitly before destroying the object, but didn't do so, and
therefore did not anticipate such a problem.  Unfortunately, the
problem happened anyway.  Should I be required to suppress this
error indication anyway?  In all cases?</P>

<P>
<U>Herb Sutter</U> (June, 2007): IMO, it's fine to suppress
it.  The user had the option of flushing the buffer and thus
being notified of the problem and chose not to use it.  If the
caller didn't flush, then likely the caller isn't ready for an
exception from the destructor, either.  You could also put an
assert into the destructor that would trigger if <TT>flush()</TT>
had not been called, to force callers to use the interface that
would report the error.  
</P>

<P>In practice, I would rather thrown an exception, even at the risk
of crashing the program if we happen to be in the middle of stack
unwinding.  The reason is that the program would crash only if a
hardware error occurred in the middle of cleaning up from some other
error that was in the process of being handled.  I would rather have
such a bizarre coincidence cause a crash, which stands a chance of
being diagnosed later, than to be ignored entirely and leave the
system in a state where the ignore error could cause other trouble
later that is even harder to diagnose.</P>

<P>If I'm not allowed to throw an exception when I detect this problem,
what are my options?</P>

<P>
<U>Herb Sutter</U>: I understand that some people might feel that
"a failed dtor during stack unwinding is preferable in certain cases"
(e.g., when recovery can be done beyond the scope of the program), but
the problem is "says who?"  It is the application program that should
be able to decide whether or not such semantics are correct for it,
and the problem here is that with the status quo a program cannot
defend itself against a <TT>std::terminate()</TT> &#8212; period. The
lower-level code makes the decision for everyone. In the original
example, the mere existence of an <TT>XY</TT> object puts at risk
every program that uses it, whether <TT>std::terminate()</TT> makes sense
for that program or not, and there is no way for a program to protect
itself.</P>

<P>That the "it's okay if the process goes south should a rare
combination of things happen" decision should be made by lower-level
code (e.g., <TT>X</TT> dtor) for all apps that use it, and which
doesn't even understand the context of any of the hundreds of apps
that use it, just cannot be correct.</P>

<P><B>Additional note (April, 2011):</B></P>

<P>The addition of the <TT>noexcept</TT> specifier, along with changes
to make many destructors <TT>noexcept</TT> by default, may have
sufficiently addressed these concerns.  CWG should consider changing
this to NAD or extension status.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>As given in the preceding note.</P>

<BR><BR><HR>
<A NAME="533"></A><H4>533.
  
Special treatment for C-style header names
</H4>
<B>Section: </B>15.3&#160; [<A href="https://wg21.link/cpp.include">cpp.include</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>4 October 2005<BR>


<P>In language imported directly from the C Standard,
15.3 [<A href="https://wg21.link/cpp.include#5">cpp.include</A>] paragraph 5 says,</P>

<BLOCKQUOTE>

The implementation provides unique mappings for sequences consisting
of one or more <I>nondigit</I>s (5.11 [<A href="https://wg21.link/lex.name">lex.name</A>]) followed
by a period (<TT>.</TT>)  and a single <I>nondigit</I>.

</BLOCKQUOTE>

<P>This is clearly intended to support C header names like
<TT>stdio.h</TT>.  However, C++ has header names like <TT>cstdio</TT>
that do not conform to this pattern but still presumably require
&#8220;unique mappings.&#8221;</P>

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

<P>Change 15.3 [<A href="https://wg21.link/cpp.include#5">cpp.include</A>] paragraph 5 as indicated:</P>

<BLOCKQUOTE>

The implementation provides unique mappings <INS>between the delimited
sequence and the external source file name</INS> for sequences consisting
of one or more nondigits or digits (5.11 [<A href="https://wg21.link/lex.name">lex.name</A>])<INS>,
optionally</INS> followed by a period (<TT>.</TT>) and a single nondigit...

</BLOCKQUOTE>

<P>(Clark Nelson will discuss this revision with WG14.)</P>

<P><B>Additional notes (October, 2006):</B></P>

<P>WG14 takes no position on this proposed change.</P>

<P><B>Rationale (September, 2008):</B></P>

<P>It is unclear what effect the provision of &#8220;unique
mappings&#8221; has or if a conforming program could detect the
failure of an implementation to do so.  There has been a
significant effort to synchronize this clause with the
corresponding section of the C99 Standard, and given the lack of
perceptible impact of the proposed change, there is insufficient
motivation to introduce a new divergence in the wording.</P>

<BR><BR><HR>
<A NAME="1720"></A><H4>1720.
  
Macro invocation in <TT>#include</TT> directive
</H4>
<B>Section: </B>15.3&#160; [<A href="https://wg21.link/cpp.include">cpp.include</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-07-24<BR>


<P>According to 15.3 [<A href="https://wg21.link/cpp.include#4">cpp.include</A>] paragraph 4,</P>

<BLOCKQUOTE>

<P>A preprocessing directive of the form</P>

<UL>
<TT># include</TT> <I>pp-tokens new-line</I>
</UL>

<P>(that does not match one of the two previous forms) is permitted. The
preprocessing tokens after <TT>include</TT> in the directive are processed
just as in normal text (Each identifier currently defined as a macro name
is replaced by its replacement list of preprocessing tokens.). If the
directive resulting after all replacements does not match one of the two
previous forms, the behavior is undefined.<SUP>155</SUP> The method by
which a sequence of preprocessing tokens between a <TT>&lt;</TT> and
a <TT>&gt;</TT> preprocessing token pair or a pair of <TT>"</TT> characters
is combined into a single header name preprocessing token is
implementation-defined.</P>

</BLOCKQUOTE>

<P>It might be inferred from the phrase &#8220;in the directive&#8221; that
only tokens before the terminating newline would be available for macro
expansion, and that consequently the closing right parenthesis of a
function-style macro must appear on the same line.  However, it would be
clearer if it used language like that of 15.7.2 [<A href="https://wg21.link/cpp.subst#1">cpp.subst</A>] paragraph 1:
</P>

<BLOCKQUOTE>

each argument's preprocessing tokens are completely macro replaced as if
they formed the rest of the preprocessing file; no other preprocessing
tokens are available.

</BLOCKQUOTE>

<P><B>Rationale (September, 2013):</B></P>

<P>The wording referring to preprocessing tokens &#8220;in the
directive&#8221; is a clear enough indication that no tokens after
the terminating newline are considered.</P>

<BR><BR><HR>
<A NAME="2193"></A><H4>2193.
  
<TT>numeric_limits&lt;int&gt;::radix</TT> and <TT>digits</TT>
</H4>
<B>Section: </B>17.3.5.2&#160; [<A href="https://wg21.link/numeric.limits.members">numeric.limits.members</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Tony Van Eerd
 &#160;&#160;&#160;

 <B>Date: </B>2015-11-02<BR>




<P>Is <TT>numeric_limits&lt;int&gt;::radix</TT> required to be 2?
17.3.5.2 [<A href="https://wg21.link/numeric.limits.members#23">numeric.limits.members</A>] paragraph 23 specifies:</P>

<PRE>
static constexpr int radix;
</PRE>

<BLOCKQUOTE>
For integer types, specifies the base of the representation.
</BLOCKQUOTE>

<P><B>Rationale (November, 2016):</B></P>

<P>CWG felt that the current specification is sufficiently clear and
there was no consensus for a change.</P>

<BR><BR><HR>
<A NAME="1277"></A><H4>1277.
  
Lax definition of <TT>intmax_t</TT> and <TT>uintmax_t</TT>
</H4>
<B>Section: </B>17.4.1&#160; [<A href="https://wg21.link/cstdint.syn">cstdint.syn</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-03-26<BR>




<P>The definition of <TT>intmax_t</TT> and <TT>uintmax_t</TT>, inherited
from C99, leaves open the possibility that the underlying types might not
be the ones with the highest integer conversion rank.  The requirements
for these types deal only with the representation, not the conversion
rank, and it is possible for, e.g., <TT>long</TT> and <TT>long long</TT>
to have the same representation, although they have different conversion
ranks.  On such an architecture, chosing <TT>long</TT> instead of
<TT>long long</TT> for <TT>intmax_t</TT> would be conforming.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>This is a C compatibility issue and has ABI implications; there
was no consensus to pursue a change.</P>

<BR><BR><HR>
<A NAME="2014"></A><H4>2014.
  
Unneeded deallocation signatures
</H4>
<B>Section: </B>17.6.3.3&#160; [<A href="https://wg21.link/new.delete.array">new.delete.array</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-10-03<BR>




<P>Paper N3778 added the following two deallocation signatures
to the standard library:</P>

<PRE>
   void operator delete(void* ptr, std::size_t size,
                        const std::nothrow_t&amp;) noexcept;
   void operator delete[](void* ptr, std::size_t size,
                          const std::nothrow_t&amp;) noexcept;
</PRE>

<P>The core language does not currently provide for calling these
functions; they could only be called as the matching deallocation
function when a constructor throws an exception, but the rules
for determining the matching deallocation function do not consider
the existence of the sized-deallocation variants.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>CWG agreed that the performance gain in using the
sized-deallocation variants when a constructor throws an
exception would be insignificant compared to the cost of the
exception handling itself and thus insufficient motivation
for changing the core language.  The issue was referred to
LWG for their consideration regarding removal of these
signatures.</P>

<BR><BR><HR>
<A NAME="266"></A><H4>266.
  
No grammar sentence symbol
</H4>
<B>Section: </B>Clause Annex A&#160; [<A href="https://wg21.link/gram">gram</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hans Aberg
 &#160;&#160;&#160;

 <B>Date: </B>2 Dec 2000<BR>


<P>The grammar in Appendix A does not indicate a grammar sentence
symbol and is therefore formally not a grammar.</P>

<P><B>Rationale (04/01):</B></P>

<P>Appendix A does not claim to be a formal grammar.  The
specification is clear enough in its current formulation.</P>

<BR><BR><HR>
<A NAME="1675"></A><H4>1675.
  
Size limit for automatic array object
</H4>
<B>Section: </B>Clause Annex B&#160; [<A href="https://wg21.link/implimits">implimits</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-05-03<BR>




<P>9.3.4.5 [<A href="https://wg21.link/dcl.array#1">dcl.array</A>] paragraph 1 says,</P>

<BLOCKQUOTE>

<P>The expression is <I>erroneous</I> if:</P>

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

<LI><P>its value is such that the size of the allocated object would exceed
the implementation-defined limit (Annex Clause Annex B [<A href="https://wg21.link/implimits">implimits</A>]);</P></LI>

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

</UL>

</BLOCKQUOTE>

<P>The only relevant limit in Clause Annex B [<A href="https://wg21.link/implimits">implimits</A>] is that
of the size of an object, but presumably an implementation might want
to impose a smaller limit on a stack-based object.  This separate
quantity is referred to in paragraph 4 when describing an array of
unspecified bound:</P>

<BLOCKQUOTE>

If the size of the array exceeds the size of the memory available for
objects with automatic storage duration, the behavior is undefined.

</BLOCKQUOTE>

<P>but perhaps it needs to be mentioned in Clause Annex B [<A href="https://wg21.link/implimits">implimits</A>] as
well.</P>

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

<P>This issue is resolved by the resolution of
<A HREF="cwg_closed.html#1761">issue 1761</A>.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>The specification was removed from the WP and moved into a
Technical Specification.</P>

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

<P>CWG discussed adding such a limit, even without the changes for
arrays of runtime bound, but decided that it was unneeded; such
handling could be added by implementations if desirable.</P>

<BR><BR><HR>
<A NAME="1933"></A><H4>1933.
  
Implementation limit for <I>initializer-list</I> elements
</H4>
<B>Section: </B>Clause Annex B&#160; [<A href="https://wg21.link/implimits">implimits</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-05-30<BR>




<P>Should there be an entry in Annex Clause Annex B [<A href="https://wg21.link/implimits">implimits</A>] for the
minimum number of elements an implementation should accept in an
<I>initializer-list</I>, and if so, what should that be?</P>

<P><B>Rationale (June, 2014):</B></P>

<P>There are already related limits in Annex Clause Annex B [<A href="https://wg21.link/implimits">implimits</A>]
(array bounds, object size), which should be sufficient.</P>

<BR><BR><HR>
<A NAME="81"></A><H4>81.
  
Null pointers and C compatibility
</H4>
<B>Section: </B>Clause Annex C&#160; [<A href="https://wg21.link/diff">diff</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>27 Oct 1998<BR>





<P>Annex C lists C compatibility issues. One item not in the annex came
up in a discussion in comp.std.c++.</P>

<P>Consider this C and C++ code:</P>
<PRE>
    const int j = 0;
    char* p = (char*)j;
</PRE>

<P>
<B>Rationale (10/99):</B> Because <TT>j</TT> is not a constant
expression in C, this code fragment has implementation-defined behavior
in C.  There is no incompatibility with C resulting from the fact that
C++ defines this behavior.</P>
<BR><BR><BR><BR><HR>
<A NAME="Dup%20Status"></A><H3>Issues with "Dup" Status</H3>
<HR>
<A NAME="1422"></A><H4>1422.
  
Type of character literals containing universal-character-names
</H4>
<B>Section: </B>5.13.3&#160; [<A href="https://wg21.link/lex.ccon">lex.ccon</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dave Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>2011-12-03<BR>




<P>The treatment of character literals containing universal-character-names
is not clear.  It is reasonable to conclude from 5.13.5 [<A href="https://wg21.link/lex.string#15">lex.string</A>] paragraph 15
that if a character named by a UCN cannot be represented by
a single character in the runtime character set, it becomes a multibyte
character and thus such a character literal is a multicharacter literal,
with type <TT>int</TT> and an implementation-defined value.  It would be
nice if 5.13.3 [<A href="https://wg21.link/lex.ccon">lex.ccon</A>] had the complete story by itself or at
least a reference to 5.13.5 [<A href="https://wg21.link/lex.string">lex.string</A>] for the details.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#912">issue 912</A>.</P>

<BR><BR><HR>
<A NAME="82"></A><H4>82.
  
Definition of "using" a constant expression
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bill Gibbons
 &#160;&#160;&#160;

 <B>Date: </B>31 Dec 1998<BR>





<P>The wording in
6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]

paragraph 2 about "potentially evaluated" is incomplete. It does not distinguish
between expressions which are used as "integral constant expressions" and
those which are not; nor does it distinguish between uses in which an objects
address is taken and those in which it is not. (A suitable definition
of "address taken" could be written without actually saying "address".)</P>

<P>Currently the definition of "use" has two parts (part (a) and (d) below);
but in practice there are two more kinds of "use" as in (b) and (c):</P>
<OL TYPE="a">
<LI>
Use in "sizeof" or a non-polymorphic "typeid". Neither the value
nor the address is really used. No definition is needed at all.</LI>

<LI>
Use as an integral constant expression. Only the value is used. A
static data member with its initializer given in the class need not have
a namespace-scope definition.</LI>

<LI>
Use which requires the value, which is known at compile time because the
object is const, of integral or enum type, and initialized with an integral
constant expression. Only the value need be used, but an implementation
is not required to use the value from the initializer; it might access
the object. So in the original example, the namespace-scope definition
is required even though most compilers will not require it.</LI>

<LI>
All other uses require that the object actually exist because its address
will be taken implicitly or explicitly.</LI>
</OL>
We discussed (b) and decided that the namespace-scope definition was not
needed, but the wording did not make it into the standard.

<P>I don't think we discussed (c).</P>

<P>
<B>Rationale (04/99):</B> The substantive part of this issue is
covered by <A HREF="cwg_defects.html#48">Core issue 48</A>
</P>
<BR><BR><HR>
<A NAME="12"></A><H4>12.
  
Default arguments on different declarations for the same function and the Koenig lookup
</H4>
<B>Section: </B>6.5.4&#160; [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>unknown<BR>





<P>Given the following test case:</P>
<PRE>
    enum E { e1, e2, e3 };

    void f(int, E e = e1);
    void f(E, E e = e1);

    void g() {
        void f(long, E e = e2);
        f(1); // calls ::f(int, E)
        f(e1); // ?
    }

</PRE>
First note that Koenig lookup breaks the concept of hiding functions through
local extern declarations as illustrated by the call `<TT>f(1)</TT>'. Should
the WP show this as an example?

<P>Second, it appears the WP is silent as to what happens with the call
`<TT>f(e1)</TT>': do the different default arguments create an ambiguity?
is the local choice preferred? or the global?</P>

<P>
<B>Tentative Resolution (10/98)</B>
In 6.5.4 [<A href="https://wg21.link/basic.lookup.argdep#2">basic.lookup.argdep</A>] paragraph 2,
 change</P>
<BLOCKQUOTE>If the ordinary unqualified lookup of the name finds the declaration
of a class member function, the associated namespaces and classes are not
considered.</BLOCKQUOTE>
to
<BLOCKQUOTE>If the ordinary unqualified lookup of the name finds the declaration
of a class member function or the declaration of a function at block scope,
the associated namespaces and classes are not considered.</BLOCKQUOTE>

<P>
<B>Rationale (04/99):</B> The proposal would also apply to local
<I>using-declaration</I>s (per Mike Ball) and was therefore deemed
undesirable.  The ambiguity issue is
dealt with in <A HREF="cwg_defects.html#1">Core issue 1</A>
</P>
<BR><BR><HR>
<A NAME="321"></A><H4>321.
  
Associated classes and namespaces for argument-dependent lookup
</H4>
<B>Section: </B>6.5.4&#160; [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>12 Nov 2001<BR>


<P>The last bullet of the second paragraph of section
6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>] says that:</P>
<BLOCKQUOTE>
If T is a template-id, its associated namespaces and classes are the
namespace in which the template is defined; for member templates, the member
template's class; the namespaces and classes associated with the types of
the template arguments provided for template type parameters (excluding
template template parameters); the namespaces in which any template template
arguments are defined; and the classes in which any member templates used as
template template arguments are defined.
</BLOCKQUOTE>

<P>The first problem with this wording is that it is misleading, since one
cannot get such a function argument whose type would be a template-id. The
bullet should be speaking about template specializations instead.</P>

<P>The second problem is owing to the use of the word "defined" in the phrases
"are the namespace in which the template is defined", "in which any template
template arguments are defined", and "as template template arguments are
defined". The bullet should use the word "declared" instead, since scenarios
like the one below are possible:</P>
<PRE>
namespace  A  {

   template&lt;class T&gt;
   struct  test  {

      template&lt;class U&gt;
      struct  mem_templ  {   };

   };

   // declaration in namespace 'A'
   template&lt;&gt; template&lt;&gt;
   struct  test&lt;int&gt;::mem_templ&lt;int&gt;;

   void  foo(test&lt;int&gt;::mem_templ&lt;int&gt;&amp;)
   {   }

}

// definition in the global namespace
template&lt;&gt; template&lt;&gt;
struct  A::test&lt;int&gt;::mem_templ&lt;int&gt;  {
};

int  main()
{
   A::test&lt;int&gt;::mem_templ&lt;int&gt;   inst;
   // According to the current definition of 3.4.2
   // foo is not found.
   foo(inst);
}
</PRE>

<P>In addition, the bullet doesn't make it clear whether a T which is a class
template specialization must also be treated as a class type, i.e. if the
contents of the second bullet of the second paragraph of section
6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>].
<BLOCKQUOTE>
<UL>
<LI>
If T is a class type (including unions), its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are defined.
[This wording is as updated by core issue 90.]
</LI>
</UL>
</BLOCKQUOTE>
must apply to it or not. The same stands for a T which is a function
template specialization. This detail can make a difference in an example
such as the one below:
<PRE>
template&lt;class T&gt;
struct  slist_iterator  {
   friend bool  operator==(const slist_iterator&amp; x, const slist_iterator&amp; y)
   {   return  true;   }
};

template&lt;class T&gt;
struct  slist  {
   typedef slist_iterator&lt;T&gt;   iterator;
   iterator  begin()
   {   return  iterator();   }
   iterator  end()
   {   return  iterator();   }
};

int  main()
{
   slist&lt;int&gt;   my_list;
   slist&lt;int&gt;::iterator   mi1 = my_list.begin(),  mi2 = my_list.end();
   // Must the the friend function declaration
   // bool  operator==(const slist_iterator&lt;int&gt;&amp;, const slist_iterator&lt;int&gt;&amp;);
   // be found through argument dependent lookup? I.e. is the specialization
   // 'slist&lt;int&gt;' the associated class of the arguments 'mi1' and 'mi2'. If we
   // apply only the contents of the last bullet of 3.4.2/2, then the type
   // 'slist_iterator&lt;int&gt;' has no associated classes and the friend declaration
   // is not found.
   mi1 == mi2;
}
</PRE>
</P>

<P>
<B>Suggested resolution</B>:</P>

<P>Replace the last bullet of the second paragraph of section
6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a <I>template-id</I>,
its associated namespaces and classes are the
namespace in which the template is defined; for member templates, the member
template's class; the namespaces and classes associated with the types of
the template arguments provided for template type parameters (excluding
template template parameters); the namespaces in which any template template
arguments are defined; and the classes in which any member templates used as
template template arguments are defined.
</LI>
</UL>
</BLOCKQUOTE>
with
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class template
specialization, its associated namespaces and
classes are those associated with <TT>T</TT> when
<TT>T</TT> is regarded as a class type; the
namespaces and classes associated with the types of the template arguments
provided for template type parameters (excluding template template
parameters); the namespaces in which the primary templates making template
template arguments are declared; and the classes in which any primary member
templates used as template template arguments are declared.
</LI>
<LI>
If <TT>T</TT> is a function template specialization,
its associated namespaces and
classes are those associated with <TT>T</TT> when
<TT>T</TT> is regarded as a function type;
the namespaces and classes associated with the types of the template
arguments provided for template type parameters (excluding template template
parameters); the namespaces in which the primary templates making template
template arguments are declared; and the classes in which any primary member
templates used as template template arguments are declared.
</LI>
</UL>
</BLOCKQUOTE>
</P>
<P>Replace the second bullet of the second paragraph of section
6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class type (including unions),
its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are defined.
</LI>
</UL>
</BLOCKQUOTE>
with
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class type (including unions),
its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are declared [Note: in case of any of the associated
classes being a class template specialization, its associated namespace is
acually the namespace containing the declaration of the primary class
template of the class template specialization].
</LI>
</UL>
</BLOCKQUOTE>
</P>

<P><B>Rationale (September, 2012):</B></P>

<P>The concerns in this issue were addressed by the resolutions of issues
<A HREF="cwg_defects.html#403">403</A> and <A HREF="cwg_defects.html#557">557</A>.</P>

<BR><BR><HR>
<A NAME="1853"></A><H4>1853.
  
Defining &#8220;allocated storage&#8221;
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jeffrey Yasskin
 &#160;&#160;&#160;

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


<P>The term &#8220;allocated storage&#8221; is used in several
places in the Standard to refer to memory in which an object may
be created (dynamic, static, or automatic storage), but it has no
formal definition.</P>

<P><B>Rationale (CWG 2023-06-15)</B></P>

<P>This issue is a dupliate of <A HREF="cwg_active.html#2551">issue 2551</A>.</P>

<BR><BR><HR>
<A NAME="2860"></A><H4>2860.
  
Remove and fix the term "vacuous initialization"
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2024-02-21<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/505">#505</A>.)</P>

<P>A class may have a trivial default constructor that is not actually
used to default-initialize a class object, e.g. because the
constructor is not eligible.  The definition of "vacuous initialization"
in 6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1, as used in
8.10 [<A href="https://wg21.link/stmt.dcl#2">stmt.dcl</A>] paragraph 2, does not reflect that fact.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The lifetime of an object or reference is a runtime property of the
object or reference. <DEL>A variable is said to have <I>vacuous
initialization</I> if it is default-initialized and, if it is of class
type or a (possibly multidimensional) array thereof, that class type
has a trivial default constructor.</DEL> The lifetime of an object of
type T begins when:
<UL>
<LI>storage with the proper alignment and size for type T is obtained,
and</LI>
<LI>its initialization (if any) is complete <DEL>(including vacuous
initialization)</DEL> (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]),</LI>
</UL>
except that if the object is a union member or subobject thereof, its
lifetime only begins if that union member is the initialized member in
the union (9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>], 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]),
or as described in 11.5 [<A href="https://wg21.link/class.union">class.union</A>],
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>], and 11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>], and
except as described in 20.2.10.2 [<A href="https://wg21.link/allocator.members">allocator.members</A>]. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 8.10 [<A href="https://wg21.link/stmt.dcl#2">stmt.dcl</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A variable with automatic storage duration
(6.8.6.4 [<A href="https://wg21.link/basic.stc.auto">basic.stc.auto</A>]) is active everywhere in the scope to
which it belongs after its <I>init-declarator</I> . Upon each transfer
of control (including sequential execution of statements) within a
function from point P to point Q, all variables with automatic storage
duration that are active at P and not at Q are destroyed in the
reverse order of their construction. Then, all variables with
automatic storage duration that are active at Q but not at P are
initialized in declaration order; unless all such variables <DEL>have
vacuous initialization (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>])</DEL>
<INS>are default-initialized and no initialization is performed for
any such variable other than calling a trivial default
constructor</INS>, the transfer of control shall not be a jump. [
Footnote: ... ] When a <I>declaration-statement</I> is executed, P and
Q are the points immediately before and after it; when a function
returns, Q is after its body. ...

</BLOCKQUOTE>
</LI>
</OL>

<P><B>CWG 2024-04-05</B></P>

<P>CWG preferred to keep the term <I>vacuous initialization</I> and
fix its definition while adressing <A HREF="cwg_defects.html#2859">issue 2859</A>.</P>

<BR><BR><HR>
<A NAME="1568"></A><H4>1568.
  
Temporary lifetime extension with intervening cast
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-10-11<BR>


<P>According to 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>] paragraphs 4-5,</P>

<BLOCKQUOTE>

<P>There are two contexts in which temporaries are destroyed at a
different point than the end of the full-expression...</P>



<P>The second context is when a reference is bound to a temporary.  The
temporary to which the reference is bound or the temporary that is the
complete object of a subobject to which the reference is bound
persists for the lifetime of the reference...
</P>

</BLOCKQUOTE>

<P>It is not clear whether this applies to an example like the
following:</P>

<PRE>
  struct S { };
  const S&amp; r = (const S&amp;)S();
</PRE>

<P>In one sense <TT>r</TT> is being bound to the temporary because
the object to which <TT>r</TT> refers is the temporary object.  From
another perspective, however, <TT>r</TT> is being bound not to a
temporary but to the lvalue expression <TT>(const S&amp;)S()</TT>, or,
more precisely, to the invented temporary variable described in
7.6.1.9 [<A href="https://wg21.link/expr.static.cast#4">expr.static.cast</A>] paragraph 4:</P>

<BLOCKQUOTE>

Otherwise, an expression <TT>e</TT> can be explicitly converted to a
type <TT>T</TT> using a <TT>static_cast</TT> of the form
<TT>static_cast&lt;T&gt;(e)</TT> if the declaration <TT>T t(e);</TT>
is well-formed, for some invented temporary variable <TT>t</TT>
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).  The effect of such an explicit conversion
is the same as performing the declaration and initialization and then
using the temporary variable as the result of the conversion.

</BLOCKQUOTE>

<P>(Since the invented variable <TT>t</TT> is called a
&#8220;temporary,&#8221; perhaps the intent is that its lifetime is
extended to that of <TT>r</TT>, and then the lifetime of the
<TT>S()</TT> temporary would be that of <TT>t</TT>.  However, this
reasoning is tenuous, and it may be better to make the intent
explicitly clear.)</P>

<P>(See also <A HREF="cwg_defects.html#1299">issue 1299</A>.)</P>

<P><B>Rationale (April, 2013):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#1376">issue 1376</A>.</P>

<BR><BR><HR>
<A NAME="1654"></A><H4>1654.
  
Literal types and <TT>constexpr</TT> defaulted constructors
</H4>
<B>Section: </B>6.9&#160; [<A href="https://wg21.link/basic.types">basic.types</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-04-20<BR>


<P>The requirement in 6.9 [<A href="https://wg21.link/basic.types">basic.types</A>] that a
literal type must have a <TT>constexpr</TT> constructor has
caused signficant problems with respect to defaulted default
constructors, since the determination of whether a
constructor is <TT>constexpr</TT> depends on its definition
and a defaulted special member function is only defined if
it is odr-used.  It might be better to remove that
requirement, at least as it applies to defaulted default
constructors.</P>

<P><B>Rationale (September, 2013):</B></P>

<P>This issue duplicates <A HREF="cwg_defects.html#1360">issue 1360</A>.</P>

<BR><BR><HR>
<A NAME="1534"></A><H4>1534.
  
cv-qualification of prvalue of type &#8220;array of class&#8221;
</H4>
<B>Section: </B>7.2.1&#160; [<A href="https://wg21.link/basic.lval">basic.lval</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-08-09<BR>


<P>According to 7.2.1 [<A href="https://wg21.link/basic.lval#4">basic.lval</A>] paragraph 4,</P>

<BLOCKQUOTE>

Class prvalues can have cv-qualified types; non-class prvalues always
have cv-unqualified types.

</BLOCKQUOTE>

<P>Presumably an array of a class type should also be permitted to have
a cv-qualified type.</P>

<P><B>Rationale (October, 2012):</B></P>

<P>This issue is a subset of, and resolved by the resolution of,
<A HREF="cwg_defects.html#1261">issue 1261</A>.</P>

<BR><BR><HR>
<A NAME="1927"></A><H4>1927.
  
Lifetime of temporaries in <I>init-capture</I>s
</H4>
<B>Section: </B>7.5.6.3&#160; [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-05-14<BR>


<P>The current Standard is not clear regarding the lifetime of a
temporary created in the initializer of an <I>init-capture</I>:</P>

<PRE>
  void g() {
    struct S { S(int); ~S(); };
    auto x = (S(1), [y = S(2)]{}, S(3));
  }
</PRE>

<P>Is the initializer for <TT>y</TT> considered a full-expression,
or does the <TT>S(2)</TT> temporary persist until the end of the
complete <TT>x</TT> initializer?</P>

<P><B>Reationale (June, 2014):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_closed.html#1695">issue 1695</A>.</P>

<BR><BR><HR>
<A NAME="2029"></A><H4>2029.
  
Abstract class return type in <TT>decltype</TT> operand
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-10-27<BR>


<P>According to 7.6.1.3 [<A href="https://wg21.link/expr.call#11">expr.call</A>] paragraph 11, when a
function call is the operand of a <I>decltype-specifier</I>,</P>

<BLOCKQUOTE>

a temporary object is not introduced for the prvalue. The
type of the prvalue may be incomplete.  [<I>Note:</I> as a
result, storage is not allocated for the prvalue and it is
not destroyed; thus, a class type is not instantiated as a
result of being the type of a function call in this
context. This is true regardless of whether the expression
uses function call notation or operator notation
(12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]). &#8212;<I>end note</I>]
[<I>Note:</I> unlike the rule for
a <I>decltype-specifier</I> that considers whether
an <I>id-expression</I> is parenthesized
(9.2.9.3 [<A href="https://wg21.link/dcl.type.simple">dcl.type.simple</A>]), parentheses have no special
meaning in this context. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>This relaxation of requirements on the return type of a
function does not mention abstract classes, so presumably the
following example is ill-formed:</P>

<PRE>
   struct Abstract {
     virtual ~Abstract() = 0;
   };

   template&lt;class T&gt; T func();

   typedef decltype(func&lt;Abstract&gt;()) type;
</PRE>

<P>However, there is implementation variance on the treatment of the
last line.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#1646">issue 1646</A>.</P>

<BR><BR><HR>
<A NAME="1300"></A><H4>1300.
  
<TT>T()</TT> for array types
</H4>
<B>Section: </B>7.6.1.4&#160; [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-18<BR>




<P>In an expression of the form <TT>T()</TT>, 7.6.1.4 [<A href="https://wg21.link/expr.type.conv#2">expr.type.conv</A>] paragraph 2
requires that <TT>T</TT> not be an array type.  Now that
temporary arrays can be created via a <I>braced-init-list</I> (see
<A HREF="cwg_defects.html#1232">issue 1232</A>), this restriction should be
eliminated.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The implications of array temporaries for the language should be
considered by the Evolution Working Group in a comprehensive fashion
rather than on a case-by-case basis.  See also issues
<A HREF="cwg_defects.html#1307">1307</A>, <A HREF="cwg_closed.html#1326">1326</A>, and
<A HREF="cwg_closed.html#1525">1525</A>.</P>

<P><B>Rationale (February, 2014):</B></P>

<P>This is a duplicate of <A HREF="cwg_active.html#914">issue 914</A>.</P>

<BR><BR><HR>
<A NAME="1521"></A><H4>1521.
  
<TT>T{</TT><I>expr</I><TT>}</TT> with reference types
</H4>
<B>Section: </B>7.6.1.4&#160; [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-10<BR>


<P>According to 7.6.1.4 [<A href="https://wg21.link/expr.type.conv#4">expr.type.conv</A>] paragraph 4,</P>

<BLOCKQUOTE>

Similarly, a <I>simple-type-specifier</I> or <I>typename-specifier</I>
followed by a <I>braced-init-list</I> creates a temporary object of
the specified type direct-list-initialized (9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]) with the specified <I>braced-init-list</I>, and its
value is that temporary object as a prvalue.

</BLOCKQUOTE>

<P>This wording does not handle the case where <TT>T</TT> is a
reference type: it is not possible to create a temporary object of
that type, and presumably the result would be an xvalue, not a prvalue.</P>



<P>(Duplicate of <A HREF="cwg_defects.html#2894">issue 2894</A>.)</P>

<BR><BR><HR>
<A NAME="1230"></A><H4>1230.
  
Confusing description of ambiguity of destructor name
</H4>
<B>Section: </B>7.6.2.2&#160; [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-12-13<BR>




<P>According to 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#10">expr.unary.op</A>] paragraph 10,</P>

<BLOCKQUOTE>

There is an ambiguity in the <I>unary-expression</I> <TT>~X()</TT>,
where <TT>X</TT> is a <I>class-name</I> or <I>decltype-specifier</I>.
The ambiguity is resolved in favor of treating <TT>~</TT> as a
unary complement rather than treating <TT>~X</TT> as referring
to a destructor.

</BLOCKQUOTE>

<P>It is not clear whether this is intended to apply to an
expression like <TT>(~S)()</TT>.  In large measure, that depends on
whether a <I>class-name</I> is an <I>id-expression</I> or not.  If it
is, the ambiguity described in 7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>] paragraph
10 does apply; if not, the expression is an unambiguous reference to
the destructor for class <TT>S</TT>.  There are several places in the
Standard that indicate that the name of a type is an
<I>id-expression</I>, but that might be more confusing than helpful.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>This issue is a duplicate of, and resolved by the resolution
of, <A HREF="cwg_defects.html#1971">issue 1971</A>.</P>

<BR><BR><HR>
<A NAME="839"></A><H4>839.
  
<TT>sizeof</TT> with opaque enumerations
</H4>
<B>Section: </B>7.6.2.5&#160; [<A href="https://wg21.link/expr.sizeof">expr.sizeof</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Alberto Ganesh Barbati
 &#160;&#160;&#160;

 <B>Date: </B>9 March, 2009<BR>


<P>7.6.2.5 [<A href="https://wg21.link/expr.sizeof#1">expr.sizeof</A>] paragraph 1 says,</P>

<BLOCKQUOTE>

The <TT>sizeof</TT> operator shall not be applied...  to an
enumeration type before all its enumerators have been declared...

</BLOCKQUOTE>

<P>This prevents use of <TT>sizeof</TT> with an opaque enumeration
type, even though the underlying type of such enumerations is known.</P>

<P><B>Rationale (May, 2009):</B></P>

<P>Duplicate of <A HREF="cwg_defects.html#803">issue 803</A>.</P>

<BR><BR><HR>
<A NAME="313"></A><H4>313.
  
Class with single conversion function to integral as array size in <TT>new</TT>
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Bill Gibbons
 &#160;&#160;&#160;

 <B>Date: </B>22 Oct 2001<BR>


<P>Should it be allowed to use an object of a class type having a single
conversion function to an integral type as an array size in the first
bound of the type in an array new?</P>

<PRE>
  struct A {
    operator int();
  } a;
  int main () {
    new int[a];
  }
</PRE>

<P>There are similar accommodations
for the expression in a <TT>delete</TT> (7.6.2.9 [<A href="https://wg21.link/expr.delete#1">expr.delete</A>] paragraph 1)
 and in a <TT>switch</TT> (8.5.3 [<A href="https://wg21.link/stmt.switch#2">stmt.switch</A>] paragraph 2)
.  There is also widespread existing practice on this
(g++, EDG, MSVC++, and Sun accept it, and even cfront 3.0.2).</P>

<P><B>Rationale (October, 2004):</B></P>

<P>Duplicate of <A HREF="cwg_defects.html#299">issue 299</A>.</P>

<BR><BR><HR>
<A NAME="265"></A><H4>265.
  
Destructors, exceptions, and deallocation
</H4>
<B>Section: </B>7.6.2.9&#160; [<A href="https://wg21.link/expr.delete">expr.delete</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>21 Nov 2000<BR>




<P>Does the Standard require that the deallocation function will
be called if the destructor throws an exception?  For example,</P>

<PRE>
    struct S {
        ~S() { throw 0; }
    };
    void f() {
        try {
            delete new S;
        }
        catch(...) { }
    }
</PRE>

<P>The question is whether the memory for the S object will be freed
or not.  It doesn't appear that the Standard answers the question,
although most people would probably assume that it will be freed.</P>

<P><B>Notes from 04/01 meeting:</B></P>

<P>There is a widespread feeling that it is a poor programming
practice to allow destructors to terminate with an exception
(see <A HREF="cwg_closed.html#219">issue 219</A>).  This question is
thus viewed as a tradeoff between efficiency and supporting "bad
code."  It was observed that there is no way in the current
language to protect against a throwing destructor, since the
throw might come from a virtual override.</P>

<P>It was suggested that the resolution to the issue might be
to make it implementation-defined whether the storage is freed
if the destructor throws.  Others suggested that the Standard
should require that the storage be freed, with the understanding
that implementations might have a flag to allow optimizing away
the overhead.  Still others thought that both this issue and
<A HREF="cwg_closed.html#219">issue 219</A> should be resolved by
forbidding a destructor to exit via an exception.  No consensus
was reached.</P>

<P><B>Rationale (October, 2008):</B></P>

<P>It was noticed that <A HREF="cwg_defects.html#353">issue 353</A>, an
exact duplicate of this one, was independently opened and
resolved.</P>

<BR><BR><HR>
<A NAME="2696"></A><H4>2696.
  
Relational comparisons of pointers to <TT>void</TT>
</H4>
<B>Section: </B>7.6.9&#160; [<A href="https://wg21.link/expr.rel">expr.rel</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>CWG
 &#160;&#160;&#160;

 <B>Date: </B>2023-02-09
  &#160;&#160;&#160;
  <B>Liaison: </B>SG22<BR>


<P>While discussing <A HREF="cwg_defects.html#2526">issue 2526</A>, it was
noted that C++ yields an unspecified result for comparing unequal
pointers to <TT>void</TT> in all cases, whereas C does specify the result
if the pointer values point to the same object or (possibly different)
subobjects thereof, because C considers <TT>void</TT> an object
type.</P>

<P><B>February, 2023</B></P>

<P>Requested confirmation of the C status quo from SG22.</P>

<P><B>Rationale (June, 2023)</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#2749">issue 2749</A>.</P>

<BR><BR><HR>
<A NAME="1626"></A><H4>1626.
  
<TT>constexpr</TT> member functions in <I>brace-or-equal-initializer</I>s
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-19<BR>


<P>The Standard should make clear that a <TT>constexpr</TT> member
function cannot be used in a constant expression until its class is
complete.  For example:</P>

<PRE>
  template&lt;typename T&gt; struct C {
    template&lt;typename T2&gt; static constexpr bool _S_chk() {
      return false;
    }
    static const bool __value = _S_chk&lt;int&gt;();
  };

  C&lt;double&gt; c;
</PRE>

<P>Current implementations accept this, although they reject the
corresponding non-template case:</P>

<PRE>
  struct C {
    static constexpr bool _S_chk() { return false; }
    static const bool __value = _S_chk();
  };

  C c;
</PRE>

<P>Presumably the template case should be handled consistently with the
non-template case.</P>



<P><B>CWG 2024-06-28</B></P>

<P>CWG opined that, contrary to the assertion in the issue, the
treatment of non-templated class definitions should be changed to more
closely resemble templated ones.  This direction is covered by
<A HREF="cwg_active.html#2335">issue 2335</A>.</P>

<BR><BR><HR>
<A NAME="1445"></A><H4>1445.
  
Argument-dependent lookup of <TT>begin</TT> and <TT>end</TT>
</H4>
<B>Section: </B>8.6.5&#160; [<A href="https://wg21.link/stmt.ranged">stmt.ranged</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2012-01-16<BR>




<P>According to 8.6.5 [<A href="https://wg21.link/stmt.ranged#1">stmt.ranged</A>] paragraph 1, the functions
<TT>begin</TT> and <TT>end</TT> are looked up &#8220;with
argument-dependent lookup (6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>])&#8221; for
non-array, non-class types and for class types with no members of
those names.  It seems surprising that the lookup is different from
the lookup that would result if the <TT>for</TT> statement were
replaced by its nominal expansion, i.e., including (as does the
referenced section, 6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]) the result of ordinary
unqualified lookup as well as the lookup in associated namespaces.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#1442">issue 1442</A>.</P>

<BR><BR><HR>
<A NAME="1498"></A><H4>1498.
  
Lifetime of temporaries in range-based <TT>for</TT>
</H4>
<B>Section: </B>8.6.5&#160; [<A href="https://wg21.link/stmt.ranged">stmt.ranged</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Beman Dawes
 &#160;&#160;&#160;

 <B>Date: </B>2012-04-26<BR>




<P>Because the reference <TT>__range</TT> in the expansion of a
range-based <TT>for</TT> statement, as described in 8.6.5 [<A href="https://wg21.link/stmt.ranged#1">stmt.ranged</A>] paragraph 1, is bound only to the top-level expression
of <I>range-init</I>, the lifetime of temporaries created at lower
levels in that expression expires before the body of the loop is
reached, leading to dangling references.  It would be helpful if the
lifetime of those temporaries were extended over the entire
statement.</P>

<P>(See also <A HREF="cwg_defects.html#1523">issue 1523</A> for another
question regarding the rewritten form of the range-based <TT>for</TT>.)</P>

<P><B>Rationale (October, 2012):</B></P>

<P>This is a duplicate of <A HREF="cwg_defects.html#900">issue 900</A>.</P>

<BR><BR><HR>
<A NAME="2884"></A><H4>2884.
  
Qualified declarations of partial specializations
</H4>
<B>Section: </B>9.2.9.5&#160; [<A href="https://wg21.link/dcl.type.elab">dcl.type.elab</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Krystian Stasiowski
 &#160;&#160;&#160;

 <B>Date: </B>2024-03-19<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/521">#521</A>.)</P>

<P>Consider:</P>

<PRE>
  namespace N
  {
    template&lt;typename T&gt;
    struct A;
  }

  template&lt;&gt;
  struct N::A&lt;int&gt;;   //<SPAN CLASS="cmnt"> #1</SPAN>

  template&lt;typename T&gt;
  struct N::A&lt;T*&gt;;    //<SPAN CLASS="cmnt"> #2</SPAN>
</PRE>

<P>#1 is currently well-formed, but #2 is an ill-formed use of
an <I>elaborated-type-specifier</I>.  This is inconsistent and not
aligned with implementation practice.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 9.2.9.5 [<A href="https://wg21.link/dcl.type.elab#2">dcl.type.elab</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If an <I>elaborated-type-specifier</I> is the sole constituent of a
declaration, the declaration is ill-formed unless it is an explicit
specialization (13.9.4 [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]), <INS>a partial
specialization (13.7.6 [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]),</INS> an explicit
instantiation (13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]) or it has one of the
following forms: ...

</BLOCKQUOTE>

<P><B>CWG 2024-05-17</B></P>

<P>Duplicate of <A HREF="cwg_defects.html#2874">issue 2874</A>.</P>

<BR><BR><HR>
<A NAME="2493"></A><H4>2493.
  
<TT>auto</TT> as a <I>conversion-type-id</I>
</H4>
<B>Section: </B>9.2.9.7.1&#160; [<A href="https://wg21.link/dcl.spec.auto.general">dcl.spec.auto.general</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2021-03-10<BR>


<P>Given the example,</P>

<PRE>
  struct A{
   operator auto(){
     return 0;
   }
  };
  int main(){
    A a;
    a.operator auto(); //<SPAN CLASS="cmnt"> #1</SPAN>
    a.operator int();  //<SPAN CLASS="cmnt"> #2</SPAN>
  }
</PRE>

<P>there is implementation divergence regarding which, if
either, of the calls is well-formed. MSVC and clang
reject #2, g++ rejects #1, and EDG rejects both.</P>

<P>According to 9.2.9.7.1 [<A href="https://wg21.link/dcl.spec.auto.general">dcl.spec.auto.general</A>] paragraph
6:</P>

<BLOCKQUOTE>

A program that uses a placeholder type in a context not
explicitly allowed in 9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>] is
ill-formed.

</BLOCKQUOTE>

<P>The use of <TT>auto</TT> as a <I>conversion-type-id</I>
in a function call is not mentioned in that section;
however, the section is dealing with declarative contexts
rather than expressions, so it's not clear how much weight
that observation should carry.</P>

<P><B>Rationale (December, 2021):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_active.html#1670">issue 1670</A>.</P>

<BR><BR><HR>
<A NAME="548"></A><H4>548.
  
<I>qualified-id</I>s in declarations
</H4>
<B>Section: </B>9.3.4&#160; [<A href="https://wg21.link/dcl.meaning">dcl.meaning</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Sebor
 &#160;&#160;&#160;

 <B>Date: </B>18 November 2005<BR>


<P>According to 9.3.4 [<A href="https://wg21.link/dcl.meaning#1">dcl.meaning</A>] paragraph 1, the declarator
in the definition or explicit instantiation of a namespace member can
only be qualified if the definition or explicit instantiation appears
outside the member's namespace:</P>

<BLOCKQUOTE>

A <I>declarator-id</I> shall not be qualified except for the
definition of a member function (11.4.2 [<A href="https://wg21.link/class.mfct">class.mfct</A>]) or static
data member (11.4.9 [<A href="https://wg21.link/class.static">class.static</A>]) outside of its class, the
definition or explicit instantiation of a function or variable member
of a namespace outside of its namespace, or the definition of a
previously declared explicit specialization outside of its namespace,
or the declaration of a friend function that is a member of another
class or namespace (11.8.4 [<A href="https://wg21.link/class.friend">class.friend</A>]). When
the <I>declarator-id</I> is qualified, the declaration shall refer to
a previously declared member of the class or namespace to which the
qualifier refers, and the member shall not have been introduced by
a <I>using-declaration</I> in the scope of the class or namespace
nominated by the <I>nested-name-specifier</I> of
the <I>declarator-id</I>.

</BLOCKQUOTE>

<P>There is no similar restriction on a <I>qualified-id</I> in a
class definition (Clause 11 [<A href="https://wg21.link/class#5">class</A>] paragraph 5):</P>

<BLOCKQUOTE>

If a <I>class-head</I> contains a <I>nested-name-specifier</I>,
the <I>class-specifier</I> shall refer to a class that was previously
declared directly in the class or namespace to which the
<I>nested-name-specifier</I> refers (i.e., neither inherited nor
introduced by a <I>using-declaration</I>), and
the <I>class-specifier</I> shall appear in a namespace enclosing the
previous declaration.

</BLOCKQUOTE>

<P>An <I>elaborated-type-specifier</I> in an explicit instatiation
containing a <I>qualified-id</I> is also not prohibited from appearing
in the namespace nominated by its <I>nested-name-specifier</I>
(13.9.3 [<A href="https://wg21.link/temp.explicit#2">temp.explicit</A>] paragraph 2):</P>

<BLOCKQUOTE>

An explicit instantiation shall appear in an enclosing namespace of
its template. If the name declared in the explicit instantiation is an
unqualified name, the explicit instantiation shall appear in the
namespace where its template is declared.

</BLOCKQUOTE>

<P>(This asymmetry is due to the removal of inappropriate mention
of classes in 9.3.4 [<A href="https://wg21.link/dcl.meaning">dcl.meaning</A>] by
<A HREF="cwg_defects.html#40">issue 40</A> and a failure to insert the
intended restrictions elsewhere.)</P>

<P>An example of this inconsistency is:</P>

<PRE>
    namespace N {
      template &lt;class T&gt; struct S { };
      template &lt;class T&gt; void foo () { }

      template struct N::S&lt;int&gt;;   //<SPAN CLASS="cmnt"> OK</SPAN>
      template void N::foo&lt;int&gt;(); //<SPAN CLASS="cmnt"> ill-formed</SPAN>
    }
</PRE>

<P>It is not clear that any purpose is served by the &#8220;outside of
its namespace&#8221; restriction on declarators in definitions and
explicit instantiations; if possible, it would be desirable to
reconcile the treatment of declarators and class names by removing
the restriction on declarators (which appears to be widespread
implementation practice, anyway).</P>

<P><B>Rationale (April, 2006):</B></P>

<P>This is the same as <A HREF="cwg_defects.html#482">issue 482</A>.</P>

<BR><BR><HR>
<A NAME="550"></A><H4>550.
  
Pointer to array of unknown bound in parameter declarations
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>22 November 2005<BR>


<P>The current wording of 9.3.4.6 [<A href="https://wg21.link/dcl.fct#6">dcl.fct</A>] paragraph 6
encompasses more than it should:</P>

<BLOCKQUOTE>

If the type of a parameter includes a type of the form &#8220;pointer
to array of unknown bound of <TT>T</TT>&#8221; or &#8220;reference to
array of unknown bound of <TT>T</TT>,&#8221; the program is
ill-formed. [<I>Footnote:</I> This excludes parameters of type
&#8220;<I>ptr-arr-seq</I> <TT>T2</TT>&#8221; where <TT>T2</TT> is
&#8220;pointer to array of unknown bound of <TT>T</TT>&#8221; and
where <I>ptr-arr-seq</I> means any sequence of &#8220;pointer
to&#8221; and &#8220;array of&#8221; derived declarator types. This
exclusion applies to the parameters of the function, and if a
parameter is a pointer to function or pointer to member function then
to its parameters also, etc. &#8212;<I>end footnote</I>]

</BLOCKQUOTE>

<P>The normative wording (contrary to the intention expressed in the
footnote) excludes declarations like</P>

<PRE>
    template&lt;class T&gt; struct S {};
    void f(S&lt;int (*)[]&gt;);
</PRE>

<P>and</P>

<PRE>
    struct S {};
    void f(int(*S::*)[]);
</PRE>

<P>but not</P>

<PRE>
    struct S {};
    void f(int(S::*)[]);
</PRE>

<P><B>Rationale (November, 2014):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#393">issue 393</A>.</P>

<BR><BR><HR>
<A NAME="998"></A><H4>998.
  
Function parameter transformations and template functions
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>8 November, 2009<BR>


<P>9.3.4.6 [<A href="https://wg21.link/dcl.fct#5">dcl.fct</A>] paragraph 5 specifies that cv-qualifiers
are deleted from parameter types.  However, it's not clear what this
should mean for function templates.  For example,</P>

<PRE>
    template&lt;class T&gt; struct A {
       typedef A arr[3];
    };

    template&lt;class T&gt; void f(const typename A&lt;T&gt;::arr) { }

    template void f&lt;int&gt;(const A&lt;int&gt;::arr); // #1

    template &lt;class T&gt; struct B {
       void g(T);
    };

    template &lt;class T&gt; void B&lt;T&gt;::g(const T) { } // #2
</PRE>

<P>If cv-qualifiers are dropped, then the explicit instantiation in
#1 will fail to match; if cv-qualifiers are retained, then the
definition in #2 does not match the declaration.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>This is a duplicate of <A HREF="cwg_active.html#1001">issue 1001</A>.</P>

<BR><BR><HR>
<A NAME="15"></A><H4>15.
  
Default arguments for parameters of function templates
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>unknown
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>





<P>9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#4">dcl.fct.default</A>] paragraph 4
says:</P>
<BLOCKQUOTE>For non-template functions, default arguments can be added
in later declarations of a functions in the same scope.</BLOCKQUOTE>
Why say for non-template functions? Why couldn't the following allowed?
<PRE>
    template &lt;class T&gt; struct B {
        template &lt;class U&gt; inline void f(U);
    };

    template &lt;class T&gt; template &lt;class U&gt;
    inline void B&lt;T&gt;::f(U = int) {} // adds default arguments
                                       // is this well-formed?
    void g()
    {
        B&lt;int&gt; b;
        b.f();
    }
</PRE>
If this is ill-formed, chapter 14 should mention this.

<P>
<B>Rationale:</B>
This is sufficiently clear in the standard. Allowing additional
default arguments would be an extension.</P>

<P><B>Notes from October 2002 meeting:</B></P>

<P>The example here is flawed.  It's not clear what is being requested.
One possibility is the extension introduced by
<A HREF="cwg_defects.html#226">issue 226</A>.  Other meanings don't seem to be
useful.</P>

<BR><BR><HR>
<A NAME="155"></A><H4>155.
  
Brace initializer for scalar
</H4>
<B>Section: </B>9.5&#160; [<A href="https://wg21.link/dcl.init">dcl.init</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>12 Aug 1999<BR>





<P>It is not clear whether the following declaration is well-formed:</P>

<PRE>
    struct S { int i; } s = { { 1 } };
</PRE>

According to 9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]

paragraph 2, a brace-enclosed initializer is permitted for a
subaggregate of an aggregate; however, <TT>i</TT> is a scalar, not an
aggregate.  9.5 [<A href="https://wg21.link/dcl.init#13">dcl.init</A>] paragraph 13

says that a standalone declaration like

<PRE>
    int i = { 1 };
</PRE>

is permitted, but it is not clear whether this says anything about the
form of initializers for scalar members of aggregates.

<P>This is (more) clearly permitted by the C89 Standard.</P>



<P><B>Rationale (May, 2008):</B></P>

<P>
<A HREF="cwg_defects.html#632">Issue 632</A> refers to exactly the same
question and has a more detailed discussion of the considerations
involved.</P>

<BR><BR><HR>
<A NAME="2269"></A><H4>2269.
  
Additional recursive references in aggregate DMIs
</H4>
<B>Section: </B>9.5.2&#160; [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

 <B>Date: </B>2016-06-07<BR>




<P>
<A HREF="cwg_defects.html#1696">Issue 1696</A> did not fully address
recursive references in default member initializers for aggregates,
for example:</P>

<PRE>
  struct S {
    int i = (S{}, 0);
  }; 
</PRE>

<P>or</P>

<PRE>
  struct S {
    int i = noexcept(S{});
  }; 
</PRE>

<BR><BR><HR>
<A NAME="2018"></A><H4>2018.
  
Qualification conversion vs reference binding
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-10-07<BR>




<P>Qualification conversions are not considered when doing reference
binding, which leads to some unexpected results:</P>

<PRE>
  template&lt;typename T&gt; T make();
  struct B {}; struct D : B {};

  const int *p1 = make&lt;int*&gt;();           //<SPAN CLASS="cmnt"> ok, qualification conversion</SPAN>
  const int *const *p2 = make&lt;int**&gt;();   //<SPAN CLASS="cmnt"> ok, qualification conversion</SPAN>
  const int **p3 = make&lt;int**&gt;();         //<SPAN CLASS="cmnt"> error, not type safe</SPAN>

  const int &amp;r1 = make&lt;int&amp;&gt;();           //<SPAN CLASS="cmnt"> ok, binds directly</SPAN>
  const int *const &amp;r2 = make&lt;int*&amp;&gt;();   //<SPAN CLASS="cmnt"> weird, binds to a temporary</SPAN>
  const int *&amp;r3 = make&lt;int*&amp;&gt;();         //<SPAN CLASS="cmnt"> error</SPAN>

  const int &amp;&amp;x1 = make&lt;int&amp;&amp;&gt;();         //<SPAN CLASS="cmnt"> ok, binds directly</SPAN>
  const int *const &amp;&amp;x2 = make&lt;int*&amp;&amp;&gt;(); //<SPAN CLASS="cmnt"> weird, binds to a temporary</SPAN>
  const int *&amp;&amp;x3 = make&lt;int*&amp;&amp;&gt;();       //<SPAN CLASS="cmnt"> weird, binds to a temporary</SPAN>
</PRE>

<P>It might make sense to say that similar types are reference-related
and if there is a qualification conversion they are reference-compatible.</P>

<P>See also <A HREF="cwg_active.html#2023">issue 2023</A>.</P>

<P><B>Rationale (September, 2023):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#2352">issue 2352</A>.</P>

<BR><BR><HR>
<A NAME="1505"></A><H4>1505.
  
Direct binding of reference to temporary in list-initialization
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2012-05-27<BR>


<P>In an example like</P>

<PRE>
  const int&amp;r {1};
</PRE>

<P>the expectation is that this creates a temporary of type <TT>const
int</TT> containing the value <TT>1</TT> and binds the reference to
it.  And it does, but along the way it creates two temporaries.  The
wording in 9.5.5 [<A href="https://wg21.link/dcl.init.list#3">dcl.init.list</A>] paragraph 3, the bullet on
reference initialization, says that a prvalue temporary of type
<TT>const int</TT> is created, and then we do reference binding.
Because this is a non-class case and the source is a prvalue, we end
up in the section of 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>] that says we create a
temporary (again of type <TT>const int</TT>) and initialize it from
the source.  So we've created two temporaries.  Now, this may not
matter to anyone, since the discarded temporary is not observable, but
it may be a concern that the reference is not binding directly to the
temporary created for the <TT>{1}</TT>, since we do sometimes base
behavior on the &#8220;bind directly&#8221; attribute. </P>

<P><B>Rationale (September, 2012):</B></P>

<P>This issue is based on the wording prior to the application of the
resolution of <A HREF="cwg_defects.html#1288">issue 1288</A>.  With that change,
there is no longer a problem.</P>

<BR><BR><HR>
<A NAME="2314"></A><H4>2314.
  
Structured bindings and lambda capture
</H4>
<B>Section: </B>9.7&#160; [<A href="https://wg21.link/dcl.struct.bind">dcl.struct.bind</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-08-14<BR>




<P>Consider:</P>

<PRE>
  void f() {
   tuple&lt;int, int&gt; a;
   auto &amp;[x, y] = a;
   [x] {};           //<SPAN CLASS="cmnt"> ok, captures reference to int member of 'a' by value</SPAN>
   [&amp;] { use(x); };  //<SPAN CLASS="cmnt"> ok, capture reference by reference</SPAN>
  }

  void g() {
   struct T { int a, b; } a;
   auto &amp;[x, y] = a;
   [x] {};           //<SPAN CLASS="cmnt"> ill-formed, 'x' does not name a variable</SPAN>
   [&amp;] { use(x); };  //<SPAN CLASS="cmnt"> ???</SPAN>
  }
</PRE>

<P>The standard is silent on whether and how identifiers of a
decomposition declaration can be captured by a lambda.</P>

<P><B>Rationale (July, 2017):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_closed.html#2308">issue 2308</A>.</P>

<BR><BR><HR>
<A NAME="1713"></A><H4>1713.
  
Linkage of variable template specializations
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-08<BR>




<P>Given a namespace-scope declaration like</P>

<PRE>
  template&lt;typename T&gt; T var = T();
</PRE>

<P>should <TT>T&lt;const int&gt;</TT> have internal linkage by virtue
of its const-qualified type?  Or should it inherit the linkage of the
template?</P>

<P><B>Notes from the February, 2014 meeting:</B></P>

<P>CWG noted that linkage is by name, and a specialization of a variable
template does not have a name separate from that of the variable
template, thus the specialization will have the linkage of the template.</P>

<P><B>Rationale (February, 2021):</B></P>

<P>This issue is a duplicate of, and resolved by the resolution
of, <A HREF="cwg_defects.html#2387">issue 2387</A>.</P>

<BR><BR><HR>
<A NAME="1039"></A><H4>1039.
  
Coordinating C and C++ alignment specifications
</H4>
<B>Section: </B>9.13.2&#160; [<A href="https://wg21.link/dcl.align">dcl.align</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-03<BR>


<P>WG14 intends to support alignment specifications in their next
Standard.  WG21 should explore possibilities for compatibility
between C and C++ for these specifications.  See paper N3093.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>This is a duplicate of <A HREF="cwg_defects.html#1115">issue 1115</A>.</P>

<BR><BR><HR>
<A NAME="1041"></A><H4>1041.
  
<I>alias-declaration</I>s as class members
</H4>
<B>Section: </B>11.4&#160; [<A href="https://wg21.link/class.mem">class.mem</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-04<BR>


<P>The grammar for <I>member-declaration</I> in 11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]
does not allow an <I>alias-declaration</I> as a class member.  This
seems like an oversight.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#924">924</A>.</P>

<BR><BR><HR>
<A NAME="1052"></A><H4>1052.
  
<TT>const</TT> non-static data member and PODness
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-12<BR>




<P>The class</P>

<PRE>
    struct A {
        const int i;
    };
</PRE>

<P>was previously considered a POD class, but it no longer is,
because it has a non-trivial (deleted) copy assignment operator.
The impact of this change is not clear.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>This is a duplicate of <A HREF="cwg_defects.html#1140">issue 1140</A>.</P>

<BR><BR><HR>
<A NAME="1203"></A><H4>1203.
  
Misleading note regarding initialized static data members
</H4>
<B>Section: </B>11.4.9.3&#160; [<A href="https://wg21.link/class.static.data">class.static.data</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-30<BR>




<P>11.4.9.3 [<A href="https://wg21.link/class.static.data#3">class.static.data</A>] paragraph 3 says,</P>

<BLOCKQUOTE>

If a <TT>static</TT> data member is of <TT>const</TT> literal type,
its declaration in the class definition can specify a
<I>brace-or-equal-initializer</I> in which every
<I>initializer-clause</I> that is an <I>assignment-expression</I> is a
constant expression.  A <TT>static</TT> data member of literal type
can be declared in the class definition with the <TT>constexpr</TT>
specifier; if so, its declaration shall specify a
<I>brace-or-equal-initializer</I> in which every
<I>initializer-clause</I> that is an <I>assignment-expression</I> is a
constant expression.  [<I>Note:</I> In both these cases, the member may
appear in constant expressions. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>The note is misleading; to be used for its value in a constant
expression, the static data member must either be declared constexpr
or have integral or enumeration type.  Though strictly speaking, the
note is true, because <I>any</I> static data member, initialized or
not, may appear in an address constant expression if its address is
taken.</P>

<P>I think the right fix is to change &#8220;const literal&#8221; back
to &#8220;const integral or const enumeration.&#8221; It would also be
nice to avoid the duplication of text.</P>

<P><B>Rationale (November, 2010):</B></P>

<P>This is a duplicate of <A HREF="cwg_defects.html#1101">issue 1101</A>.</P>

<BR><BR><HR>
<A NAME="1019"></A><H4>1019.
  
Dependent <I>simple-template-id</I>s in <I>base-specifier</I>s and <I>mem-initializer</I>s
</H4>
<B>Section: </B>11.7&#160; [<A href="https://wg21.link/class.derived">class.derived</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>2010-01-12<BR>




<P>Although accepted by several compilers and used in popular code,
the grammar currently does not permit the use of a dependent template
name in a <I>base-specifier</I> or <I>mem-initializer-id</I>, for
example:</P>

<PRE>
    template&lt;typename T, typename U&gt;
    struct X : T::template apply&lt;U&gt; { };
</PRE>

<P>There does not seem to be a good reason to reject this usage.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#314">issue 314</A>.</P>

<BR><BR><HR>
<A NAME="747"></A><H4>747.
  
Access of protected base classes
</H4>
<B>Section: </B>11.8.3&#160; [<A href="https://wg21.link/class.access.base">class.access.base</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Sam Saariste
 &#160;&#160;&#160;

 <B>Date: </B>18 November, 2008<BR>




<P>Consider the following example:</P>

<PRE>
    struct B { void f(){} };
    class N : protected B { };

    struct P: N { friend int main(); };
    int main() {
          N n;
          B&amp; b = n; // R
          b.f();
    }
</PRE>

<P>This code is rendered well-formed by bullet 3 of 11.8.3 [<A href="https://wg21.link/class.access.base#4">class.access.base</A>] paragraph 4,
 which says that a base class <TT>B</TT> of <TT>N</TT> is
accessible at <I>R</I> if</P>

<UL><LI><P>
<I>R</I> occurs in a member or friend of a class <TT>P</TT>
derived from <TT>N</TT>, and an invented public member of <TT>B</TT>
would be a private or protected member of <TT>P</TT>
</P></LI></UL>

<P>This provision circumvents the additional restrictions on access
to protected members found in 11.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>] &#8212;
<TT>main()</TT> could not call <TT>B::f()</TT> directly because the
reference is not via an object of the class through which access is
obtained.  What is the purpose of this rule?</P>

<P><B>Rationale (April, 2010):</B></P>

<P>This is a duplicate of <A HREF="cwg_active.html#472">issue 472</A>.</P>

<BR><BR><HR>
<A NAME="1855"></A><H4>1855.
  
Out-of-lifetime access to nonstatic data members
</H4>
<B>Section: </B>11.9.5&#160; [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2014-02-11<BR>


<P>The resolution of <A HREF="cwg_defects.html#597">issue 597</A> and anticipated
resolution of <A HREF="cwg_active.html#1517">issue 1517</A> allow access to
non-virtual base classes outside the lifetime of the object.  However, for
no apparent reason, references to nonstatic data members are still
prohibited.  This disparity should be rectified.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_active.html#1530">issue 1530</A>.</P>

<BR><BR><HR>
<A NAME="1373"></A><H4>1373.
  
Overload resolution changes matching reference-binding changes
</H4>
<B>Section: </B>12.2.2.7&#160; [<A href="https://wg21.link/over.match.ref">over.match.ref</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-15<BR>


<P>It looks like the resolution to <A HREF="cwg_defects.html#1138">issue 1138</A>
neglected to update 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] (in N3225) or
otherwise mention it from 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>] for the rvalue
cases.</P>

<P>Since this is a context where overload resolution is required (to
find the correct conversion function), 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>]
should probably be used (12.2 [<A href="https://wg21.link/over.match#2">over.match</A>] paragraph 2);
however, there are some oddities.</P>

<P><B>(Issue 1)</B></P>

<P>Consider:</P>

<PRE>
    struct A {
      typedef void functype();
      operator functype&amp;&amp;();
    };
    void (&amp;&amp;x)() = A();
</PRE>

<P>We are looking for a function lvalue; 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] (if we take it to be applicable) says the viable
functions are limited to conversion functions yielding
&#8220;lvalue reference&#8221; when 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
requires an lvalue result. The above would then fail to have any
candidate conversion functions and we are left with a non-viable
indirect binding to a &#8220;function temporary.&#8221;</P>

<P><B>(Issue 2)</B></P>

<P>Also, since the candidate functions in the case where an rvalue
(that is prvalue or xvalue) result is required do not include ones
which return lvalue references, I do not see what the wording
regarding the second standard conversion sequence having an
lvalue-to-rvalue transformation added in <A HREF="cwg_defects.html#1138">issue 1138</A> is meant to catch.</P>

<P>If the example containing</P>

<PRE>
    int&amp;&amp; rri2 = X();
</PRE>

<P>with a comment about <TT>operator int&amp;()</TT> is a clue,
then it seems that 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] is being
ignored.</P>

<P><B>(Conclusion)</B></P>

<P>It would seem that 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] should apply (and
be fixed to match the cases from <A HREF="cwg_defects.html#1138">issue1138</A>), the verbiage about the second standard conversion is
redundant, and the explanation in the example is wrong.</P>

<P>In particular, the previous wording for 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
did have distinct bullets for converting to an &#8220;lvalue&#8221;
and to an &#8220;rvalue;&#8221; we now have a bullet which is not
exclusively one or the other.</P>

<P><B>Possible fix</B></P>

<P>Add reference to [12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>]] in
9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>] for direct binding to rvalue
reference/const non-volatile via UDC.</P>

<P>Remove redundent sentence referring to second SCS.</P>

<P>Modify example to indicate <TT>operator int&amp;()</TT> is not
a candidate function.</P>

<P>Clarify that the point from 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>] below:</P>

<BLOCKQUOTE>

has a class type (i.e., <TT>T2</TT> is a class type), where
<TT>T1</TT> is not reference-related to <TT>T2</TT>, and can be
implicitly converted to an xvalue, class prvalue, or function
lvalue of type &#8220;<I>cv3</I> <TT>T3</TT>,&#8221; where
&#8220;<I>cv1</I> <TT>T1</TT>&#8221; is reference-compatible with
&#8220;<I>cv3</I> <TT>T3</TT>&#8221;...

</BLOCKQUOTE>

<P>is an rvalue case for 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] for
non-function types and lvalue case for function types.</P>

<P>Fix 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] to allow candidate functions
return rvalue reference to function type for lvalue cases.</P>

<P><B>Update 110510:</B></P>

<P>The example appears to be actually well-formed because the wording
about the second SCS is not triggered. Falling through to indirect
binding then succeeds.</P>

<P><B>Rationale (February, 2012):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#1328">issue 1328</A>.</P>

<BR><BR><HR>
<A NAME="2291"></A><H4>2291.
  
Implicit conversion sequences in non-call contexts
</H4>
<B>Section: </B>12.2.4.2&#160; [<A href="https://wg21.link/over.best.ics">over.best.ics</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2016-06-20<BR>


<P><B>Rationale (August, 2017):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_active.html#2243">issue 2243</A>.</P>

<BR><BR><HR>
<A NAME="1205"></A><H4>1205.
  
Lvalue reference binding and function viability
</H4>
<B>Section: </B>12.2.4.2.5&#160; [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-06<BR>


<P>According to 12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref#3">over.ics.ref</A>] paragraph 3,</P>

<BLOCKQUOTE>

Except for an implicit object parameter, for which see 12.2.2 [<A href="https://wg21.link/over.match.funcs">over.match.funcs</A>], a standard conversion sequence cannot be formed if it
requires binding an lvalue reference to non-<TT>const</TT> to an rvalue or
binding an rvalue reference to an lvalue.

</BLOCKQUOTE>

<P>This isn't precisely the restriction placed by 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
on binding an lvalue reference to an rvalue; the requirement there is that
the cv-qualification must be exactly <TT>const</TT> in such cases.  This
has an impact on the interpretation of the following example:</P>

<PRE>
    void f(const volatile int&amp;);
    void f(...);
    void g() {
        f(1);
    }
</PRE>

<P>Because <TT>f(const volatile int&amp;)</TT> is considered a viable
function for the call, it is a better match than <TT>f(...)</TT>, but
the binding of the argument to the parameter cannot be done, so the
program is ill-formed.  Presumably &#8220;lvalue reference to
non-<TT>const</TT>&#8221; should be clarified to exclude the
<TT>const volatile</TT> case.  (Implementations vary on their handling
of this example.)</P>

<P><B>Rationale (November, 2010):</B></P>

<P>This is a duplicate of <A HREF="cwg_defects.html#1152">issue 1152</A>.</P>

<BR><BR><HR>
<A NAME="507"></A><H4>507.
  
Ambiguity assigning class object to built-in type
</H4>
<B>Section: </B>12.5&#160; [<A href="https://wg21.link/over.built">over.built</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>9 Mar 2005<BR>


<P>The following example is ambiguous according to the Standard:</P>

<PRE>
    struct Y {
      operator int();
      operator double();
    };
    void f(Y y) {
      double d;
      d = y;    //<SPAN CLASS="cmnt"> Ambiguous: </SPAN>Y::operator int()<SPAN CLASS="cmnt"> or </SPAN>Y::operator double()<SPAN CLASS="cmnt">?</SPAN>
    }
</PRE>

<P>The reason for the ambiguity is that 12.5 [<A href="https://wg21.link/over.built#18">over.built</A>] paragraph 18
says that there are candidate functions
<TT>double&amp;&#160;operator=(double&amp;,&#160;int)</TT> and
<TT>double&amp;&#160;operator=(double&amp;,&#160;double)</TT> (among
others).  In each case, the second argument is converted by a
user-defined conversion sequence (12.2.4.2.3 [<A href="https://wg21.link/over.ics.user">over.ics.user</A>])
where the initial and final standard conversion sequences are the
identity conversion &#8212; i.e., the conversion sequences for the
second argument are indistinguishable for each of these candidate
functions, and they are thus ambiguous.</P>

<P>Intuitively one might expect that, because it converts directly
to the target type in the assignment, <TT>Y::operator&#160;double()</TT>
would be selected, and in fact, most compilers do select it, but there
is currently no rule to distinguish between these user-defined
conversions.  Should there be?</P>

<P><B>Additional note (May, 2008):</B></P>

<P>Here is another example that is somewhat similar:</P>

<PRE>
    enum En { ec };

    struct S {
       operator int();
       operator En();
    };

    void foo () {
       S() == 0;   // ambiguous?
    }
</PRE>

<P>According to 12.5 [<A href="https://wg21.link/over.built#12">over.built</A>] paragraph 12, the candidate
functions are</P>

<UL><TT>bool operator==(<I>L</I>, <I>R</I>);</TT></UL>

<P>where <TT><I>R</I></TT> is <TT>int</TT> and <TT><I>L</I></TT>
is every promoted arithmetic type. Overload resolution proceeds in
two steps: first, for each candidate function, determine which
implicit conversion sequence is used to convert from the argument
type to the parameter type; then compare the candidate functions on
the basis of the relative costs of those conversion sequences.</P>

<P>In the case of <TT>operator==(int, int)</TT> there is a clear
winner: <TT>S::operator int()</TT> is chosen because the identity
conversion <TT>int -&gt; int</TT> is better than the promotion <TT>En
-&gt; int</TT>. For all the other candidates, the conversion for the
first parameter is ambiguous: both <TT>S::operator int()</TT> and
<TT>S::operator En()</TT> require either an integral conversion (for
integral <TT><I>L</I></TT>) or a floating-integral conversion (for
floating point <TT><I>L</I></TT>) and are thus indistinguishable.</P>

<P>These additional candidates are not removed from the set of viable
functions, however; because of 12.2.4.2 [<A href="https://wg21.link/over.best.ics#10">over.best.ics</A>] paragraph 10,
 they are assigned the &#8220;ambiguous conversion
sequence,&#8221; which &#8220;is treated as a user-defined sequence
that is indistinguishable from any other user-defined conversion
sequence.&#8221; As a result, all the viable functions are
indistinguishable and the call is ambiguous. Like the earlier example,
one might naively think that the exact match with <TT>S::operator int()</TT>
and <TT>bool operator==(int, int)</TT> would be selected, but that is not
the case.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>Duplicate of <A HREF="cwg_active.html#260">issue 260</A>.</P>

<BR><BR><HR>
<A NAME="72"></A><H4>72.
  
Linkage and storage class specifiers for templates
</H4>
<B>Section: </B>Clause 13&#160; [<A href="https://wg21.link/temp">temp</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Ball
 &#160;&#160;&#160;

 <B>Date: </B>19 Oct 1998<BR>





<P>
<U>John Spicer</U>: The standard does say that a namespace scope template
has external linkage unless it is a function template declared "static".
It doesn't explicitly say that the linkage of the template is also the
linkage of the instantiations, but I believe that is the intent.
For example, a storage class is prohibited on an explicit specialization
to ensure that a specialization cannot be given a different storage class
than the template on which it is based.</P>

<P>
<U>Mike Ball</U>: This makes sense, but I couldn't find much support
in the document. Sounds like yet another interpretation to add to
the list.</P>

<P>
<U>John Spicer</U>: The standard does not talk about the linkage of
instantiations, because only "names" are considered to have linkage, and
instances are not really names. So, from an implementation point
of view, instances have linkage, but from a language point of view, only
the template from which the instances are generated has linkage.</P>

<P>
<U>Mike Ball</U>: Which is why I think it would be cleaner to eliminate
storage class specifiers entirely and rely on the unnamed namespace.
There is a statement that specializations go into the namespace of the
template. No big deal, it's not something it says, so we live with
what's there.</P>

<P>
<U>John Spicer</U>: That would mean prohibiting static function templates.
I doubt those are common, but I don't really see much motivation for getting
rid of them at this point.</P>

<P>"export" is an additional attribute that is separate from linkage, but
that can only be applied to templates with external linkage.</P>

<P>
<U>Mike Ball</U>: I can't find that restriction in the standard, though
there is one that templates in an unnamed namespace can't be exported.
I'm pretty sure that we intended it, though.</P>

<P>
<U>John Spicer</U>: I can't find it either. The "inline" case
seems to be addressed, but not static. Surely this is an error as,
by definition, a static template can't be used from elsewhere.</P>

<P>
<B>Rationale:</B> Duplicate of
<A HREF="cwg_defects.html#69">Core issue 69</A>.</P>
<BR><BR><HR>
<A NAME="1023"></A><H4>1023.
  
<TT>thread_local</TT> objects as non-type template arguments
</H4>
<B>Section: </B>13.4.3&#160; [<A href="https://wg21.link/temp.arg.nontype">temp.arg.nontype</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Jeffrey Yasskin
 &#160;&#160;&#160;

 <B>Date: </B>2010-01-28<BR>




<P>Currently, 13.4.3 [<A href="https://wg21.link/temp.arg.nontype#1">temp.arg.nontype</A>] paragraph 1 only requires that
an object whose address is used as a non-type template argument
have external linkage, thus allowing objects of thread storage duration
to be used.  The requirement should presumably be for an object to have
static storage duration as well as external linkage.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>This is a duplicate of <A HREF="cwg_defects.html#1154">issue 1154</A>.</P>

<BR><BR><HR>
<A NAME="2391"></A><H4>2391.
  
Additional template parameters following pack expansion
</H4>
<B>Section: </B>13.7.4&#160; [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2018-12-03<BR>


<P>The Standard is not clear on the treatment of an example like the
following, and there is implementation variance:</P>

<PRE>
  template&lt;class ...Types&gt; struct Tuple_ { //<SPAN CLASS="cmnt"> _VARIADIC_TEMPLATE</SPAN>
    template&lt;Types ...T, int&gt; int f() {
      return sizeof...(Types);
    }
  };

  int main() {
    Tuple_&lt;char,int&gt; a;
    int b = a.f&lt;1, 2, 3&gt;();
  }
</PRE>

<P><B>Rationale (February, 2019):</B></P>

<P>This issue is covered in more detail in
<A HREF="cwg_active.html#2395">issue 2395</A>.</P>

<BR><BR><HR>
<A NAME="2021"></A><H4>2021.
  
Function template redeclaration via alias template
</H4>
<B>Section: </B>13.7.7.2&#160; [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-10-15<BR>




<P>See also <A HREF="cwg_closed.html#2025">issue 2025</A>.</P>

<P>Given the declarations</P>

<PRE>
   template&lt;int&gt; using T = int;
   template&lt;typename U&gt; void h(T&lt;f(U())&gt;);
   template&lt;typename U&gt; void h(T&lt;g(U())&gt;);
</PRE>

<P>Does this declare one function template or two?</P>

<P><B>Rationale (November, 2014):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_active.html#1980">issue 1980</A>.</P>

<BR><BR><HR>
<A NAME="2025"></A><H4>2025.
  
Declaration matching via alias templates
</H4>
<B>Section: </B>13.7.7.2&#160; [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-10-17<BR>




<P>Consider the following example:</P>

<PRE>
  template&lt;typename ...T&gt; struct X { void f(); static int n; };
  template&lt;typename T, typename U&gt; using A = T;
  template&lt;typename ...T&gt; void X&lt;A&lt;T, decltype(sizeof(T))&gt;...&gt;::f() {}
  template&lt;typename ...T&gt; void X&lt;A&lt;T, decltype(sizeof(T))&gt;...&gt;::n = 0;
  void g() { X&lt;void&gt;().f(); X&lt;void&gt;::n = 1; }
</PRE>

<P>Should this be valid?  The best answer would seem to be to produce
an error during instantiation, and that appears to be consistent with
the current Standard wording, but there is implementation divergence.</P>

<P>See also <A HREF="cwg_closed.html#2021">issue 2021</A>.</P>

<P><B>Rationale (May, 2015):</B></P>

<P>This issue is a duplicate os <A HREF="cwg_active.html#1979">issue 1979</A>.</P>

<BR><BR><HR>
<A NAME="200"></A><H4>200.
  
Partial ordering and explicit arguments
</H4>
<B>Section: </B>13.7.7.3&#160; [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Sebor
 &#160;&#160;&#160;

 <B>Date: </B>28 Jan 2000<BR>





<P>The description of how the partial ordering of template functions
is determined in
13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]
paragraphs 3-5 does
not make any provision for nondeduced template parameters.  For
example, the function call in the following code is ambiguous, even
though one template is "obviously" more specialized than the other:</P>

<PRE>
    template &lt;class T&gt; T f(int);
    template &lt;class T, class U&gt; T f(U);
    void g() {
        f&lt;int&gt;(1);
    }
</PRE>

The reason is that neither function parameter list allows template
parameter <TT>T</TT> to be deduced; both deductions fail, so neither
template is considered more specialized than the other and the
function call is ambiguous.

<P>One possibility of addressing this situation would be to
incorporate explicit template arguments from the call in the argument
deduction using the transformed function parameter lists.  In this
case, that would result in finding the first template to be more
specialized than the second.</P>

<P><B>Rationale (04/00):</B></P>

<P>This issue is covered in a more general context in
<A HREF="cwg_defects.html#214">issue 214</A>.</P>

<BR><BR><HR>
<A NAME="1349"></A><H4>1349.
  
Consistency of alias template redeclarations
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR>




<P>There appears to be no requirement that a redeclaration of an alias
template must be equivalent to the earlier one. An <I>alias-declaration</I>
is not a definition (6.2 [<A href="https://wg21.link/basic.def#2">basic.def</A>] paragraph 2), so presumably
an alias template declaration is also not a definition and thus the ODR
does not apply.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>This issue is superseded by <A HREF="cwg_defects.html#1896">issue 1896</A>.</P>

<BR><BR><HR>
<A NAME="375"></A><H4>375.
  
Confusing example on lookup with <TT>typename</TT>
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Manish Pagey
 &#160;&#160;&#160;

 <B>Date: </B>23 August 2002<BR>


<P>Section 13.8 [<A href="https://wg21.link/temp.res#4">temp.res</A>] paragraph 4 uses the
following example to show that
qualified name lookup described in Section 6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>]
applies even in the presence of "typename":</P>
<PRE>
  struct A {
    struct X { } ;
    int X ;
  } ;
  template&lt;class T&gt; void f(T t) {
    typename T::X x ; // ill-formed: finds the data member X
                      // not the member type X
  }
</PRE>
<P>This example is confusing because the definition of the template function
itself is not ill formed unless it is instantiated with "A" as the template
parameter. In other words, the example should be modified to something
like: </P>
<PRE>
  struct A {
    struct X { } ;
    int X ;
  } ;
  struct B {
    struct X { } ;
  } ;
  template&lt;class T&gt; void f(T t) {
    typename T::X x ;
  }
  void foo() {
    A a ;
    B b ;
    f(b) ; // OK -- finds member type B::X.
    f(a) ; // ill-formed: finds the data member A::X not
           // the member type A::X.
  }
</PRE>

<P><B>Notes from October 2002 meeting:</B></P>

<P>This is a duplicate of <A HREF="cwg_defects.html#345">Core Issue 345</A>.</P>

<BR><BR><HR>
<A NAME="1526"></A><H4>1526.
  
Dependent-class lookup in the current instantiation
</H4>
<B>Section: </B>13.8.3&#160; [<A href="https://wg21.link/temp.dep">temp.dep</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-22<BR>




<P>According to 13.8.3 [<A href="https://wg21.link/temp.dep#3">temp.dep</A>] paragraph 3,</P>

<BLOCKQUOTE>

In the definition of a class or class template, if a base class
depends on a <I>template-parameter</I>, the base class scope is not
examined during unqualified name lookup either at the point of
definition of the class template or member or during an instantiation
of the class template or member.

</BLOCKQUOTE>

<P>Note that this is phrased not as &#8220;if a base class is a
dependent type&#8221; but as &#8220;if a base class depends on a
<I>template-parameter</I>;&#8221; the current instantiation depends on
a <I>template-parameter</I> but is not a dependent type.  The
difference can be seen in this example:</P>

<PRE>
  template&lt;typename T&gt; struct A {
    typedef int type;
    struct C;
  };

  template&lt;typename T&gt; struct A&lt;T&gt;::C {
    void type();
    struct B;
  };

  template&lt;typename T&gt; struct A&lt;T&gt;::C::B : A&lt;T&gt; {
    type x;
  };

  A&lt;int&gt;::C::B b;   //<SPAN CLASS="cmnt"> #1</SPAN>
</PRE>

<P>If the excluded bases were dependent types, the reference to
<TT>type</TT> at #1 would resolve to <TT>A::type</TT>; with the
current wording, the reference resolves to <TT>C::type</TT>.</P>

<P>(See also <A HREF="cwg_active.html#1524">issue 1524</A> for another case
in which this distinction makes a difference.)</P>

<P><B>Rationale (September, 2012):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#591">issue 591</A>.</P>

<BR><BR><HR>
<A NAME="1994"></A><H4>1994.
  
Confusing wording regarding multiple <TT>template&lt;&gt;</TT> prefixes
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-09-03<BR>




<P>According to 13.9.4 [<A href="https://wg21.link/temp.expl.spec#15">temp.expl.spec</A>] paragraph 15,</P>

<BLOCKQUOTE>

<P>A member or a member template may be nested within many
enclosing class templates. In an explicit specialization for
such a member, the member declaration shall be preceded by a
template&lt;&gt; for each enclosing class template that is
explicitly specialized. [<I>Example:</I>
</P>

<PRE>
  template&lt;class T1&gt; class A {
    template&lt;class T2&gt; class B {
      void mf();
    };
  };
  template&lt;&gt; template&lt;&gt; class A&lt;int&gt;::B&lt;double&gt;;
  template&lt;&gt; template&lt;&gt; void A&lt;char&gt;::B&lt;char&gt;::mf();
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<P>However, in the declaration of <TT>A&lt;int&gt;::B&lt;double&gt;</TT>,
<TT>A&lt;int&gt;</TT> is not explicitly instantiated, it is implicitly
instantiated.</P>

<P><B>Rationale (November, 2014):</B></P>

<P>This issue is a duplicate of <A HREF="cwg_active.html#529">issue 529</A>.</P>

<BR><BR><HR>
<A NAME="1326"></A><H4>1326.
  
Deducing an array bound from an <I>initializer-list</I>
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Faisal Vali
 &#160;&#160;&#160;

 <B>Date: </B>2011-05-28<BR>




<P>It would be useful to be able to deduce an array bound from the
number of elements in an initializer list.</P>

<P><B>Rationale (August, 2011):</B></P>

<P>The implications of array temporaries for the language should be
considered by the Evolution Working Group in a comprehensive fashion
rather than on a case-by-case basis.  See also issues
<A HREF="cwg_closed.html#1300">1300</A>, <A HREF="cwg_defects.html#1307">1307</A>,
and <A HREF="cwg_closed.html#1525">1525</A>.</P>

<P><B>Rationale (January, 2021):</B></P>

<P>This issue is a duplicate of
<A HREF="cwg_defects.html#1591">issue 1591</A>.</P>

<BR><BR><HR>
<A NAME="2326"></A><H4>2326.
  
Type deduction with initializer list containing ambiguous functions
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Caves
 &#160;&#160;&#160;

 <B>Date: </B>2016-08-12<BR>


<P>Consider the following example:</P>

<PRE>
  template&lt;typename T, int N&gt; void g(T (* const (&amp;)[N])(T)) { }

  int f1(int);
  int f4(int);
  char f4(char);

  void f() {
    g({ &amp;f1, &amp;f4 });  //<SPAN CLASS="cmnt"> OK, </SPAN>T<SPAN CLASS="cmnt"> deduced to </SPAN>int<SPAN CLASS="cmnt">, </SPAN>N<SPAN CLASS="cmnt"> deduced to </SPAN>2<SPAN CLASS="cmnt">?</SPAN>
  }
</PRE>

<P>There is implementation divergence on the handling of this
example. According to 13.10.3.2 [<A href="https://wg21.link/temp.deduct.call#1">temp.deduct.call</A>] paragraph 1,</P>

<BLOCKQUOTE>

If 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 (9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]), 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.

</BLOCKQUOTE>

<P>Deduction fails for the <TT>&amp;f4</TT> element fails due to
ambiguity, so by 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#5.5.1">temp.deduct.type</A>] bullet 5.5.1 the
function parameter is a non-deduced context.</P>

<P>It is not clear, however, whether that implies that the
function parameter is a non-deduced context from the perspective
of the entire deduction, so we cannot deduct <TT>T</TT> and
<TT>N</TT>, or if it's only a non-deduced context for this slice
of the initializer list deduction and we can still deduce the
template parameters from the <TT>&amp;f1</TT> element.</P>

<P>See also <A HREF="cwg_active.html#1513">issue 1513</A>.</P>

<P><B>Rationale, July, 2017</B></P>

<P>This issue is a duplicate of <A HREF="cwg_defects.html#2318">issue 2318</A>.</P>

<BR><BR><HR>
<A NAME="1337"></A><H4>1337.
  
Partial ordering and non-deduced parameters
</H4>
<B>Section: </B>13.10.3.5&#160; [<A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-07-05<BR>




<P><B>Rationale (August, 2011):</B></P>

<P>This issue duplicates <A HREF="cwg_closed.html#455">issue 455</A>.</P>

<BR><BR><HR>
<A NAME="133"></A><H4>133.
  
Exception specifications and checking
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>25 June 1999<BR>





<P>14.5 [<A href="https://wg21.link/except.spec#1">except.spec</A>] paragraph 1
says,</P>

<BLOCKQUOTE>
An <I>exception-specification</I> shall appear only on a function
declarator in a function, pointer, reference or pointer to member
declaration or definition.
</BLOCKQUOTE>

This wording forbids
exception specifications in declarations where they might plausibly
occur (e.g., an array of function pointers).  This restriction seems
arbitrary.  It's also unclear whether this wording allows declarations
such as

<PRE>
    void (*f())() throw(int);  // returns a pointer to a function
                               // that might throw "int"
</PRE>

<P>At the same time, other cases are allowed by the wording in
paragraph 1 (e.g., a pointer to a pointer to a function), but no
checking for such cases is specified in paragraph 3.  For example,
the following appears to be allowed:</P>

<PRE>
    void (*p)() throw(int);
    void (**pp)() throw() = &amp;p;
</PRE>

<P>
<B>Rationale (10/99):</B> Duplicate of issues
<A HREF="cwg_defects.html#87">87</A> and
<A HREF="cwg_defects.html#92">92</A>.</P>
<BR><BR><HR>
<A NAME="595"></A><H4>595.
  
Exception specifications in templates instantiated from class bodies
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>7 September 2006<BR>


<P>A type used in an exception specification must be complete
(14.5 [<A href="https://wg21.link/except.spec#2">except.spec</A>] paragraph 2).  The resolution of
<A HREF="cwg_defects.html#437">issue 437</A> stated that a class type
appearing in an exception specification inside its own
<I>member-specification</I> is considered to be complete.  Should
this also apply to exception specifications in class templates
instantiated because of a reference inside
the <I>member-specification</I> of a class?  For example,</P>

<PRE>
    template&lt;class T&gt; struct X {
        void f() throw(T) {}
    };

    struct S {
        X&lt;S&gt; xs;
    };
</PRE>

<P><B>Note, January, 2012:</B></P>

<P>With the deprecation of <I>dynamic-exception-specification</I>s,
the importance of this issue is reduced even further.  The current
specification is clear, and the suggested resolution is an extension.
It has been suggested that the issue be closed as NAD.</P>

<P><B>Notes from the February, 2012 meeting:</B></P>

<P>The outcome of this issue will be affected by the resolution of
<A HREF="cwg_defects.html#1330">issue 1330</A>.  See also
<A HREF="cwg_active.html#287">issue 287</A>.</P>

<P><B>This issue is subsumed by the newer <A HREF="cwg_defects.html#1330">issue 1330</A>
and should be discussed in that context.</B></P>

<BR><BR><HR>
<A NAME="2420"></A><H4>2420.
  
Exception specifications in explicit instantiation
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2019-06-19<BR>


<P>The expected behavior of the following example is not clear:</P>

<PRE>
  template&lt;class T&gt; struct Y {
    typedef typename T::value_type blah;
    void swap(Y&lt;T&gt; &amp;);
  };
  template&lt;class T&gt;
  void swap(Y&lt;T&gt;&amp; Left, Y&lt;T&gt;&amp; Right) noexcept(noexcept(Left.swap(Right))) {
  }

  template &lt;class T&gt; struct Z {
     void swap(Z&lt;T&gt; &amp;);
  };
  template&lt;class T&gt;
  void swap(Z&lt;T&gt;&amp; Left, Z&lt;T&gt;&amp; Right) noexcept(noexcept(Left.swap(Right))) {
  }
  Z&lt;int&gt; x00, y00;
  constexpr bool b00 = noexcept(x00.swap(y00));
  //<SPAN CLASS="cmnt"> Instantiates the </SPAN>Z&lt;int&gt;<SPAN CLASS="cmnt"> overload:</SPAN>
  template void swap&lt;int&gt;(Z&lt;int&gt;&amp;, Z&lt;int&gt;&amp;) noexcept(b00);
</PRE>

<P>The question is whether the explicit instantiation directive
also instantiates the <TT>Y&lt;int&gt;</TT> overload and thus
<TT>Y&lt;int&gt;</TT> (because of the exception specification),
which will fail because of the reference to <TT>T::value_type</TT>
with <TT>T=int</TT>.</P>

<P>According to 14.5 [<A href="https://wg21.link/except.spec#13.3">except.spec</A>] bullet 13.3, one of the
contexts in which an exception specification is needed (thus
triggering its instantiation) is when:</P>

<BLOCKQUOTE>

the exception specification is compared to that of another
declaration (e.g., an explicit specialization or an
overriding virtual function);

</BLOCKQUOTE>

<P>In this example, the declarations of <TT>swap</TT> must be
compared in order to determine which function template is being
instantiated, resulting in the instantiation of <TT>Y&lt;int&gt;</TT>.
There is implementation divergence, however, with some accepting
the example and some issuing an error for the instantiation of
<TT>Y&lt;int&gt;</TT>.</P>

<P>
<B>Rationale (February, 2022):</B> Duplicate of
<A HREF="cwg_active.html#2417">issue 2417</A>.</P>

<BR><BR><HR>
<A NAME="79"></A><H4>79.
  
Alignment and placement new
</H4>
<B>Section: </B>17.6.3.4&#160; [<A href="https://wg21.link/new.delete.placement">new.delete.placement</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>15 Dec 1998<BR>





<P>The example in 17.6.3.4 [<A href="https://wg21.link/new.delete.placement">new.delete.placement</A>]

reads:</P>
<BLOCKQUOTE>[<I>Example:</I>  This  can  be  useful for constructing
an object at a known address:
<PRE>
    char place[sizeof(Something)];
    Something* p = new (place) Something();
</PRE>
&#8212;<I>end example</I>]</BLOCKQUOTE>
This example has potential alignment problems. One way to correct it would
be to change the definition of <TT>place</TT> to read:
<PRE>
    char* place = new char[sizeof(Something)];
</PRE>

<P>
<B>Rationale (10/99):</B> This is an issue for the Library
Working Group.</P>
<BR><BR><HR>
<A NAME="1377"></A><H4>1377.
  
Access declarations not mentioned in Annex C
</H4>
<B>Section: </B>C.6&#160; [<A href="https://wg21.link/diff.cpp03">diff.cpp03</A>]
 &#160;&#160;&#160;

 <B>Status: </B>dup
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-18<BR>


<P>Access declarations were removed from C++11 but are not mentioned in
C.6 [<A href="https://wg21.link/diff.cpp03">diff.cpp03</A>].</P>

<P><B>Rationale (January, 2012):</B></P>

<P>
<A HREF="cwg_active.html#1279">Issue 1279</A> already deals with missing
differences between C++03 and C++11; this specific item has been added
to the list there.</P>

<BR><BR><BR><BR><HR>
<A NAME="Concepts%20Status"></A><H3>Issues with "concepts" Status</H3>
<HR>
<A NAME="889"></A><H4>889.
  
Default implementations of associated functions
</H4>
<B>Section: </B>_N2914_.14.10.1.1&#160; [<A href="https://wg21.link/concept.fct">concept.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>4 May, 2009<BR>




<P>In the example in _N2914_.14.10.1.1 [<A href="https://wg21.link/concept.fct#10">concept.fct</A>] paragraph 10,</P>

<PRE>
    concept EqualityComparable&lt;typename T&gt; {
      bool operator==(T, T);
      bool operator!=(T x, T y) { return !(x == y); }
    }
</PRE>

<P>is the call to <TT>operator==</TT> in the default implementation
well-formed, or is another requirement needed to allow the arguments
to be passed by value?  If another requirement is needed, should it
be added in this example, or should the rules for implicit requirements
be changed so that the example is well-formed?</P>

<BR><BR><HR>
<A NAME="780"></A><H4>780.
  
Questions regarding the point of definition of a concept map
</H4>
<B>Section: </B>_N2914_.14.10.2&#160; [<A href="https://wg21.link/concept.map">concept.map</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>10 February, 2009<BR>




<OL>
<LI>
<P>According to _N2914_.14.11.1.1 [<A href="https://wg21.link/temp.req.sat#2">temp.req.sat</A>] paragraph 2,
a concept requirement is satisfied if a concept map with the same
name and template argument list is found by concept map lookup. The
point at which the name of a concept map is inserted into its scope
is, according to _N2914_.14.10.2 [<A href="https://wg21.link/concept.map#2">concept.map</A>] paragraph 2, immediately
following its <I>concept-id</I>.  This enables a requirement on a
member of a concept map to be satisfied by the concept map in which it
appears, for example:</P>

<PRE>
    concept C2&lt;typename T&gt;{}

    concept D2&lt;typename T&gt; {
            typename type;
            requires C2&lt;type&gt;;
    }

    template&lt;D2 T&gt;
    concept_map C2&lt;T&gt;{}

    concept_map D2&lt;int&gt; {
            typedef int type; // Okay
    }
</PRE>

<P>However, these rules might lead to problems with the concept maps
that the compiler tries but fails to generate for auto concepts.
Presumably a compiler might insert the name of the generated concept
map into the containing scope, so that it can satisfy its own
requirements, but then if some other requirement cannot be satisfied
and thus the concept map is not defined after all (_N2914_.14.10.2 [<A href="https://wg21.link/concept.map#11">concept.map</A>] paragraph 11), the name must then be removed again.  It
might be clearer to make the point of definition for a concept map
after the closing brace and just have a special case for how the
concept map is handled within its own definition.
</P>

</LI>

<LI>
<P>On a related note, the current specification seems unclear
about whether a failure to generate a concept map for an auto
concept means that no further attempts will be made to generate it.
Consider the following example:
</P>

<PRE>
    auto concept A&lt;typename X&gt; { /* */ }
    auto concept B&lt;typename X&gt; : A&lt;X&gt; { void enabler(X); }

    template &lt;A T&gt; void f(T x); // #1
    template &lt;B T&gt; void f(T x); // #2

    class C
    {
       // a class that satisfies A&lt;C&gt; but not B&lt;C&gt;
       // because no enabler(X) in scope
    };

    int foo()
    {
       C x;
       f(x); // #3
    }

    void enabler(C);

    int bar()
    {
       C x;
       f(x); // #4
    }
</PRE>

<P>At #3, the concept map for <TT>B</TT> cannot be generated, so the
call invokes #1. There doesn't appear to be anything currently that
indicates that the reference at #4 should not once again attempt to
generate the concept map for <TT>B</TT>, which will succeed this time
and make the call invoke #2.  It seems preferable that both calls
should invoke #1, but that does not seem to be the effect of the
current wording.</P>

</LI>

</OL>

<BR><BR><HR>
<A NAME="911"></A><H4>911.
  
<TT>late_check</TT> and concept map templates
</H4>
<B>Section: </B>_N2914_.14.10.2&#160; [<A href="https://wg21.link/concept.map">concept.map</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>6 June, 2009<BR>




<P>Given a concept and an unconstrained template, e.g.,</P>

<PRE>
    auto concept HasFoo&lt;typename T&gt; {
      void foo(T&amp;);
    }

    template&lt;typename T&gt;
    struct SomeThing {
      void bar(){}
    };
</PRE>

<P>how can one write a concept map template that adapts all
specializations of <TT>SomeThing</TT> to concept <TT>HasFoo</TT>?
Because a concept map template is a constrained context, referring
to <TT>SomeThing</TT> violates the prohibition against using a
specialization of an unconstrained template.</P>

<P>Surrounding the entire concept map template with <TT>late_check</TT>
would appear not to work; the location of the <TT>late_check</TT> is
in the unconstrained context, and <TT>late_check</TT> is ignored in
unconstrained contexts.</P>

<P>One possibility would be to allow <TT>late_check</TT> to appear
in the <TT>concept_map</TT> syntax.</P>

<BR><BR><HR>
<A NAME="870"></A><H4>870.
  
Context of expression when satisfying an associated function requirement
</H4>
<B>Section: </B>_N2914_.14.10.2.1&#160; [<A href="https://wg21.link/concept.map.fct">concept.map.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>14 April, 2009<BR>




<P>_N2914_.14.10.2.1 [<A href="https://wg21.link/concept.map.fct#3">concept.map.fct</A>] paragraph 3 says,</P>

<BLOCKQUOTE>

Construct an expression <TT>E</TT> (as defined below) in the scope of
the concept map.

</BLOCKQUOTE>

<P>This is the wrong context for this expression.  Requirement
members are visible to name lookup, and they are obviously not a
desirable lookup result; names within the concept map should be
invisible during the evaluation of <TT>E</TT>.  Presumably this
should read,</P>

<BLOCKQUOTE>

...in the scope in which the concept map is defined.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="871"></A><H4>871.
  
Satisfying associated functions with built-in operators
</H4>
<B>Section: </B>_N2914_.14.10.2.1&#160; [<A href="https://wg21.link/concept.map.fct">concept.map.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>15 April, 2009<BR>




<P>_N2914_.14.10.2.1 [<A href="https://wg21.link/concept.map.fct#5">concept.map.fct</A>] paragraph 5 says,</P>

<BLOCKQUOTE>

<P>Each satisfied associated function (or function template) requirement
has a corresponding associated function candidate set. An
<I>associated function candidate set</I> is a candidate set
(_N2914_.14.11.3 [<A href="https://wg21.link/temp.constrained.set">temp.constrained.set</A>]) representing the functions or
operations used to satisfy the requirement. The seed of the associated
function candidate set is determined based on the expression
<TT>E</TT> used to determine that the requirement was satisfied.</P>

<UL>
<LI><P>If the evaluation of <TT>E</TT> involves overload
resolution at the top level, the seed is the function (12.2.2 [<A href="https://wg21.link/over.match.funcs">over.match.funcs</A>]) selected by the outermost application of overload
resolution (Clause 12 [<A href="https://wg21.link/over">over</A>]).</P></LI>

<LI><P>Otherwise, if <TT>E</TT> is a pseudo destructor call
(_N4778_.7.6.1.4 [<A href="https://wg21.link/expr.pseudo">expr.pseudo</A>]), the seed is a
<I>pseudo-destructor-name</I>.</P></LI>

<LI><P>Otherwise, the seed is the initialization of an object.</P></LI>

</UL>

</BLOCKQUOTE>

<P>It is not clear that this takes built-in operators into account.
For example:</P>

<PRE>
    concept C&lt;class T, class U&gt; {
       typename R;
       R operator+( T, U );
    }

    concept_map C&lt;int, double&gt; {}
</PRE>

<BR><BR><HR>
<A NAME="916"></A><H4>916.
  
Does a reference type have a destructor?
</H4>
<B>Section: </B>_N2914_.14.10.2.1&#160; [<A href="https://wg21.link/concept.map.fct">concept.map.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>12 June, 2009<BR>




<P>Is the following well-formed?</P>

<PRE>
    auto concept HasDestructor&lt;typename T&gt; {
      T::~T();
    }

    concept_map HasDestructor&lt;int&amp;&gt; { }
</PRE>

<P>According to _N2914_.14.10.2.1 [<A href="https://wg21.link/concept.map.fct#4">concept.map.fct</A>] paragraph 4, the
destructor requirement in the concept map results in an expression
<TT>x.~X()</TT>, where <TT>X</TT> is the type <TT>int&amp;</TT>.
According to _N4778_.7.6.1.4 [<A href="https://wg21.link/expr.pseudo">expr.pseudo</A>], this expression is ill-formed
because the object type and the <I>type-name</I> must be the same type,
but the object type cannot be a reference type (references are dropped
from types used in expressions, Clause 7 [<A href="https://wg21.link/expr#5">expr</A>] paragraph 5).</P>

<P>It is not clear whether this should be addressed by changing
_N4778_.7.6.1.4 [<A href="https://wg21.link/expr.pseudo">expr.pseudo</A>] or _N2914_.14.10.2.1 [<A href="https://wg21.link/concept.map.fct">concept.map.fct</A>].</P>

<BR><BR><HR>
<A NAME="918"></A><H4>918.
  
Declaration/expression ambiguity in associated function expressions
</H4>
<B>Section: </B>_N2914_.14.10.2.1&#160; [<A href="https://wg21.link/concept.map.fct">concept.map.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>19 June, 2009<BR>




<P>It is possible that under some circumstances an expression created
under the rules of _N2914_.14.10.2.1 [<A href="https://wg21.link/concept.map.fct">concept.map.fct</A>] might be syntactically
ambiguous with declarations, in which case they would be interpreted as
declarations and not expressions.  It would be helpful to have an
explicit statement to the effect that the expressions created by these
rules shall always be interpreted as expressions and never as
declarations.</P>

<BR><BR><HR>
<A NAME="907"></A><H4>907.
  
Default types in requirements in auto concepts
</H4>
<B>Section: </B>_N2914_.14.10.2.2&#160; [<A href="https://wg21.link/concept.map.assoc">concept.map.assoc</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>28 May, 2009<BR>




<P>Given the following example:</P>

<PRE>
    auto concept C&lt;typename T, typename U&gt; {
      Returnable U;
      typename type = T&amp;&amp;;
      U::U(type);
    }
</PRE>

<P>_N2914_.14.10.2.2 [<A href="https://wg21.link/concept.map.assoc#5">concept.map.assoc</A>] paragraph 5 says,</P>

<BLOCKQUOTE>

If an associated type or class template (_N2914_.14.10.1.2 [<A href="https://wg21.link/concept.assoc">concept.assoc</A>]) has a default value, a concept map member
satisfying the associated type or class template requirement shall be
implicitly defined by substituting the concept map
arguments into the default value.

</BLOCKQUOTE>

<P>It is not clear what the order of processing should be between this
step and the formation of the expression in _N2914_.14.10.2.1 [<A href="https://wg21.link/concept.map.fct">concept.map.fct</A>].  Deduction of the associated type (in _N2914_.14.10.2.2 [<A href="https://wg21.link/concept.map.assoc#4">concept.map.assoc</A>] paragraph 4) isn't used in this example, but in
general requires the expression, but the expression can't be created
without the definition of the associated type.  Perhaps the approach
should be to attempt to define the expression, fail for want of the
associated type, apply the default, and then try to define the
expression again.  Whatever the answer, this needs to be spelled out
more clearly.</P>

<BR><BR><HR>
<A NAME="841"></A><H4>841.
  
Ill-formed concept refinement example
</H4>
<B>Section: </B>_N2914_.14.10.3.2&#160; [<A href="https://wg21.link/concept.refine.maps">concept.refine.maps</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>20 March, 2009<BR>




<P>The example in _N2914_.14.10.3.2 [<A href="https://wg21.link/concept.refine.maps#3">concept.refine.maps</A>] paragraph 3 reads:</P>

<PRE>
    concept C&lt;typename T&gt; { }
    concept D&lt;typename T, typename U&gt; : C&lt;T&gt; { }
    template&lt;typename T&gt; struct A { };
    template&lt;typename T&gt; concept_map D&lt;A&lt;T&gt;, T&gt; { }
    ...
</PRE>

<P>Since all concept maps templates are constrained templates, we know
that we're in a constrained context at the point of the
<TT>concept_map</TT> keyword.  Then the first argument to <TT>D</TT>
is <TT>A&lt;T&gt;</TT>, and <TT>A</TT> is an unconstrained template,
so this is ill-formed by _N2914_.14.11 [<A href="https://wg21.link/temp.constrained#5">temp.constrained</A>] paragraph 5:</P>

<BLOCKQUOTE>

Within a constrained context, a program shall not require a template
specialization of an unconstrained template for which the template
arguments of the specialization depend on a template parameter.

</BLOCKQUOTE>

<P>Suggestion: make <TT>A</TT> a constrained template, e.g.,</P>

<PRE>
    template&lt;std::ObjectType T&gt; struct A { };
</PRE>

<P><B>Additional notes (May, 2009):</B></P>



<P>There are other examples that exhibit the same problem.  For
example, _N2960_.14.6.8 [<A href="https://wg21.link/temp.concept.map#7">temp.concept.map</A>] paragraph 7 has this example:</P>

<PRE>
    concept Stack&lt;typename X&gt; {
      typename value_type;
      value_type&amp; top(X&amp;);
      // ...
    }

    template&lt;typename T&gt; struct dynarray {
      T&amp; top();
    };

    template&lt;&gt; struct dynarray&lt;bool&gt; {
      bool top();
    };

    template&lt;typename T&gt;
    concept_map Stack&lt;dynarray&lt;T&gt;&gt; {
      typedef T value_type;
      T&amp; top(dynarray&lt;T&gt;&amp; x) { return x.top(); }
    }
</PRE>

<P>
<TT>dynarray</TT> needs to be constrained.  Similarly, in
_N2914_.14.10.2.2 [<A href="https://wg21.link/concept.map.assoc#3">concept.map.assoc</A>] paragraph 3, in the example</P>

<PRE>
    concept Allocator&lt;typename Alloc&gt; {
      template&lt;class T&gt; class rebind_type;
    }

    template&lt;typename T&gt;
    class my_allocator {
      template&lt;typename U&gt; class rebind_type;
    };

    template&lt;typename T&gt;
    concept_map Allocator&lt;my_allocator&lt;T&gt;&gt; {
      template&lt;class U&gt; using rebind_type = my_allocator&lt;T&gt;::rebind_type;
    }
</PRE>

<P>
<TT>my_allocator</TT> must be constrained.  (Note also the missing
template argument in the target of the template alias declaration.)</P>

<BR><BR><HR>
<A NAME="825"></A><H4>825.
  
<TT>TriviallyCopyableType</TT> concept
</H4>
<B>Section: </B>_N2914_.14.10.4&#160; [<A href="https://wg21.link/concept.support">concept.support</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>JP
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#JP20">N2800 comment
  JP&#160;20<BR></A>

<P>
Trivially copyable type was added in 6.9 [<A href="https://wg21.link/basic.types">basic.types</A>], so we
think that it is necessary to add a concept for trivially copyable type like
<TT>TriviallyCopyableType</TT>.
</P>

<P><B>Notes from the March, 2009 meeting:</B></P>

<P>It is not clear whether this should be supported here or in
_N2914_.20.2.9 [<A href="https://wg21.link/concept.copymove">concept.copymove</A>], similar to
<TT>TriviallyCopyConstructible</TT> and
<TT>TriviallyCopyAssignable</TT>.</P>

<BR><BR><HR>
<A NAME="848"></A><H4>848.
  
Unconstrained template template parameters in constrained contexts
</H4>
<B>Section: </B>_N2914_.14.11&#160; [<A href="https://wg21.link/temp.constrained">temp.constrained</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>31 March, 2009<BR>




<P>_N2914_.14.11 [<A href="https://wg21.link/temp.constrained#5">temp.constrained</A>] paragraph 5 says,</P>

<BLOCKQUOTE>

Within a constrained context, a program shall not require a template
specialization of an unconstrained template for which the template
arguments of the specialization depend on a template parameter.

</BLOCKQUOTE>

<P>This would appear to indicate that an example like the following
is ill-formed:</P>

<PRE>
    auto concept C&lt;class T&gt; {};

    template&lt;template&lt;class&gt; class T, C U&gt;
    struct Y {
         Y() {
             T&lt;U&gt; x; // Well-formed?
         }
    };
</PRE>

<P>because <TT>T'</TT> is not a constrained template archetype.  However,
this is not the intended outcome.  The wording needs to be clarified on
this point (and an example and a note explaining the rationale would be
helpful).</P>

<P>(See also issues <A HREF="cwg_closed.html#849">849</A> and
<A HREF="cwg_closed.html#851">851</A>.)</P>

<BR><BR><HR>
<A NAME="826"></A><H4>826.
  
Accept boolean constant expressions as constraints
</H4>
<B>Section: </B>_N2914_.14.11.1&#160; [<A href="https://wg21.link/temp.req">temp.req</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>JP
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK129">N2800 comment
  UK&#160;129<BR></A>

<P>
It should be
possible to support boolean constant expressions as
requirements without resorting to defining the <TT>True</TT> concept
in the library. Boolean expressions are very likely to be
constraints when dealing with non-type template parameters
and variadic templates, and constraints in these cases
should feel just as natural as constraints on the type
system.
</P>

<BR><BR><HR>
<A NAME="827"></A><H4>827.
  
Use of <TT>&amp;&amp;</TT> as requirement separator
</H4>
<B>Section: </B>_N2914_.14.11.1&#160; [<A href="https://wg21.link/temp.req">temp.req</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#US60">N2800 comment
  US&#160;60<BR></A>

<P>
The use of <TT>&amp;&amp;</TT> as the separator for
a list of requirements has shown itself to be a serious
teachability problem. The mental model behind
<TT>&amp;&amp;</TT> treats concepts as simple
predicates, which ignores the role of concepts in
type-checking templates. The more programmers read into the
<TT>&amp;&amp;</TT> (and especially try to fake <TT>||</TT>
with <TT>&amp;&amp;</TT> and <TT>!</TT>), the harder it is for them to
understand the role of concept maps. Simply changing the
separator to <TT>,</TT> would eliminate a significant
source of confusion.
</P>

<BR><BR><HR>
<A NAME="890"></A><H4>890.
  
Missing requirement in example
</H4>
<B>Section: </B>_N2914_.14.11.1.1&#160; [<A href="https://wg21.link/temp.req.sat">temp.req.sat</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>6 May, 2009<BR>




<P>The example in _N2914_.14.11.1.1 [<A href="https://wg21.link/temp.req.sat#6">temp.req.sat</A>] paragraph 6 reads,</P>

<PRE>
    concept C&lt;typename T&gt; { }
    concept D&lt;typename T&gt; { }
    namespace N2 {
      template&lt;C T&gt; void f(T);                // #1
      template&lt;C T&gt; requires D&lt;T&gt; void f(T);  // #2
      template&lt;C T&gt; void g(T x) {
        f(x);
      }
    ...
</PRE>

<P>The call <TT>f(x)</TT> is ill-formed without a constraint
indicating that <TT>x</TT> can be passed by value.</P>

<BR><BR><HR>
<A NAME="857"></A><H4>857.
  
Implying requirements from enclosing scopes
</H4>
<B>Section: </B>_N2914_.14.11.1.2&#160; [<A href="https://wg21.link/temp.req.impl">temp.req.impl</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>5 April, 2009<BR>




<P>Consider the following example:</P>

<PRE>
    auto concept A&lt;class T&gt; {
         int f(T);
    }

    auto concept B&lt;class T&gt; {

         int f(T)

         template&lt;class U&gt;
             requires A&lt;U&gt; // brings f(U') into scope
         auto g(T p, U q) -&gt;
             decltype(f(p) + f(q));
             // Both B&lt;T&gt;::f(T) and A&lt;U&gt;::f(U) needed here
             // but B&lt;T&gt;::f(T) is hidden by A&lt;U&gt;::f(U)
             // (declared in the same scope as g's template parameters)
    }
</PRE>

<P>This is similar to the case that motivated 11.4 [<A href="https://wg21.link/class.mem#19">class.mem</A>] paragraph 19:
</P>

<BLOCKQUOTE>

A constrained member is treated as a constrained template
(_N2914_.14.11 [<A href="https://wg21.link/temp.constrained">temp.constrained</A>]) whose template requirements include the
requirements specified in its <I>member-requirement</I> clause and the
requirements of each enclosing constrained template.

</BLOCKQUOTE>

<P>See also _N2914_.14.10.1.1 [<A href="https://wg21.link/concept.fct#10">concept.fct</A>] paragraph 10 for a similar rule
for default implementations.</P>

<P>A more general version of this merging of requirements is needed,
but it does not appear to exist.  _N2914_.14.11.1.2 [<A href="https://wg21.link/temp.req.impl">temp.req.impl</A>]
would seem to be the logical place for such a rule.</P>

<BR><BR><HR>
<A NAME="781"></A><H4>781.
  
Missing requirement in constrained function example
</H4>
<B>Section: </B>_N2914_.14.11.2&#160; [<A href="https://wg21.link/temp.archetype">temp.archetype</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>1 March, 2009<BR>




<P>The example at the end of _N2914_.14.11.2 [<A href="https://wg21.link/temp.archetype#13">temp.archetype</A>] paragraph 13
reads,</P>

<PRE>
    auto concept CopyConstructible&lt;typename T&gt; {
      T::T(const T&amp;);
    }

    template&lt;CopyConstructible T&gt; struct vector;

    auto concept VectorLike&lt;typename X&gt; {
      typename value_type = typename X::value_type;
      X::X();
      void X::push_back(const value_type&amp;);
      value_type&amp; X::front();
    }

    template&lt;CopyConstructible T&gt;
    requires VectorLike&lt;vector&lt;T&gt;&gt;  //<SPAN CLASS="cmnt"> </SPAN>vector&lt;T&gt;<SPAN CLASS="cmnt"> is an archetype (but not an instantiated archetype)</SPAN>
    void f(const T&amp; value) {
      vector&lt;T&gt; x;                  //<SPAN CLASS="cmnt"> OK: default constructor in </SPAN>VectorLike&lt;vector&lt;T&gt; &gt;
      x.push_back(value);           //<SPAN CLASS="cmnt"> OK: </SPAN>push_back<SPAN CLASS="cmnt"> in </SPAN>VectorLike&lt;vector&lt;T&gt; &gt;
      VectorLike&lt;vector&lt;T&gt;&gt;::value_type&amp; val = x.front();  //<SPAN CLASS="cmnt"> OK: </SPAN>front<SPAN CLASS="cmnt"> in </SPAN>VectorLike&lt;vector&lt;T&gt; &gt;
    }
</PRE>

<P>However, <TT>x.push_back(value)</TT> is, in fact, ill-formed: there
is no relationship between
<TT>VectorLike&lt;vector&lt;T&gt;&gt;::value_type</TT> and T in this
example.  The function needs one further requirement, e.g.,
<TT>std::SameType&lt;VectorLike&lt;vector&lt;T&gt;&gt;::value_type, T&gt;</TT>
to allow use of the function parameter <TT>value</TT> as the argument
of the <TT>push_back</TT> call.</P>

<BR><BR><HR>
<A NAME="748"></A><H4>748.
  
Always-complete archetypes
</H4>
<B>Section: </B>_N2914_.14.11.2.1&#160; [<A href="https://wg21.link/temp.archetype.assemble">temp.archetype.assemble</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>28 November, 2008<BR>




<P>Suppose we have</P>

<PRE>
    template&lt;std::ObjectType T&gt;
    T* f(T* p) {
         return ++p; // Presumably ok
    }
</PRE>

<P>7.6.2.3 [<A href="https://wg21.link/expr.pre.incr#1">expr.pre.incr</A>] paragraph 1 requires that &#8220;The
type of the operand shall be an arithmetic type or a pointer to a
completely-defined effective object type.&#8221;  At <TT>++p</TT> in
this example, the type archetype <TT>T'</TT> is considered to be
completely-defined because</P>

<BLOCKQUOTE>

A type archetype is considered to be completely defined when it is
established

</BLOCKQUOTE>

<P>(_N2914_.14.11.2.1 [<A href="https://wg21.link/temp.archetype.assemble#1">temp.archetype.assemble</A>] paragraph 1) and
13.9.3 [<A href="https://wg21.link/temp.explicit#7">temp.explicit</A>] paragraph 7 says that an archetype becomes
established when</P>

<BLOCKQUOTE>

the archetype is used in a context where a complete type is required

</BLOCKQUOTE>

<P>So far, so good.  Consider use of <TT>f(T*)</TT> with an incomplete
type, for instance:</P>

<PRE>
    struct A; // A is not defined yet.

    A* g(A* p) {
         return f(p);
    }
</PRE>

<P>During template argument deduction against the template
<TT>f(T*)</TT>, we find that there is a concept map for
<TT>std::ObjectType&lt;A&gt;</TT> because <TT>std::ObjectType</TT> is
a compiler-supported concept, and because <TT>A</TT> is an object type
(6.9 [<A href="https://wg21.link/basic.types">basic.types</A>]), so the compiler provides the concept map
implicitly. Type deduction succeeds, but then we get an instantiation-time
error on <TT>++p</TT> because <TT>A</TT> is incomplete.</P>

<P>I see two potential solutions:</P>

<OL>
<LI><P>We can remove built-in operations for
ptr-to-effective-object-type, so that you would have to explicitly
require something like <TT>std::HasPreincrement&lt;T*&gt;</TT> before
using <TT>++</TT> on values of type <TT>T*</TT> in <TT>f(T*)</TT>.
Then <TT>A</TT>'s lack of completeness would be indicated when we try
to satisfy those requirements automatically (and not at instantiation
time).</P></LI>

<LI><P>Alternatively, we can introduce the notion of a
compiler-supported concept <TT>std::CompleteType&lt;T&gt;</TT>, and
amend _N2914_.14.11.2.1 [<A href="https://wg21.link/temp.archetype.assemble">temp.archetype.assemble</A>] so that a type archetype is only
considered to be completely-defined if it has that requirement.  This
would imply that <TT>f(T*)</TT> above is ill-formed at <TT>++p</TT>
because <TT>T</TT> would then be an incomplete effective object type;
the user could fix this by inserting <TT>requires
std::CompleteType&lt;T&gt;</TT> after the
<I>template-parameter-list</I>, and then the call <TT>f(p)</TT> would
be ill-formed because <TT>std::CompleteType&lt;A&gt;</TT> would not be
satisfied.</P></LI>

</OL>

<BR><BR><HR>
<A NAME="895"></A><H4>895.
  
Missing destructor requirements
</H4>
<B>Section: </B>_N2914_.14.11.2.1&#160; [<A href="https://wg21.link/temp.archetype.assemble">temp.archetype.assemble</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>8 May, 2009<BR>


<P>If there is no requirement for a destructor for a type, according to
_N2914_.14.11.2.1 [<A href="https://wg21.link/temp.archetype.assemble#5">temp.archetype.assemble</A>] paragraph 5 its archetype will have a
deleted destructor.  As a result, several examples in the current
wording are ill-formed:</P>

<UL>
<LI><P>_N2914_.14.10.2 [<A href="https://wg21.link/concept.map#11">concept.map</A>] paragraph 11: the
<TT>add</TT> function.</P></LI>

<LI><P>_N2914_.14.10.3.1 [<A href="https://wg21.link/concept.member.lookup#3">concept.member.lookup</A>] paragraph 3: the <TT>f</TT>
function.  (Also missing the copy constructor requirement.)</P></LI>

<LI><P>_N2914_.14.10.3.1 [<A href="https://wg21.link/concept.member.lookup#5">concept.member.lookup</A>] paragraph 5: the <TT>h</TT>
function.  (Also missing the copy constructor requirement.)</P></LI>

<LI><P>_N2914_.14.11.1 [<A href="https://wg21.link/temp.req#3">temp.req</A>] paragraph 3: the <TT>f</TT>
function.</P></LI>

<LI><P>_N2914_.14.11.1.1 [<A href="https://wg21.link/temp.req.sat#6">temp.req.sat</A>] paragraph 6: the <TT>g</TT>
function.  (Also missing the copy constructor requirement.)</P></LI>

<LI><P>_N2914_.14.11.2 [<A href="https://wg21.link/temp.archetype#15">temp.archetype</A>] paragraph 15: the <TT>distance</TT>
function.</P></LI>

<LI><P>_N2914_.14.11.2.1 [<A href="https://wg21.link/temp.archetype.assemble#2">temp.archetype.assemble</A>] paragraph 2: the <TT>foo</TT>
function.</P></LI>

<LI><P>_N2914_.14.11.2.1 [<A href="https://wg21.link/temp.archetype.assemble#3">temp.archetype.assemble</A>] paragraph 3: the <TT>f</TT>
function.</P></LI>

<LI><P>_N2914_.14.11.4 [<A href="https://wg21.link/temp.constrained.inst#4">temp.constrained.inst</A>] paragraph 4: needed for
<TT>difference_type</TT>.</P></LI>

</UL>

<P>One possibility would be to add the destructor requirement
directly in these examples.  Another might be to use
<TT>std::CopyConstructible</TT> instead of a local concept.
Yet another would be to consider an implicit requirement for a
destructor for <TT>std::Returnable</TT> and
<TT>std::VariableType</TT>.</P>

<BR><BR><HR>
<A NAME="894"></A><H4>894.
  
Incorrect example for constrained overload resolution
</H4>
<B>Section: </B>_N2914_.14.11.4&#160; [<A href="https://wg21.link/temp.constrained.inst">temp.constrained.inst</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>8 May, 2009<BR>




<P>The example in _N2914_.14.11.4 [<A href="https://wg21.link/temp.constrained.inst#4">temp.constrained.inst</A>] paragraph 4 is
ill-formed.  The call to <TT>advance(i, 1)</TT> in <TT>f</TT>
attempts to pass <TT>1</TT> to a parameter declared as
<TT>Iter::difference_type</TT>, but there is nothing that says
that <TT>int</TT> is compatible with <TT>Iter::difference_type.</TT>
</P>

<BR><BR><HR>
<A NAME="856"></A><H4>856.
  
Overlapping concept and requirements scopes
</H4>
<B>Section: </B>_N2960_.3.3.9&#160; [<A href="https://wg21.link/basic.scope.req">basic.scope.req</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>5 April, 2009<BR>




<P>According to _N2960_.3.3.9 [<A href="https://wg21.link/basic.scope.req#2">basic.scope.req</A>] paragraph 2,</P>

<BLOCKQUOTE>

In a constrained context (_N2914_.14.11 [<A href="https://wg21.link/temp.constrained">temp.constrained</A>]), the names of
all associated functions inside the concepts named by the concept
requirements in the template's requirements are declared in the
same scope as the constrained template's template parameters.

</BLOCKQUOTE>

<P>This does not appear to cover the case when the requirement
appears in a concept definition:</P>

<PRE>
    auto concept B&lt;class T&gt; {
         void f( T );
    }

    auto concept C&lt;class T&gt; {
         typename U = int;
         requires B&lt;U&gt;;  // Is void f(U) placed in the scope of C?

         void g(U x) {
             f(x);   // Ok, finds the 'f(U)' implicitly declared as a
                     // result of the associated requirement B&lt;U&gt;.
         }
    }

    void f(int);

    void g() {
         C&lt;char&gt;::f(42); // Ok?
    }
</PRE>

<P>This program should be well-formed, but the current wording does
not make that clear.</P>

<P>Another question that must be addressed is if <TT>C</TT> also
contained an explicit declaration of <TT>f(U)</TT>, either before
or after <TT>B&lt;U&gt;</TT>, and whether it would need a satisfier
within a concept map to <TT>C</TT>.</P>

<P>(See also <A HREF="cwg_closed.html#866">issue 866</A>.)</P>

<BR><BR><HR>
<A NAME="859"></A><H4>859.
  
Incomplete comment in <TT>late_check</TT> example
</H4>
<B>Section: </B>_N2960_.6.9&#160; [<A href="https://wg21.link/stmt.late">stmt.late</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>6 April, 2009<BR>




<P>_N2960_.6.9 [<A href="https://wg21.link/stmt.late#2">stmt.late</A>] paragraph 2 consists of the following
example:</P>

<PRE>
    concept Semigroup&lt;typename T&gt; {
      T::T(const T&amp;);
      T operator+(T, T);
    }

    concept_map Semigroup&lt;int&gt; {
      int operator+(int x, int y) { return x * y; }
    }

    template&lt;Semigroup T&gt;
    T add(T x, T y) {
      T r = x + y; //<SPAN CLASS="cmnt"> uses </SPAN>Semigroup&lt;T&gt;::operator+
      late_check {
        r = x + y; //<SPAN CLASS="cmnt"> uses </SPAN>operator+<SPAN CLASS="cmnt"> found at instantiation time (not considering </SPAN>Semigroup&lt;T&gt;::operator+<SPAN CLASS="cmnt">)</SPAN>
      }
      return r;
    }
</PRE>

<P>The second comment is correct but incomplete, because the assignment
operator is also found at instantiation time.  The assignment would be
ill-formed outside the <TT>late_check</TT> block, because the
<TT>Semigroup</TT> concept has no copy assignment operator.  The comment
should be extended accordingly.</P>

<BR><BR><HR>
<A NAME="724"></A><H4>724.
  
Qualified name lookup in a constrained context
</H4>
<B>Section: </B>6.5.5&#160; [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>24 September, 2008<BR>




<P>According to 6.5.5 [<A href="https://wg21.link/basic.lookup.qual#7">basic.lookup.qual</A>] paragraph 7,</P>

<BLOCKQUOTE>

 In a constrained context (_N2914_.14.11 [<A href="https://wg21.link/temp.constrained">temp.constrained</A>]), a name
 prefixed by a <I>nested-name-specifier</I> that nominates a template
 type parameter <TT>T</TT> is looked up as follows: for each template
 requirement <TT>C&lt;</TT><I>args</I><TT>&gt;</TT> whose template
 argument list references <TT>T</TT>, the name is looked up as if the
<I>nested-name-specifier</I> referenced
<TT>C&lt;</TT><I>args</I><TT>&gt;</TT> instead of <TT>T</TT>
(_N2960_.3.4.3.3 [<A href="https://wg21.link/concept.qual">concept.qual</A>]), except that only the names of
associated types are visible during this lookup. If an associated type
of at least one requirement is found, then each name found shall refer
to the same type.  Otherwise, if the reference to the name occurs
within a constrained context, the name is looked up within the scope
of the archetype associated with <TT>T</TT> (and no special
restriction on name visibility is in effect for this lookup).

</BLOCKQUOTE>

<P>In an example like,</P>

<PRE>
    concept A&lt;typename T&gt; {
      typename assoc_type;
    }

    concept B&lt;typename T&gt; {
      typename assoc_type;
    }

    template&lt;typename T&gt;
    requires A&lt;T&gt;
    B&lt;T::assoc_type&gt;::assoc_type f();
</PRE>

<P>it is not clear whether the argument <TT>T::assoc_type</TT> of
<TT>B</TT> &#8220;references&#8221; <TT>T</TT> or not.</P>

<P>
<U>James Widman</U>: In our mental model (and in our intentions
while drafting), we still have a (non-archetype) dependent type for
the <TT>T</TT> in your example, and, even after the <TT>SameType</TT>
requirement is seen, we also have a distinct dependent type to
represent <TT>A&lt;T&gt;::assoc_type</TT> (which itself is distinct
from the type of the entity named <TT>assoc_type</TT> that lives in
the scope of the concept <TT>A</TT>).  And those two dependent types
(<TT>A&lt;T&gt;::assoc_type</TT> and <TT>T</TT>) will both alias the
same type archetype when that archetype is established (see the
paragraph on establishment in _N2914_.14.11.2 [<A href="https://wg21.link/temp.archetype">temp.archetype</A>]).
</P>

<P>I think 6.5.5 [<A href="https://wg21.link/basic.lookup.qual#6">basic.lookup.qual</A>] paragraph 6 will read more
easily if we change the &#8220;references a template parameter&#8221;
verbiage to a generalized &#8220;dependent type&#8221; verbiage.  (We
shied away from that in the past because we wanted to say that there's
nothing &#8220;dependent&#8221; within a constrained context.  That's
because we wanted to say that all name references are bound to
something, overload resolution is done, etc.  So certainly there are
no instances of deferred name lookup or deferred overload resolution
within a constrained context.  But we still need to be able to say
when a type, template, value or concept instance depends on a template
parameter.)  I propose we change this wording to read,
</P>

<BLOCKQUOTE>

In a constrained context (_N2914_.14.11 [<A href="https://wg21.link/temp.constrained">temp.constrained</A>]), the identifier
of an <I>unqualified-id</I> prefixed by a <I>nested-name-specifier</I>
that nominates a dependent type <TT>T</TT> is looked up as follows:
for each template requirement <TT>C&lt;</TT><I>args</I><TT>&gt;</TT>
such that either <TT>T</TT> or an equivalent type (_N2914_.14.11.1 [<A href="https://wg21.link/temp.req">temp.req</A>]) is a template argument to <TT>C</TT>, the identifier of
the <I>unqualified-id</I> is looked up as if the
<I>nested-name-specifier</I> nominated
<TT>C&lt;</TT><I>args</I><TT>&gt;</TT> instead of <TT>T</TT>
(_N2960_.3.4.3.3 [<A href="https://wg21.link/concept.qual">concept.qual</A>]), except that only the names of
associated types and class templates (_N2914_.14.10.1.2 [<A href="https://wg21.link/concept.assoc">concept.assoc</A>])
are visible during this lookup.  If an associated type or class
template of at least one requirement is found, then the
<I>unqualified-id</I> shall refer either to the same type or to an
equivalent type when its identifier is looked up in each of the
concepts of the other requirements where <TT>T</TT> is a template
argument.  [<I>Note:</I> no part of the procedure described in the
preceding part of this paragraph results in the establishment of an
archetype (_N2914_.14.11.2 [<A href="https://wg21.link/temp.archetype">temp.archetype</A>]).  However, in the event that
the <I>unqualified-id</I> is a <I>template-id</I>, one of its template
arguments could contain some construct that would force archetype
establishment.  &#8212;<I>end note</I>] Otherwise, the name is looked
up within the scope of the archetype aliased by <TT>T</TT> (and no
special restriction on name visibility is in effect for this lookup).
[<I>Note:</I> this establishes the archetype of <TT>T</TT> (if it was
not established already).  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>(It looks like we have a wording nit to fix in the archetype
establishment paragraph: it talks about a type archetype coming into
existence &#8220;when it is used [in some way].&#8221; It seems odd to
say that something is used in a particular way before it exists.  We
should instead say something like &#8220;when <I>a
necessarily-dependent type that would alias the archetype</I> is used
[in some way].&#8221;)</P>

<P>(It might also be nice to have a cleanup in the paragraph that
introduces the notion of <TT>std::SameType</TT> and &#8220;equivalent
types&#8221; (_N2914_.14.11.1 [<A href="https://wg21.link/temp.req#3">temp.req</A>] paragraph 3) so that the
congruence relation is part of the normative text rather than a note.)
</P>

<BR><BR><HR>
<A NAME="791"></A><H4>791.
  
Linkage of concept names
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>FR/UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#FR17">N2800 comment
  FR&#160;17<BR></A>
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK30">N2800 comment
  UK&#160;30<BR></A>
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK119">N2800 comment
  UK&#160;119<BR></A>

<P>6.7 [<A href="https://wg21.link/basic.link">basic.link</A>] does not specify whether concept names have
linkage or not.</P>

<BR><BR><HR>
<A NAME="917"></A><H4>917.
  
Pointer conversions between archetypes
</H4>
<B>Section: </B>7.3.12&#160; [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>12 June, 2009<BR>




<P>Given an example like:</P>

<PRE>
    auto concept Conv&lt;typename T, typename U&gt; {
      U::U(T&amp;&amp;);
      U::U(const U&amp;);
      U::~U();
    };

    template&lt;typename U, typename T&gt;
    requires Conv&lt;T*, U*&gt;
    U* f(T* p) {
      return static_cast&lt;T*&amp;&amp;&gt;(p);
    }
</PRE>

<P>There is currently no normative wording that makes a <TT>T*</TT>
convertible to a <TT>U*</TT> in the return statement.</P>

<P>One possible approach would be to take the concept map archetype
as specifying an additional case for the pointer conversions in
7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>].</P>

<BR><BR><HR>
<A NAME="802"></A><H4>802.
  
Problems with restrictions on taking the address of a member of a concept map
</H4>
<B>Section: </B>7.6.2.2&#160; [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK69">N2800 comment
  UK&#160;69<BR></A>

<P>
If we cannot
bind references/take address of functions in concept_maps,
does that mean we cannot use generic bind in constrained
templates? Launch threads with expressions found via
concept map lookup? Hit problems creating std::function
objects? Does the problem only occur if we use qualified
lookup to explicitly name a concept map? Does it only kick
in if we rely on the implicit function implementation
provided by a concept_map, so some types will work and
others won't for the same algorithm?!
</P>

<P><B>Additional note, June, 2009:</B></P>



<P>Here is an example illustrating the question:</P>

<PRE>
    auto concept Fooable&lt;T&gt; {
       void foo(T);
    }

    struct test_type {
       void foo() {
          cout &lt;&lt; "foo test_type\n";
       }
    };

    concept_map Fooable&lt;test_type&gt; {
       void foo(test_type&amp; t) {
          t.foo();
       }
    }

    void foo(int x) {
       cout "foo int\n";
    }

    template&lt;typename T&gt;
       requires Fooable&lt;T&gt;
    function&lt;void(T)&gt; callback(T t) {
       void(*fn)(T) = foo;
       return fn;
    }

    int main() {
       auto fn1 = factory(test_type{});
       auto fn2 = factory(0);
       fn1(test_type{});
       fn2(0);
       return 0;
    }
</PRE>

<BR><BR><HR>
<A NAME="866"></A><H4>866.
  
Concept maps and the range-based <TT>for</TT>
</H4>
<B>Section: </B>8.6.5&#160; [<A href="https://wg21.link/stmt.ranged">stmt.ranged</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>8 April, 2009<BR>




<P>The expansion of the range-based <TT>for</TT> statement is given
in 8.6.5 [<A href="https://wg21.link/stmt.ranged#1">stmt.ranged</A>] paragraph 1 as:</P>

<PRE>
    {
      auto &amp;&amp; __range = ( expression );
      for ( auto __begin = std::Range&lt;_RangeT&gt;::begin(__range),
                 __end = std::Range&lt;_RangeT&gt;::end(__range);
            __begin != __end;
            ++__begin ) {
        for-range-declaration = *__begin;
        statement
      }
    }
</PRE>

<P>In a non-templated context, the concept map to <TT>std::Range</TT>
has been dropped, so the operators and initialization will be
whatever they would normally be; if the concept map replaced those
with some customized version (e.g., if the iterator's <TT>++</TT>
were supposed to skip odd-numbered elements), that customized
meaning would be lost.</P>

<P>What we really want are the operators associated with the concept
map to <TT>std::Iterator</TT> that was used to satisfy the associated
requirement (<TT>std::Iterator&lt;iterator&gt;</TT>) within
<TT>std::Range&lt;_RangeT&gt;</TT> (in whatever concept map was
used to satisfy <TT>std::Range&lt;_RangeT&gt;</TT>). That is, if
the grammar permitted it, we want something like</P>

<PRE>
    std::Range&lt;_RangeT&gt;::concept_map
      ::std::Iterator&lt;std::Range&lt;_RangeT&gt;::iterator&gt;::operator++(_begin)
</PRE>

<P>Another alternative would be, if <A HREF="cwg_closed.html#856">issue 856</A>
is resolved by injecting the declaration of associated functions into
concept definitions, something like</P>

<PRE>
    std::Range&lt;_RangeT&gt;::operator++(__begin)
</PRE>

<BR><BR><HR>
<A NAME="723"></A><H4>723.
  
Archetypes in skipped declarations
</H4>
<B>Section: </B>8.10&#160; [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>3 October, 2008<BR>


<P>Paper N2762 changed 8.10 [<A href="https://wg21.link/stmt.dcl#3">stmt.dcl</A>] paragraph 3 from</P>

<BLOCKQUOTE>

...unless the variable has trivial type (6.9 [<A href="https://wg21.link/basic.types">basic.types</A>])...

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

...unless the variable has scalar type, class type with a trivial
default constructor and a trivial destructor, a cv-qualified
version of one of these types, or an array of one of the preceding
types...

</BLOCKQUOTE>

<P>However, this change overrode the colliding change from
N2773 that would have changed it to read</P>

<BLOCKQUOTE>

...unless the variable has effective trivial type...

</BLOCKQUOTE>

<P>The revised wording needs to be changed to allow for
archetypes with the appropriate requirements.</P>

<BR><BR><HR>
<A NAME="725"></A><H4>725.
  
When should the requirement for <TT>std::Returnable&lt;T&gt;</TT>, etc., apply?
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Alberto Ganesh Barbati
 &#160;&#160;&#160;

 <B>Date: </B>30 September, 2008<BR>




<P>If we write</P>

<PRE>
    concept C&lt;class T&gt; {}

    template&lt;C T&gt;
    struct B {
         B f();
         virtual void g() = 0;
    };
</PRE>

<P>... it seems reasonable to expect a diagnostic about
<TT>B&lt;T&gt;::f()</TT> not because it doesn't require
<TT>std::Returnable&lt;B&lt;T&gt;&gt;</TT> (which I think should not
draw an error), but because <TT>g()</TT> is a pure virtual function.
</P>

<P>Now how about this:</P>

<PRE>
    template&lt;C T&gt;
    struct G {
         B&lt;T&gt; f() { return B&lt;T&gt;(); }
    };
</PRE>

<P>Here, I'd like to see an error not because we lack the requirement
<TT>std::Returnable&lt;B&lt;T&gt;&gt;</TT>, but because, when we
instantiate <TT>B&lt;T'&gt;</TT> (as the current wording indicates we
must within the definition of <TT>G&lt;T&gt;::f()</TT>), it turns out
to be an abstract class.</P>

<P>Now, it could be that when we instantiate <TT>G</TT>, we get a
different partial specialization of <TT>B</TT>, and that partial
specialization could have a pure virtual member.  So you might see an
instantiation-time error.  But partial specializations present dangers
like this anyway.</P>

<P>I suggest we make the rule about <TT>Returnable&lt;T&gt;</TT> apply
only in the case where <TT>T</TT> is not an instantiated archetype.
The rationale is that with an instantiated archetype, it's possible to
see at template definition time whether the type is abstract, whereas
with a non-instantiated archetype, the only known attributes come
from requirements.</P>

<P>I suspect we need similar changes for the declarator section.
E.g., for a class template <TT>A</TT>, we shouldn't need to explicitly
require <TT>VariableType&lt;A&lt;T&gt;&gt;</TT> if we want to declare a
variable of type <TT>A&lt;T&gt;</TT>.  Instead, we just instantiate
<TT>A&lt;T'&gt;</TT> (as would be naturally required at the point of
definition of a variable of type <TT>A&lt;T'&gt;</TT>), and issue
errors when appropriate like we do with ordinary classes today.
</P>

<BR><BR><HR>
<A NAME="844"></A><H4>844.
  
Is a constrained member function a template?
</H4>
<B>Section: </B>11.4&#160; [<A href="https://wg21.link/class.mem">class.mem</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>20 March, 2009<BR>




<P>According to 11.4 [<A href="https://wg21.link/class.mem#19">class.mem</A>] paragraph 19,</P>

<BLOCKQUOTE>

A non-template <I>member-declaration</I> that has a
<I>member-requirement</I> (_N2914_.14.11.1 [<A href="https://wg21.link/temp.req">temp.req</A>]) is a
<I>constrained member</I> and shall occur only in a class template
(13.7.2 [<A href="https://wg21.link/temp.class">temp.class</A>]) or nested class thereof. The
<I>member-declaration</I> for a constrained member shall declare a
member function. A constrained member is treated as a constrained
template (_N2914_.14.11 [<A href="https://wg21.link/temp.constrained">temp.constrained</A>]) whose template requirements
include the requirements specified in its <I>member-requirement</I>
clause and the requirements of each enclosing constrained template.

</BLOCKQUOTE>

<P>Furthermore, 13.7.3 [<A href="https://wg21.link/temp.mem#9">temp.mem</A>] paragraph 9 says,</P>

<BLOCKQUOTE>

A member template of a constrained class template is itself a
constrained template (_N2914_.14.11 [<A href="https://wg21.link/temp.constrained">temp.constrained</A>])...

</BLOCKQUOTE>

<P>and illustrates this statement with the following example:</P>

<PRE>
    concept C&lt;typename T&gt; { void f(const T&amp;); }
    concept D&lt;typename T&gt; { void g(const T&amp;); }

    template&lt;C T&gt; class A {
      requires D&lt;T&gt; void h(const T&amp; x) {
        f(x); //<SPAN CLASS="cmnt"> OK: </SPAN>C&lt;T&gt;::f
        g(x); //<SPAN CLASS="cmnt"> OK: </SPAN>D&lt;T&gt;::g
      }
    };
</PRE>

<P>If these passages are taken at face value and a constrained member
function is, in fact, &#8220;treated as a... template,&#8221; there
are negative consequences.  For example, according to
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#2">class.copy.ctor</A>] paragraph 2, a member function template is
never considered to be a copy constructor, so a constrained
constructor that is in the form of a copy constructor does not
suppress the implicit declaration and definition of a default copy
constructor.  Also, according to 13.7.3 [<A href="https://wg21.link/temp.mem">temp.mem</A>] paragraph
3, a member function template cannot be virtual, so it is not possible
to specify a <I>member-requirement</I> clause for a virtual function.</P>

<P>Presumably these consequences are unintended, so the wording that
suggests otherwise should be revised to make that clear.</P>

<BR><BR><HR>
<A NAME="875"></A><H4>875.
  
Associated conversion functions converting to the same type
</H4>
<B>Section: </B>11.4.8.3&#160; [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>19 April, 2009<BR>




<P>11.4.8.3 [<A href="https://wg21.link/class.conv.fct#1">class.conv.fct</A>] paragraph 1 says,</P>

<BLOCKQUOTE>

A conversion function is never used to convert a (possibly
cv-qualified) object to the (possibly cv-qualified) same object type
(or a reference to it), to a (possibly cv-qualified) base class of
that type (or a reference to it), or to (possibly cv-qualified) void.

</BLOCKQUOTE>

<P>Does this mean that the following example is ill-formed?</P>

<PRE>
    auto concept Convertible&lt;typename T, typename U&gt; {
      operator U(const T&amp;);
    }

    template &lt;typename T, typename U&gt;
    requires Convertible&lt;T, U&gt;
    U convert(const T&amp; t) { return t; }

    int main() {
      convert&lt;int&gt;(42);
    }
</PRE>

<BR><BR><HR>
<A NAME="878"></A><H4>878.
  
Effective class types in built-in pointer-to-member operator
</H4>
<B>Section: </B>12.5&#160; [<A href="https://wg21.link/over.built">over.built</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>25 April, 2009<BR>




<P>12.5 [<A href="https://wg21.link/over.built#11">over.built</A>] paragraph 11 says,</P>

<BLOCKQUOTE>

<P>For every quintuple (<I>C1, C2, T, CV1, CV2</I>), where <I>C2</I>
is a class type, <I>C1</I> is the same type as <I>C2</I> or is a
derived class of <I>C2</I>, <I>T</I> is an effective object type or a
function type, and <I>CV1</I> and <I>CV2</I> are
<I>cv-qualifier-seq</I>s, there exist candidate operator functions of
the form</P>

<UL><TT><I>CV12 T&amp;</I> operator-&gt;*(<I>CV1 C1*, CV2 T C2</I>::*);</TT></UL>

<P>where <I>CV12</I> is the union of <I>CV1</I> and <I>CV2</I>.</P>

</BLOCKQUOTE>

<P>
<I>C1</I> and <I>C2</I> should be effective class types (cf
7.6.4 [<A href="https://wg21.link/expr.mptr.oper#3">expr.mptr.oper</A>] paragraph 3.</P>

<P>Also, should the relationship between those two classes be
expressed as <TT>std::SameType</TT> or <TT>std::DerivedFrom</TT>
requirements?</P>

<BR><BR><HR>
<A NAME="821"></A><H4>821.
  
Exported concept map templates?
</H4>
<B>Section: </B>Clause 13&#160; [<A href="https://wg21.link/temp">temp</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK116">N2800 comment
  UK&#160;116<BR></A>

<P>
Is it possible
to export a concept map template? The current wording
suggests it is possible, but it is not entirely clear what
it would mean.
</P>

<P><B>Notes from the March, 2009 meeting:</B></P>

<P>Export is only useful for non-inline function templates and static
data members of class templates, so it does not make sense to export
a concept map template.</P>

<BR><BR><HR>
<A NAME="881"></A><H4>881.
  
Inconsistent requirement for naming template parameters
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>25 April, 2009<BR>




<P>The grammar for <I>constrained-template-parameter</I> given in
13.2 [<A href="https://wg21.link/temp.param#1">temp.param</A>] paragraph 1 is:</P>

<UL>
<I>constrained-template-parameter:</I><BR>
<UL>
<TT>::</TT><I><SUB>opt</SUB> nested-name-specifier<SUB>opt</SUB> concept-name</I> <TT>...</TT><I><SUB>opt</SUB> identifier<SUB>opt</SUB></I><BR>
<TT>::</TT><I><SUB>opt</SUB> nested-name-specifier<SUB>opt</SUB> concept-name identifier<SUB>opt</SUB> constrained-default-argument<SUB>opt</SUB></I><BR>
<TT>::</TT><I><SUB>opt</SUB> nested-name-specifier<SUB>opt</SUB> concept-name</I> <TT>&lt;</TT><BR>
<UL>
<I>simple-requirement-argument-list</I> <TT>&gt; ...</TT><I><SUB>opt</SUB> identifier</I>
</UL>
<TT>::</TT><I><SUB>opt</SUB> nested-name-specifier<SUB>opt</SUB> concept-name</I> <TT>&lt;</TT><BR>
<UL>
<I>simple-requirement-argument-list</I> <TT>&gt;</TT><I> identifier constrained-default-argument<SUB>opt</SUB></I>
</UL>
</UL>
</UL>

<P>The <I>identifier</I> naming the parameter is optional in the first
two productions but not in the latter two productions.  Is there a reason
for this discrepancy?</P>

<BR><BR><HR>
<A NAME="867"></A><H4>867.
  
Naming a specialization of a constrained template
</H4>
<B>Section: </B>13.3&#160; [<A href="https://wg21.link/temp.names">temp.names</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>13 April, 2009<BR>




<P>There is currently no way to distinguish between templates that
differ only by their requirements when naming a specialization.  For
example:</P>

<PRE>
    auto concept A&lt;class T&gt; {}
    auto concept B&lt;class T&gt; {}

    template&lt;class T&gt; requires A&lt;T&gt; void f(T); // #1
    template&lt;class T&gt; requires B&lt;T&gt; void f(T); // #2

    template &lt;&gt; void f(int);  // Which one?
</PRE>

<P>(See also <A HREF="cwg_closed.html#868">issue 868</A>.)</P>

<BR><BR><HR>
<A NAME="868"></A><H4>868.
  
Specifying a concept map in the name of a specialization
</H4>
<B>Section: </B>13.3&#160; [<A href="https://wg21.link/temp.names">temp.names</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>13 April, 2009<BR>




<P>There is no way to specify a concept map in the name of a
specialization.  It would be useful to be able to do something like</P>

<PRE>
    void g(int n) {
        f&lt;int : N::concept_map A&lt;int&gt;&gt;(n);
    }
</PRE>

<P>(See also <A HREF="cwg_closed.html#867">issue 867</A>.)</P>

<BR><BR><HR>
<A NAME="849"></A><H4>849.
  
Constraints and template template parameters
</H4>
<B>Section: </B>13.4.4&#160; [<A href="https://wg21.link/temp.arg.template">temp.arg.template</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>31 March, 2009<BR>




<P>The requirements for matching of template template parameters and
template template arguments given in 13.4.4 [<A href="https://wg21.link/temp.arg.template">temp.arg.template</A>] do
not mention constraints, leaving questions about whether examples like
the following are well-formed:</P>

<PRE>
    auto concept C&lt;class T&gt; {};

    template &lt;template &lt;C T&gt; class U, C V&gt; struct A{};

    template &lt;class T&gt; struct X {};

    A&lt;X,int&gt; ax;  // Well-formed?

    template &lt;template &lt;class T&gt; class U, C V&gt; struct B{};

    template &lt;C T&gt; struct Y {};

    B&lt;Y,int&gt; by;  // Well-formed?

    template &lt;template &lt;class T&gt; class U&gt; struct D{};

    template &lt;C T&gt; struct Z {};

    D&lt;Z&gt; dz;  // Well-formed?
</PRE>

<P>(See also <A HREF="cwg_closed.html#848">issue 848</A>.)</P>

<BR><BR><HR>
<A NAME="824"></A><H4>824.
  
Constrained special member functions
</H4>
<B>Section: </B>13.7.2&#160; [<A href="https://wg21.link/temp.class">temp.class</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#US53">N2800 comment
  US&#160;53<BR></A>

<P>If the requirements of a constrained special member function are
not satisfied, the result is that the member function is not declared
(13.7.2 [<A href="https://wg21.link/temp.class#5">temp.class</A>] paragraph 5). This allows the special
member function to be implicitly declared and defined, which will
likely result in an ill-formed program or one with the wrong semantics.</P>



<BR><BR><HR>
<A NAME="843"></A><H4>843.
  
Unclear interaction of constraints and special member functions
</H4>
<B>Section: </B>13.7.2&#160; [<A href="https://wg21.link/temp.class">temp.class</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>19 March, 2009<BR>




<P>Although the current wording does specify the outcome, it is not
immediately apparent what the result of an example like the following
should be:</P>

<PRE>
    template&lt;std::ObjectType T&gt;
    struct S {
        requires std::CopyConstructible&lt;T&gt;
        S(const S&amp;) = default;
    };
</PRE>

<P>The outcome (that <TT>S</TT> will have an implicitly-declared
copy constructor that is defined as deleted in specializations in
which <TT>T</TT> is not copy-constructible) would be clearer
with the addition of two notes.  First, it would be helpful if
13.7.2 [<A href="https://wg21.link/temp.class#5">temp.class</A>] paragraph 5, which currently reads,</P>

<BLOCKQUOTE>

A constrained member (11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]) in a class template is
declared only in class template specializations in which its template
requirements (_N2914_.14.11.1 [<A href="https://wg21.link/temp.req">temp.req</A>]) are satisfied
(_N2914_.14.11.1.1 [<A href="https://wg21.link/temp.req.sat">temp.req.sat</A>])...

</BLOCKQUOTE>

<P>had a note or footnote to the effect,</P>

<BLOCKQUOTE>

When a constrained member of a template is a special member function,
and when, in an instantiation, the member is not declared because its
requirements are not satisfied, the special member is considered not
to have been &#8220;explicitly declared&#8221; (i.e., the member is
not user-declared); therefore a declaration may still be implicitly
generated as specified in 11.4.4 [<A href="https://wg21.link/special">special</A>].

</BLOCKQUOTE>

<P>The fact that the implicitly-declared copy constructor in this
case is defined as deleted would be clearer if somewhere in
the second list in 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#5">class.copy.ctor</A>] paragraph 5, which
currently reads</P>

<BLOCKQUOTE>

<P>...An implicitly-declared copy constructor for a class <TT>X</TT> is
defined as deleted if <TT>X</TT> has:</P>

<UL>
<LI><P>a variant member with a non-trivial copy constructor and
<TT>X</TT> is a union-like class,</P></LI>

<LI><P>a non-static data member of class type <TT>M</TT> (or array
thereof) that cannot be copied because overload resolution
(12.2 [<A href="https://wg21.link/over.match">over.match</A>]), as applied to <TT>M</TT>'s copy
constructor, results in an ambiguity or a function that is deleted or
inaccessible from the implicitly-declared copy constructor,
or</P></LI>

<LI><P>a direct or virtual base class <TT>B</TT> that cannot be copied
because overload resolution (12.2 [<A href="https://wg21.link/over.match">over.match</A>]), as applied to
<TT>B</TT>'s copy constructor, results in an ambiguity or a function
that is deleted or inaccessible from the implicitly-declared copy
constructor.</P></LI>

</UL>

</BLOCKQUOTE>

<P>there were a cross-reference to _N2914_.14.11.2.1 [<A href="https://wg21.link/temp.archetype.assemble">temp.archetype.assemble</A>],
whose third paragraph reads,</P>

<BLOCKQUOTE>

If no requirement specifies a copy constructor for a type <TT>T</TT>,
a copy constructor is implicitly declared (11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>])
in the archetype of <TT>T</TT> with the following signature:

<PRE>
    T(const T&amp;) = delete;
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="851"></A><H4>851.
  
Constraints and template aliases
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

 <B>Status: </B>concepts
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>1 April, 2009<BR>




<P>The relationship of requirements with template aliases is not clear
in the current wording.  For example, something like</P>

<PRE>
    auto concept C{};

    template &lt;class T&gt; struct A{};

    template &lt;C T&gt;  using B = A&lt;T&gt;;
</PRE>

<P>is presumably allowed by the current wording of 13.7.8 [<A href="https://wg21.link/temp.alias">temp.alias</A>]
but, unless a good use case is presented, should probably be prohibited.</P>

<P>On the other hand, _N2914_.14.11 [<A href="https://wg21.link/temp.constrained#5">temp.constrained</A>] paragraph 5,</P>

<BLOCKQUOTE>

Within a constrained context, a program shall not require a template
specialization of an unconstrained template for which the template
arguments of the specialization depend on a template parameter.

</BLOCKQUOTE>

<P>might be considered to forbid an example like</P>

<PRE>
    template &lt;C T&gt; struct X {};

    template &lt;class T&gt; using Y = X&lt;T&gt;;

    template &lt;std::VariableType T&gt;
    void f(Y&lt;T&gt;); // Error?
</PRE>

<P>although it should probably be allowed.  (Note, however, that
13.7.8 [<A href="https://wg21.link/temp.alias#2">temp.alias</A>] paragraph 2,</P>

<BLOCKQUOTE>

When a <I>template-id</I> refers to the specialization of a template
alias, it is equivalent to the associated type obtained by
substitution of its <I>template-argument</I>s for the
<I>template-parameter</I>s in the <I>type-id</I> of the template
alias.

</BLOCKQUOTE>

<P>could be viewed as allowing this example, depending on how the
word &#8220;equivalent&#8221; is understood.)</P>

<P>The text should be amended to clarify the resolution of these
questions.  (See also <A HREF="cwg_closed.html#848">issue 848</A>.)</P>

<BR><BR><BR><BR><HR>
<A NAME="Extension%20Status"></A><H3>Issues with "Extension" Status</H3>
<HR>
<A NAME="2097"></A><H4>2097.
  
Lambdas and <TT>noreturn</TT> attribute
</H4>
<B>Section: </B>7.5.6&#160; [<A href="https://wg21.link/expr.prim.lambda">expr.prim.lambda</A>]
 &#160;&#160;&#160;

 <B>Status: </B>extension
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Caves
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-12<BR>




<P>The current grammar does not allow indicating that a lambda
is <TT>noreturn</TT>, because currently attributes in a
<I>lambda-expression</I> appertain to the type of the conversion
function/template, per 7.5.6 [<A href="https://wg21.link/expr.prim.lambda#5">expr.prim.lambda</A>] paragraph 5.</P>

<P><B>Additional note (February, 2022):</B></P>

<P>This issue was addressed by the adoption of paper
P2173R1 at the February, 2022 plenary.</P>

<BR><BR><HR>
<A NAME="2500"></A><H4>2500.
  
<TT>noexcept(false)</TT> functions and <TT>noexcept</TT> expressions
</H4>
<B>Section: </B>7.6.1.9&#160; [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
 &#160;&#160;&#160;

 <B>Status: </B>extension
 &#160;&#160;&#160;

 <B>Submitter: </B>CWG
 &#160;&#160;&#160;

 <B>Date: </B>2021-08-09<BR>


<P>Part of <A HREF="cwg_defects.html#2486">issue 2486</A> raised the
question of whether <TT>static_cast</TT> should be
permitted to cast a <TT>noexcept(false)</TT> function
type to a <TT>noexcept</TT> function type. Presumably
that would also involve changing 7.6.1.3 [<A href="https://wg21.link/expr.call#6">expr.call</A>] paragraph 6
to allow a call through the converted
value, with undefined behavior resulting only if the
called function actually exits via an exception.</P>

<P>CWG felt these questions should be addressed by EWG, so
they were spun off into a separate issue.</P>

<BR><BR><HR>
<A NAME="2449"></A><H4>2449.
  
Thunks as an implementation technique for pointers to virtual functions
</H4>
<B>Section: </B>7.6.2.2&#160; [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 &#160;&#160;&#160;

 <B>Status: </B>extension
 &#160;&#160;&#160;

 <B>Submitter: </B>John McCall
 &#160;&#160;&#160;

 <B>Date: </B>2020-06-03<BR>




<P>Although there are implementations that use thunks for
pointers to virtual member functions, it appears that
such a technique is not permitted by the Standard.
Concerns particularly include the requirements for complete
types for parameter and return types at the point at which
the member function pointer is formed.</P>

<BR><BR><HR>
<A NAME="2320"></A><H4>2320.
  
<TT>constexpr if</TT> and boolean conversions
</H4>
<B>Section: </B>8.5.2&#160; [<A href="https://wg21.link/stmt.if">stmt.if</A>]
 &#160;&#160;&#160;

 <B>Status: </B>extension
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-09-06<BR>




<P>Consider:</P>

<PRE>
  template&lt;void *P&gt; void f() {
    if constexpr (P) {}  // #1
  } 
</PRE>

<P>This is ill-formed at #1, because an expression of
type <TT>void*</TT> cannot be converted to <TT>bool</TT> as a
contextually converted constant expression.</P>

<BR><BR><HR>
<A NAME="1914"></A><H4>1914.
  
Duplicate standard attributes
</H4>
<B>Section: </B>9.13&#160; [<A href="https://wg21.link/dcl.attr">dcl.attr</A>]
 &#160;&#160;&#160;

 <B>Status: </B>extension
 &#160;&#160;&#160;

 <B>Submitter: </B>Aaron Ballman
 &#160;&#160;&#160;

 <B>Date: </B>2014-04-15<BR>


<P>[This suggestion was adopted as paper P2156R1 at the June, 2021
plenary.]</P>



<P>The standard attributes <TT>noreturn</TT>, <TT>carries_dependency</TT>,
and <TT>deprecated</TT> all specify that they cannot appear more than once
in an <I>attribute-list</I>, but there is no such prohibition if they
appear in separate <I>attribute-specifier</I>s within a single
<I>attribute-specifier-seq</I>.  Since intuitively these cases are
equivalent, they should be treated the same, accepting duplicates in
both or neither.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>EWG should determine the desired outcome for this question.</P>

<BR><BR><HR>
<A NAME="2261"></A><H4>2261.
  
Explicit instantiation of in-class <TT>friend</TT> definition
</H4>
<B>Section: </B>13.7.5&#160; [<A href="https://wg21.link/temp.friend">temp.friend</A>]
 &#160;&#160;&#160;

 <B>Status: </B>extension
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>2016-04-28<BR>




<P>The status of an example like the following is unclear:</P>

<PRE>
  struct S {
   template &lt;class T&gt; friend void f(T) { }
  };
  template void f(int);  //<SPAN CLASS="cmnt"> Well-formed?</SPAN>
</PRE>

<P>A friend is not found by ordinary name lookup until it is explicitly
declared in the containing namespace, but declaration matching does not
use ordinary name lookup. There is implementation divergence on the
handling of this example.</P>

<P><B>Notes from the March, 2018 meeting:</B></P>

<P>CWG did not come to consensus on the desired outcome and feels that
the question should be addressed by EWG.</P>

<BR><BR><BR><BR>
</BODY>
</HTML>
