<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core "ready" Issues
   </TITLE>
<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 }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
       &#160;P3046R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2023-11-10</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Project:
     </TD>
<TD>
      &#160;Programming Language C++
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reference:
     </TD>
<TD>
      &#160;ISO/IEC IS 14882:2020
     </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>
     Core Language Working Group "ready" Issues
     for the
     November, 2023 meeting
    </H2></CENTER>
<BR><P>
    References in this document reflect the section and paragraph
    numbering of document
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4958.pdf">WG21 N4958</A>.
   </P>
<HR>
<A NAME="1038"></A><H4>1038.
  
Overload resolution of <TT>&amp;x.static_func</TT>
</H4>
<B>Section: </B>12.3&#160; [<A href="https://wg21.link/over.over">over.over</A>]
 &#160;&#160;&#160;

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

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

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


<P>The Standard is not clear whether the following example is
well-formed or not:</P>

<PRE>
    struct S {
        static void f(int);
        static void f(double);
    };
    S s;
    void (*pf)(int) = &amp;s.f;
</PRE>

<P>According to 7.6.1.5 [<A href="https://wg21.link/expr.ref#4.3">expr.ref</A>] bullet 4.3,
you do function overload resolution to determine whether
<TT>x.f</TT> is a static or non-static member function.
7.6.2.2 [<A href="https://wg21.link/expr.unary.op#6">expr.unary.op</A>] paragraph 6 says that you can only
take the address of an overloaded function in a context that
determines the overload to be chosen, and the initialization of a
function pointer is such a context (12.3 [<A href="https://wg21.link/over.over#1">over.over</A>] paragraph 1)
.  The problem is that 12.3 [<A href="https://wg21.link/over.over">over.over</A>] is
phrased in terms of &#8220;an overloaded function name,&#8221;
and this is a member access expression, not a name.</P>

<P>There is variability among implementations as to whether this
example is accepted; some accept it as written, some only if the
<TT>&amp;</TT> is omitted, and some reject it in both forms.</P>

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

<P>A related question concerns an example like</P>

<PRE>
    struct S {
        static void g(int*) {}
        static void g(long) {}
    } s;

    void foo() {
        (&amp;s.g)(0L);
    }
</PRE>

<P>Because the address occurs in a call context and not in one of
the contexts mentioned in 12.3 [<A href="https://wg21.link/over.over#1">over.over</A>] paragraph 1,
the call expression in <TT>foo</TT> is presumably ill-formed.
Contrast this with the similar example</P>

<PRE>
    void g1(int*) {}
    void g1(long) {}

    void foo1() {
        (&amp;g1)(0L);
    }
</PRE>

<P>This call presumably is well-formed because 12.2.2.2 [<A href="https://wg21.link/over.match.call">over.match.call</A>] applies to &#8220;the address of a set of overloaded
functions.&#8221; (This was clearer in the wording prior to the
resolution of issue 704: &#8220;...in
this context using <TT>&amp;F</TT> behaves the same as using the
name <TT>F</TT> by itself.&#8221;) It's not clear that there's any
reason to treat these two cases differently.</P>

<P>This question also bears on the original question of this issue,
since the original wording of 12.2.2.2 [<A href="https://wg21.link/over.match.call">over.match.call</A>] also
described the case of an ordinary member function call like
<TT>s.g(0L)</TT> as involving the &#8220;name&#8221; of the function,
even though the <I>postfix-expression</I> is a member access
expression and not a &#8220;name.&#8221; Perhaps the reference to
&#8220;name&#8221; in 12.3 [<A href="https://wg21.link/over.over">over.over</A>] should be similarly
understood as applying to member access expressions?</P>



<P><B>Additional notes (February, 2023)</B></P>

<P>This appears to be resolved, in part by P1787R6 (accepted November, 2020).</P>

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

<P>The clarifications in P1787R6 did not address the core of this
issue, so it is kept open.  In order to avoid confusion, a wording
change to clarify the treatment (regardless of direction) seems
advisable. CWG felt that the first and second examples should be
treated consistently, and expressed a mild preferences towards making
those ill-formed.  It was noted that the reference
to <I>id-expression</I> in 12.3 [<A href="https://wg21.link/over.over">over.over</A>] can be understood
to refer to the <I>id-expression</I> of a class member access.</P>

<P>This issue is resolved by issue 2725.</P>

<BR><BR><HR>
<A NAME="1698"></A><H4>1698.
  
Files ending in <TT>\</TT>
</H4>
<B>Section: </B>5.2&#160; [<A href="https://wg21.link/lex.phases">lex.phases</A>]
 &#160;&#160;&#160;

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

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

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


<P>The description of how to handle file not ending in a newline in
5.2 [<A href="https://wg21.link/lex.phases#1">lex.phases</A>] paragraph 1, phase 2, is:</P>

<OL START="2">
<LI><P>Each instance of a backslash character (<TT>\</TT>)
immediately followed by a new-line character is deleted, splicing physical
source lines to form logical source lines. Only the last backslash on any
physical source line shall be eligible for being part of such a splice. If,
as a result, a character sequence that matches the syntax of a
universal-character-name is produced, the behavior is undefined. A source
file that is not empty and that does not end in a new-line character, or
that ends in a new-line character immediately preceded by a backslash
character before any such splicing takes place, shall be processed as if an
additional new-line character were appended to the file.</P></LI>

</OL>

<P>This is not clear regarding what happens if the last character in the
file is a backslash.  In such a case, presumably the result of adding the
newline should not be a line splice but rather a
backslash <I>preprocessing-token</I> (that will be diagnosed as an invalid
token in phase 7), but that should be spelled out.</P>

<P><B>CWG 2023-07-14</B></P>

<P>Addressed by the resolution for issue 2747.</P>

<BR><BR><HR>
<A NAME="2054"></A><H4>2054.
  
Missing description of class SFINAE
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

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

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




<P>Presumably something like the following should be well-formed, where
a deduction failure in a partial specialization is handled as a SFINAE
case as it is with function templates and not a hard error:</P>

<PRE>
  template &lt;class T, class U&gt; struct X   {
    typedef char member;
  };

  template&lt;class T&gt; struct X&lt;T,
   typename enable_if&lt;(sizeof(T)&gt;sizeof(
     float)), float&gt;::type&gt;
  {
    typedef long long member;
  };

  int main() {
    cout &lt;&lt; sizeof(X&lt;double, float&gt;::member);
  }
</PRE>

<P>However, this does not appear to be described anywhere in the
Standard.</P>

<P><B>Additional notes (January, 2023)</B></P>

<P>The section on SFINAE (13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#8">temp.deduct.general</A>] paragraph 8) is
not specific to function templates, and 13.7.6.2 [<A href="https://wg21.link/temp.spec.partial.match#2">temp.spec.partial.match</A>] paragraph 2 hands off the "matching" determination for partial
specializations to 13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>] in general.  However,
the definition of deduction substitution loci in
13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#7">temp.deduct.general</A>] paragraph 7 does not account
for the template argument list of a partial specialization.</P>



<P><B>Proposed resolution (approved by CWG 2023-11-08):</B></P>

<P>Change in 13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#7">temp.deduct.general</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

The deduction substitution loci are
<UL>
<LI>the function type outside of the <I>noexcept-specifier</I>,</LI>
<LI>the <I>explicit-specifier</I>, <DEL>and</DEL>
</LI>
<LI>the template parameter declarations<DEL>.</DEL><INS>, and</INS>
</LI>
<LI><INS>the template argument list of a partial specialization
(13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general">temp.spec.partial.general</A>]).</INS></LI>
</UL>
The substitution occurs in all types and expressions that are used in
the deduction substitution loci. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2102"></A><H4>2102.
  
Constructor checking in <I>new-expression</I>
</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>ready
 &#160;&#160;&#160;

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

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




<P>According to 7.6.2.8 [<A href="https://wg21.link/expr.new#25">expr.new</A>] paragraph 25,</P>

<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>]).

</BLOCKQUOTE>

<P>The mention of &#8220;the constructor&#8221; here is
strange.  For the &#8220;object of class type&#8221; case,
access and ambiguity control are done when we perform
initialization in paragraph 17, and we might not be calling a
constructor anyway (for aggregate initialization). This
seems wrong.</P>

<P>For the &#8220;array of objects of class type&#8221;
case, it makes slightly more sense (we need to check the
trailing array elements can be default-initialized) but
again (a) we aren't necessarily using a constructor, (b) we
should say <I>which</I> constructor &#8212; and we may need
overload resolution to find it, and (c) shouldn't this be
part of initialization, so we can distinguish between the
cases where we should copy-initialize from <TT>{}</TT> and
the cases where we should default-initialize?</P>

<P><B>Additional notes (May, 2023):</B></P>

<P>It is unclear whether default-initialization is required to be
well-formed even for an array with no elements.</P>

<P><B>Proposed resolution (approved by CWG 2023-06-16):</B></P>

<OL>
<LI>
<P>Insert a new paragraph before 7.6.2.8 [<A href="https://wg21.link/expr.new#9">expr.new</A>] paragraph 9:</P>

<BLOCKQUOTE>

<P class="ins">If the allocated type is an array,
the <I>new-initializer</I> is a <I>braced-init-list</I>, and
the <I>expression</I> is potentially-evaluated and not a core constant
expression, the semantic constraints of copy-initializing a
hypothetical element of the array from an empty initializer list are
checked (9.4.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]). [ Note: The array can contain
more elements than there are elements in the <I>braced-init-list</I>,
requiring initialization of the remainder of the array elements from
an empty initializer list. -- end note ]</P>

<P>Objects created by a new-expression have dynamic storage duration
(6.7.5.5 [<A href="https://wg21.link/basic.stc.dynamic">basic.stc.dynamic</A>]). ...</P>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#25">expr.new</A>] paragraph 25 as follows:</P>

<BLOCKQUOTE>

<DEL>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
(6.7.5.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]), and the constructor
(11.4.5 [<A href="https://wg21.link/class.ctor">class.ctor</A>]) selected for the initialization (if
any).</DEL> If the <I>new-expression</I> creates an array of objects of
class type, the destructor is potentially invoked
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]).

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#28">expr.new</A>] paragraph 28 as follows:</P>

<BLOCKQUOTE>

A declaration of a placement deallocation function matches the
declaration of a placement allocation function if it has the same
number of parameters and, after parameter transformations
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]), all parameter types except the first
are identical. If the lookup finds a single matching deallocation
function, that function will be called; otherwise, no deallocation
function will be called. If the lookup finds a usual deallocation
function and that function, considered as a placement deallocation
function, would have been selected as a match for the allocation
function, the program is ill-formed. For a non-placement allocation
function, the normal deallocation function lookup is used to find the
matching deallocation function (7.6.2.9 [<A href="https://wg21.link/expr.delete">expr.delete</A>]).
<INS>In any case, the matching deallocation function (if any) shall be
non-deleted and accessible from the point where
the <I>new-expression</I> appears.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.4.1 [<A href="https://wg21.link/dcl.init.general#7">dcl.init.general</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

To <I>default-initialize</I> an object of type T means:
<UL>
<LI>...</LI>
<LI>If T is an array type, <INS>the semantic constraints of
default-initializing a hypothetical element shall be met and</INS>
each element is default-initialized.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.4.1 [<A href="https://wg21.link/dcl.init.general#9">dcl.init.general</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

To <I>value-initialize</I> an object of type T means:

<UL>
<LI>
<DEL>if</DEL> <INS>If</INS> T is a
(possibly cv-qualified) class type (Clause 11 [<A href="https://wg21.link/class">class</A>]),
then
<UL>
<LI>if T has either no default constructor
(11.4.5.2 [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>]) or a default constructor that is
user-provided or deleted, then the object is default-initialized;
</LI>
<LI>
otherwise, the object is zero-initialized and the semantic constraints
for default-initialization are checked, and if T has a non-trivial
default constructor, the object is
default-initialized<DEL>;</DEL><INS>.</INS>
</LI>
</UL>
</LI>

<LI>
<DEL>if</DEL> <INS>If</INS> T is an array type, <INS>the semantic
constraints of value-initializing a hypothetical element shall be met
and</INS> each element is value-initialized<DEL>;</DEL><INS>.</INS>
</LI>

<LI>
<DEL>otherwise</DEL><INS>Otherwise</INS>, the object is
zero-initialized.</LI>

</UL>

</BLOCKQUOTE>
</LI>



</OL>

<BR><BR><HR>
<A NAME="2252"></A><H4>2252.
  
Enumeration list-initialization from the same type
</H4>
<B>Section: </B>9.4.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

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




<P>According to 9.4.5 [<A href="https://wg21.link/dcl.init.list#3.8">dcl.init.list</A>] bullet 3.8,</P>

<BLOCKQUOTE>

Otherwise, if <TT>T</TT> is an enumeration with a fixed underlying type
(9.7.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]), the <I>initializer-list</I> has a single
element <TT>v</TT>, and the initialization is direct-list-initialization,
the object is initialized with the value <TT>T(v)</TT>
(7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>]); if a narrowing conversion is required to
convert <TT>v</TT> to the underlying type of <TT>T</TT> , the program is
ill-formed.

</BLOCKQUOTE>

<P>This could be read as requiring that there be a conversion from
<TT>v</TT> to the underlying type of <TT>T</TT>, leaving the status of an
example like the following unclear:</P>

<PRE>
  enum class E {};
  struct X { operator E(); };
  E{X()}; //<SPAN CLASS="cmnt"> ok? </SPAN>
</PRE>

<P><B>Notes from the March, 2018 meeting:</B></P>

<P>CWG disagreed that the existing wording requires such a conversion, only
that if such a conversion is possble, it must not narrow. A formulation
along the lines of &#8220;if that initialization involves a narrowing
conversion to the underlying type of <TT>T</TT>...&#8221; was suggested to
clarify the intent. This will be handled editorially, and the issue will be
left in "review" status until the change has been verified.</P>

<P><B>Additional notes (August, 2023)</B></P>

<P>Issue 2374 has meanwhile clarified
that <TT>v</TT> is required to implicitly convert to the underlying
type of the enumeration for 9.4.5 [<A href="https://wg21.link/dcl.init.list#3.8">dcl.init.list</A>] bullet 3.8 to
apply.  Now, the logic falls through to 9.4.5 [<A href="https://wg21.link/dcl.init.list#3.9">dcl.init.list</A>] bullet 3.9 for the above example, making it well-formed.</P>

<P><B>CWG 2023-09-15</B></P>

<P>Class types with conversions to scalar types were not in view when
the wording in this bullet was conceived.</P>

<P><B>Proposed resolution (approved by CWG 2023-10-06):</B></P>

<P>Change in 9.4.5 [<A href="https://wg21.link/dcl.init.list#3.8">dcl.init.list</A>] bullet 3.8 as follows:</P>

<BLOCKQUOTE>

Otherwise, if T is an enumeration with a fixed underlying type
(9.7.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]) U, the initializer-list has a single
element v <INS>of scalar type</INS>, v can be implicitly converted to
U, and the initialization is direct-list-initialization, the object is
initialized with the value T(v) (7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>]); if a
narrowing conversion is required to convert v to U, the program is
ill-formed.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2504"></A><H4>2504.
  
Inheriting constructors from virtual base classes
</H4>
<B>Section: </B>11.9.4&#160; [<A href="https://wg21.link/class.inhctor.init">class.inhctor.init</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2021-11-03




<P>According to 11.9.4 [<A href="https://wg21.link/class.inhctor.init#1">class.inhctor.init</A>] paragraph 1,</P>

<BLOCKQUOTE>

When a constructor for type <TT>B</TT> is invoked to
initialize an object of a different type <TT>D</TT> (that
is, when the constructor was inherited
(9.9 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>])), initialization proceeds as if a
defaulted default constructor were used to initialize
the <TT>D</TT> object and each base class subobject from
which the constructor was inherited, except that
the <TT>B</TT> subobject is initialized by the invocation of
the inherited constructor. The complete initialization is
considered to be a single function call; in particular, the
initialization of the inherited constructor's parameters is
sequenced before the initialization of any part of the <TT>D</TT>object.

</BLOCKQUOTE>

<P>First, this assumes that the base class constructor will
be invoked from the derived class constructor, which will not
be true if the base is virtual and initialized by a
more-derived constructor.</P>

<P>If the call to the virtual base constructor is omitted,
the last sentence is unclear whether the initialization of
the base class constructor's parameters by the inheriting
constructor occurs or not.  There is implementation
divergence in the initialization of <TT>V</TT>'s parameter
in the following example:</P>

<PRE>
  struct NonTriv {
    NonTriv(int);
    ~NonTriv();
  };
  struct V { V() = default; V(NonTriv); };
  struct Q { Q(); };
  struct A : virtual V, Q {
    using V::V;
    A() : A(42) { }
  };
  struct B : A { };
  void foo() { B b; }
</PRE>

<P><B>CWG telecon 2022-09-23:</B></P>

<P>Inheriting constructors from a virtual base class ought to be
ill-formed.  Inform EWG accordingly.</P>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change in 9.9 [<A href="https://wg21.link/namespace.udecl#3">namespace.udecl</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

... If a <I>using-declarator</I> names a constructor,
its <I>nested-name-specifier</I> shall name a
direct <INS>non-virtual</INS> base class of the current class. If the
immediate (class) scope is associated with a class template, it shall
derive from the specified base class or have at least one dependent
base class.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change the example in 11.9.4 [<A href="https://wg21.link/class.inhctor.init#1">class.inhctor.init</A>] paragraph 1 as follows:</P>

<PRE>
D2 f(1.0);  //<SPAN CLASS="cmnt"> error: </SPAN>B1<SPAN CLASS="cmnt"> has <DEL>a deleted</DEL> <INS>no</INS> default constructor</SPAN>

<DEL>struct W { W(int); };
struct X : virtual W { using W::W; X() = delete; };
struct Y : X { using X::X; };
struct Z : Y, virtual W { using Y::Y; };
Z z(0);  //<SPAN CLASS="cmnt"> OK, initialization of Y does not invoke default constructor of X</SPAN></DEL>
</PRE>
</LI>

<LI>
<P>Change the example in 11.9.4 [<A href="https://wg21.link/class.inhctor.init#2">class.inhctor.init</A>] paragraph 2 as follows:</P>

<PRE>
<DEL>struct V1 : virtual B { using B::B; };
struct V2 : virtual B { using B::B; };

struct D2 : V1, V2 {
  using V1::V1;
  using V2::V2;
};</DEL>
D1 d1(0);  //<SPAN CLASS="cmnt"> error: ambiguous</SPAN>
<DEL>D2 d2(0);  //<SPAN CLASS="cmnt"> OK, initializes virtual B base class, which initializes the A base class</SPAN>
           //<SPAN CLASS="cmnt"> then initializes the V1 and V2 base classes as if by a defaulted default constructor</SPAN></DEL>
</PRE>
</LI>

</OL>

<P><B>CWG telecon 2022-10-07:</B></P>

<P>Given that there are examples that discuss inheriting constructors
from virtual base classes and given the existing normative wording,
making it clear that <TT>NonTriv</TT> is not constructed, CWG felt
that the implementation divergence is best addressed by amending the
examples.</P>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<P>Add another example before 11.9.4 [<A href="https://wg21.link/class.inhctor.init#2">class.inhctor.init</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P class="ins">[ Example:</P>

<PRE class="ins">
struct NonTriv {
  NonTriv(int);
  ~NonTriv();
};
struct V { V() = default; V(NonTriv); };
struct Q { Q(); };
struct A : virtual V, Q {
  using V::V;
  A() : A(42) { }    //<SPAN CLASS="cmnt"> #1, </SPAN>A(42)<SPAN CLASS="cmnt"> is equivalent to </SPAN>V(42)
};
struct B : A { };
void foo() { B b; }
</PRE>
<P class="ins">
In this example, the <TT>V</TT> subobject of <TT>b</TT> is constructed
using the defaulted default constructor.  The <I>mem-initializer</I>
naming the constructor inherited from <TT>V</TT> at #1 is not
evaluated and thus no object of type <TT>NonTriv</TT> is constructed.
-- end example ]</P>

<P>
If the constructor was inherited from multiple base class subobjects of type B, the program is ill-formed.
</P>

</BLOCKQUOTE>



<P><B>Proposed resolution (approved by CWG 2023-11-06):</B></P>

<OL>

<LI>
<P>Change in 11.9.4 [<A href="https://wg21.link/class.inhctor.init#1">class.inhctor.init</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

When a constructor for type <TT>B</TT> is invoked to initialize an
object of a different type <TT>D</TT> (that is, when the constructor
was inherited (9.9 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>])), initialization proceeds as
if a defaulted default constructor were used to initialize
the <TT>D</TT> object and each base class subobject from which the
constructor was inherited, except that the <TT>B</TT>
subobject is initialized by <DEL>the invocation of</DEL> the inherited
constructor <INS>if the base class subobject were to be
initialized as part of the <TT>D</TT> object
(11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>])</INS>. <INS>The invocation of the inherited constructor,
including the evaluation of any arguments, is omitted if
the <TT>B</TT> subobject is not to be initialized as part of
the <TT>D</TT> object.</INS> The complete initialization is considered
to be a single function call; in particular, <INS>unless
omitted,</INS> the initialization of the inherited constructor's
parameters is sequenced before the initialization of any part of
the <TT>D</TT>object.

</BLOCKQUOTE>

</LI>

<LI>
<P>Add another example before 11.9.4 [<A href="https://wg21.link/class.inhctor.init#2">class.inhctor.init</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P class="ins">[ Example:</P>

<PRE class="ins">
struct V { V() = default; V(int); };
struct Q { Q(); };
struct A : virtual V, Q {
  using V::V;
  A() = delete;
};
int bar() { return 42; }
struct B : A {
  B() : A(bar()) {}  //<SPAN CLASS="cmnt"> ok</SPAN>
};
struct C : B {};
void foo() { C c; } // bar<SPAN CLASS="cmnt"> is not invoked, because the</SPAN> V <SPAN CLASS="cmnt">subobject is not initialized as part of</SPAN> B
</PRE>

<P class="ins">-- end example ]</P>

</BLOCKQUOTE>

</LI>
</OL>

<P><B>CWG telecon 2022-10-21:</B></P>

<P>This is an ABI break for implementations when transitioning to the
C++17 model for inheriting constructors.</P>

<BR><BR><HR>
<A NAME="2531"></A><H4>2531.
  
Static data members redeclared as constexpr
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2022-02-16




<P>C++17 made constexpr static data members implicitly inline
(9.2.6 [<A href="https://wg21.link/dcl.constexpr#1">dcl.constexpr</A>] paragraph 1):</P>

<BLOCKQUOTE>

A function or static data member declared with the <TT>constexpr</TT> or
<TT>consteval</TT> specifier is implicitly an inline function or variable
(9.2.8 [<A href="https://wg21.link/dcl.inline">dcl.inline</A>]).

</BLOCKQUOTE>

<P>However, that makes the following well-formed C++14 program ill-formed,
no diagnostic required, per 9.2.8 [<A href="https://wg21.link/dcl.inline#5">dcl.inline</A>] paragraph 5:</P>

<BLOCKQUOTE>

If a function or variable with external or module linkage is declared
inline in one definition domain, an inline declaration of it shall be
reachable from the end of every definition domain in which it is
declared; no diagnostic is required.

</BLOCKQUOTE>

<PRE>
  //<SPAN CLASS="cmnt"> x.hh</SPAN>
  struct X {
    static const int x;
  };

  //<SPAN CLASS="cmnt"> TU 1</SPAN>
  #include "x.hh"
  constexpr int X::x{};

  //<SPAN CLASS="cmnt"> TU 2</SPAN>
  #include "x.hh"
  int main() { return !&amp;X::x; }
</PRE>

<P><B>Proposed resolution (reviewed by CWG 2023-02-07, approved by CWG 2023-11-07):</B></P>

<P>Change 9.2.6 [<A href="https://wg21.link/dcl.constexpr#1">dcl.constexpr</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A function or static data member declared with the <TT>constexpr</TT> or
<TT>consteval</TT> specifier
<INS>on its first declaration</INS>
is implicitly an inline function or variable
(9.2.8 [<A href="https://wg21.link/dcl.inline">dcl.inline</A>]).

</BLOCKQUOTE>

<P>
<I>Drafting note:</I> Functions must be declared <TT>constexpr</TT> on
every declaration if on any, so this isn't a change for them.</P>

<BR><BR><HR>
<A NAME="2556"></A><H4>2556.
  
Unusable <TT>promise::return_void</TT>
</H4>
<B>Section: </B>8.7.5&#160; [<A href="https://wg21.link/stmt.return.coroutine">stmt.return.coroutine</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2022-03-24




<P>Subclause 8.7.5 [<A href="https://wg21.link/stmt.return.coroutine#3">stmt.return.coroutine</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

If <TT>p.return_void()</TT> is a valid expression, flowing off the end
of a coroutine's <I>function-body</I> is equivalent to
a <TT>co_return</TT> with no operand; otherwise flowing off the end of
a coroutine's <I>function-body</I> results in undefined behavior.

</BLOCKQUOTE>

<P>However, 9.5.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#6">dcl.fct.def.coroutine</A>] paragraph 6 suggests:</P>

<BLOCKQUOTE>

If searches for the names <TT>return_void</TT>
and <TT>return_value</TT> in the scope of the promise type each find
any declarations, the program is ill-formed.  [<I>Note</I>: If
<TT>return_void</TT> is found, flowing off the end of a coroutine is
equivalent to a <TT>co_return</TT> with no operand.  Otherwise,
flowing off the end of a coroutine results in undefined behavior
(8.7.5 [<A href="https://wg21.link/stmt.return.coroutine">stmt.return.coroutine</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>The difference is between the conditions "valid expression" and
"found by name lookup".  Effectively, it means that undefined behavior
might result where the implementation could instead diagnose an
ill-formed use of <TT>return_void</TT> (for example, because it is
inaccessible, deleted, or the function call requires arguments).</P>

<P><B>Proposed resolution (approved by CWG 2023-06-17):</B></P>

<P>Change in 8.7.5 [<A href="https://wg21.link/stmt.return.coroutine#3">stmt.return.coroutine</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

If <DEL><TT>p.return_void()</TT> is a valid expression</DEL>
<INS>a search for the name <TT>return_void</TT> in the scope of the
promise type finds any declarations</INS>, flowing off the end of a
coroutine's <I>function-body</I> is equivalent to a <TT>co_return</TT>
with no operand; otherwise flowing off the end of a
coroutine's <I>function-body</I> results in undefined behavior.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2570"></A><H4>2570.
  
Clarify constexpr for defaulted functions
</H4>
<B>Section: </B>9.5.2&#160; [<A href="https://wg21.link/dcl.fct.def.default">dcl.fct.def.default</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Gabriel dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>2022-04-18




<P>After the application of P2448R2, 9.5.2 [<A href="https://wg21.link/dcl.fct.def.default#3">dcl.fct.def.default</A>] paragraph 3 reads:</P>

<BLOCKQUOTE>

A function explicitly defaulted on its first declaration is implicitly
inline (9.2.8 [<A href="https://wg21.link/dcl.inline">dcl.inline</A>]), and is implicitly constexpr
(9.2.6 [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]) if it satisfies the requirements for a
constexpr function.

</BLOCKQUOTE>

<P>It is unclear that no other such defaulted function is implicitly
constexpr.</P>

<P><B>Proposed resolution (approved by CWG 2023-06-17):</B></P>

<BLOCKQUOTE>

A function explicitly defaulted on its first declaration is implicitly
inline (9.2.8 [<A href="https://wg21.link/dcl.inline">dcl.inline</A>]), and is implicitly constexpr
(9.2.6 [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]) if it satisfies the requirements for a
constexpr function.
<INS>[<I>Note:</I> Other defaulted functions are not implicitly
constexpr. -- <I>end note</I> ]</INS>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2591"></A><H4>2591.
  
Implicit change of active union member for anonymous union in union
</H4>
<B>Section: </B>11.5.1&#160; [<A href="https://wg21.link/class.union.general">class.union.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-05-29


<P>Subclause 11.5.1 [<A href="https://wg21.link/class.union.general#6">class.union.general</A>] paragraph 6 describes how union
member subobjects are implicitly created by certain assignment
operations that assign to union members. However, this description
does not appear to properly handle the case of an anonymous union
appearing within a union:</P>

<PRE>
  union A {
    int x;
    union {
     int y;
    };
  };
  void f() {
    A a = {.x = 1};
    a.y = 2;
  }
</PRE>

<P>Here, the expectation is that the assignment to <TT>a.y</TT> starts
the lifetime of the anonymous union member subobject within <TT>A</TT>
and also the int member subobject of the anonymous union member
subobject. But the algorithm for computing S(<TT>a.y</TT>) determines
that it is {<TT>a.y</TT>} and does not include the anonymous union
member subobject.</P>

<P><B>Proposed resolution (approved by CWG 2023-06-17):</B></P>

<P>Change in 11.5.1 [<A href="https://wg21.link/class.union.general#6">class.union.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

In an assignment expression of the form <TT>E1 = E2</TT> that uses
either the built-in assignment operator (7.6.19 [<A href="https://wg21.link/expr.ass">expr.ass</A>])
or a trivial assignment operator (11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]), for
each element X of S(E1) <INS>and each anonymous union member X
(11.5.2 [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]) that is a member of a union and has such
an element as an immediate subobject (recursively)</INS>, if
modification of X would have undefined behavior under
6.7.3 [<A href="https://wg21.link/basic.life">basic.life</A>], an object of the type of X is implicitly
created in the nominated storage; no initialization is performed and
the beginning of its lifetime is sequenced after the value computation
of the left and right operands and before the assignment.

</BLOCKQUOTE>

<P>Editing note: Adding this rule into the definition of S would be more
logical, but S(E) is a set of subexpressions of E and there is no form
of expression that names an anonymous union member. Redefining S(E) to
be a set of objects might be a better option.</P>

<BR><BR><HR>
<A NAME="2595"></A><H4>2595.
  
"More constrained" for eligible 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>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Barry Revzin
 &#160;&#160;&#160;

 <B>Date: </B>2022-06-08


<P>Consider:</P>

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

  template&lt;typename T&gt;
  concept Int = std::is_same_v&lt;T, int&gt;;

  template&lt;typename T&gt;
  concept Float = std::is_same_v&lt;T, float&gt;;

  template&lt;typename T&gt;
  struct Foo {
    Foo() requires Int&lt;T&gt; = default; //<SPAN CLASS="cmnt"> #1</SPAN>
    Foo() requires Int&lt;T&gt; || Float&lt;T&gt; = default; //<SPAN CLASS="cmnt"> #2</SPAN>
  };
</PRE>

<P>Per the wording, #1 is not eligible for <TT>Foo&lt;float&gt;</TT>,
because the constraints are not satisfied.  But #2 also is not
eligible, because #1 is more constrained than #2.  The intent is that
#2 is eligible.</P>

<P><B>Proposed resolution (approved by CWG 2023-06-17):</B></P>

<P>Change in 11.4.4 [<A href="https://wg21.link/special#6">special</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

An <I>eligible special member function</I> is a special member function for
which:
<UL>
<LI>the function is not deleted,</LI>

<LI>the associated constraints (13.5 [<A href="https://wg21.link/temp.constr">temp.constr</A>]), if any,
are satisfied, and</LI>

<LI>no special member function of the same kind <INS>whose associated
constraints, if any, are satisfied</INS> is more constrained
(13.5.5 [<A href="https://wg21.link/temp.constr.order">temp.constr.order</A>]).</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2600"></A><H4>2600.
  
Type dependency of placeholder types
</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>ready
 &#160;&#160;&#160;

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

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


<P>Subclause 13.8.3.2 [<A href="https://wg21.link/temp.dep.type#7">temp.dep.type</A>] paragraph 7 has a list of
types considered to be dependent. This list covers placeholder types
only insofar as it has an entry
about <TT>decltype(expression)</TT>. Subclause
13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#3">temp.dep.expr</A>] paragraph 3 has a list of expression forms
not considered dependent unless specific types named by the
expressions are dependent. This list includes forms where placeholder
types are allowed. For example, the wording does not say that
the <I>new-expression</I> at #1 (below) is dependent, but it ought to
be:</P>

<PRE>
  template &lt;typename T&gt; struct A { A(bool, T); };

  void g(...);

  template &lt;typename T&gt;
  auto f(T t) { return g(new A(t, 0)); }  // <SPAN CLASS="cmnt">#1</SPAN>

  int g(A&lt;int&gt; *);
  int h() { return f&lt;void *&gt;(nullptr); }
</PRE>

<P>Some implementation even treats an obviously non-dependent case as
dependent:</P>

<PRE>
  template &lt;typename T, typename U&gt; struct A { A(T, U); };

  void g(...); //<SPAN CLASS="cmnt"> #1</SPAN>

  template &lt;typename T&gt;
  auto f() { return g(new A(0, 0)); } //<SPAN CLASS="cmnt"> #1 or #2?</SPAN>

  int g(A&lt;int, int&gt; *); //<SPAN CLASS="cmnt"> #2</SPAN>
  void h() { return f&lt;void *&gt;(); }
</PRE>

<P>A similar example that is non-dependent:</P>

<PRE>
  template &lt;typename T, typename U = T&gt; struct A { A(T, U); };

  void g(...);

  template &lt;typename T&gt;
  auto f() { return g(new A(0, 0)); }

  int g(A&lt;int&gt; *);
  void h() { return f&lt;void *&gt;(); }
</PRE>

<P>And another non-dependent one:</P>

<PRE>
  template &lt;typename T, typename U = T&gt; struct A { A(T); };

  void g(...);

  template &lt;typename T&gt;
  auto f() { return g(new A(0)); }

  int g(A&lt;int&gt; *);
  void h() { return f&lt;void *&gt;(); }
</PRE>

<P>And here is an example that is dependent:</P>

<PRE>
  template&lt;class T&gt;
  struct S {
   template&lt;class U = T&gt; struct A { A(int); };

   auto f() { return new A(0); } //<SPAN CLASS="cmnt"> dependent return type</SPAN>
  };
</PRE>

<P><B>Proposed resolution (November, 2022) [SUPERSEDED]:</B></P>

<OL>

<LI>
<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#2">expr.new</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If a placeholder type (9.2.9.6 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>])
<INS>or a placeholder for a deduced class type
(9.2.9.7 [<A href="https://wg21.link/dcl.type.class.deduct">dcl.type.class.deduct</A>])</INS> appears in
the <I>type-specifier-seq</I> of a <I>new-type-id</I>
or <I>type-id</I> of a <I>new-expression</I>, the allocated type is
deduced as follows: Let init be the <I>new-initializer</I> , if any,
and T be the <I>new-type-id</I> or <I>type-id</I> of
the <I>new-expression</I>, then the allocated type is the type deduced
for the variable x in the invented declaration
(9.2.9.6 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]):
<PRE>
T x <I>init</I> ;
</PRE>

</BLOCKQUOTE>

</LI>

<LI>
<P>Insert new paragraphs before
13.8.3.2 [<A href="https://wg21.link/temp.dep.type#7">temp.dep.type</A>] paragraph 7 and change the latter as follows:</P>

<BLOCKQUOTE>

<P>
<INS>An initializer is dependent if any constituent expression
(6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of the initializer is type-dependent.  A
placeholder type (9.2.9.6.1 [<A href="https://wg21.link/dcl.spec.auto.general">dcl.spec.auto.general</A>]) is dependent if it
designates a type deduced from a dependent initializer.</INS>
</P>

<P>
<INS>A placeholder for a deduced class type
(9.2.9.7 [<A href="https://wg21.link/dcl.type.class.deduct">dcl.type.class.deduct</A>]) is dependent if</INS>

<UL>
<LI><INS>it has a dependent initializer or</INS></LI>

<LI><INS>any default <I>template-argument</I> of the primary class
template named by the placeholder is dependent when considered in the
scope enclosing the primary class template.</INS></LI>
</UL>
</P>

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

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

<LI>a function type whose exception specification is value-dependent,</LI>

<LI><INS>denoted by a dependent placeholder type,</INS></LI>

<LI><INS>denoted by a dependent placeholder for a deduced class
type,</INS></LI>

<LI>...</LI>

</UL>

</BLOCKQUOTE>

</LI>

</OL>

<P><B>Proposed resolution (approved by CWG 2023-06-12):</B></P>

<OL>

<LI>
<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#2">expr.new</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If a placeholder type (9.2.9.6 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>])
<INS>or a placeholder for a deduced class type
(9.2.9.7 [<A href="https://wg21.link/dcl.type.class.deduct">dcl.type.class.deduct</A>])</INS> appears in
the <I>type-specifier-seq</I> of a <I>new-type-id</I>
or <I>type-id</I> of a <I>new-expression</I>, the allocated type is
deduced as follows: Let init be the <I>new-initializer</I> , if any,
and T be the <I>new-type-id</I> or <I>type-id</I> of
the <I>new-expression</I>, then the allocated type is the type deduced
for the variable x in the invented declaration
(9.2.9.6 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]):
<PRE>
T x <I>init</I> ;
</PRE>

</BLOCKQUOTE>

</LI>

<LI>
<P>Insert new paragraphs before
13.8.3.2 [<A href="https://wg21.link/temp.dep.type#7">temp.dep.type</A>] paragraph 7 and change the latter as follows:</P>

<BLOCKQUOTE>

<P>
<INS>An initializer is dependent if any constituent expression
(6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of the initializer is type-dependent.  A
placeholder type (9.2.9.6.1 [<A href="https://wg21.link/dcl.spec.auto.general">dcl.spec.auto.general</A>]) is dependent if it
designates a type deduced from a dependent initializer.</INS>
</P>

<P><INS>A placeholder for a deduced class type
(9.2.9.7 [<A href="https://wg21.link/dcl.type.class.deduct">dcl.type.class.deduct</A>]) is dependent if</INS></P>

<UL>
<LI><INS>it has a dependent initializer, or</INS></LI>

<LI>
<INS>it refers to an alias template that is a member of the
current instantiation and whose <I>defining-type-id</I> is dependent after
class template argument deduction (12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]) and
substitution (13.7.8 [<A href="https://wg21.link/temp.alias">temp.alias</A>]).</INS>
</LI>
</UL>

<P class="ins">[ Example:</P>

<PRE class="ins">
  template&lt;class T, class V&gt;
  struct S { S(T); };

  template&lt;class U&gt;
  struct A {
    template&lt;class T&gt; using X = S&lt;T, U&gt;;
    template&lt;class T&gt; using Y = S&lt;T, int&gt;;
    void f() {
      new X(1);    // dependent
      new Y(1);    // not dependent
    }
  };
</PRE>
<P class="ins">-- end example ]</P>

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

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

<LI>a function type whose exception specification is value-dependent,</LI>

<LI><INS>denoted by a dependent placeholder type,</INS></LI>

<LI><INS>denoted by a dependent placeholder for a deduced class
type,</INS></LI>

<LI>...</LI>

</UL>

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2628"></A><H4>2628.
  
Implicit deduction guides should propagate constraints
</H4>
<B>Section: </B>12.2.2.9&#160; [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Roy Jacobson
 &#160;&#160;&#160;

 <B>Date: </B>2022-09-11


<P>Consider:</P>

<PRE>
template&lt;class T&gt; concept True = true;

template&lt;class T&gt; struct X {
  template&lt;class U&gt; requires True&lt;T&gt; X(T, U(&amp;)[3]);
};
template&lt;typename T, typename U&gt; X(T, U(&amp;)[3]) -&gt; X&lt;T&gt;;
int arr3[3];
X z(3, arr3);     //<SPAN CLASS="cmnt"> #1</SPAN>
</PRE>

<P>According to 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#1.1">over.match.class.deduct</A>] bullet 1.1,
the <I>requires-clause</I> of the constructor is not propagated to the
function template synthesized for the implicit deduction guide.  Thus,
instead of favoring the more-constrained implicit deduction guide per
12.2.4.1 [<A href="https://wg21.link/over.match.best.general#2.6">over.match.best.general</A>] bullet 2.6, the
user-declared <I>deduction-guide</I> is preferred per
12.2.4.1 [<A href="https://wg21.link/over.match.best.general#2.11">over.match.best.general</A>] bullet 2.11.
</P>

<P><B>Proposed resolution (approved by CWG 2023-10-20):</B></P>

<P>Change in 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#1.1">over.match.class.deduct</A>] bullet 1.1 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>
If <TT>C</TT> is defined, for each constructor of <TT>C</TT>, a
function template with the following properties:
<UL>

<LI>The template parameters are the template parameters of <TT>C</TT>
followed by the template parameters (including default template
arguments) of the constructor, if any.
</LI>

<LI><INS>The associated constraints (13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>]) are
the conjunction of the associated constraints of <TT>C</TT> and the
associated constraints of the constructor.</INS></LI>

<LI>The types of the function parameters are those of the
constructor.</LI>

<LI>The return type is the class template specialization designated by
<TT>C</TT> and template arguments corresponding to the template parameters of
<TT>C</TT>.</LI>

</UL>
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2672"></A><H4>2672.
  
Lambda body SFINAE is still required, contrary to intent and note
</H4>
<B>Section: </B>13.10.3.1&#160; [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-09-30


<P>Subclause 13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#9">temp.deduct.general</A>] paragraph 9 specifies:</P>

<BLOCKQUOTE>

A <I>lambda-expression</I> appearing in a function type or a template
parameter is not considered part of the immediate context for the
purposes of template argument deduction.  [<I>Note 7:</I> The intent
is to avoid requiring implementations to deal with substitution
failure involving arbitrary statements. ... -- end note ]

</BLOCKQUOTE>

<P>However, the intent of the note is not satisfied by the normative
rule, because a <I>lambda-expression</I> appearing in
a <I>requires-expression</I> has the same concerns as one in a
function signature.</P>

<P>Suggested resolution: Change the rule to say that substitution into
the body of a lambda is never in the immediate context of substitution
into the lambda-expression and move the rule somewhere more
general.</P>

<P><U>Possible resolution (reviewed by CWG 2023-08-25) [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change in 13.5.2.3 [<A href="https://wg21.link/temp.constr.atomic#3">temp.constr.atomic</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

To determine if an atomic constraint is satisfied, the parameter
mapping and template arguments are first substituted into its
expression. If substitution results in an invalid type or
expression <INS>in the immediate context of the atomic constraint
(13.10.3.1 [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>])</INS>, the constraint is not
satisfied. Otherwise, the lvalue-to-rvalue conversion
(7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]) is performed if necessary, and E shall be
a constant expression of type bool. The constraint is satisfied if and
only if evaluation of E results in true.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#9">temp.deduct.general</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

<DEL>A <I>lambda-expression</I> appearing in a function type or a template
parameter</DEL>
<INS>Substituting into the body of a <I>lambda-expression</I></INS>
is <DEL>not considered part of</DEL> <INS>never in</INS> the immediate
context <DEL>for the purposes of template argument deduction</DEL>
<INS>of substitution into the <I>lambda-expression</I></INS>.
[<I>Note 7:</I> The intent is to avoid requiring implementations to
deal with substitution failure involving arbitrary statements.

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

<P><B>Proposed resolution (approved by CWG 2023-11-09):</B></P>

<OL>

<LI>
<P>Change in 7.5.7.1 [<A href="https://wg21.link/expr.prim.req.general#5">expr.prim.req.general</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

The substitution of template arguments into
a <I>requires-expression</I> <DEL>may</DEL> <INS>can</INS> result in
the formation of invalid types or expressions in <INS>the immediate
context of</INS>
its <I>requirement</I>s <INS>(13.10.3.1 [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>])</INS> or
the violation of the semantic constraints of
those <I>requirement</I>s.  In such cases,
the <I>requires-expression</I> evaluates to false; it does not cause
the program to be ill-formed. The substitution and semantic constraint
checking proceeds in lexical order and stops when a condition that
determines the result of the <I>requires-expression</I> is
encountered. If substitution (if any) and semantic constraint checking
succeed, the <I>requires-expression</I> evaluates to true.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 13.5.2.3 [<A href="https://wg21.link/temp.constr.atomic#3">temp.constr.atomic</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

To determine if an atomic constraint is satisfied, the parameter
mapping and template arguments are first substituted into its
expression. If substitution results in an invalid type or
expression <INS>in the immediate context of the atomic constraint
(13.10.3.1 [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>])</INS>, the constraint is not
satisfied. Otherwise, the lvalue-to-rvalue conversion
(7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]) is performed if necessary, and E shall be
a constant expression of type bool. The constraint is satisfied if and
only if evaluation of E results in true.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#9">temp.deduct.general</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

<DEL>A <I>lambda-expression</I> appearing in a function type or a template
parameter
is not considered part of the immediate
context for the purposes of template argument deduction</DEL>.
<INS>When substituting into a <I>lambda-expression</I>, substitution
into its body is not in the immediate context.</INS>
[<I>Note 7:</I> The intent is to avoid requiring implementations to
deal with substitution failure involving arbitrary statements.

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

<BR><BR><HR>
<A NAME="2725"></A><H4>2725.
  
Overload resolution for non-call of class member access
</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>ready
 &#160;&#160;&#160;

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

 <B>Date: </B>2023-04-26




<P>Consider:</P>

<PRE>
  struct A {
    static void f();
    static void f(int);
  } x;
  void (*p)() = x.f;   //<SPAN CLASS="cmnt"> error</SPAN>
</PRE>

<P>This is ill-formed as confirmed by issue 61.  Various other changes (see issue 2241) have put the following example into the same category:
</P>

<PRE>
  struct B {
    static void f();
  } y;
  void (*q)() = y.f;   //<SPAN CLASS="cmnt"> error</SPAN>
</PRE>

<P>If this is the intended outcome (although major implementations
disagree), then the rules in 7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>] should be
clarified accordingly.</P>

<P><B>Proposed resolution (approved by CWG 2023-06-13):</B></P>

<P>Change in 7.6.1.5 [<A href="https://wg21.link/expr.ref#6.3">expr.ref</A>] bullet 6.3 as follows:</P>

<BLOCKQUOTE>

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

<LI>If E2 is an overload set, <INS>the expression shall be the
(possibly-parenthesized) left-hand operand of a member function call
(7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]), and</INS> function overload resolution
(12.2 [<A href="https://wg21.link/over.match">over.match</A>]) is used to select the function to which E2
refers. The type of E1.E2 is the type of E2 and E1.E2 refers to the
function referred to by E2.
<UL>
<LI>If E2 refers to a static member function, E1.E2 is an lvalue.</LI>

<LI>Otherwise (when E2 refers to a non-static member function), E1.E2
is a prvalue. <DEL>The expression can be used only as the left-hand
operand of a member function call (11.4.2 [<A href="https://wg21.link/class.mfct">class.mfct</A>]).</DEL>
[<I>Note 5:</I> Any redundant set of parentheses surrounding the
expression is ignored (7.5.3 [<A href="https://wg21.link/expr.prim.paren">expr.prim.paren</A>]). &#8212;<I>end
note</I>]
</LI>
</UL>
</LI>

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

</BLOCKQUOTE>

<P>This also addresses issue 1038.</P>

<BR><BR><HR>
<A NAME="2733"></A><H4>2733.
  
Applying <TT>[[maybe_unused]]</TT> to a label
</H4>
<B>Section: </B>9.12.8&#160; [<A href="https://wg21.link/dcl.attr.unused">dcl.attr.unused</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Barry Revzin
 &#160;&#160;&#160;

 <B>Date: </B>2023-05-25


<P>Subclause 9.12.8 [<A href="https://wg21.link/dcl.attr.unused#2">dcl.attr.unused</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

The attribute may be applied to the declaration of a class,
a <I>typedef-name</I>, a variable (including a structured binding
declaration), a non-static data member, a function, an enumeration, or
an enumerator.

</BLOCKQUOTE>

<P>Absent from that list are labels, but both gcc and clang
accept <TT>[[maybe_unused]]</TT> on a label, and behave
accordingly.</P>

<P><B>Proposed resolution (approved by CWG 2023-07-14)</B></P>

<P>Change in 9.12.8 [<A href="https://wg21.link/dcl.attr.unused">dcl.attr.unused</A>] as follows:</P>

<BLOCKQUOTE>

<P>The <I>attribute-token</I> <TT>maybe_unused</TT> indicates that a
name<INS>, label,</INS> or entity is possibly intentionally unused.
No <I>attribute-argument-clause</I> shall be present.</P>

<P>The attribute may be applied to the declaration of a class,
<DEL>a</DEL> <I>typedef-name</I>, <DEL>a</DEL> variable (including a
structured binding declaration), <DEL>a</DEL> non-static data
member, <DEL>a</DEL> function, <DEL>an</DEL> enumeration,
or <DEL>an</DEL> enumerator<INS>, or to an <I>identifier</I>
label (8.2 [<A href="https://wg21.link/stmt.label">stmt.label</A>])</INS>.</P>

<P>A name or entity declared without the <TT>maybe_unused</TT>
attribute can later be redeclared with the attribute and vice
versa. An entity is considered marked after the first declaration that
marks it.</P>

<P>
<I>Recommended practice</I>: For an entity
marked <TT>maybe_unused</TT>, implementations should not emit a
warning that the entity or its structured bindings (if any) are used
or unused. For a structured binding declaration not
marked <TT>maybe_unused</TT>, implementations should not emit such a
warning unless all of its structured bindings are unused.
<INS>For a label to which <TT>maybe_unused</TT> is applied,
implementations should not emit a warning that the label is used or
unused.</INS>
</P>

[<I>Example 1:</I>
<PRE>
  [[maybe_unused]] void f([[maybe_unused]] bool thing1,
                          [[maybe_unused]] bool thing2) {
    [[maybe_unused]] bool b = thing1 &amp;&amp; thing2;
    assert(b);
<INS>#ifdef NDEBUG
    goto x;
#endif</INS>
    <INS>[[maybe_unused]] x:</INS>
  }
</PRE>
Implementations should not warn
that <TT>b</TT> <INS>or <TT>x</TT></INS> is unused, whether or not
<TT>NDEBUG</TT> is defined. &#8212; <I>end example</I>]

</BLOCKQUOTE>

<P><B>CWG 2023-07-14</B></P>

<P>
CWG has reviewed and approved the proposed resolution.  However, this
is a new (albeit small) feature, thus forwarding to EWG via
<A HREF="https://github.com/cplusplus/papers/issues/1585">paper issue 1585</A>
for approval.
</P>

<P><B>EWG 2023-11-07</B></P>

<P>Accept the proposed resolution, forward to CWG for inclusion in C++26.</P>

<BR><BR><HR>
<A NAME="2747"></A><H4>2747.
  
Cannot depend on an already-deleted splice
</H4>
<B>Section: </B>5.2&#160; [<A href="https://wg21.link/lex.phases">lex.phases</A>]
 &#160;&#160;&#160;

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

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

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


<P>(From editorial issue
<A HREF="https://github.com/cplusplus/draft/issues/4903">4903</A>.)</P>

<P>Subclause 5.2 [<A href="https://wg21.link/lex.phases#2">lex.phases</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

... Each sequence of a backslash character (\) immediately
followed by zero or more whitespace characters other than new-line
followed by a new-line character is deleted, splicing physical source
lines to form logical source lines. ...  A source
file that is not empty and that does not end in a new-line character,
or that ends in a splice, shall be processed as if an additional
new-line character were appended to the file.

</BLOCKQUOTE>

<P>This is confusing, because the first sentence deletes all splices,
and then the last sentence checks for a splice that has already been
deleted.</P>

<P><B>Proposed resolution (approved by CWG 2023-07-14):</B></P>

<P>Change in 5.2 [<A href="https://wg21.link/lex.phases#2">lex.phases</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

... Each sequence of a backslash character (\) immediately
followed by zero or more whitespace characters other than new-line
followed by a new-line character is deleted, splicing physical source
lines to form logical source lines. ...  A source file that is not
empty and that <INS>(after splicing)</INS> does not end in a new-line character<DEL>, or that ends
in a splice,</DEL> shall be processed as
if an additional new-line character were appended to the file.

</BLOCKQUOTE>

<P><B>CWG 2023-07-14</B></P>

<P>CWG noted that a lone backslash at the end of a file remains (in
the status quo and with the proposed change) and turns into an
ill-formed <I>preprocessing-token</I>. The wording as amended seems
sufficiently clear to consider issue 1698
resolved.</P>

<BR><BR><HR>
<A NAME="2749"></A><H4>2749.
  
Treatment of "pointer to void" for relational comparisons
</H4>
<B>Section: </B>7.6.9&#160; [<A href="https://wg21.link/expr.rel">expr.rel</A>]
 &#160;&#160;&#160;

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

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

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


<P>(From editorial issue
<A HREF="https://github.com/cplusplus/draft/pull/6173">6173</A>.)</P>

<P>Subclause 7.6.9 [<A href="https://wg21.link/expr.rel#4">expr.rel</A>] paragraph 4 and paragraph 5 specify:</P>

<BLOCKQUOTE>

<P>The result of comparing unequal pointers to objects [ Footnote: ]
is defined in terms of a partial order consistent with the following
rules: ...</P>

<P>[Note 1: A relational operator applied to unequal function
pointers or to unequal pointers to void yields an unspecified
result. -- end note]</P>

</BLOCKQUOTE>

<P>Comparing pointers to objects that are stored in a variable of type
"pointer to void" should be fine.</P>

<P><B>Proposed resolution (approved by CWG 2023-06-16):</B></P>

<P>Change in 7.6.9 [<A href="https://wg21.link/expr.rel#4">expr.rel</A>] paragraph 4 and paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P>The result of comparing unequal pointers to objects [ Footnote:
... ] is defined in terms of a partial order consistent with the
following rules: ...</P>

<P>[Note 1: A relational operator applied to unequal function
pointers <DEL>or to unequal pointers to void</DEL> yields an
unspecified result. <INS>A pointer value of type "pointer
to <I>cv</I> <TT>void</TT>" can point to an object
(6.8.4 [<A href="https://wg21.link/basic.compound">basic.compound</A>]).</INS> -- end note]</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2753"></A><H4>2753.
  
Storage reuse for string literal objects and backing arrays
</H4>
<B>Section: </B>6.7.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-29




<P>Subclause 6.7.2 [<A href="https://wg21.link/intro.object#9">intro.object</A>] paragraph 9 specifies the general
principle that two objects with overlapping lifetimes have
non-overlapping storage, which can be observed by comparing
addresses:</P>

<BLOCKQUOTE>

Unless an object is a bit-field or a subobject of zero size, the
address of that object is the address of the first byte it
occupies. Two objects with overlapping lifetimes that are not
bit-fields may have the same address if one is nested within the
other, or if at least one is a subobject of zero size and they are of
different types; otherwise, they have distinct addresses and occupy
disjoint bytes of storage.

</BLOCKQUOTE>

<P>After P2752, there are two exceptions: string literal objects and
backing arrays for initializer lists.</P>

<P>Subclause 5.13.5 [<A href="https://wg21.link/lex.string#9">lex.string</A>] paragraph 9 specifies:</P>

<BLOCKQUOTE>

Evaluating a <I>string-literal</I> results in a string literal object
with static storage duration (6.7.5 [<A href="https://wg21.link/basic.stc">basic.stc</A>]). Whether
all <I>string-literal</I>s are distinct (that is, are stored in
nonoverlapping objects) and whether successive evaluations of
a <I>string-literal</I> yield the same or a different object is
unspecified.

</BLOCKQUOTE>

<P>Subclause 9.4.4 [<A href="https://wg21.link/dcl.init.ref#5">dcl.init.ref</A>] paragraph 5, after application of P2752R3 (approved in June, 2023), specifies:</P>

<BLOCKQUOTE>

Whether all backing arrays are distinct (that is, are stored in
non-overlapping objects) is unspecified.

</BLOCKQUOTE>

<P>It is unclear whether a backing array can overlap with a string
literal object.</P>

<P>Furthermore, it is unclear whether any such object can overlap with
named objects or temporaries, for example:</P>

<PRE>
  const char (&amp;r) [] = "foo";
  const char a[] = {'f', 'o', 'o', '\0'};

  int main() {  
    assert(&amp;r == &amp;a);   // allowed not to fail?
  }
</PRE>

<P><B>Proposed resolution (approved by CWG 2023-11-09):</B></P>

<OL>

<LI>
<P>Add a new paragraph before 6.7.2 [<A href="https://wg21.link/intro.object#9">intro.object</A>] paragraph 9 and
change the latter as follows:</P>

<BLOCKQUOTE>

<P class="ins">
An object is a <I>potentially non-unique object</I> if it is a string literal
object (5.13.5 [<A href="https://wg21.link/lex.string">lex.string</A>]), the backing array of an
initializer list (9.4.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]), or a subobject thereof.
</P>

<P>Unless an object is a bit-field or a subobject of zero size, the
address of that object is the address of the first byte it
occupies. Two objects with overlapping lifetimes that are not
bit-fields may have the same address if one is nested within the
other, or if at least one is a subobject of zero size and they are of
different types<INS>, or if they are both potentially non-unique objects</INS>;
otherwise, they have distinct addresses and occupy disjoint bytes of
storage.</P>

<P>[Example 2:</P>

<PRE>
  static const char test1 = 'x';
  static const char test2 = 'x';
  const bool b = &amp;test1 != &amp;test2;  //<SPAN CLASS="cmnt"> always true</SPAN>

<INS>  static const char (&amp;r) [] = "x";
  static const char *s = "x";  
  static std::initializer_list&lt;char&gt; il = { 'x' };
  const bool b2 = r != il.begin();        //<SPAN CLASS="cmnt"> unspecified result</SPAN>
  const bool b3 = r != s;                 //<SPAN CLASS="cmnt"> unspecified result</SPAN>
  const bool b4 = il.begin() != &amp;test1;   //<SPAN CLASS="cmnt"> always </SPAN>true
  const bool b5 = r != &amp;test1;            //<SPAN CLASS="cmnt"> always </SPAN>true</INS>
</PRE>
<P> -- end example]</P>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in subclause 5.13.5 [<A href="https://wg21.link/lex.string#9">lex.string</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

Evaluating a <I>string-literal</I> results in a string literal object
with static storage duration (6.7.5 [<A href="https://wg21.link/basic.stc">basic.stc</A>]). <INS>[
Note: String literal objects are potentially non-unique
(6.7.2 [<A href="https://wg21.link/intro.object">intro.object</A>]).</INS> Whether
<DEL>all <I>string-literal</I>s are distinct (that is, are stored in
nonoverlapping objects) and whether</DEL> successive evaluations of
a <I>string-literal</I> yield the same or a different object
is unspecified. <INS>-- end note ]</INS>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in subclause 9.4.4 [<A href="https://wg21.link/dcl.init.ref#5">dcl.init.ref</A>] paragraph 5, after
application of P2752R3 (approved in June, 2023), as follows:</P>

<BLOCKQUOTE>

<DEL>Whether all backing arrays are distinct (that is, are stored in
non-overlapping objects) is unspecified.</DEL> <INS>[ Note: Backing
arrays are potentially non-unique objects (6.7.2 [<A href="https://wg21.link/intro.object">intro.object</A>]). -- end
note ]</INS>

</BLOCKQUOTE>
</LI>

</OL>

<P><B>CWG 2023-07-14</B></P>

<P>CWG resolved that a named or temporary object is always disjoint
from any other object, and thus cannot overlap with a string literal
object or a backing array.  The lines <TT>b4</TT> and <TT>b5</TT> in the example
highlight that outcome.</P>

<P>Backing arrays and string literals can arbitrarily overlap among
themselves; CWG believes the proposed wording achieves that
outcome.</P>

<P>The ancillary question how address comparisons between potentially
non-unique objects are treated during constant evaluation is handled
in issue 2765.</P>

<BR><BR><HR>
<A NAME="2754"></A><H4>2754.
  
Using *this in explicit object member functions that are coroutines
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Christof Meerwald
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-23


<P>Subclause 9.5.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#4">dcl.fct.def.coroutine</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

In the following, pi is an lvalue of type Pi , where p1 denotes the
object parameter and pi+1 denotes the ith non-object function
parameter for a non-static member function, and pi denotes the ith
function parameter otherwise. For a non-static member function, q1 is
an lvalue that denotes <TT>*this</TT>; any other qi is an lvalue that denotes
the parameter copy corresponding to pi , as described below.

</BLOCKQUOTE>

<P>An explicit object member function is a non-static member function,
but there is no <TT>this</TT>.</P>

<P><B>Proposed resolution (approved by CWG 2023-07-14):</B></P>

<P>Change in 9.5.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#4">dcl.fct.def.coroutine</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

In the following, pi is an lvalue of type Pi , where p1 denotes the
object parameter and pi+1 denotes the ith non-object function
parameter for <DEL>a non-static</DEL> <INS>an implicit object</INS>
member function, and pi denotes the ith function parameter
otherwise. For <DEL>a non-static</DEL> <INS>an implicit object</INS>
member function, q1 is an lvalue that denotes <TT>*this</TT>; any
other qi is an lvalue that denotes the parameter copy corresponding to
pi, as described below.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2755"></A><H4>2755.
  
Incorrect wording applied by P2738R1
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-06-28


<P>
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2738r1.pdf">P2738R1</A>
(constexpr cast from void*: towards constexpr type-erasure)
applied incorrect wording to 7.7 [<A href="https://wg21.link/expr.const#5.14">expr.const</A>] bullet 5.14:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>a conversion from a prvalue P of type &#8221;pointer to cv
void&#8221; to a pointer-to-object type T unless P points to an object
whose type is similar to T;
</LI>

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

</BLOCKQUOTE>

<P>The issue is that <TT>T</TT> is defined to be a pointer type, but
the "similar to" phrasing uses it as the pointee type.</P>

<P><B>Proposed resolution (approved by CWG 2023-07-14):</B></P>

<P>Change in 7.7 [<A href="https://wg21.link/expr.const#5.14">expr.const</A>] bullet 5.14 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>a conversion from a prvalue P of type &#8221;pointer to cv
void&#8221; to a <DEL>pointer-to-object</DEL> type <DEL>T</DEL> <INS>"<I>cv1</I>
pointer to <TT>T</TT>", where <TT>T</TT> is
not <I>cv2</I> <TT>void</TT>,</INS> unless P points to an
object whose type is similar to T;
</LI>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2758"></A><H4>2758.
  
What is "access and ambiguity control"?
</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>ready
 &#160;&#160;&#160;

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

 <B>Date: </B>2023-06-12


<P>Subclause 7.6.2.9 [<A href="https://wg21.link/expr.delete#12">expr.delete</A>] paragraph 12 specifies:</P>

<BLOCKQUOTE>

Access and ambiguity control are done for both the deallocation
function and the destructor (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>],
11.4.11 [<A href="https://wg21.link/class.free">class.free</A>]).

</BLOCKQUOTE>

<P>It is unclear what that means.  In particular, ambiguity checking
is part of overload resolution, and access checking requires a point
of reference.</P>

<P><B>Proposed resolution (approved by CWG 2023-08-25):</B></P>

<OL>
<LI>
<P>Change in 7.6.2.9 [<A href="https://wg21.link/expr.delete#6">expr.delete</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

If the value of the operand of the <I>delete-expression</I> is not a
null pointer value and the selected deallocation function (see below)
is not a destroying operator delete, <INS>evaluating</INS>
the <I>delete-expression</I> <DEL>will invoke</DEL> <INS>invokes</INS>
the destructor (if any) for the object or the elements of the array
being deleted. <INS>The destructor shall be accessible from the point
where the <I>delete-expression</I> appears.</INS> In the case of an
array, the elements <DEL>will be</DEL> <INS>are</INS> destroyed in
order of decreasing address (that is, in reverse order of the
completion of their constructor; see 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.2.9 [<A href="https://wg21.link/expr.delete#10">expr.delete</A>] paragraph 10</P>

<BLOCKQUOTE>

<DEL>If more than one deallocation function is found,
the</DEL> <INS>The deallocation</INS> function to be called is
selected as follows:

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

<P class="ins">Unless the deallocation function is selected at the
point of definition of the dynamic type's virtual destructor, the
selected deallocation function shall be accessible from the point
where the <I>delete-expression</I> appears.</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Remove 7.6.2.9 [<A href="https://wg21.link/expr.delete#12">expr.delete</A>] paragraph 12:</P>

<BLOCKQUOTE>

<DEL>Access and ambiguity control are done for both the deallocation
function and the destructor (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>],
11.4.11 [<A href="https://wg21.link/class.free">class.free</A>]).</DEL>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2759"></A><H4>2759.
  
[[no_unique_address] and common initial sequence
</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>ready
 &#160;&#160;&#160;

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

 <B>Date: </B>2020-11-10




<P>The interaction of [[no_unique_address]] and the definition of
common initial sequence is still problematic.  Subclause
11.4.1 [<A href="https://wg21.link/class.mem.general#23.3">class.mem.general</A>] bullet 23.3 specifies that corresponding
members in a common initial sequence are not allowed to differ with
respect to the presence or absence of a [[no_unique_address]]
attribute.  However, the Itanium ABI will not allocate two successive
data members of the same empty class type at the same address, causing
non-conforming behavior for the following example:</P>

<PRE>
  struct A {};
  struct B {};

  struct C {
   [[no_unique_address]] A a;
   [[no_unique_address]] B b;
  };

  struct D {
   [[no_unique_address]] A a1;
   [[no_unique_address]] A a2;
  };

  static_assert(offsetof(C, b) == offsetof(D, a2));
</PRE>

<P>See <A HREF="https://github.com/itanium-cxx-abi/cxx-abi/issues/108">Itanium
ABI issue 108</A>.</P>

<P>Since "common initial sequence" and "layout compatible" are
concepts mostly used for C compatibility, but [[no_unique_address]]
does not exist in C, it seems reasonable to terminate a common initial
sequence at the first data member that is declared
[[no_unique_address]].</P>

<P>Another concern is the behavior
of <TT>std::is_layout_compatible</TT> on implementations that ignore
[[no_unique_address]]. On such an implementation, the following
example would be considered layout-compatible, although it actually is
not:</P>

<PRE>
  struct E {};

  struct A {
    E e;
    int i;
  };

  struct B {
    [[no_unique_address]] E e;
    int i;
  };

  static_assert(
    std::is_layout_compatible_v&lt;A, B&gt;
  );
</PRE>


<P><U>Alternative possible resolution [SUPERSEDED]:</U></P>

<P>Change in 11.4.1 [<A href="https://wg21.link/class.mem.general#23">class.mem.general</A>] paragraph 23 as follows:</P>

<BLOCKQUOTE>

The common initial sequence of two standard-layout struct
(11.2 [<A href="https://wg21.link/class.prop">class.prop</A>]) types is the longest sequence of
non-static data members and bit-fields in declaration order, starting
with the first such entity in each of the structs, such that
<UL>
<LI>corresponding entities have layout-compatible types
(6.8 [<A href="https://wg21.link/basic.types">basic.types</A>]),</LI>

<LI>corresponding entities have the same alignment requirements
(6.7.6 [<A href="https://wg21.link/basic.align">basic.align</A>]),</LI>

<LI>
<DEL>either both entities are declared with the no_unique_address
attribute (9.12.11 [<A href="https://wg21.link/dcl.attr.nouniqueaddr">dcl.attr.nouniqueaddr</A>]) or neither is,</DEL>
<INS>neither entity is declared with the <TT>no_unique_address</TT>
attribute (9.12.11 [<A href="https://wg21.link/dcl.attr.nouniqueaddr">dcl.attr.nouniqueaddr</A>]),</INS> and</LI>

<LI>either both entities are bit-fields with the same width or neither
is a bit-field.
</LI>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-08-25):</B></P>

<P>Change in 11.4.1 [<A href="https://wg21.link/class.mem.general#23">class.mem.general</A>] paragraph 23 as follows:</P>

<BLOCKQUOTE>

The common initial sequence of two standard-layout struct
(11.2 [<A href="https://wg21.link/class.prop">class.prop</A>]) types is the longest sequence of
non-static data members and bit-fields in declaration order, starting
with the first such entity in each of the structs, such that
<UL>
<LI>corresponding entities have layout-compatible types
(6.8 [<A href="https://wg21.link/basic.types">basic.types</A>]),</LI>

<LI>corresponding entities have the same alignment requirements
(6.7.6 [<A href="https://wg21.link/basic.align">basic.align</A>]),</LI>

<LI>
<DEL>either both entities are declared with the no_unique_address
attribute (9.12.11 [<A href="https://wg21.link/dcl.attr.nouniqueaddr">dcl.attr.nouniqueaddr</A>]) or neither is,</DEL>
<INS>if a <I>has-attribute-expression</I> (15.2 [<A href="https://wg21.link/cpp.cond">cpp.cond</A>])
is not 0 for the <TT>no_unique_address</TT> attribute, then neither
entity is declared with the <TT>no_unique_address</TT> attribute
(9.12.11 [<A href="https://wg21.link/dcl.attr.nouniqueaddr">dcl.attr.nouniqueaddr</A>]),</INS> and</LI>

<LI>either both entities are bit-fields with the same width or neither
is a bit-field.
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2760"></A><H4>2760.
  
Defaulted constructor that is an immediate function
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-08


<P>Consider:</P>

<PRE>
  consteval int f(int);
  struct S {
   int x = f(0);
   S() = default;
  };

  int main() {
    S s;     //<SPAN CLASS="cmnt"> OK?</SPAN>
  }
</PRE>

<P>Is <TT>S</TT> an immediate function?</P>

<P>The relevant specification is in 7.7 [<A href="https://wg21.link/expr.const#18">expr.const</A>] paragraph 18:</P>

<BLOCKQUOTE>

An immediate function is a function or constructor that is
<UL>
<LI>declared with the <TT>consteval</TT> specifier, or</LI>
<LI>an immediate-escalating function F whose function body contains an
immediate-escalating expression E such that E's innermost enclosing
non-block scope is F's function parameter scope.</LI>
</UL>

</BLOCKQUOTE>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

<P>Change in 7.7 [<A href="https://wg21.link/expr.const#18">expr.const</A>] paragraph 18 as follows:</P>

<BLOCKQUOTE>

An immediate function is a function or constructor that is
<UL>
<LI>declared with the <TT>consteval</TT> specifier, or</LI>
<LI>an immediate-escalating function F whose function body contains an
immediate-escalating expression E such that E's innermost enclosing
non-block scope is F's function parameter scope<INS>, or</INS>
</LI>
<LI class="ins">an immediate-escalating default constructor of a class
which has at least one non-static data member with an
immediate-escalating default member initializer.</LI>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-08-25):</B></P>

<OL>
<LI>
<P>Change in 7.7 [<A href="https://wg21.link/expr.const#18">expr.const</A>] paragraph 18 as follows:</P>

<BLOCKQUOTE>

An immediate function is a function or constructor that is
<UL>
<LI>declared with the <TT>consteval</TT> specifier, or</LI>
<LI>an immediate-escalating function F whose function body contains an
immediate-escalating expression E such that E's innermost enclosing
non-block scope is F's function parameter scope.
<INS>[ Note: Default member initializers used to initialize a base or
member subobject (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]) are considered to be
part of the function body (9.5.1 [<A href="https://wg21.link/dcl.fct.def.general">dcl.fct.def.general</A>]). -- end note
]</INS>
</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.5.1 [<A href="https://wg21.link/dcl.fct.def.general#1">dcl.fct.def.general</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Any informal reference to the body of a function should be interpreted
as a reference to the non-terminal <I>function-body</I><INS>,
including, for a constructor, default member initializers or default
initialization used to initialize a base or member subobject in the
absence of a <I>mem-initializer-id</I>
(11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>])</INS>.

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2761"></A><H4>2761.
  
Implicitly invoking the deleted destructor of an anonymous union member
</H4>
<B>Section: </B>11.4.7&#160; [<A href="https://wg21.link/class.dtor">class.dtor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-11




<P>Consider:</P>

<PRE>
  struct S{
    ~S() {}
  };

  struct A {
    union {
      S arr_;
    };
    ~A(); //<SPAN CLASS="cmnt"> user-provided!</SPAN>
  };

  auto foo() {
    return A{S()};
  }
</PRE>

<P>Does the destructor of <TT>A</TT> attempt to destroy the (unnamed)
data member that is the anonymous union?  The latter has a deleted
destructor per 11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>].  For the default
constructor, 11.9.3 [<A href="https://wg21.link/class.base.init#9.2">class.base.init</A>] paragraph 9.2 prevents the
corresponding construction.</P>

<P><B>Proposed resolution (approved by CWG 2023-08-25):</B></P>

<OL>
<LI>
<P>Change in 9.4.2 [<A href="https://wg21.link/dcl.init.aggr#9">dcl.init.aggr</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

The destructor for each element of class type <INS>other than an
anonymous union member</INS> is potentially invoked
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]) from the context where the aggregate
initialization occurs

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.7 [<A href="https://wg21.link/class.dtor#13">class.dtor</A>] paragraph 13 as follows:</P>

<BLOCKQUOTE>

After executing the body of the destructor and destroying any objects
with automatic storage duration allocated within the body, a
destructor for class X calls the destructors for X's direct
non-variant non-static data members <INS>other than anonymous
unions</INS>, the destructors for X's non-virtual direct base classes
and, if X is the most derived class (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]), its
destructor calls the destructors for X's virtual base classes. All
destructors are called as if they were referenced with a qualified
name, that is, ignoring any possible virtual overriding destructors in
more derived classes.  Bases and members are destroyed in the reverse
order of the completion of their constructor (see
11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 14.3 [<A href="https://wg21.link/except.ctor#3">except.ctor</A>] paragraph 3 as follows:</P>



<BLOCKQUOTE>

A subobject is <I>known to be initialized</I> if <INS>it is not an
anonymous union member and</INS> its initialization is specified
<UL>
<LI>in 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>] for initialization by
constructor,</LI>
<LI>in 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>] for initialization by defaulted
copy/move constructor,</LI>
<LI>in 11.9.4 [<A href="https://wg21.link/class.inhctor.init">class.inhctor.init</A>] for initialization by inherited
constructor,</LI>
<LI>in 9.4.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>] for aggregate initialization,</LI>
<LI>in 7.5.5.3 [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>] for the initialization of the
closure object when evaluating a lambda-expression,</LI>
<LI>in 9.4.1 [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>] for default-initialization,
value-initialization, or direct-initialization of an array.</LI>
</UL>

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

<BR><BR><HR>
<A NAME="2762"></A><H4>2762.
  
Type of implicit object parameter
</H4>
<B>Section: </B>12.2.2.1&#160; [<A href="https://wg21.link/over.match.funcs.general">over.match.funcs.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-07-11


<P>Subclause 12.2.2.1 [<A href="https://wg21.link/over.match.funcs.general#4">over.match.funcs.general</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

For implicit object member functions, the type of the implicit object
parameter is
<UL>
<LI>&#8220;lvalue reference to cv X&#8221; for functions declared
without a <I>ref-qualifier</I> or with the
&amp; <I>ref-qualifier</I>
</LI>
<LI>&#8220;rvalue reference to cv X&#8221; for functions declared with
the &amp;&amp; <I>ref-qualifier</I>
</LI>
</UL>
where X is the class of which the function is a member and cv is the
cv-qualification on the member function declaration.

</BLOCKQUOTE>

<P>Since a member of some class C is also a member of any class
derived from C, this specification is unclear.</P>

<P><B>Proposed resolution (approved by CWG 2023-08-25):</B></P>

<P>Change in 12.2.2.1 [<A href="https://wg21.link/over.match.funcs.general#4">over.match.funcs.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

For implicit object member functions, the type of the implicit object
parameter is
<UL>
<LI>&#8220;lvalue reference to cv X&#8221; for functions declared
without a <I>ref-qualifier</I> or with the
&amp; <I>ref-qualifier</I>
</LI>
<LI>&#8220;rvalue reference to cv X&#8221; for functions declared with
the &amp;&amp; <I>ref-qualifier</I>
</LI>
</UL>
where X is the class of which the function is a <INS>direct</INS>
member and cv is the cv-qualification on the member function
declaration.

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="2763"></A><H4>2763.
  
Ignorability of [[noreturn]] during constant evaluation
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-10


<P>Subclause 9.12.10 [<A href="https://wg21.link/dcl.attr.noreturn#2">dcl.attr.noreturn</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

If a function f is called where f was previously declared with the
<TT>noreturn</TT> attribute and f eventually returns, the behavior is
undefined.

</BLOCKQUOTE>

<P>Undefineed behavior is, in general, detected during constant
evaluation, thus requiring an implementation to actually support
the <TT>noreturn</TT> attribute, such as in the following example:</P>

<PRE>
  [[noreturn]] constexpr void f() {}
  constexpr int x = (f(), 0);
</PRE>

<P>It might be desirable to treat the <TT>assume</TT>
and <TT>noreturn</TT> attributes alike in that regard.</P>

<P><B>Proposed resolution (approved by CWG 2023-07-14) [SUPERSEDED]:</B></P>

<P>Split into a separate paragraph and change 7.7 [<A href="https://wg21.link/expr.const#5">expr.const</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

It is unspecified whether E is a core constant expression if E
satisfies the constraints of a core constant expression, but
evaluation of E would evaluate
<UL>
<LI>an operation that has undefined
behavior as specified in Clause 16 through Clause 33,</LI>
<LI>an invocation of the va_start macro
(17.13.2 [<A href="https://wg21.link/cstdarg.syn">cstdarg.syn</A>]), <DEL>or</DEL>
</LI>
<LI class="ins">a <TT>return</TT> statement in a function that was
previously declared with the <TT>noreturn</TT> attribute
(9.12.10 [<A href="https://wg21.link/dcl.attr.noreturn">dcl.attr.noreturn</A>]), or</LI>
<LI>
a statement with an assumption (9.12.3 [<A href="https://wg21.link/dcl.attr.assume">dcl.attr.assume</A>])
whose converted <I>conditional-expression</I>, if evaluated where the
assumption appears, would not disqualify E from being a core constant
expression and would not evaluate to <TT>true</TT>.  [ Note: .... ]</LI>
</UL>

</BLOCKQUOTE>

<P><B>CWG 2023-07-14</B></P>

<P>As an alternative, all of 9.12 [<A href="https://wg21.link/dcl.attr">dcl.attr</A>] could be added
to the "library undefined behavior" bullet.  However, CWG felt that a
case-by-case consideration is warranted, given that assumptions set
precedent in requiring special treatment.</P>

<P><B>Possible resolution (reviewed by CWG 2023-08-25) [SUPERSEDED]:</B></P>

<P>Split into a separate paragraph and change 7.7 [<A href="https://wg21.link/expr.const#5">expr.const</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
an operation that would have undefined behavior as specified in
Clause 4 [<A href="https://wg21.link/intro">intro</A>] through Clause 15 [<A href="https://wg21.link/cpp">cpp</A>], excluding
9.12.3 [<A href="https://wg21.link/dcl.attr.assume">dcl.attr.assume</A>] <INS>and 9.12.10 [<A href="https://wg21.link/dcl.attr.noreturn">dcl.attr.noreturn</A>]</INS>; [
Footnote: ...]
</LI>
<LI>...</LI>
</UL>

It is unspecified whether E is a core constant expression if E
satisfies the constraints of a core constant expression, but
evaluation of E would evaluate
<UL>
<LI>an operation that has undefined
behavior as specified in Clause 16 through Clause 33,</LI>
<LI>an invocation of the va_start macro
(17.13.2 [<A href="https://wg21.link/cstdarg.syn">cstdarg.syn</A>]), <DEL>or</DEL>
</LI>
<LI class="ins">a <TT>return</TT> statement in a function that was
previously declared with the <TT>noreturn</TT> attribute
(9.12.10 [<A href="https://wg21.link/dcl.attr.noreturn">dcl.attr.noreturn</A>]), or</LI>
<LI>
a statement with an assumption (9.12.3 [<A href="https://wg21.link/dcl.attr.assume">dcl.attr.assume</A>])
whose converted <I>conditional-expression</I>, if evaluated where the
assumption appears, would not disqualify E from being a core constant
expression and would not evaluate to <TT>true</TT>.  [ Note: .... ]</LI>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-11-09):</B></P>

<P>Split into a separate paragraph and change 7.7 [<A href="https://wg21.link/expr.const#5">expr.const</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
an operation that would have undefined behavior as specified in
Clause 4 [<A href="https://wg21.link/intro">intro</A>] through Clause 15 [<A href="https://wg21.link/cpp">cpp</A>], excluding
9.12.3 [<A href="https://wg21.link/dcl.attr.assume">dcl.attr.assume</A>] <INS>and 9.12.10 [<A href="https://wg21.link/dcl.attr.noreturn">dcl.attr.noreturn</A>]</INS>; [
Footnote: ...]
</LI>
<LI>...</LI>
</UL>

It is unspecified whether E is a core constant expression if E
satisfies the constraints of a core constant expression, but
evaluation of E would evaluate
<UL>
<LI>an operation that has undefined
behavior as specified in Clause 16 through Clause 33,</LI>
<LI>an invocation of the va_start macro
(17.13.2 [<A href="https://wg21.link/cstdarg.syn">cstdarg.syn</A>]), <DEL>or</DEL>
</LI>
<LI class="ins">a call to a function that was previously declared
with the <TT>noreturn</TT> attribute (9.12.10 [<A href="https://wg21.link/dcl.attr.noreturn">dcl.attr.noreturn</A>])
and that call returns to its caller, or</LI>
<LI>
a statement with an assumption (9.12.3 [<A href="https://wg21.link/dcl.attr.assume">dcl.attr.assume</A>])
whose converted <I>conditional-expression</I>, if evaluated where the
assumption appears, would not disqualify E from being a core constant
expression and would not evaluate to <TT>true</TT>.  [ Note: .... ]</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2764"></A><H4>2764.
  
Use of placeholders affecting name mangling
</H4>
<B>Section: </B>6.4.1&#160; [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]
 &#160;&#160;&#160;

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

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

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




<P>Paper P2169R4 (A nice placeholder with no name), as approved by
WG21 in Varna, added a placeholder facility.  The intent was that the
use of placeholders is sufficiently limited such that they never need
to be mangled.  Quote from 6.4.1 [<A href="https://wg21.link/basic.scope.scope#5">basic.scope.scope</A>] paragraph 5 as
modified by the paper:</P>

<BLOCKQUOTE>

A declaration is name-independent if its name is _ and it declares a
variable with automatic storage duration, a structured binding not
inhabiting a namespace scope, the variable introduced by
an <I>init-capture</I>, or a non-static data member.

</BLOCKQUOTE>

<P>The following example does not seem to follow that intent:</P>

<PRE>
  struct A { A(); };
  inline void f() {
    static union { A _{}; };
    static union { A _{}; };
  }
  void g() { return f(); }
</PRE>

<P>The preceding example needs handling similar to the following
example, which is unrelated to the placeholder feature:</P>

<PRE>
  struct A { A(); };
  inline void f() {
    { static union { A a{}; }; }
    { static union { A a{}; }; }
  }
  void g() { return f(); }
</PRE>

<P>A similar problem may arise for <TT>static</TT>
or <TT>thread_local</TT> structured bindings at block scope.</P>

<P>Finally, another example involving placeholders in anonymous unions:</P>

<PRE>
  static union { int _ = 42; };
  int &amp;ref = _;
  int foo() { return 13; }
  static union { int _ = foo(); };
  int main() { return ref; }
</PRE>

<P><U>Possible resolution (reviewed by CWG 2023-08-25) [SUPERSEDED]:</U></P>

<P>Change in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#5">basic.scope.scope</A>] paragraph 5 and add bullets as
follows:</P>

<BLOCKQUOTE>

<INS>A class is <I>name-dependent</I> if it is an anonymous union
declared at namespace scope or with a <I>storage-class-specifier</I>
(11.5.2 [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]).</INS> A declaration
is <I>name-independent</I> if its name is _ and it declares
<UL>
<LI>a variable with automatic storage duration,</LI>
<LI>a structured binding <INS>with no <I>storage-class-specifier</I>
and</INS> not inhabiting a namespace scope,</LI>
<LI>the variable introduced by an <I>init-capture</I>, or</LI>
<LI>a non-static data member <INS>of other than a name-dependent
class</INS>.</LI>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-09-15):</B></P>

<P>Change in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#5">basic.scope.scope</A>] paragraph 5 and add bullets as
follows:</P>

<BLOCKQUOTE>

A declaration is <I>name-independent</I> if its name is _ and it
declares
<UL>
<LI>a variable with automatic storage duration,</LI>
<LI>a structured binding <INS>with no <I>storage-class-specifier</I>
and</INS> not inhabiting a namespace scope,</LI>
<LI>the variable introduced by an <I>init-capture</I>, or</LI>
<LI>a non-static data member <INS>of other than an anonymous union</INS>.</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2768"></A><H4>2768.
  
Assignment to enumeration variable with a <I>braced-init-list</I>
</H4>
<B>Section: </B>7.6.19&#160; [<A href="https://wg21.link/expr.ass">expr.ass</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Shafik Yaghmour
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-06


<P>Consider:</P>

<PRE>
   enum class E {E1};

   void f() {
     E e;
     e = E{0}; //<SPAN CLASS="cmnt"> #1</SPAN>
     e = {0};  //<SPAN CLASS="cmnt"> #2</SPAN>
   }
</PRE>

<P>#1 first initializes a temporary of type <TT>E</TT> and then
assigns that to <TT>e</TT>.  For #2,
7.6.19 [<A href="https://wg21.link/expr.ass#8.1">expr.ass</A>] bullet 8.1 specifies that #2 is
equivalent to #1:</P>

<BLOCKQUOTE>

A <I>braced-init-list</I> may appear on the right-hand side of
<UL>
<LI>
an assignment to a scalar, in which case the initializer list shall
have at most a single element. The meaning of <TT>x = {v}</TT>, where T is the
scalar type of the expression x, is that of <TT>x = T{v}</TT>. The meaning of
<TT>x = {}</TT> is <TT>x = T{}</TT>.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>However, there is no syntactic hint that #2 would invoke
direct-initialization, and in fact gcc, icc, and MSVC reject #2, but
clang accepts.</P>

<P><B>Proposed resolution (approved by CWG 2023-11-06):</B></P>

<P>Change in 7.6.19 [<A href="https://wg21.link/expr.ass#8">expr.ass</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

A <I>braced-init-list</I> <INS><I>B</I></INS> may appear on the
right-hand side of
<UL>
<LI>
an assignment to a scalar <INS>of type <TT>T</TT></INS>, in which
case <DEL>the initializer list</DEL> <INS><I>B</I></INS> shall have at
most a single element. The meaning of <TT>x
= <DEL>{v}</DEL><INS><I>B</I></INS></TT> <INS> is <TT>x = t</TT>,
where <TT>t</TT> is an invented temporary variable declared and
initialized as <TT>T t = <I>B</I></TT></INS><DEL>, where T is the
scalar type of the expression x, is that of <TT>x = T{v}</TT>. The
meaning of <TT>x = {}</TT> is <TT>x = T{}</TT></DEL>.</LI>

<LI>
an assignment to an object of class type, in which case <DEL>the
initializer list</DEL> <INS><I>B</I></INS> is passed as the argument
to the assignment operator function selected by overload resolution
(12.4.3.2 [<A href="https://wg21.link/over.ass">over.ass</A>], 12.2 [<A href="https://wg21.link/over.match">over.match</A>]).
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2772"></A><H4>2772.
  
Missing Annex C entry for linkage effects of <I>linkage-specification</I>
</H4>
<B>Section: </B>C.6.4&#160; [<A href="https://wg21.link/diff.cpp03.dcl.dcl">diff.cpp03.dcl.dcl</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-07-15




<P>With C++11, anonymous namespaces changed from external linkage
(with a unique namespace name) to internal linkage.  That implies
that <TT>extern "C"</TT>, which affects names with external linkage
only, no longer has an effect inside anonymous namespaces.</P>

<P>However, a corresponding Annex C entry is missing.</P>

<P><B>Proposed resolution (approved by CWG 2023-09-15):</B></P>

<P>Add a new paragraph in C.6.4 [<A href="https://wg21.link/diff.cpp03.dcl.dcl">diff.cpp03.dcl.dcl</A>] as follows:</P>

<BLOCKQUOTE class="ins">

Affected subclause: 9.11 [<A href="https://wg21.link/dcl.link">dcl.link</A>]<BR>
Change: Names declared in an anonymous namespace changed from external
linkage to internal linkage; language linkage applies to names with
external linkage only.<BR>
Rationale: Alignment with user expectations.<BR>
Effect on original feature: Valid C++ 2003 code may violate the one-definition rule (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) in this revision of C++. For example:
<PRE>
  namespace { extern "C" { extern int x; } }  // <SPAN CLASS="cmnt">#1, previously external linkage and C language linkage, now internal linkage and C++ language linkage</SPAN>
  namespace A { extern "C" int x = 42; }      // <SPAN CLASS="cmnt">#2, external linkage and C language linkage</SPAN>
  int main(void) { return x; }
</PRE>
This code is valid in C++ 2003, but #2 is not a definition for #1 in
this revision of C++, violating the one-definition rule.
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2780"></A><H4>2780.
  
<TT>reinterpret_cast</TT> to reference to function types
</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>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Lauri Vasama
 &#160;&#160;&#160;

 <B>Date: </B>2023-08-07


<P>Subclause 7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast#11">expr.reinterpret.cast</A>] paragraph 11 specifies:</P>

<BLOCKQUOTE>

A glvalue of type T1, designating an object x, can be cast to the type
&#8220;reference to T2&#8221; if an expression of type &#8220;pointer
to T1&#8221; can be explicitly converted to the type &#8220;pointer to
T2&#8221; using a reinterpret_cast.  The result is that of
*reinterpret_cast&lt;T2 *&gt;(p) where p is a pointer to x of type
&#8220;pointer to T1&#8221;. No temporary is created, no copy is made,
and no constructors (11.4.5 [<A href="https://wg21.link/class.ctor">class.ctor</A>]) or conversion
functions (11.4.8 [<A href="https://wg21.link/class.conv">class.conv</A>]) are called. [ Footnote: ... ]

</BLOCKQUOTE>

<P>The wording does not cover references to function type, only
references to object types.  All major implementations accept the
following example:</P>

<PRE>
  void f() {}

  void(&amp;g())(int) {
    return reinterpret_cast&lt;void(&amp;)(int)&gt;(f);
  }
</PRE>

<P><B>Proposed resolution (approved by CWG 2023-09-15):</B></P>

<P>Change in 7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast#11">expr.reinterpret.cast</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

A glvalue of type T1, designating
an object <INS>or function</INS> x, can be cast to the type
&#8220;reference to T2&#8221; if an expression of type &#8220;pointer
to T1&#8221; can be explicitly converted to the type &#8220;pointer to
T2&#8221; using a <TT>reinterpret_cast</TT>.  The result is that of
<TT>*reinterpret_cast&lt;T2 *&gt;(p)</TT> where <TT>p</TT> is a
pointer to x of type &#8220;pointer to T1&#8221;. No temporary is
created, no copy is made, and no constructors
(11.4.5 [<A href="https://wg21.link/class.ctor">class.ctor</A>]) or conversion functions
(11.4.8 [<A href="https://wg21.link/class.conv">class.conv</A>]) are called. [ Footnote: ... ]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2783"></A><H4>2783.
  
Handling of deduction guides in <I>global-module-fragment</I>
</H4>
<B>Section: </B>10.4&#160; [<A href="https://wg21.link/module.global.frag">module.global.frag</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Daniela Engert
 &#160;&#160;&#160;

 <B>Date: </B>2023-08-21


<P>Consider:</P>

<PRE>
  // <SPAN CLASS="cmnt">header</SPAN> "S.h"
  
  template&lt;class T&gt;
  struct S {
    S(const T*);
  };
  template&lt;class T&gt;
  S(T*) -&gt; S&lt;T&gt;

  // <SPAN CLASS="cmnt">translation unit</SPAN>
  module;
  #include "S.h"

  export module M;
  export using ::S;
</PRE>

<P>Obviously, the <I>using-declaration</I> referring to the class
template <TT>S</TT> is exported by <TT>M</TT>, but what about the
deduction guide of <TT>S</TT>?</P>

<P><B>Proposed resolution (approved by CWG 2023-08-25) [SUPERSEDED]:</B></P>

<P>Add a new bullet after 10.4 [<A href="https://wg21.link/module.global.frag#3.5.7">module.global.frag</A>] bullet 3.5.7 as
follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
there exists a declaration M that is not a <I>namespace-definition</I>
for which M is decl-reachable from S and either
<UL>
<LI>...</LI>
<LI>one of M and D declares a template and the other declares a
partial or explicit specialization or an implicit or explicit
instantiation of that template, or</LI>
<LI class="ins">one of M and D declares a class template and the other
declares a deduction guide for that template, or</LI>
</UL>
</LI>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-10-06):</B></P>

<P>Add a new bullet after 10.4 [<A href="https://wg21.link/module.global.frag#3.5.7">module.global.frag</A>] bullet 3.5.7 as
follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
there exists a declaration M that is not a <I>namespace-definition</I>
for which M is decl-reachable from S and either
<UL>
<LI>...</LI>
<LI>one of M and D declares a template and the other declares a
partial or explicit specialization or an implicit or explicit
instantiation of that template, or</LI>
<LI class="ins">M declares a class template and D
is a deduction guide for that template, or</LI>
</UL>
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2785"></A><H4>2785.
  
Type-dependence of <I>requires-expression</I>
</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>ready
 &#160;&#160;&#160;

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

 <B>Date: </B>2023-07-17


<P>(Split off from issue 2774.)</P>

<P>Subclause 13.8.3.3 [<A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>] is lacking specifiation
about the type-dependence of <I>requires-expression</I>s.</P>

<P><B>Proposed resolution (approved by CWG 2023-08-25):</B></P>

<P>Change in 13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#4">temp.dep.expr</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Expressions of the following forms are never type-dependent (because
the type of the expression cannot be dependent):

<PRE>
  ...
  noexcept ( <I>expression</I> )
  <INS><I>requires-expression</I></INS>
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2789"></A><H4>2789.
  
Overload resolution with implicit and explicit object member functions
</H4>
<B>Section: </B>12.2.4.1&#160; [<A href="https://wg21.link/over.match.best.general">over.match.best.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

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


<P>Consider:</P>

<PRE>
  template &lt;typename T = int&gt;
  struct S {
    constexpr void f();                      //<SPAN CLASS="cmnt"> #1</SPAN>
    constexpr void f(this S&amp;) requires true; //<SPAN CLASS="cmnt"> #2</SPAN>
  };

  void test() {
    S&lt;&gt; s;
    s.f();                 //<SPAN CLASS="cmnt"> #3</SPAN>
  }
</PRE>

<P>With the current rules, the call at #3 is ambiguous, even though #2
is more constrainted.</P>

<P><B>Proposed resolution (approved by CWG 2023-11-07):</B></P>

<P>Change in 12.2.4.1 [<A href="https://wg21.link/over.match.best.general#2.6">over.match.best.general</A>] bullet 2.6 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>F1 and F2 are non-template functions <DEL>with</DEL> <INS>and</INS>
<UL>
<LI>
<INS>they have</INS> the same
<DEL>parameter-type-lists</DEL> <INS>non-object-parameter-type-lists
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]), </INS> and</LI>
<LI class="ins">if they are member functions, both are direct members of the same
class, and</LI>
<LI class="ins">if both are non-static member
functions, they have the same types for their object parameters, and</LI>
<LI>F1 is more constrained than F2 according to the
partial ordering of constraints described in
13.5.5 [<A href="https://wg21.link/temp.constr.order">temp.constr.order</A>],
</LI>
</UL>
or if not that,

<P class="ins">[ Example:</P>
<PRE class="ins">
  template &lt;typename T = int&gt;
  struct S {
    constexpr void f();                      // #1
    constexpr void f(this S&amp;) requires true; // #2
  };

  void test() {
    S&lt;&gt; s;
    s.f();                 // calls #2
  }
</PRE>
<P class="ins"> -- end example ]</P>
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2791"></A><H4>2791.
  
Unclear phrasing about "returning to the caller"
</H4>
<B>Section: </B>8.7.4&#160; [<A href="https://wg21.link/stmt.return">stmt.return</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2023-08-23


<P>In 8.7.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>] and 8.7.5 [<A href="https://wg21.link/stmt.return.coroutine">stmt.return.coroutine</A>], the
standard uses the phrasing "returns to its caller" when
specifying <TT>return</TT> or <TT>co_return</TT>.  It would be better
to talk about transfer of control, which is a term used elsewhere in
the standard.</P>

<P><B>Proposed resolution (approved by CWG 2023-10-06):</B></P>

<OL>
<LI>
<P>Change in 7.6.2.4 [<A href="https://wg21.link/expr.await#1">expr.await</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The co_await expression is used to suspend evaluation of a coroutine
(9.5.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]) while awaiting completion of the
computation represented by the operand expression.
<INS>Suspending the evaluation of a coroutine transfers control to its
caller or resumer.</INS>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 8.7.4 [<A href="https://wg21.link/stmt.return#1">stmt.return</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A function returns <INS>control</INS> to its caller by the return statement.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change 8.7.5 [<A href="https://wg21.link/stmt.return.coroutine#1">stmt.return.coroutine</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<DEL>A coroutine returns to its caller or resumer
(9.5.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]) by the <TT>co_return</TT> statement or when
suspended (7.6.2.4 [<A href="https://wg21.link/expr.await">expr.await</A>]).</DEL>
<INS>A <TT>co_return</TT> statement transfers control to the caller or
resumer of a coroutine (9.5.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]).</INS> A coroutine
shall not enclose a <TT>return</TT> statement
(8.7.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>]).

</BLOCKQUOTE>
</LI>

<LI>

<P>Change in 9.5.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#10">dcl.fct.def.coroutine</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

If the allocation function returns nullptr, the
coroutine <DEL>returns</DEL> <INS>transfers</INS> control to the
caller of the coroutine and the return value is obtained by a call to
<TT>T::get_return_object_on_allocation_failure()</TT>, where T is the
promise type.

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2792"></A><H4>2792.
  
Clean up specification of <TT>noexcept</TT> operator
</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>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2023-08-30


<P>The introductory sentence "can throw an exception" is misleading,
because it might be interpreted to cover exceptions thrown as the
result of encountering undefined behavior.</P>

<P><B>Proposed resolution (approved by CWG 2023-10-06):</B></P>

<P>Change all of 7.6.2.7 [<A href="https://wg21.link/expr.unary.noexcept">expr.unary.noexcept</A>] as follows:</P>

<BLOCKQUOTE>

<P>
<DEL>The noexcept operator determines whether the evaluation of its
operand, which is an unevaluated operand (7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]),
can throw an exception (14.2 [<A href="https://wg21.link/except.throw">except.throw</A>]).</DEL>
<PRE>
<I>noexcept-expression</I>:
        noexcept ( <I>expression</I> )
</PRE>
</P>

<P class="ins">
The operand of the <TT>noexcept</TT> operator is an unevaluated operand
(7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]).  If the operand is a prvalue, the
temporary materialization conversion (7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>]) is
applied.
</P>

<P>The result of the <TT>noexcept</TT> operator is a prvalue of
type <TT>bool</TT>.
<INS>
The result is <TT>false</TT> if the full-expression of the operand is
potentially-throwing (14.5 [<A href="https://wg21.link/except.spec">except.spec</A>]), and <TT>true</TT>
otherwise.
</INS>

</P>

<P>
[<I>Note 1:</I> A <I>noexcept-expression</I> is an integral constant
expression (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). &#8212;<I>end note</I>]</P>

<P><DEL>If the operand is a prvalue, the temporary materialization
conversion (7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>]) is applied. The result of the
noexcept operator is true unless the full-expression of the operand is
potentially-throwing (14.5 [<A href="https://wg21.link/except.spec">except.spec</A>]).</DEL></P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2793"></A><H4>2793.
  
Block-scope declaration conflicting with parameter name
</H4>
<B>Section: </B>6.4.3&#160; [<A href="https://wg21.link/basic.scope.block">basic.scope.block</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-08-31




<P>Consider:</P>

<PRE>
  void f(int i) { extern int i; } 
</PRE>

<P>According to 6.4.3 [<A href="https://wg21.link/basic.scope.block#2">basic.scope.block</A>] paragraph 2, the target scope
of the declaration is relevant (which would be the global scope), but
not the scope in which the name is bound.  That seems wrong. For
comparison, template parameter names use the latter rule
(13.8.2 [<A href="https://wg21.link/temp.local#6">temp.local</A>] paragraph 6).</P>

<P><B>Proposed resolution (approved by CWG 2023-09-15):</B></P>

<BLOCKQUOTE>

If a declaration that is not a name-independent declaration
and <DEL>whose target scope is</DEL> <INS>that binds a name in</INS>
the block scope S of a
<UL>
<LI>
<I>compound-statement</I> of
a <I>lambda-expression</I>, <I>function-body</I>,
or <I>function-try-block</I>,</LI>
<LI>substatement of  a selection  or iteration  statement that  is not
itself a selection or iteration statement, or</LI>
<LI>handler of a <I>function-try-block</I>
</LI>
</UL>
potentially conflicts with a declaration whose target scope is the
parent scope of S, the program is ill-formed.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2795"></A><H4>2795.
  
Overlapping empty subobjects with different cv-qualification
</H4>
<B>Section: </B>6.7.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-09-04




<P>Subclause 6.7.2 [<A href="https://wg21.link/intro.object#9">intro.object</A>] paragraph 9 specifies:</P>

<BLOCKQUOTE>

... Two objects with overlapping lifetimes that are not bit-fields may
have the same address if one is nested within the other, or if at
least one is a subobject of zero size and they are of different types;
otherwise, they have distinct addresses and occupy disjoint bytes of
storage. [ Footnote: ... ]

</BLOCKQUOTE>

<P>Types <TT>T</TT> and <TT>const T</TT> are different types, but it
is unlikely the rule is intending to differentiate along that
line.</P>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

<P>Change in 6.7.2 [<A href="https://wg21.link/intro.object#9">intro.object</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

... Two objects with overlapping lifetimes that are not bit-fields may
have the same address if one is nested within the other, or if at
least one is a subobject of zero size and they are of different types
<INS>(ignoring top-level cv-qualifiers)</INS>; otherwise, they have
distinct addresses and occupy disjoint bytes of storage. [ Footnote:
... ]

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-09-15):</B></P>

<P>(Hypothetically, pointer-to-member types can be empty, but might
differ in non-top-level cv-qualification.)</P>

<P>Change in 6.7.2 [<A href="https://wg21.link/intro.object#9">intro.object</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

... Two objects with overlapping lifetimes that are not bit-fields may
have the same address if one is nested within the other, or if at
least one is a subobject of zero size and they are <INS>not</INS>
of <DEL>different</DEL> <INS>similar</INS>
types <INS>(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>])</INS>; otherwise, they have
distinct addresses and occupy disjoint bytes of storage. [ Footnote:
... ]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2796"></A><H4>2796.
  
Function pointer conversions for relational operators
</H4>
<B>Section: </B>7.6.9&#160; [<A href="https://wg21.link/expr.rel">expr.rel</A>]
 &#160;&#160;&#160;

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

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

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


<P>Consider:</P>

<PRE>
  void f() {}
  void g() noexcept {}

  void q() {
    bool b1 = f == g;     // <SPAN CLASS="cmnt">OK</SPAN>
    bool b2 = f &gt; g;      // <SPAN CLASS="cmnt">error: different types</SPAN>
  }
</PRE>

<P>For the equality operators, 7.6.10 [<A href="https://wg21.link/expr.eq#3">expr.eq</A>] paragraph 3
specifies:</P>

<BLOCKQUOTE>

If at least one of the operands is a pointer, pointer conversions
(7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]), function pointer conversions
(7.3.14 [<A href="https://wg21.link/conv.fctptr">conv.fctptr</A>]), and qualification conversions
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]) are performed on both operands to bring
them to their composite pointer type
(7.2.2 [<A href="https://wg21.link/expr.type">expr.type</A>]). Comparing pointers is defined as
follows: ...

</BLOCKQUOTE>

<P>In contrast, the corresponding rule for relational operators in
7.6.9 [<A href="https://wg21.link/expr.rel#3">expr.rel</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

The usual arithmetic conversions (7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are
performed on operands of arithmetic or enumeration type. If both
operands are pointers, pointer conversions
(7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]) and qualification conversions
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]) are performed to bring them to their
composite pointer type (7.2.2 [<A href="https://wg21.link/expr.type">expr.type</A>]). After
conversions, the operands shall have the same type.

</BLOCKQUOTE>

<P>However, all major implementations accept the example.</P>

<P><B>Proposed resolution (approved by CWG 2023-10-06):</B></P>

<P>Change in 7.6.9 [<A href="https://wg21.link/expr.rel#3">expr.rel</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

The usual arithmetic conversions (7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are
performed on operands of arithmetic or enumeration type. If both
operands are pointers, pointer conversions
(7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>])<INS>, function pointer conversions
(7.3.14 [<A href="https://wg21.link/conv.fctptr">conv.fctptr</A>]),</INS> and qualification conversions
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]) are performed to bring them to their
composite pointer type (7.2.2 [<A href="https://wg21.link/expr.type">expr.type</A>]). After
conversions, the operands shall have the same type.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2798"></A><H4>2798.
  
Manifestly constant evaluation of the <TT>static_assert</TT> message
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-09-12




<P>The message of a <TT>static_assert</TT> declaration is
a <I>conditional-expression</I> and thus is not manifestly constant
evaluated. Consider this example:</P>

<PRE>
  struct X {
    std::string s;
    const char *p;
  };
  consteval X f() { return {.s = "some long string that requires a heap allocation", .p = "hello"}; }

  static_assert(cond, f().p);
</PRE>

<P>The example is ill-formed, because the immediate
invocation <TT>f()</TT> lets a pointer to the heap escape.</P>

<P><B>Proposed resolution (approved by CWG 2023-10-06):</B></P>

<OL>
<LI>
<P>Change in 7.7 [<A href="https://wg21.link/expr.const#19">expr.const</A>] paragraph 19 as follows:</P>

<BLOCKQUOTE>

[<I>Note 11:</I> <INS>Except for
a <I>static_assert-message</I>, a</INS> <DEL>A</DEL> manifestly
constant-evaluated expression is evaluated even in an unevaluated
operand (7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change the grammar in 9.1 [<A href="https://wg21.link/dcl.pre">dcl.pre</A>] as follows:</P>

<BLOCKQUOTE>
<PRE>
<I>static_assert-message:
  unevaluated-string
  <DEL>conditional-expression</DEL> <INS>constant-expression</INS></I>
</PRE>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.1 [<A href="https://wg21.link/dcl.pre#11.2">dcl.pre</A>] bullet 11.2 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>if the <I>static_assert-message</I> is a <I><DEL>conditional-expression</DEL> <INS>constant-expression</INS></I>
M, ...</LI>
</UL>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2801"></A><H4>2801.
  
Reference binding with reference-related types
</H4>
<B>Section: </B>9.4.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-09-18




<P>Consider:</P>

<PRE>
  int* p;
  const int*&amp;&amp; r = static_cast&lt;int*&amp;&amp;&gt;(p);
</PRE>

<P>The intent of core issues 2018 and
2352 was to make this example ill-formed,
because it surprisingly introduces a temporary.</P>

<P><B>Proposed resolution (approved by CWG 2023-10-20):</B></P>

<P>Change in 9.4.4 [<A href="https://wg21.link/dcl.init.ref#5.4">dcl.init.ref</A>] bullet 5.4 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>Otherwise<DEL>:</DEL><INS>, <TT>T1</TT> shall not be
reference-related to <TT>T2</TT>.</INS>
<UL>
<LI>If T1 or T2 is a class type <DEL>and T1 is not reference-related
to T2</DEL>, user-defined conversions are considered using the rules
for copy-initialization of an object of type &#8220;cv1 T1&#8221; by
user-defined conversion (9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>],
12.2.2.5 [<A href="https://wg21.link/over.match.copy">over.match.copy</A>], 12.2.2.6 [<A href="https://wg21.link/over.match.conv">over.match.conv</A>]); the
program is ill-formed if the corresponding non-reference
copy-initialization would be ill-formed. The result of the call to the
conversion function, as described for the non-reference
copy-initialization, is then used to direct-initialize the reference.
For this direct-initialization, user-defined conversions are not
considered.</LI>
<LI>Otherwise, the initializer expression is
implicitly converted to a prvalue of type &#8220;T1&#8221;. The
temporary materialization conversion is applied, considering the type
of the prvalue to be &#8220;cv1 T1&#8221;, and the reference is bound
to the result.
</LI>
</UL>
<DEL>If T1 is reference-related to T2:</DEL>
<UL>
<LI><DEL>cv1 shall be the same cv-qualification as, or greater
cv-qualification than, cv2; and</DEL></LI>
<LI>
<DEL>if the reference is an rvalue reference, the initializer
expression shall not be an lvalue.  [<I>Note 3:</I> This can be
affected by whether the initializer expression is move-eligible
(7.5.4.2 [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>]). &#8212;<I>end note</I>]</DEL>
</LI>
</UL>
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2806"></A><H4>2806.
  
Make a <I>type-requirement</I> a type-only context
</H4>
<B>Section: </B>13.8.1&#160; [<A href="https://wg21.link/temp.res.general">temp.res.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Barry Revzin
 &#160;&#160;&#160;

 <B>Date: </B>2023-10-10


<P>Consider:</P>

<PRE>
  template &lt;typename T&gt;
  concept C = requires {
    typename T::type&lt;void&gt;;   // template <SPAN CLASS="cmnt">required?</SPAN>
  };
</PRE>

<P>There is implementation divergence: gcc accepts, clang and MSVC reject.</P>

<P>A <I>type-requirement</I> ought to be a type-only context.</P>

<P><B>Proposed resolution (approved by CWG 2023-10-20):</B></P>

<OL>
<LI>
<P>Change in 7.5.7.3 [<A href="https://wg21.link/expr.prim.req.type#1">expr.prim.req.type</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A <I>type-requirement</I> asserts the validity of a type.
<INS>The component names of a <I>type-requirement</I> are those of
its <I>nested-name-specifier</I> (if any) and <I>type-name</I>.</INS>

[<I>Note 1:</I> The enclosing <I>requires-expression</I> will evaluate
to <TT>false</TT> if substitution of template arguments
fails. &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.8.1 [<A href="https://wg21.link/temp.res.general#4">temp.res.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A qualified or unqualified name is said to be in a <I>type-only context</I>
if it is the terminal name of
<UL>
<LI>a <I>typename-specifier</I>, <INS><I>type-requirement</I>,</INS>
<I>nested-name-specifier</I>, <I>elaborated-type-specifier</I>,
<I>class-or-decltype</I>, or</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

</OL>


<BR><BR><HR>
<A NAME="2807"></A><H4>2807.
  
Destructors declared <TT>consteval</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>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2023-09-07


<P>There is a conflict between 9.2.6 [<A href="https://wg21.link/dcl.constexpr#2">dcl.constexpr</A>] paragraph 2</P>

<BLOCKQUOTE>

A destructor, an allocation function, or a deallocation function shall
not be declared with the <TT>consteval</TT> specifier.

</BLOCKQUOTE>

<P>and 11.4.7 [<A href="https://wg21.link/class.dtor#1">class.dtor</A>] paragraph 1</P>

<BLOCKQUOTE>

Each <I>decl-specifier</I> of the <I>decl-specifier-seq</I> of a
prospective destructor declaration (if any) shall be friend, inline,
virtual, constexpr, or consteval.

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-10-20):</B></P>

<P>Change in 11.4.7 [<A href="https://wg21.link/class.dtor#1">class.dtor</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Each <I>decl-specifier</I> of the <I>decl-specifier-seq</I> of a
prospective destructor declaration (if any) shall
be <TT>friend</TT>, <TT>inline</TT>, <TT>virtual</TT>, <INS>or</INS>
<TT>constexpr</TT><DEL>, or <TT>consteval</TT></DEL>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2823"></A><H4>2823.
  
Implicit undefined behavior when dereferencing pointers
</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>ready
 &#160;&#160;&#160;

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

 <B>Date: </B>2023-11-06


<P>Subclause 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#1">expr.unary.op</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

The unary * operator performs indirection. Its 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>

<P>It is unclear what happens if the operand does not point to an
object or function.</P>

<P><B>Proposed resolution (approved by CWG 2023-11-08):</B></P>

<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 * operator performs indirection. Its 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 <DEL>denoting
the object or function to which the operand points</DEL>. <INS>If the
operand points to an object or function, the result denotes that
object or function; otherwise, the behavior is undefined except as
specified in 7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>].</INS>

</BLOCKQUOTE>

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