<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 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  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;P2622R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2022-07-15</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
     July, 2022 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/2022/n4910.pdf">WG21 N4910</A>.
   </P>
<HR>
<A NAME="2355"></A><H4>2355.
  
Deducing <I>noexcept-specifier</I>s
</H4>
<B>Section: </B>13.10.3.6&#160; [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2017-09-06


<P>The list of deducible forms in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>] paragraph
8 does not include the ability to deduce the value of the constant in a
<I>noexcept-specifier</I>, although implementations appear to allow it.</P>

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

<P>Although this appears to be an obvious omission, CWG felt that EWG should
weigh in on whether this capability should be supported or not.</P>

<P><B>EWG guidance (January, 2021):</B></P>

<P>Modify the Standard such that the value of a constant in
a <I>noexcept-specifier</I> can be deduced.
See <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1018r8.html#CWG2355">vote</A>.</P>

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

<OL>
<LI><P>Change 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<P>A given type <TT>P</TT> can be composed from a number of
other types, templates, and non-type values:</P>

<UL>
<LI><P>A function type includes the types of each of the
function parameters<DEL> and</DEL><INS>,</INS> the return
type<INS>, and its exception specification</INS>.</P></LI>

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

</UL>

</BLOCKQUOTE>

<LI><P>Add the following to Example 3 in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
paragraph 7:</P></LI>

<BLOCKQUOTE>

<P>Here is an example where two template arguments are deduced
from a single function parameter/argument pair...</P>

<P><INS>Here is an example where the exception specification
of a function type is deduced:</INS></P>

<PRE>
<INS>  template &lt;bool E&gt; void f1(void (*)() noexcept(E));
  template&lt;bool&gt; struct A { };
  template&lt;bool B&gt; void f2(void (*)(A&lt;B&gt;) noexcept(B));

  void g1();
  void g2() noexcept;
  void g3(A&lt;true&gt;);

  void h() {
    f1(g1);    //<SPAN CLASS="cmnt"> OK: </SPAN>E<SPAN CLASS="cmnt"> is </SPAN>false
    f1(g2);    //<SPAN CLASS="cmnt"> OK: </SPAN>E<SPAN CLASS="cmnt"> is </SPAN>true
    f2(g3);    //<SPAN CLASS="cmnt"> error: </SPAN>B<SPAN CLASS="cmnt"> deduced as both </SPAN>true<SPAN CLASS="cmnt"> and </SPAN>false
  }</INS>
</PRE>

<P>Here is an example where a qualification conversion applies...</P>

</BLOCKQUOTE>

<LI><P>Change 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

A template type argument <TT>T</TT>, a template template
argument <TT>TT</TT><INS>,</INS> or a template non-type
argument <TT>i</TT> can be deduced if <TT>P</TT>
and <TT>A</TT> have one of the following forms:

<UL>
<DEL><TT>T</TT><BR></DEL>
<I>cv<INS><SUB><I>opt</I></SUB></INS></I> <TT>T</TT><BR>
<TT>T*</TT><BR>
<TT>T&amp;</TT><BR>
<TT>T&amp;&amp;</TT><BR>
<TT>T<INS><SUB><I>opt</I></SUB></INS>[</TT><DEL><I>integer-constant</I></DEL>
<INS><TT>i<SUB><I>opt</I></SUB></TT></INS><TT>]</TT><BR>
<DEL><I>template-name</I><TT>&lt;T&gt;</TT> (where <I>template-name</I> refers to a class template)<BR>
<I>type</I><TT>(T)</TT><BR>
<TT>T()</TT><BR></DEL>
<TT>T<INS><SUB><I>opt</I></SUB></INS>(T<INS><SUB><I>opt</I></SUB></INS>)<INS> noexcept(i<SUB><I>opt</I></SUB>)</INS></TT><BR>
<DEL><TT>T</TT> <I>type</I><TT>::*</TT><BR>
<I>type</I> <TT>T::*</TT><BR></DEL>
<TT>T<INS><SUB><I>opt</I></SUB></INS> T<INS><SUB><I>opt</I></SUB></INS>::*</TT><BR>
<DEL><TT>T (</TT><I>type</I><TT>::*)()</TT><BR>
<I>type</I> <TT>(T::*)()</TT><BR>
<I>type</I> <TT>(</TT><I>type</I><TT>::*)(T)</TT><BR>
<I>type</I> <TT>(T::*)(T)</TT><BR>
<TT>T (</TT><I>type</I><TT>::*)(T)</TT><BR>
<TT>T (T::*)()</TT><BR>
<TT>T (T::*)(T)</TT><BR></DEL>
<DEL><I>type</I><TT>[i]</TT><BR>
<I>template-name</I><TT>&lt;i&gt;</TT> (where <I>template-name</I> refers to a class template)<BR></DEL>
<TT>TT<INS><SUB><I>opt</I></SUB></INS>&lt;T&gt;</TT><BR>
<TT>TT<INS><SUB><I>opt</I></SUB></INS>&lt;i&gt;</TT><BR>
<INS><TT>TT<SUB><I>opt</I></SUB>&lt;TT&gt;</TT><BR></INS>
<TT>TT<INS><SUB><I>opt</I></SUB></INS>&lt;&gt;</TT><BR>
</UL>

<P>where <DEL><TT>(T)</TT> represents
a parameter-type-list (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>])
where at least one parameter type contains a <TT>T</TT>,
and <TT>()</TT> represents a parameter-type-list
where no parameter type contains a <TT>T</TT>.</DEL>

<UL>
<LI><P><INS><TT>T<SUB><I>opt</I></SUB></TT> represents a
type or parameter-type-list that either satisfies these rules
recursively, is a non-deduced context in <TT>P</TT> or
<TT>A</TT>, or is the same non-dependent type in <TT>P</TT>
and <TT>A</TT>,</INS></P></LI>

<LI><P><INS><TT>TT<INS><SUB><I>opt</I></SUB></INS></TT>
represents either a class template or a template template
parameter,</INS></P></LI>

<LI><P><INS><TT>i<SUB><I>opt</I></SUB></TT> represents an expression
that either is an <TT>i</TT>, is value-dependent in <TT>P</TT>
or <TT>A</TT>, or has the same constant value in <TT>P</TT> and
<TT>A</TT>, and</INS></P></LI>

<LI><P><INS><TT>noexcept(i<SUB><I>opt</I></SUB>)</TT> represents an
exception specification (14.5 [<A href="https://wg21.link/except.spec">except.spec</A>]) in which
the (possibly-implicit, see 9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>])
<I>noexcept-specifier</I>'s operand satisfies the rules for an
<TT>i<SUB><I>opt</I></SUB></TT> above.</INS></P></LI>

</UL>
</P>

<P><INS>[<I>Note:</I> If a type matches such a form but
contains no <TT>T</TT>s, <TT>i</TT>s, or <TT>TT</TT>s,
deduction is not possible. &#8212;<I>end note</I>]</INS></P>

<P>Similarly,
<TT>&lt;T&gt;</TT> represents template argument lists where
at least one argument contains
a <TT>T</TT>, <TT>&lt;i&gt;</TT> represents template
argument lists where at least one argument contains
an <TT>i</TT> and &lt;&gt; represents template argument
lists where no argument contains a <TT>T</TT>
or an <TT>i</TT>.</P>

</BLOCKQUOTE>

<LI><P>Add the following as a new paragraph following
13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>] paragraph 14:</P></LI>

<BLOCKQUOTE>

<P>The type of <TT>N</TT> in the type <TT>T[N]</TT>
is <TT>std::size_t</TT>.  [<I>Example 9:</I> ...
&#8212;<I>end example</I>]</P>

<P><INS>The type of <TT>B</TT> in the <I>noexcept-specifier</I>
<TT>noexcept(B)</TT> of a function type
is <TT>bool</TT>.<BR>
[<I>Example:</I></INS></P>

<PRE>
<INS>  template&lt;bool&gt; struct A { };
  template&lt;auto&gt; struct B;
  template&lt;auto X, void (*F)() noexcept(X)&gt; struct B&lt;F&gt; {
    A&lt;X&gt; ax;
  };
  void f_nothrow() noexcept;
  B&lt;f_nothrow&gt; bn;   //<SPAN CLASS="cmnt"> OK: type of </SPAN>X<SPAN CLASS="cmnt"> deduced as </SPAN>bool</INS>
</PRE>

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

</BLOCKQUOTE>

<LI><P>Change 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>] paragraph 19 as follows:</P></LI>

<BLOCKQUOTE>

If <TT>P</TT> has a form that contains <TT>&lt;i&gt;</TT>,
and if the type of <TT>i</TT> differs from the type of the
corresponding template parameter of the template named by
the enclosing <I>simple-template-id</I>, deduction fails. If
<TT>P</TT> has a form that contains <TT>[i]</TT>, and if the
type of <TT>i</TT> is not an integral type, deduction
fails.<SUP>131</SUP> <INS>If <TT>P</TT> has a form that includes
<TT>noexcept(i)</TT> and the type of <TT>i</TT> is not
<TT>bool</TT>, deduction fails.</INS><BR>
[<I>Example 12:</I> ...

</BLOCKQUOTE>

<LI><P>Add the following as a new section preceding
C.1.4 [<A href="https://wg21.link/diff.cpp20.library">diff.cpp20.library</A>]:</P></LI>

<BLOCKQUOTE>

<TABLE WIDTH="85%"><TR>
<TD><B>C.1.4 Clause 13: templates</B></TD>
<TD ALIGN="right"><B>[diff.cpp20.temp]</B></TD>
</TR></TABLE>

<P>
<B>Affected subclause:</B> 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]<BR>
<B>Change:</B> Deducing template arguments from exception
specifications.<BR>
<B>Rationale:</B> Facilitate generic handling of throwing and
non-throwing functions.<BR>
<B>Effect on original feature:</B> Valid ISO C++20 code may
be ill-formed in this revision of C++.<BR>
</P>
<P>[<I>Example 1:</I>
</P>
<PRE>
   template&lt;bool&gt; struct A { };
   template&lt;bool B&gt; void f(void (*)(A&lt;B&gt;) noexcept(B));
   void g(A&lt;false&gt;) noexcept;
   void h() {
     f(g);    //<SPAN CLASS="cmnt"> ill-formed; previously well-formed.</SPAN>
   }
</PRE>
<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR>
<A NAME="2405"></A><H4>2405.
  
Additional type-dependent expressions
</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>Andrey Davydov
 &#160;&#160;&#160;

 <B>Date: </B>2018-08-20


<P>According to 13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#3">temp.dep.expr</A>] paragraph 3,</P>

<BLOCKQUOTE>

<P>...Expressions of the
following forms are type-dependent only if the type
specified by
the <I>type-id</I>, <I>simple-type-specifier</I>
or <I>new-type-id</I> is dependent, even if any
subexpression is type-dependent:</P>

<UL>
<I>simple-type-specifier</I> <TT>(</TT> <I>expression-list</I> <TT>)</TT><BR>
<TT>::</TT><SUB><I>opt</I></SUB> <TT>new</TT> <I>new-placement<SUB>opt</SUB> new-type-id new-initializer<SUB>opt</SUB></I><BR>
<TT>::</TT><SUB><I>opt</I></SUB> <TT>new</TT> <I>new-placement<SUB>opt</SUB></I> <TT>(</TT> <I>type-id</I> <TT>)</TT> <I>new-initializer<SUB>opt</SUB></I><BR>
<TT>dynamic_cast &lt;</TT> <I>type-id</I> <TT>&gt; (</TT> <I>expression</I> <TT>)</TT><BR>
<TT>static_cast &lt;</TT> <I>type-id</I> <TT>&gt; (</TT> <I>expression</I> <TT>)</TT><BR>
<TT>const_cast &lt;</TT> <I>type-id</I> <TT>&gt; (</TT> <I>expression</I> <TT>)</TT><BR>
<TT>reinterpret_cast &lt;</TT> <I>type-id</I> <TT>&gt; (</TT> <I>expression</I> <TT>)</TT><BR>
<TT>(</TT> <I>type-id</I> <TT>)</TT> <I>cast-expression</I>
</UL>

</BLOCKQUOTE>

<P>This list is missing cases for:</P>

<UL>
<I>simple-type-specifier braced-init-list</I><BR>
<I>typename-specifier</I> <TT>(</TT> <I>expression-list<SUB>opt</SUB> <TT>)</TT><BR>
<I>typename-specifier braced-init-list</I>
</I>
</UL>

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

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

<BLOCKQUOTE>

Expressions of the following forms are type-dependent only if the type
specified by the <I>type-id</I>,
<I>simple-type-specifier</I><INS>, <I>typename-specifier</I>,</INS>
or <I>new-type-id</I> is dependent, even if any subexpression is
type-dependent:

<PRE>
<I>simple-type-specifier</I> ( <I>expression-list</I><SUB>opt</SUB> )
<INS><I>simple-type-specifier</I> <I>braced-init-list</I>
<I>typename-specifier</I> ( <I>expression-list</I><SUB>opt</SUB> )
<I>typename-specifier</I> <I>braced-init-list</I></INS>
...
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2507"></A><H4>2507.
  
Default arguments for <TT>operator[]</TT>
</H4>
<B>Section: </B>12.4.1&#160; [<A href="https://wg21.link/over.oper.general">over.oper.general</A>]
 &#160;&#160;&#160;

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

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

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


<P>The intent of paper P2128R6, which permitted multiple
parameters in overloaded subscript operators and was adopted
at the October, 2021 plenary, was that
overloaded <TT>operator[]</TT> should allow parameters with
default arguments. However, the adopted wording did not
address the following restriction from 12.4.1 [<A href="https://wg21.link/over.oper.general#10">over.oper.general</A>] paragraph 10:
</P>

<BLOCKQUOTE>

An operator function cannot have default arguments
(9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]), except where explicitly
stated below.

</BLOCKQUOTE>

<P>Similar wording to that of <TT>operator()</TT> should
be added for <TT>operator[]</TT>.</P>

<P><B>Proposed resolution (December, 2021):</B></P>

<P>Change 12.4.5 [<A href="https://wg21.link/over.sub#1">over.sub</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A <I>subscripting operator function</I> is a function
named <TT>operator[]</TT> that is a non-static member
function <INS>with an arbitrary number of parameters.
It may have default arguments</INS>. For an expression...

</BLOCKQUOTE>



<P><B>Approved by EWG 2022-04-14.</B></P>

<P><B>Approved by CWG 2022-04-22.</B></P>

<BR><BR><HR>
<A NAME="2534"></A><H4>2534.
  
Value category of pseudo-destructor expression
</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>Andrey Erokhin
 &#160;&#160;&#160;

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


<P>Subclause 7.6.1.5 [<A href="https://wg21.link/expr.ref#3">expr.ref</A>] paragraph 3 defines the value
category of a pseudo-destructor class member access expression to be
an lvalue:</P>

<BLOCKQUOTE>

Abbreviating <I>postfix-expression</I>.<I>id-expression</I> as E1.E2,
E1 is called the <I>object expression</I>. If the object expression is
of scalar type, E2 shall name the pseudo-destructor of that same type
(ignoring cv-qualifications) and E1.E2 is an lvalue of type
&#8220;function of () returning <TT>void</TT>&#8221;.

</BLOCKQUOTE>

This is inconsistent with the analogous situation naming the
destructor of a class.  In that case, the class member access
expression is a prvalue, not an lvalue, as specified in
7.6.1.5 [<A href="https://wg21.link/expr.ref#6.3">expr.ref</A>] bullet 6.3
(see also issue 2458):

<BLOCKQUOTE>

<UL>
<LI>If E2 is an overload set, 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. 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>]).</LI>
</UL>
</LI>
</UL>

</BLOCKQUOTE>

It also contradicts 7.2.1 [<A href="https://wg21.link/basic.lval#1.1">basic.lval</A>] bullet 1.1:

<BLOCKQUOTE>

<UL>
<LI>A <I>glvalue</I> is an expression whose evaluation determines the
identity of an object or function.</LI>
</UL>

</BLOCKQUOTE>

A pseudo-destructor does not have an identity.

<P><B>Proposed resolution (approved by CWG 2022-04-08):</B></P>

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

<BLOCKQUOTE>

If the object expression is of scalar type, E2 shall name the
pseudo-destructor of that same type (ignoring cv-qualifications) and
E1.E2 is <DEL>an lvalue</DEL> <INS>a prvalue</INS> of type
&#8220;function of () returning <TT>void</TT>&#8221;.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2535"></A><H4>2535.
  
Type punning in 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>Andrey Erokhin
 &#160;&#160;&#160;

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




<P>The initialization of <TT>j</TT> ought to have undefined behavior,
but the standard does not explicitly say so:</P>

<PRE>
  struct C { int m; };

  int i = 0;
  int j = reinterpret_cast&lt;C&amp;&gt;(i).m; //<SPAN CLASS="cmnt"> the same as </SPAN>int j = i<SPAN CLASS="cmnt"> ?</SPAN>
</PRE>

<P>A related case for pointer-to-member expressions is covered by
7.6.4 [<A href="https://wg21.link/expr.mptr.oper#4">expr.mptr.oper</A>] paragraph 4:</P>

<BLOCKQUOTE>

If the dynamic type of <TT>E1</TT> does not contain the member to
which <TT>E2</TT> refers, the behavior is undefined.

</BLOCKQUOTE>

<P>The invocation of non-static member functions is covered by
11.4.3 [<A href="https://wg21.link/class.mfct.non.static#2">class.mfct.non.static</A>] paragraph 2:</P>

<BLOCKQUOTE>

If a non-static member function of a class <TT>X</TT> is called for an
object that is not of type <TT>X</TT>, or of a type derived
from <TT>X</TT>, the behavior is undefined.

</BLOCKQUOTE>

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

<P>(updated according to 2022-05-20 and 2022-06-03 CWG guidance)</P>

<OL>
<LI>
<P>Add a new paragraph after 7.6.1.5 [<A href="https://wg21.link/expr.ref#7">expr.ref</A>] paragraph 7:</P>

<BLOCKQUOTE>

<P>If <TT>E2</TT> is a non-static <DEL>data member or a non-static</DEL>
member <DEL>function</DEL>, the program is ill-formed if the class of
which <TT>E2</TT> is directly a member is an ambiguous base
(6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]) of the naming class
(11.8.3 [<A href="https://wg21.link/class.access.base">class.access.base</A>]) of <TT>E2</TT>.  [Note: The program is also
ill-formed if the naming class is an ambiguous base of the class type
of the object expression; see
11.8.3 [<A href="https://wg21.link/class.access.base">class.access.base</A>]. &#8212;<I>end note</I> -- end note]</P>

<P>
<INS>If <TT>E2</TT> is a non-static member and the result
of <TT>E1</TT> is an object whose type is not similar
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]) to the type of <TT>E1</TT>, the behavior
is undefined. [ Example:</INS>
<PRE>
<INS>  struct A { int i; };
  struct B { int j; };
  struct D : A, B {};
  void f() {
    D d;
    static_cast&lt;B&amp;&gt;(d).j;       //<SPAN CLASS="cmnt"> OK, object expression designates the </SPAN>B<SPAN CLASS="cmnt"> subobject of</SPAN> d
    reinterpret_cast&lt;B&amp;&gt;(d).j;  //<SPAN CLASS="cmnt"> undefined behavior</SPAN>
  }</INS>
</PRE>
<INS>-- end example ]</INS>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.4 [<A href="https://wg21.link/expr.mptr.oper#4">expr.mptr.oper</A>] paragraph 4:</P>

<BLOCKQUOTE>

<DEL>If the dynamic type of <TT>E1</TT></DEL>

<INS>If the result of E1 is an object whose type is not similar to the
type of E1, or whose most derived object</INS>

does not contain the member to which E2 refers, the behavior is
undefined. <DEL>Otherwise, t</DEL> <INS>T</INS>he expression E1 is
sequenced before the expression E2.

</BLOCKQUOTE>
</LI>

<LI>
<P>Remove 11.4.3 [<A href="https://wg21.link/class.mfct.non.static#2">class.mfct.non.static</A>] paragraph 2:</P>

<BLOCKQUOTE>

<DEL>If a non-static member function of a class <TT>X</TT> is called for an
object that is not of type <TT>X</TT>, or of a type derived
from <TT>X</TT>, the behavior is undefined.</DEL>

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

<BR><BR><HR>
<A NAME="2540"></A><H4>2540.
  
Unspecified interpretation of <I>numeric-escape-sequence</I>
</H4>
<B>Section: </B>5.13.3&#160; [<A href="https://wg21.link/lex.ccon">lex.ccon</A>]
 &#160;&#160;&#160;

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

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

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


<P>Subclause 5.13.3 [<A href="https://wg21.link/lex.ccon">lex.ccon</A>] does not specify how the
characters in an <I>octal-escape-sequence</I>
or <I>hexadecimal-escape-sequence</I> are interpreted to obtain the
integer value <I>v</I> that is used in bullet 3.2:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
A <I>character-literal</I> with a <I>c-char-sequence</I> consisting of
a single <I>numeric-escape-sequence</I> that specifies an integer
value <I>v</I> has a value as follows:
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2022-03-11):</B></P>

<OL>
<LI>
Change in 5.13.3 [<A href="https://wg21.link/lex.ccon#3.2">lex.ccon</A>] bullet 3.2 as follows:

<BLOCKQUOTE>

<UL>
<LI>
A <I>character-literal</I> with a <I>c-char-sequence</I> consisting of
a single <I>numeric-escape-sequence</I> <DEL>that specifies an integer
value <I>v</I></DEL> has a value as follows:
<UL>
<LI><INS>Let <I>v</I> be the integer value represented by the octal
number comprising the sequence of <I>octal-digit</I>s in
an <I>octal-escape-sequence</I> or by the hexadecimal number
comprising the sequence of <I>hexadecimal-digit</I>s in
a <I>hexadecimal-escape-sequence</I>.</INS></LI>

<LI>If <I>v</I> does not exceed the range of representable values of
the character-literal's type, then the value is <I>v</I>.
</LI>
<LI>...</LI>
</UL>
</LI>

</UL>

</BLOCKQUOTE>
</LI>

<LI>
Change in 5.13.5 [<A href="https://wg21.link/lex.string#10.2">lex.string</A>] bullet 10.2 as follows:

<BLOCKQUOTE>

<UL>
<LI>
Each <I>numeric-escape-sequence</I> (5.13.3 [<A href="https://wg21.link/lex.ccon">lex.ccon</A>])
<DEL>that specifies an integer value <I>v</I></DEL> contributes a
single code unit with a value as follows:
<UL>
<LI><INS>Let <I>v</I> be the integer value represented by the octal
number comprising the sequence of <I>octal-digit</I>s in
an <I>octal-escape-sequence</I> or by the hexadecimal number
comprising the sequence of <I>hexadecimal-digit</I>s in
a <I>hexadecimal-escape-sequence</I>.</INS></LI>

<LI>If <I>v</I> does not exceed the range of representable values of
the <I>string-literal</I>'s array element type, then the value
is <I>v</I>.</LI>

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

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

<BR><BR><HR>
<A NAME="2571"></A><H4>2571.
  
Evaluation order for subscripting
</H4>
<B>Section: </B>7.6.1.2&#160; [<A href="https://wg21.link/expr.sub">expr.sub</A>]
 &#160;&#160;&#160;

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

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

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




<P>The specification about the relative sequencing of multiple
parameters of the subscripting operator is missing.  Also,
issue 2507 adds support for default
arguments for user-defined subscripting operators, but the sequencing
of these is unspecified, too.</P>

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

<P>Add a new paragraph 4 at the end of 7.6.1.2 [<A href="https://wg21.link/expr.sub">expr.sub</A>]:</P>

<BLOCKQUOTE>

<INS>If the subscript operator invokes an operator function, the
sequencing restrictions of the corresponding function call expression
apply (12.4.5 [<A href="https://wg21.link/over.sub">over.sub</A>],
7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]).</INS>

</BLOCKQUOTE>

<P><B>Notes from the 2022-05-20 CWG telecon:</B></P>

<P>A wording approach amending 12.2.2.3 [<A href="https://wg21.link/over.match.oper#2">over.match.oper</A>] paragraph 2
instead would be preferred.</P>

<P><U>Possible resolution (2022-05-21): [SUPERSEDED]</U></P>

<P>Change in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#2">over.match.oper</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Therefore, the operator notation is first transformed to the
equivalent function-call notation as summarized in Table 17 (where @
denotes one of the operators covered in the specified
subclause). However, <INS>except for the subscript operator
(7.6.1.2 [<A href="https://wg21.link/expr.sub">expr.sub</A>]),</INS> the operands are sequenced in
the order prescribed for the built-in operator
(7.6 [<A href="https://wg21.link/expr.compound">expr.compound</A>]).

</BLOCKQUOTE>

<P><B>Notes from the 2022-06-03 CWG telecon:</B></P>

<P>Repeating the function call rules for the subscript operator in
7.6.1.2 [<A href="https://wg21.link/expr.sub">expr.sub</A>] instead would be preferred, to
avoid any impression of a special case.</P>

<P><B>Proposed resolution (2022-06-24, amended 2022-07-15, approved by CWG 2022-07-15):</B></P>

<P>Change in 7.6.1.2 [<A href="https://wg21.link/expr.sub#1">expr.sub</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A <I>subscript expression</I> is a postfix expression followed by
square brackets containing a possibly empty, comma-separated list
of <I>initializer-clause</I>s <DEL>which</DEL> <INS>that</INS>
constitute the arguments to the subscript
operator. The <I>postfix-expression</I>
<INS>and the initialization of the object parameter of any applicable
subscript operator function</INS> is sequenced before each expression
in the <I>expression-list</I>
<INS>and also before any default argument.  The initialization of a
non-object parameter of a subscript operator function S
(12.4.5 [<A href="https://wg21.link/over.sub">over.sub</A>]), including every associated value
computation and side effect, is indeterminately sequenced with respect
to that of any other non-object parameter of S</INS>.
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2582"></A><H4>2582.
  
Differing member lookup from nested classes
</H4>
<B>Section: </B>6.5.2&#160; [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]
 &#160;&#160;&#160;

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

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

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




<P>Consider:</P>

<PRE>
  typedef int T;
  struct A {
   struct B {
    static T t;
   };
   typedef float T; //<SPAN CLASS="cmnt"> IFNDR?</SPAN>
  };
</PRE>

<P>Subclause 6.5.2 [<A href="https://wg21.link/class.member.lookup#6">class.member.lookup</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

The result of the search is the declaration set of S(N, T). If it is
an invalid set, the program is ill-formed. If it differs from the
result of a search in T for N from immediately after
the <I>class-specifier</I> of T, the program is ill-formed, no
diagnostic required.

</BLOCKQUOTE>

<P>It is unclear whether the lookup of <TT>T</TT> inside <TT>A::B</TT>
is subject to the "if it differs" rule, given that
the <I>class-specifier</I> of <TT>A::B</TT> ends before
introducing <TT>A::T</TT>.</P>

<P><B>Proposed resolution (approved by CWG 2022-05-06):</B></P>

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

<BLOCKQUOTE>

 If it differs from the result of a search in T for N <DEL>from
immediately after the <I>class-specifier</I></DEL> <INS>in a
complete-class context</INS> of T, the program is ill-formed, no
diagnostic required.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2585"></A><H4>2585.
  
Name lookup for coroutine allocation
</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>Xu Chuanqi
 &#160;&#160;&#160;

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




<P>Consider:</P>

<PRE>
  struct Allocator;

  struct resumable::promise_type {
    void* operator new(std::size_t sz, Allocator&amp;);
    //<SPAN CLASS="cmnt"> ...</SPAN>
  };
  resumable foo() {
    co_return;
  }
</PRE>

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

<BLOCKQUOTE>

... The allocation function's name is looked up by searching for it in the
scope of the promise type.
<UL>
<LI>If any declarations are found, overload resolution is performed on
a function call created by assembling an argument list. The first
argument is the amount of space requested, and has
type <TT>std::size_t</TT>.  The lvalues p1 . . . pn are the succeeding
arguments.
</LI>
<LI>Otherwise, a search is performed in the global scope.
</LI>
</UL>
If no viable function is found (12.2.3 [<A href="https://wg21.link/over.match.viable">over.match.viable</A>]), overload
resolution is performed again on a function call created by passing
just the amount of space required as an argument of
type <TT>std::size_t</TT>.

</BLOCKQUOTE>

<P>Is the example ill-formed because <TT>resumable::promise_type</TT>
is not viable, or is the example well-formed because the
global <TT>operator new</TT> can be used?  There is implementation
divergence.</P>

<P>See also <A HREF="https://github.com/llvm/llvm-project/issues/54881">LLVM issue 54881</A>.</P>

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

<P>(updated according to 2022-05-20, 2022-06-03, and 2022-06-17 CWG
guidance)</P>

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

<BLOCKQUOTE>

... The allocation function's name is looked up by searching for it in
the scope of the promise type.

<UL>
<LI>
If <INS>the search finds</INS> any declarations <DEL>are found</DEL>,
overload resolution is performed on a function call created
by assembling an argument list. The first argument is the amount of
space requested, and <DEL>has</DEL> <INS>is a prvalue of</INS> type <TT>std::size_t</TT>.  The lvalues p1
... pn are the <DEL>succeeding</DEL> <INS>successive</INS> arguments.
<DEL>Otherwise, a search is performed in the global scope.</DEL>
If no
viable function is found (12.2.3 [<A href="https://wg21.link/over.match.viable">over.match.viable</A>]), overload
resolution is performed again on a function call created by passing
just the amount of space required as <DEL>an argument</DEL> <INS>a prvalue</INS> of
type <TT>std::size_t</TT>.
</LI>

<LI>
<INS>If the search finds no declarations, a search is performed in
the global scope.  Overload resolution is performed on a function call
created by passing the amount of space required as a prvalue of
type <TT>std::size_t</TT>.</INS>
</LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2586"></A><H4>2586.
  
Explicit object parameter for assignment and comparison
</H4>
<B>Section: </B>11.10.1&#160; [<A href="https://wg21.link/class.compare.default">class.compare.default</A>]
 &#160;&#160;&#160;

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

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

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




<P>"Deducing this" allows to declare assignment and comparison
operator functions as explicit object member functions.</P>

<P>However, such an assignment operator can never be a copy or move
assignment operator, which means it always conflicts with the
implicitly-defined one:</P>

<PRE>
  struct C {
    C&amp; operator=(this C&amp;, C const&amp;); //<SPAN CLASS="cmnt"> error: can't overload with the copy assignment operator</SPAN>
  };
</PRE>

<P>Similarly, <TT>operator==</TT> or <TT>operator&lt;=&gt;</TT> can be
declared with an explicit object parameter, but they cannot be
defaulted:</P>

<PRE>
  struct D {
    bool operator==(this D const&amp;, D const&amp;) = default; //<SPAN CLASS="cmnt"> error: not a kind of comparison that can be defaulted</SPAN>
  };
</PRE>

<P>There seems to be no reason to disallow that, for people who prefer
writing all of their members with explicit object parameters.</P>

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

<OL>
<LI>
<P>Change in 11.4.6 [<A href="https://wg21.link/class.copy.assign#1">class.copy.assign</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A user-declared copy assignment operator <TT>X::operator=</TT> is a
non-static non-template member function of class <TT>X</TT> with exactly one
<INS>non-object</INS> parameter of
type <TT>X</TT>, <TT>X&amp;</TT>, <TT>const X&amp;</TT>, <TT>volatile
X&amp;</TT>, or <TT>const volatile X&amp;</TT>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.6 [<A href="https://wg21.link/class.copy.assign#3">class.copy.assign</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

A user-declared move assignment operator <TT>X::operator=</TT> is a
non-static non-template member function of class <TT>X</TT> with
exactly one <INS>non-object</INS> parameter of
type <TT>X&amp;&amp;</TT>, <TT>const X&amp;&amp;</TT>, <TT>volatile
X&amp;&amp;</TT>, or <TT>const volatile X&amp;&amp;</TT>.

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

A defaulted comparison operator function (12.4.3 [<A href="https://wg21.link/over.binary">over.binary</A>])
for some class C shall be a non-template function that is

<UL>
<LI>a non-static <DEL>const non-volatile</DEL> member <DEL>of C having
one parameter
of type const C&amp; and either no <I>ref-qualifier</I> or
the <I>ref-qualifier</I> &amp;, or</DEL>
<INS>or friend of C and</INS>
</LI>

<LI>
<DEL>a friend of C having</DEL> either <INS>has</INS> two
parameters of type <TT>const C&amp;</TT> or two parameters of
type <TT>C</TT>
<INS>, where the implicit object
parameter (if any) is considered to be the first parameter.</INS>.
</LI>
</UL>

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

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

<P>Forwarded to EWG with
<A HREF="https://github.com/cplusplus/papers/issues/1235">paper issue 1235</A>,
by decision of the CWG chair.
</P>

<P><B>Approved by EWG telecon 2022-06-09 and EWG 2022-06 electronic poll.</B></P>
<P>See
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1018r17.html#CWG2586">vote</A>.</P>


<P><B>Additional notes (July, 2022):</B></P>



<P>The suggested resolution makes the following a copy assignment
operator, suppressing the implicitly-declared one, which is
surprising:</P>

<PRE>
  struct B {
    B &amp;operator =(this int, const B &amp;); //<SPAN CLASS="cmnt"> copy assignment operator</SPAN>
  };
</PRE>

<P><B>Proposed resolution (approved by CWG 2022-07-15):</B></P>

<OL>
<LI>
<P>Change in 9.5.2 [<A href="https://wg21.link/dcl.fct.def.default#2">dcl.fct.def.default</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<DEL>The type T1 of an</DEL> <INS>An</INS> explicitly defaulted special member
function <DEL>F</DEL> <INS>F1 with type T1</INS> is allowed to differ from the
<INS>corresponding special member function F2 with</INS>
type T2 <DEL>it would have had if it were</DEL>
<INS>that would have been</INS> implicitly declared, as follows:
<UL>
<LI>T1 and T2 may have differing <I>ref-qualifier</I>s;</LI>
<LI><INS>if F2 has an implicit object parameter of type "reference
to <TT>C</TT>", F1 may be an explicit object member function whose
explicit object parameter is of type "reference
to <TT>C</TT>";</INS></LI>
<LI>T1 and T2 may have differing exception specifications; and</LI>
<LI>if <DEL>T2</DEL> <INS>F2</INS> has a <INS>non-object</INS>
parameter of type <TT>const C&amp;</TT>, the
corresponding <INS>non-object</INS> parameter
of <DEL>T1</DEL> <INS>F1</INS> may be of type <TT>C&amp;</TT>.</LI>
</UL>
If T1 differs from T2 in <DEL>any other</DEL> <INS>a</INS>
way <INS>other than as allowed by the preceding rules</INS>,
then:
<UL>
<LI>if <DEL>F</DEL> <INS>F1</INS> is an assignment operator, and the
return type of T1 differs from the return type of T2 or
<DEL>T1</DEL> <INS>F1</INS>'s <INS>non-object</INS> parameter type is
not a reference, the program is ill-formed;</LI>
<LI>
otherwise, if <DEL>F</DEL> <INS>F1</INS> is explicitly defaulted on its
first declaration, it is defined as deleted;</LI>
<LI>otherwise, the program is ill-formed.</LI>
</UL>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

A user-declared copy assignment operator <TT>X::operator=</TT> is a
non-static non-template member function of class <TT>X</TT> with

exactly one
<INS>non-object</INS> parameter of
type <TT>X</TT>, <TT>X&amp;</TT>, <TT>const X&amp;</TT>, <TT>volatile
X&amp;</TT>, or <TT>const volatile X&amp;</TT>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.6 [<A href="https://wg21.link/class.copy.assign#3">class.copy.assign</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

A user-declared move assignment operator <TT>X::operator=</TT> is a
non-static non-template member function of class <TT>X</TT> with

exactly one <INS>non-object</INS> parameter of
type <TT>X&amp;&amp;</TT>, <TT>const X&amp;&amp;</TT>, <TT>volatile
X&amp;&amp;</TT>, or <TT>const volatile X&amp;&amp;</TT>.

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

A defaulted comparison operator function (12.4.3 [<A href="https://wg21.link/over.binary">over.binary</A>])
for some class C shall be a non-template function that is

<UL>
<LI>a non-static <DEL>const non-volatile</DEL> member <DEL>of C having
one parameter
of type const C&amp; and either no <I>ref-qualifier</I> or
the <I>ref-qualifier</I> &amp;, or</DEL>
<INS>or friend of C and</INS>
</LI>

<LI>
<DEL>a friend of C having</DEL> either <INS>has</INS> two
parameters of type <TT>const C&amp;</TT> or two parameters of
type <TT>C</TT>
<INS>, where the implicit object
parameter (if any) is considered to be the first parameter.</INS>.
</LI>
</UL>

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

<BR><BR><HR>
<A NAME="2594"></A><H4>2594.
  
Disallowing a global function template <TT>main</TT>
</H4>
<B>Section: </B>6.9.3.1&#160; [<A href="https://wg21.link/basic.start.main">basic.start.main</A>]
 &#160;&#160;&#160;

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

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

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


<P>Consider:</P>

<PRE>
  template&lt;class T&gt;
  int main(T) {}
</PRE>

<P>C++20 specified in 6.9.3.1 [<A href="https://wg21.link/basic.start.main#2">basic.start.main</A>] paragraph 2:</P>

<BLOCKQUOTE>

An implementation shall not predefine the main function. This function
shall not be overloaded.

</BLOCKQUOTE>

<P>While it is unclear what "overloaded" means when multiple
translation units are involved, it arguably disallowed function
templates called <TT>main</TT>.  This prohibition was removed with
P1787R6 (Declarations and where to find them).</P>

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

<P>Change in 6.9.3.1 [<A href="https://wg21.link/basic.start.main#3">basic.start.main</A>] paragraph 3 and add bullets as
follows:</P>

<BLOCKQUOTE>

... A program that declares
<UL>
<LI>a variable <TT>main</TT> that belongs to the global scope, or</LI>

<LI>
<DEL>that declares</DEL> a function <TT>main</TT> that belongs to
the global scope and is attached to a named module, or</LI>

<LI><INS>a function template <TT>main</TT> that belongs to the global
scope, or</INS></LI>

<LI>
<DEL>that declares</DEL> an entity named <TT>main</TT> with C
language linkage (in any namespace)</LI>
</UL>
is ill-formed. The name <TT>main</TT> is not otherwise reserved.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2597"></A><H4>2597.
  
Replaceable allocation and deallocation functions in the global module
</H4>
<B>Section: </B>10.1&#160; [<A href="https://wg21.link/module.unit">module.unit</A>]
 &#160;&#160;&#160;

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

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

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




<P>Subclause 10.1 [<A href="https://wg21.link/module.unit#7">module.unit</A>] paragraph 7 implicitly attaches
the replaceable global allocation or deallocation functions to the global
module.  Now that <TT>extern "C++"</TT> can be used to introduce
declarations in the global module, even when in the purview of a named
module, the provision seems superfluous.</P>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<OL>
<LI>
<P>Change in 6.7.5.5.1 [<A href="https://wg21.link/basic.stc.dynamic.general#2">basic.stc.dynamic.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

The library provides default definitions for the global allocation and
deallocation functions. Some global allocation and deallocation
functions are replaceable (17.6.3 [<A href="https://wg21.link/new.delete">new.delete</A>]). A C++ program
shall provide at most one definition of a replaceable allocation or
deallocation function. Any such function definition replaces the
default version provided in the library
(16.4.5.6 [<A href="https://wg21.link/replacement.functions">replacement.functions</A>]). The following allocation and
deallocation functions (17.6 [<A href="https://wg21.link/support.dynamic">support.dynamic</A>]) are implicitly
declared in global scope in each translation unit of a
program <INS>and are attached to the global module
(10.1 [<A href="https://wg21.link/module.unit">module.unit</A>])</INS>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 10.1 [<A href="https://wg21.link/module.unit#7.2">module.unit</A>] bullet 7.2 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>If the declaration is ...</LI>

<LI>Otherwise, if the declaration
<UL>
<LI>
<DEL>is a replaceable global allocation or deallocation function
(17.6.3.2 [<A href="https://wg21.link/new.delete.single">new.delete.single</A>], 17.6.3.3 [<A href="https://wg21.link/new.delete.array">new.delete.array</A>]), or</DEL>
</LI>

<LI>is a <I>namespace-definition</I> with external linkage<DEL>,</DEL> or
</LI>

<LI>appears within a <I>linkage-specification</I>
<INS>(9.11 [<A href="https://wg21.link/dcl.link">dcl.link</A>])</INS><DEL>,</DEL>
</LI>
</UL>
it is attached
to the global module.
</LI>

<LI>Otherwise, ...</LI>
</UL>

</BLOCKQUOTE>

</LI>
</OL>

<P><B>Additional notes (June, 2022):</B></P>
<P>Forwarded to EWG with
<A HREF="https://github.com/cplusplus/papers/issues/1273">paper issue 1273</A>,
by decision of the CWG chair.
</P>

<P><B>Approved by EWG telecon 2022-07-07.</B></P>

<P><B>Proposed resolution (approved by CWG 2022-07-15):</B></P>

<OL>
<LI>
<P>Change in 6.7.5.5.1 [<A href="https://wg21.link/basic.stc.dynamic.general#2">basic.stc.dynamic.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

The library provides default definitions for the global allocation and
deallocation functions. Some global allocation and deallocation
functions are replaceable (17.6.3 [<A href="https://wg21.link/new.delete">new.delete</A>])
<INS>; these are attached to the global module 10.1 [<A href="https://wg21.link/module.unit">module.unit</A>])</INS>.
A C++ program
shall provide at most one definition of a replaceable allocation or
deallocation function. Any such function definition replaces the
default version provided in the library
(16.4.5.6 [<A href="https://wg21.link/replacement.functions">replacement.functions</A>]). The following allocation and
deallocation functions (17.6 [<A href="https://wg21.link/support.dynamic">support.dynamic</A>]) are implicitly
declared in global scope in each translation unit of a
program.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 10.1 [<A href="https://wg21.link/module.unit#7.2">module.unit</A>] bullet 7.2 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>If the declaration is ...</LI>

<LI>Otherwise, if the declaration
<UL>
<LI>
<DEL>is a replaceable global allocation or deallocation function
(17.6.3.2 [<A href="https://wg21.link/new.delete.single">new.delete.single</A>], 17.6.3.3 [<A href="https://wg21.link/new.delete.array">new.delete.array</A>]), or</DEL>
</LI>

<LI>is a <I>namespace-definition</I> with external linkage<DEL>,</DEL> or
</LI>

<LI>appears within a <I>linkage-specification</I>
<INS>(9.11 [<A href="https://wg21.link/dcl.link">dcl.link</A>])</INS><DEL>,</DEL>
</LI>
</UL>
it is attached
to the global module.
</LI>

<LI>Otherwise, ...</LI>
</UL>

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="2606"></A><H4>2606.
  
<TT>static_cast</TT> from "pointer to void" does not handle similar types
</H4>
<B>Section: </B>7.6.1.9&#160; [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
 &#160;&#160;&#160;

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

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

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


<P>Consider:</P>

<PRE>
  struct S {
    int a[5];
  } s;
  int (*p)[] = reinterpret_cast&lt;int(*)[]&gt;(&amp;s);
  int n = (*p)[0];
</PRE>

<P>This ought to have defined behavior: a pointer to <TT>s</TT> and a
pointer to <TT>s.a</TT> are pointer-interconvertible, so you should be
able to navigate between them this way. But the cast as shown does not
work, because the type of the pointer-interconvertible object
is <TT>int[5]</TT>, not <TT>int[]</TT>.</P>

<P><B>Proposed resolution (approved by CWG 2022-07-01):</B></P>

<P>Change in 7.6.1.9 [<A href="https://wg21.link/expr.static.cast#13">expr.static.cast</A>] paragraph 13 as follows:</P>

<BLOCKQUOTE>

... Otherwise, if the original pointer value points to an object a,
and there is an object b of type <INS>similar
to</INS> <TT>T</TT> <DEL>(ignoring cv-qualification)</DEL> that is
pointer-interconvertible (6.8.3 [<A href="https://wg21.link/basic.compound">basic.compound</A>]) with a, the
result is a pointer to b. Otherwise, the pointer value is unchanged by
the conversion.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2608"></A><H4>2608.
  
Omitting an empty template argument list
</H4>
<B>Section: </B>13.10.2&#160; [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Anoop Rana
 &#160;&#160;&#160;

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




<P>Subclause 13.10.2 [<A href="https://wg21.link/temp.arg.explicit#4">temp.arg.explicit</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

Trailing template arguments that can be deduced
(13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]) or obtained from
default <I>template-argument</I>s may be omitted from the list of
explicit <I>template-argument</I>s.
<br>

[<I>Note 1:</I> A trailing template parameter pack
(13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]) not otherwise deduced will be deduced as
an empty sequence of template arguments. &#8212;<I>end note</I>]
<br>

If all of the template arguments can be deduced, they may all be
omitted; in this case, the empty template argument list &lt;&gt;
itself may also be omitted.

</BLOCKQUOTE>

<P>The wording does not allow omitting the empty template argument
list &lt;&gt; if all of the template arguments have been obtained from
default <I>template-argument</I>s.  For example:</P>

<PRE>
  template&lt;typename T = int&gt;
  int f();

  int x = f();      //<SPAN CLASS="cmnt"> ill-formed per the wording</SPAN>
  int (*y)() = f;   //<SPAN CLASS="cmnt"> ditto</SPAN>
</PRE>

<P><B>Proposed resolution (approved by CWG 2022-07-15):</B></P>

<P>Change in 13.10.2 [<A href="https://wg21.link/temp.arg.explicit#4">temp.arg.explicit</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

... If all of the template arguments can be deduced <INS>or obtained
from default <I>template-argument</I>s</INS>, they may all be omitted;
in this case, the empty template argument list &lt;&gt; itself may
also be omitted.

</BLOCKQUOTE>

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