<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core "NB" 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 }
  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;P2710R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2022-11-11</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Project:
     </TD>
<TD>
      &#160;Programming Language C++
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reference:
     </TD>
<TD>
      &#160;ISO/IEC IS 14882: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 NB comment resolutions 
     for the
     November, 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/n4917.pdf">WG21 N4917</A>.
   </P>
<HR>
<A NAME="2242"></A><H4>2242.
  
ODR violation with constant initialization possibly omitted
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US5-033">P2720R0 comment
  US&#160;5-033<BR></A>

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

<PRE>
  //<SPAN CLASS="cmnt"> tu1.cpp</SPAN>
  extern const int a = 1;
  inline auto f() {
    static const int b = a;
    struct A { auto operator()() { return &amp;b; } } a;
    return a;
  }

  //<SPAN CLASS="cmnt"> tu2.cpp</SPAN>
  extern const int a;
  inline auto f() {
    static const int b = a;
    struct A { auto operator()() { return &amp;b; } } a;
    return a;
  }
  int main() {
    return *decltype(f())()();
  }
</PRE>

<P>Here, <TT>b</TT> may or may not have constant initialization.
This example should be an ODR violation.</P>

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

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

<P>Insert after 6.3 [<A href="https://wg21.link/basic.def.odr#14.7">basic.def.odr</A>] bullet 14.7 as follows:</P>

<UL>

<LI>...</LI>

<LI>In each such definition, corresponding entities shall
have the same language linkage.
</LI>

<LI><INS>In each such definition, const objects with static or thread
storage duration shall be constant-initialized if the object is
constant-initialized in any such definition.</INS></LI>

<LI>...</LI>

</UL>

<BR><BR><HR>
<A NAME="2538"></A><H4>2538.
  
Can standard attributes be syntactically ignored?
</H4>
<B>Section: </B>9.12.1&#160; [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#GB055">P2720R0 comment
  GB&#160;055<BR></A>



<P>Subclause 9.12.1 [<A href="https://wg21.link/dcl.attr.grammar#6">dcl.attr.grammar</A>] paragraph 6 specifies
that an unrecognized <I>attribute-token</I> is ignored:</P>

<BLOCKQUOTE>

For an <I>attribute-token</I> (including an
<I>attribute-scoped-token</I>) not specified in this document, the
behavior is implementation-defined. Any <I>attribute-token</I> that is
not recognized by the implementation is ignored.

</BLOCKQUOTE>

<P>The intent is that only non-standard
unrecognized <I>attribute-token</I>s can be ignored; in particular, an
implementation is required to syntax-check all standard attributes,
even if the implementation then chooses not to effect any semantics
for that attribute.</P>

<P>The paper introducing attributes was
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf">N2761</A>;
the phrasing in question was introduced by
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0283r2.html">P0283R2</A>
attempting to implement the design change presented in
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0283r1.pdf">P0283R1</A>.
</P>

<P>See also paper
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2552r0.pdf">P2552</A>
(On the ignorability of standard attributes).</P>

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

<P>Change in 9.12.1 [<A href="https://wg21.link/dcl.attr.grammar#6">dcl.attr.grammar</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

For an <I>attribute-token</I> (including an
<I>attribute-scoped-token</I>) not specified in this document, the
behavior is implementation-defined<DEL>. Any</DEL> <INS>; any such</INS>
<I>attribute-token</I> that is not recognized by the implementation
is ignored.

</BLOCKQUOTE>

<P><B>EWG telecon 2022-05-26</B></P>

<P>See <A HREF="https://github.com/cplusplus/papers/issues/1252">paper
issue 1252</A>.
</P>

<P>There was consensus for the statement "It is EWG's intent that
[dcl.attr]/6 ONLY permits an implementation to ignore a standard
attribute's effect, but not appertainment and argument parsing." To be
confirmed by electronic polling.</P>

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

<P>Change in 9.12.1 [<A href="https://wg21.link/dcl.attr.grammar#6">dcl.attr.grammar</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

For an <I>attribute-token</I> (including an
<I>attribute-scoped-token</I>) not specified in this document, the
behavior is implementation-defined<DEL>. Any</DEL> <INS>; any such</INS>
<I>attribute-token</I> that is not recognized by the implementation
is ignored.
<INS>[ Note: A program is ill-formed if it contains
an <I>attribute</I> specified in 9.12 [<A href="https://wg21.link/dcl.attr">dcl.attr</A>] that
violates the rules to which entity or statement the attribute may
apply or the syntax rules for the
attribute's <I>attribute-argument-clause</I>, if any.  -- end note
]</INS>
</BLOCKQUOTE>

<P><B>EWG 2022-06 electronic polling</B></P>

<P>No consensus. See
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1018r17.html#CWG2538">vote</A>.</P>

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

<P>Approved the direction of the 2022-07-01 proposed resolution.</P>


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

<P>Change in 9.12.1 [<A href="https://wg21.link/dcl.attr.grammar#6">dcl.attr.grammar</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

For an <I>attribute-token</I> (including an
<I>attribute-scoped-token</I>) not specified in this document, the
behavior is implementation-defined<DEL>. Any</DEL> <INS>; any such</INS>
<I>attribute-token</I> that is not recognized by the implementation
is ignored.
<INS>[ Note: A program is ill-formed if it contains
an <I>attribute</I> specified in 9.12 [<A href="https://wg21.link/dcl.attr">dcl.attr</A>] that
violates the rules specifying to which entity or statement the attribute may
apply or the syntax rules for the
attribute's <I>attribute-argument-clause</I>, if any.  -- end note
]</INS>
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2615"></A><H4>2615.
  
Missing <TT>__has_cpp_attribute(assume)</TT>
</H4>
<B>Section: </B>15.2&#160; [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>S. B. Tam
 &#160;&#160;&#160;

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#GB070">P2720R0 comment
  GB&#160;070<BR></A>

<P>Paper P1774R8 (accepted in July, 2022) adds a new
attribute <TT>assume</TT>, but neglects to update table 22 in
15.2 [<A href="https://wg21.link/cpp.cond">cpp.cond</A>].</P>

<P><B>Proposed resolution (accepted by CWG 2022-08-26):</B></P>

<P>In 15.2 [<A href="https://wg21.link/cpp.cond">cpp.cond</A>], add a row to table tab:cpp.cond.ha as
follows:</P>

<BLOCKQUOTE>

<TABLE>
<TR>
<TH>Attribute</TH>
<TH>Value</TH>
</TR>

<TR>
<TD><INS><TT>assume</TT></INS></TD> <TD><INS><TT>202207L</TT></INS></TD>
</TR>
</TABLE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2621"></A><H4>2621.
  
Kind of lookup for <TT>using enum</TT> declarations
</H4>
<B>Section: </B>9.7.2&#160; [<A href="https://wg21.link/enum.udecl">enum.udecl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Sean Baxter
 &#160;&#160;&#160;

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#CA054">P2720R0 comment
  CA&#160;054<BR></A>

<P>Consider:</P>

<PRE>
enum class E {
  a, b, c
};

using MyE = E;

int main() {
  using enum MyE;   //<SPAN CLASS="cmnt"> #1</SPAN>
}
</PRE>

<P>Does the lookup for the <I>elaborated-enum-specifier</I> at #1 use
type-only lookup per 6.5.6 [<A href="https://wg21.link/basic.lookup.elab">basic.lookup.elab</A>]?  There is
implementation divergence; EDG, gcc, and MSVC accept, clang rejects.</P>

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

<P>Change in 9.7.2 [<A href="https://wg21.link/enum.udecl#1">enum.udecl</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<INS>Lookup for the <I>elaborated-enum-specifier</I> is as specified
in 6.5.6 [<A href="https://wg21.link/basic.lookup.elab">basic.lookup.elab</A>].</INS>
The <I>elaborated-enum-specifier</I> shall not name a dependent type
and the type shall have a reachable <I>enum-specifier</I>.

</BLOCKQUOTE>

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

<P>The example at #1 is intended to be valid; even though the grammar
suggests that an <I>elaborated-type-specifier</I> is used here, an
ordinary (not a type-only) lookup is performed.</P>

<P><B>Proposed resolution (approved by CWG 2022-09-23) [SUPERSEDED]:</B></P>

<P>Change in 9.7.2 [<A href="https://wg21.link/enum.udecl#1">enum.udecl</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<INS>The terminal name of the <I>elaborated-enum-specifier</I>
undergoes ordinary lookup (6.5.3 [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>],
6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>]).</INS>
The <I>elaborated-enum-specifier</I> shall not name a dependent type
and the type shall have a reachable <I>enum-specifier</I>.

</BLOCKQUOTE>

<P><B>CWG 2022-11-07:</B></P>

<P>Use the wording approach presented in CA-054, with necessary
adjunct fixes.</P>

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

<P>Change the grammar before 9.2.9.4 [<A href="https://wg21.link/dcl.type.elab#1">dcl.type.elab</A>] paragraph 1 as
follows, merging the grammar productions:</P>

<BLOCKQUOTE>

<PRE>
<I>elaborated-type-specifier :
    class-key attribute-specifier-seq<SUB>opt</SUB> nested-name-specifier<SUB>opt</SUB> identifier
    class-key simple-template-id
    class-key nested-name-specifier template<SUB>opt</SUB> simple-template-id</I>
    <DEL><I>elaborated-enum-specifier
    
elaborated-enum-specifier :</I></DEL>
    enum <I>nested-name-specifier<SUB>opt</SUB> identifier</I>
</PRE>

</BLOCKQUOTE>

<P>Change the grammar before 9.7.2 [<A href="https://wg21.link/enum.udecl#1">enum.udecl</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<PRE>
<I>using-enum-declaration:</I>
    using <DEL><I>elaborated-enum-specifier</I></DEL> <INS>enum <I>using-enum-declarator</I></INS> ;

<INS><I>using-enum-declarator:
    nested-name-specifier<SUB>opt</SUB> identifier
    nested-name-specifier<SUB>opt</SUB> simple-template-id</I></INS>
</PRE>

</BLOCKQUOTE>

<P>Change in 9.7.2 [<A href="https://wg21.link/enum.udecl#1">enum.udecl</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<INS>A <I>using-enum-declarator</I> names the set of declarations
found by lookup (6.5.3 [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>],
6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>]) for
the <I>using-enum-declarator</I>.</INS>
The <DEL><I>elaborated-enum-specifier</I></DEL>
<INS><I>using-enum-declarator</I></INS> shall
<DEL>not name a dependent</DEL> <INS>designate a non-dependent</INS>
type <DEL>and the type shall have</DEL> <INS>with</INS> a
reachable <I>enum-specifier</I>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2631"></A><H4>2631.
  
Immediate function evaluations in default arguments
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

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




<P>Consider:</P>

<PRE>
consteval int const_div(int a, int b) { return a / b; }
int func(int x = const_div(10, 0));
</PRE>

<P>According to 7.7 [<A href="https://wg21.link/expr.const#14">expr.const</A>] paragraph 14:</P>

<BLOCKQUOTE>

An expression or conversion is an <I>immediate invocation</I> if it is a
potentially-evaluated explicit or implicit invocation of an immediate
function and is not in an immediate function context. An immediate
invocation shall be a constant expression.

</BLOCKQUOTE>

<P>Subclause 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#5">dcl.fct.default</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

The default argument has the same semantic constraints as the
initializer in a declaration of a variable of the parameter type,
using the copy-initialization semantics
(9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]). The names in the default argument are
looked up, and the semantic constraints are checked, at the point
where the default argument appears. Name lookup and checking of
semantic constraints for default arguments of templated functions are
performed as described in 13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>].

</BLOCKQUOTE>

<P>Checking the semantic constraints of the default argument appears
to include a check whether the immediate invocation
of <TT>const_div</TT> is actually a constant expression, even though
the default argument's value might never actually be used for any
function call in the program.</P>

<P>However, instantiation of a consteval function template to be able
to perform the constant evaluation is not permitted per
13.9.2 [<A href="https://wg21.link/temp.inst#11">temp.inst</A>] paragraph 11:</P>

<BLOCKQUOTE>

... The use of a template specialization in a default argument shall
not cause the template to be implicitly instantiated except that a
class template may be instantiated where its complete type is needed
to determine the correctness of the default argument. The use of a
default argument in a function call causes specializations in the
default argument to be implicitly instantiated.

</BLOCKQUOTE>

<P>Example 2:</P>

<PRE>
constexpr int g();
consteval int f() {
  return g();
}

int k(int x = f()) {  //<SPAN CLASS="cmnt"> error: constexpr evaluation of undefined function </SPAN>g
  return x;
}

constexpr int g() {
  return 42;
}

int main() {
  return k();
}
</PRE>

<P>Example 3:</P>

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

consteval int const_div(int a, int b) {
  return a / b;
}

#line 5
void foo(int x = const_div(1000, std::source_location::current().line() - 15)) {
  std::cout &lt;&lt; x &lt;&lt; "\n";
}

//<SPAN CLASS="cmnt"> Should the definition of `bar` produce errors? (division by zero during constant</SPAN>
//<SPAN CLASS="cmnt"> evaluation for constraint checking)</SPAN>
#line 10
void bar(int x = const_div(1000, std::source_location::current().line() - 10)) {
  std::cout &lt;&lt; x &lt;&lt; "\n";
}

int main() {
  //<SPAN CLASS="cmnt"> Should this call produce errors? (division by zero during constant</SPAN>
  //<SPAN CLASS="cmnt"> evaluation of the default argument)</SPAN>
  #line 15
  foo();
  #line 20
  bar();
}
</PRE>

<P>Note that <TT>source_location::current()</TT> is specified to take
its value from the location where it is evaluated, if it appears in a
default argument (17.8.2.2 [<A href="https://wg21.link/support.srcloc.cons#2">support.srcloc.cons</A>] paragraph 2):</P>

<BLOCKQUOTE>

<I>Remarks:</I> Any call to current that appears as a default member
initializer (11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]), or as a subexpression
thereof, should correspond to the location of the constructor
definition or aggregate initialization that uses the default member
initializer. Any call to current that appears as a default argument
(9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]), or as a subexpression thereof, should
correspond to the location of the invocation of the function that uses
the default argument (7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]).

</BLOCKQUOTE>

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

<OL>
<LI>

<P>Split 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#5">dcl.fct.default</A>] paragraph 5
and change as follows:</P>

<BLOCKQUOTE>

<P>The default argument has the same semantic constraints as the
initializer in a declaration of a variable of the parameter type,
using the copy-initialization semantics (9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).
</P>

<P>
<INS>A <I>default argument context</I> is</INS>
<UL>
<LI><INS>the <I>initializer-clause</I> in
a <I>parameter-declaration</I>, including any conversions to the
parameter type,</INS></LI>
<LI><INS>a subexpression of one of the above that is not a
subexpression of a nested unevaluated operand.</INS></LI>
</UL>

The names in the default argument are looked up, and the semantic
constraints are checked, at the point where the default argument
appears<INS>, except that an immediate invocation
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) in a default argument context is neither
evaluated nor checked for whether it is a constant expression at that
point</INS>.  Name lookup and checking of semantic constraints for
default arguments of templated functions are performed as described in
13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>].</P>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#11">temp.inst</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

... The use of a template specialization in a default argument shall
not cause the template to be implicitly instantiated except that a
class template <INS>or a function template with a deduced return
type</INS> may be instantiated where its complete type is needed to
determine the correctness of the default argument.  The use of a
default argument in a function call causes specializations in the
default argument to be implicitly instantiated.

</BLOCKQUOTE>

</LI>
</OL>

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

<P><U>Amendment to also cover default member initializers (October, 2022) [SUPERSEDED]:</U></P>

<OL>
<LI>

<P>Split 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#5">dcl.fct.default</A>] paragraph 5
and change as follows:</P>

<BLOCKQUOTE>

<P>The default argument has the same semantic constraints as the
initializer in a declaration of a variable of the parameter type,
using the copy-initialization semantics (9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).
</P>

<P>
<INS>A <I>default argument context</I> of an <I>initializer</I> is</INS>
<UL>
<LI><INS>the <I>initializer</I>, including any conversions to the
target type, or</INS></LI>
<LI><INS>a subexpression thereof that is not a
subexpression of a nested unevaluated operand.</INS></LI>
</UL>

The names in the default argument are looked up, and the semantic
constraints are checked, at the point where the default argument
appears<INS>, except that an immediate invocation
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) in a default argument context of
the <I>initializer-clause</I> in a <I>parameter-declaration</I> is
neither evaluated nor checked for whether it is a constant expression
at that point</INS>.  Name lookup and checking of semantic constraints
for default arguments of templated functions are performed as
described in 13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>].</P>

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

A <I>brace-or-equal-initializer</I> for a non-static data member
specifies a <I>default member initializer</I> for the member, and
shall not directly or indirectly cause the implicit definition of a
defaulted default constructor for the enclosing class or the exception
specification of that constructor.

<INS>An immediate invocation (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) in a default
argument context (9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]) of a default member
initializer is neither evaluated nor checked for whether it is a
constant expression at the point where it appears.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#11">temp.inst</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

... The use of a template specialization in a default argument shall
not cause the template to be implicitly instantiated except that a
class template <INS>or a function template with a deduced return
type</INS> may be instantiated where its complete type is needed to
determine the correctness of the default argument.  The use of a
default argument in a function call causes specializations in the
default argument to be implicitly instantiated.

</BLOCKQUOTE>

</LI>

</OL>

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

<P>The new term should be defined in 6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]
without reference to immediacy.</P>

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

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

<BLOCKQUOTE>

A <I>subexpression</I> of an expression E is an immediate subexpression of E
or a subexpression of an immediate subexpression of E. [ Note: ... -- end note ]

</BLOCKQUOTE>

<BLOCKQUOTE class="ins">
The <I>potentially-evaluated subexpressions</I> of an expression,
conversion, or <I>initializer</I> <TT>E</TT> are

<UL>
<LI>the constituent expressions of <TT>E</TT> and</LI>
<LI>the subexpressions thereof that are not subexpressions of a nested
unevaluated operand (7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]).</LI>

</UL>

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

An expression or conversion is <I>potentially constant evaluated</I> if it
is:
<UL>
<LI>...</LI>
<LI>a <INS>potentially-evaluated</INS> subexpression
(6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of one of the above<DEL> that is not a
subexpression of a nested unevaluated operand
(7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>])</DEL>.</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>

<P>Change in 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#5">dcl.fct.default</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P>The default argument has the same semantic constraints as the
initializer in a declaration of a variable of the parameter type,
using the copy-initialization semantics (9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).
The names in the default argument are looked up, and the semantic
constraints are checked, at the point where the default argument
appears<INS>, except that an immediate invocation
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is a potentially-evaluated
subexpression (6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of
the <I>initializer-clause</I> in a <I>parameter-declaration</I> is
neither evaluated nor checked for whether it is a constant expression
at that point</INS>.  Name lookup and checking of semantic constraints
for default arguments of templated functions are performed as
described in 13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>].</P>

</BLOCKQUOTE>

</LI>

<LI>

<P>Add a paragraph before 9.4.1 [<A href="https://wg21.link/dcl.init.general#17">dcl.init.general</A>] paragraph 17 as follows:</P>

<BLOCKQUOTE class="ins">

An immediate invocation (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is not
evaluated where it appears (9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>],
11.4.1 [<A href="https://wg21.link/class.mem.general">class.mem.general</A>]) is evaluated and checked for whether it
is a constant expression at the point where the
enclosing <I>initializer</I> is used in a function call, a constructor
definition, or an aggregate initialization.

</BLOCKQUOTE>

<BLOCKQUOTE>

An <I>initializer-clause</I> followed by an ellipsis is a pack
expansion (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]).

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

A <I>brace-or-equal-initializer</I> for a non-static data member
specifies a <I>default member initializer</I> for the member, and
shall not directly or indirectly cause the implicit definition of a
defaulted default constructor for the enclosing class or the exception
specification of that constructor.

<INS>An immediate invocation (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is a
potentially-evaluated subexpression (6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of a
default member initializer is neither evaluated nor checked for
whether it is a constant expression at the point where the
subexpression appears.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#11">temp.inst</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

... The use of a template specialization in a default argument <INS>or
default member initializer</INS> shall not cause the template to be
implicitly instantiated except that a
<INS>templated</INS> class <DEL>template</DEL> <INS>, a templated
function with a deduced return type, or a variable template with a
deduced type</INS> may be instantiated where its complete type is
needed to determine the correctness of the default argument <INS>or
default member initializer</INS>.  The use of a default argument in a
function call causes specializations in the default argument to be
implicitly instantiated. <INS>Similarly, the use of a default member
initializer in a constructor definition or an aggregate initialization
causes specializations in the default member initializer to be
instantiated.</INS>

</BLOCKQUOTE>

</LI>

</OL>

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

<P>In the above wording, "constituent expression of a conversion" is
not a defined term.</P>

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

<OL>
<LI>

<P>Change in 6.9.1 [<A href="https://wg21.link/intro.execution#2">intro.execution</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A constituent expression is defined as follows:

<UL>
<LI>The constituent expression of an expression is that expression.
</LI>

<LI><INS>The constituent expression of a conversion is the
corresponding implicit function call, if any, or the converted
expression otherwise.</INS></LI>

<LI>The constituent expressions of a <I>braced-init-list</I> or of a
(possibly parenthesized) <I>expression-list</I> are the constituent
expressions of the elements of the respective list.
</LI>

<LI>The constituent expressions of a <I>brace-or-equal-initializer</I>
of the form = <I>initializer-clause</I> are the constituent
expressions of the <I>initializer-clause</I>.
</LI>

</UL>

</BLOCKQUOTE>

</LI>

<LI>

<P>Change in 6.9.1 [<A href="https://wg21.link/intro.execution#4">intro.execution</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A <I>subexpression</I> of an expression E is an immediate subexpression of E
or a subexpression of an immediate subexpression of E. [ Note: ... -- end note ]

</BLOCKQUOTE>

<BLOCKQUOTE class="ins">
The <I>potentially-evaluated subexpressions</I> of an expression,
conversion, or <I>initializer</I> <TT>E</TT> are

<UL>
<LI>the constituent expressions of <TT>E</TT> and</LI>
<LI>the subexpressions thereof that are not subexpressions of a nested
unevaluated operand (7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]).</LI>

</UL>

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

An expression or conversion is <I>potentially constant evaluated</I> if it
is:
<UL>
<LI>...</LI>
<LI>a <INS>potentially-evaluated</INS> subexpression
(6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of one of the above<DEL> that is not a
subexpression of a nested unevaluated operand
(7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>])</DEL>.</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>

<P>Change in 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#5">dcl.fct.default</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P>The default argument has the same semantic constraints as the
initializer in a declaration of a variable of the parameter type,
using the copy-initialization semantics (9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).
The names in the default argument are looked up, and the semantic
constraints are checked, at the point where the default argument
appears<INS>, except that an immediate invocation
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is a potentially-evaluated
subexpression (6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of
the <I>initializer-clause</I> in a <I>parameter-declaration</I> is
neither evaluated nor checked for whether it is a constant expression
at that point</INS>.  Name lookup and checking of semantic constraints
for default arguments of templated functions are performed as
described in 13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>].</P>

</BLOCKQUOTE>

</LI>

<LI>

<P>Add a paragraph before 9.4.1 [<A href="https://wg21.link/dcl.init.general#17">dcl.init.general</A>] paragraph 17 as follows:</P>

<BLOCKQUOTE class="ins">

An immediate invocation (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is not
evaluated where it appears (9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>],
11.4.1 [<A href="https://wg21.link/class.mem.general">class.mem.general</A>]) is evaluated and checked for whether it
is a constant expression at the point where the
enclosing <I>initializer</I> is used in a function call, a constructor
definition, or an aggregate initialization.

</BLOCKQUOTE>

<BLOCKQUOTE>

An <I>initializer-clause</I> followed by an ellipsis is a pack
expansion (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]).

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

A <I>brace-or-equal-initializer</I> for a non-static data member
specifies a <I>default member initializer</I> for the member, and
shall not directly or indirectly cause the implicit definition of a
defaulted default constructor for the enclosing class or the exception
specification of that constructor.

<INS>An immediate invocation (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is a
potentially-evaluated subexpression (6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of a
default member initializer is neither evaluated nor checked for
whether it is a constant expression at the point where the
subexpression appears.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#11">temp.inst</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

... The use of a template specialization in a default argument <INS>or
default member initializer</INS> shall not cause the template to be
implicitly instantiated except that a
<INS>templated</INS> class <DEL>template</DEL> <INS>, a templated
function with a deduced return type, or a variable template with a
deduced type</INS> may be instantiated where its complete type is
needed to determine the correctness of the default argument <INS>or
default member initializer</INS>.  The use of a default argument in a
function call causes specializations in the default argument to be
implicitly instantiated. <INS>Similarly, the use of a default member
initializer in a constructor definition or an aggregate initialization
causes specializations in the default member initializer to be
instantiated.</INS>

</BLOCKQUOTE>

</LI>

</OL>

<P><B>CWG 2022-11-07</B></P>

<P>Expand requirement to avoid template instantiations in default
arguments by not giving a specific, closed list.</P>

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

<OL>
<LI>

<P>Change in 6.9.1 [<A href="https://wg21.link/intro.execution#2">intro.execution</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A constituent expression is defined as follows:

<UL>
<LI>The constituent expression of an expression is that expression.
</LI>

<LI><INS>The constituent expression of a conversion is the
corresponding implicit function call, if any, or the converted
expression otherwise.</INS></LI>

<LI>The constituent expressions of a <I>braced-init-list</I> or of a
(possibly parenthesized) <I>expression-list</I> are the constituent
expressions of the elements of the respective list.
</LI>

<LI>The constituent expressions of a <I>brace-or-equal-initializer</I>
of the form = <I>initializer-clause</I> are the constituent
expressions of the <I>initializer-clause</I>.
</LI>

</UL>

</BLOCKQUOTE>

</LI>

<LI>

<P>Change in 6.9.1 [<A href="https://wg21.link/intro.execution#4">intro.execution</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A <I>subexpression</I> of an expression E is an immediate subexpression of E
or a subexpression of an immediate subexpression of E. [ Note: ... -- end note ]

</BLOCKQUOTE>

<BLOCKQUOTE class="ins">
The <I>potentially-evaluated subexpressions</I> of an expression,
conversion, or <I>initializer</I> <TT>E</TT> are

<UL>
<LI>the constituent expressions of <TT>E</TT> and</LI>
<LI>the subexpressions thereof that are not subexpressions of a nested
unevaluated operand (7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]).</LI>

</UL>

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

An expression or conversion is <I>potentially constant evaluated</I> if it
is:
<UL>
<LI>...</LI>
<LI>a <INS>potentially-evaluated</INS> subexpression
(6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of one of the above<DEL> that is not a
subexpression of a nested unevaluated operand
(7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>])</DEL>.</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>

<P>Change in 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#5">dcl.fct.default</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P>The default argument has the same semantic constraints as the
initializer in a declaration of a variable of the parameter type,
using the copy-initialization semantics (9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).
The names in the default argument are looked up, and the semantic
constraints are checked, at the point where the default argument
appears<INS>, except that an immediate invocation
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is a potentially-evaluated
subexpression (6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of
the <I>initializer-clause</I> in a <I>parameter-declaration</I> is
neither evaluated nor checked for whether it is a constant expression
at that point</INS>.  Name lookup and checking of semantic constraints
for default arguments of templated functions are performed as
described in 13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>].</P>

</BLOCKQUOTE>

</LI>

<LI>

<P>Add a paragraph before 9.4.1 [<A href="https://wg21.link/dcl.init.general#17">dcl.init.general</A>] paragraph 17 as follows:</P>

<BLOCKQUOTE class="ins">

An immediate invocation (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is not
evaluated where it appears (9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>],
11.4.1 [<A href="https://wg21.link/class.mem.general">class.mem.general</A>]) is evaluated and checked for whether it
is a constant expression at the point where the
enclosing <I>initializer</I> is used in a function call, a constructor
definition, or an aggregate initialization.

</BLOCKQUOTE>

<BLOCKQUOTE>

An <I>initializer-clause</I> followed by an ellipsis is a pack
expansion (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]).

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

A <I>brace-or-equal-initializer</I> for a non-static data member
specifies a <I>default member initializer</I> for the member, and
shall not directly or indirectly cause the implicit definition of a
defaulted default constructor for the enclosing class or the exception
specification of that constructor.

<INS>An immediate invocation (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is a
potentially-evaluated subexpression (6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) of a
default member initializer is neither evaluated nor checked for
whether it is a constant expression at the point where the
subexpression appears.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#11">temp.inst</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

... The use of a template specialization in a default argument <INS>or
default member initializer</INS> shall not cause the template to be
implicitly instantiated except <DEL>that a
class template may be instantiated</DEL> where <DEL>its complete type is</DEL>
needed to determine the correctness of the default argument <INS>or
default member initializer</INS>.  The use of a default argument in a
function call causes specializations in the default argument to be
implicitly instantiated. <INS>Similarly, the use of a default member
initializer in a constructor definition or an aggregate initialization
causes specializations in the default member initializer to be
instantiated.</INS>

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2636"></A><H4>2636.
  
Update Annex E based on Unicode 15.0 UAX #31
</H4>
<B>Section: </B>Clause Annex E&#160; [<A href="https://wg21.link/uaxid">uaxid</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-10-20


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US64-132">P2720R0 comment
  US&#160;64-132<BR></A>

<P>Unicode 15.0 UAX #31 clarified that rule R3 was, in fact, intended
to apply to programming languages.  WG21's prior understanding was
that programming languages are not in scope of that rule.  The
proposed resolution updates E.4 [<A href="https://wg21.link/uaxid.pattern">uaxid.pattern</A>] to the revised
understanding. See paper P2653R1 (Update Annex E based on Unicode 15.0
UAX 31) for more details.</P>

<P><B>Proposed resolution (approved by CWG 2022-10-21):</B></P>

<P>Change in E.4 [<A href="https://wg21.link/uaxid.pattern">uaxid.pattern</A>] as follows:</P>

<BLOCKQUOTE>

<P>
UAX #31 describes how <INS>formal</INS> languages <DEL>that use or
interpret patterns of characters, such as regular expressions or
number formats, may describe that syntax with Unicode properties</DEL>
<INS>such as computer languages should describe and implement their
use of whitespace and syntactically significant characters during the
processes of lexing and parsing</INS>.
</P>

<P>
C++ does not <DEL>do this as part of the language, deferring to
library components for such usage of patterns.  This requirement does
not apply to C++</DEL> <INS>claim conformance with this
requirement</INS>.
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2639"></A><H4>2639.
  
new-lines after phase 1
</H4>
<B>Section: </B>5.2&#160; [<A href="https://wg21.link/lex.phases">lex.phases</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US3-030">P2720R0 comment
  US&#160;3-030<BR></A>

<P>Translation phases 2 and 3 assume that lines are terminated by
"new-line characters". However, the current specification of phase 1
does not guarantee that to be true. In particular, for a UTF-8 file
the verbatim sequence of source file characters forms the input for
phase 2, even on systems where the line terminator is a carriage
return. The non-UTF-8 specification is also defective in that it
speaks of "introducing" new-line characters, even for encodings like
Latin-1 where new-lines might already be present and no "introduction"
is needed or appropriate.</P>

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

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

<BLOCKQUOTE>

<P>
...  If an input file is determined to be a UTF-8 file, then it shall
be a well-formed UTF-8 code unit sequence and it is decoded to produce
a sequence of UCS scalar values that constitutes the sequence of
elements of the translation character set<INS>, representing each
line-termination character or character sequence as a new-line
character</INS>.
</P>

<P>
For any other kind of input file supported by the implementation,
characters are mapped, in an implementation-defined manner, to a
sequence of translation character set elements
(5.3 [<A href="https://wg21.link/lex.charset">lex.charset</A>]) (<DEL>introducing new-line characters
for</DEL> <INS>representing</INS> end-of-line indicators <INS>as
new-line characters</INS>).
</P>

</BLOCKQUOTE>

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

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

<BLOCKQUOTE>

<P>
...  If an input file is determined to be a UTF-8 file, then it shall
be a well-formed UTF-8 code unit sequence and it is decoded to produce
a sequence of UCS scalar values that constitutes the sequence of
elements of the translation character set. <INS>In the resulting
sequence, each pair of characters in the input sequence consisting of U+000D
CARRIAGE RETURN followed by U+000A LINE FEED, as well as each U+000D
CARRIAGE RETURN not immediately followed by a U+000A LINE FEED, is
replaced by a single new-line character.</INS>
</P>

<P>
For any other kind of input file supported by the implementation,
characters are mapped, in an implementation-defined manner, to a
sequence of translation character set elements
(5.3 [<A href="https://wg21.link/lex.charset">lex.charset</A>]) <DEL>(introducing new-line characters
for</DEL> <INS>, representing</INS> end-of-line indicators <INS>as
new-line characters</INS> <DEL>)</DEL>.
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2640"></A><H4>2640.
  
Allow more characters in an n-char sequence
</H4>
<B>Section: </B>5.3&#160; [<A href="https://wg21.link/lex.charset">lex.charset</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US1-028">P2720R0 comment
  US&#160;1-028<BR></A>

<P>The n-char grammar term is defined to match only the Latin uppercase, Latin digit, hyphen and space characters. This results in \N{ABC} matching named-universal-character while \N{abc} does not. This leads to programs like the following being unexpectedly well-formed because the \N{abc} sequence is lexed as the preprocessing token sequence , N, {, abc, }. The expansion of macro a then leads to the token sequence being passed as an argument to macro z where it is discarded.</P>

<PRE>
  #define z(x) 0
  #define a z(
  int x = a\N{abc});
</PRE>

<P>Changes to make the above program ill-formed would provide two benefits:

<UL>
<LI>Implementations could diagnose the \N{abc} sequence as an
ill-formed named-universal-character regardless of where it appears in
a program.</LI>
<LI>The <TT>\N{...}</TT> syntax space would be reserved for expansion (e.g., for
extensions or future support of UAX44-LM2 loose matching
schemes).</LI>
</UL>
</P>

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

<P>Change the grammar in 5.3 [<A href="https://wg21.link/lex.charset#3">lex.charset</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<PRE>
<I>n-char</I>:
     <DEL>A B C D E F G H I J K L M N O P Q R S T U V W X Y Z</DEL>
     <DEL>0 1 2 3 4 5 6 7 8 9</DEL>
     <DEL>U+002d hyphen-minus</DEL>
     <DEL>U+0020 space</DEL>
     <INS>any member of the translation character set except the U+007D RIGHT CURLY BRACKET or new-line character</INS>
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2642"></A><H4>2642.
  
Inconsistent use of T and C
</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>NB
 &#160;&#160;&#160;

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US7-035">P2720R0 comment
  US&#160;7-035<BR></A>

<P>T and C are used inconsistently throughout these paragraphs.</P>

<P><B>Proposed resolution:</B></P>

<OL>

<LI>

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

<BLOCKQUOTE>

A search in a scope X for a name N from a program point P is a single
search in X for N from P unless X is the scope of a class or class
template <DEL>T</DEL> <INS>C</INS>, in which case the following steps
define the result of the search.

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

[<I>Note 2:</I> If <DEL>T</DEL> <INS>C</INS> is incomplete, only base
classes whose <I>base-specifier</I> appears before P are
considered. If <DEL>T</DEL> <INS>C</INS> is an instantiated class, its
base classes are not dependent. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>

<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>

The result of the search is the declaration set of
S(N, <DEL>T</DEL> <INS>C</INS>). If it is an invalid set, the program
is ill-formed.  If it differs from the result of a search
in <DEL>T</DEL> <INS>C</INS> for N in a complete-class context
(11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]) of <DEL>T</DEL> <INS>C</INS>, the program
is ill-formed, no diagnostic required.

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

If N is a non-dependent <I>conversion-function-id</I>, conversion
function templates that are members of <DEL>T</DEL> <INS>C</INS> are
considered. For each such template F, the lookup set
S(t, <DEL>T</DEL> <INS>C</INS>) is constructed, considering a function
template declaration to have the name t only if it corresponds to a
declaration of F (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]).

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

[<I>Note 4:</I> A static member, a nested type or an enumerator
defined in a base class <DEL>T</DEL> <INS><TT>B</TT></INS> can
unambiguously be found even if an object has more than one base class
subobject of type <DEL>T</DEL> <INS><TT>B</TT></INS>. Two base class
subobjects share the non-static member subobjects of their common
virtual base classes. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2643"></A><H4>2643.
  
Completing a pointer to array of unknown bound
</H4>
<B>Section: </B>6.8.1&#160; [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US10-039">P2720R0 comment
  US&#160;10-039<BR></A>

<P>Subclause 6.8.1 [<A href="https://wg21.link/basic.types.general#6">basic.types.general</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

... The type of a pointer to array of unknown bound, or of a type defined
by a <TT>typedef</TT> declaration to be an array of unknown bound,
cannot be completed.

</BLOCKQUOTE>

<P>This is misleading; such a type is already complete.</P>

<P><B>Proposed resolution:</B></P>

<P>Change in 6.8.1 [<A href="https://wg21.link/basic.types.general#6">basic.types.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

... <INS>[ Note:</INS> The type of a pointer <INS>or reference</INS>
to array of unknown bound <INS>permanently points to or refers to an incomplete
type.  An array of unknown bound</INS> <DEL>, or of a type
defined</DEL> <INS>named</INS> by a <TT>typedef</TT>
declaration <DEL>to be an array of unknown bound,</DEL>
<INS>permanently refers to an incomplete type.  In either case, the
array type</INS> cannot be completed. <INS>-- end note ]</INS>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2644"></A><H4>2644.
  
Incorrect comment in example
</H4>
<B>Section: </B>7.5.5.3&#160; [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US13-042">P2720R0 comment
  US&#160;13-042<BR></A>

<P>
The comment in the example in 7.5.5.3 [<A href="https://wg21.link/expr.prim.lambda.capture#6">expr.prim.lambda.capture</A>] paragraph 6
refers to "local variable", but should refer to <I>init-capture</I>
instead.
</P>

<P><B>Possible resolution:</B></P>

<P>Change in 7.5.5.3 [<A href="https://wg21.link/expr.prim.lambda.capture#6">expr.prim.lambda.capture</A>] paragraph 6 as follows:</P>

<PRE>
  auto z = [a = 42](int a) { return 1; };   //<SPAN CLASS="cmnt"> error: parameter and <INS>conceptual</INS> local variable have the same name</SPAN>
</PRE>

<BR><BR><HR>
<A NAME="2645"></A><H4>2645.
  
Unused term "default argument promotions"
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US15-044">P2720R0 comment
  US&#160;15-044<BR></A>

<P>The phrase "default argument promotions" is apparently unused.</P>

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

<OL>

<LI>

<P>Change in 7.6.1.3 [<A href="https://wg21.link/expr.call#12">expr.call</A>] paragraph 12 as follows:</P>

<BLOCKQUOTE>

...If the argument has integral or enumeration type that is
subject to the integral promotions (7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>]), or a
floating-point type that is subject to the floating-point promotion
(7.3.8 [<A href="https://wg21.link/conv.fpprom">conv.fpprom</A>]), the value of the argument is converted
to the promoted type before the call.  <DEL>These promotions are referred to
as the <I>default argument promotion</I>s.</DEL>

</BLOCKQUOTE>

</LI>

<LI>

<P>Change in 17.13.2 [<A href="https://wg21.link/cstdarg.syn">cstdarg.syn</A>] as follows:</P>

<P>See also: ISO C <DEL>7.16.1.1</DEL> <INS>7.16.1</INS>
</P>

</LI>

</OL>

<P><B>CWG 2022-11-10</B></P>

<P>The phrase is useful and needed to override C's deviating
definition, as applicable to <TT>va_arg</TT>.</P>

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

<P>Change in 17.13.2 [<A href="https://wg21.link/cstdarg.syn">cstdarg.syn</A>] as follows:</P>

<BLOCKQUOTE>

The contents of the header &lt;cstdarg&gt; are the same as the C
standard library header &lt;stdarg.h&gt;, with the following changes:
<INS>In lieu of the default argument promotions specified in ISO C
6.5.2.2, the definition in 7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>] applies.</INS>
The restrictions that ISO C places on the second parameter to
the <TT>va_start</TT> macro in header &lt;stdarg.h&gt; are different
in this document. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2646"></A><H4>2646.
  
Defaulted special member 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>NB
 &#160;&#160;&#160;

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US20-052">P2720R0 comment
  US&#160;20-052<BR></A>

<P>The exposition in terms of F1 and F2 as well as T1 and T2 is confusing.</P>

<P><U>Possible resolution:</U></P>

<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>

An explicitly defaulted special member function F1 <DEL>with type T1</DEL> is
allowed to differ from the corresponding special member function F2
<DEL>with type T2</DEL> that would have been implicitly declared, as follows:

<UL>

<LI>
<DEL>T1</DEL> <INS>F1</INS> and <DEL>T2</DEL> <INS>F2</INS> may have
differing <I>ref-qualifier</I> s;
</LI>

<LI>
if F2 has an implicit object parameter of type &#8220;reference to
C&#8221;, F1 may be an explicit object member function whose explicit
object parameter is of type &#8220;reference to C&#8221;, in which
case <DEL>T1</DEL> <INS>the type of F1</INS> would differ
from <DEL>T2</DEL> <INS>the type of F2</INS> in
that <DEL>T1</DEL> <INS>the type of F1</INS> has an additional
parameter;
</LI>

<LI>
<DEL>T1</DEL> <INS>F1</INS> and <DEL>T2</DEL> <INS>F2</INS> may have
differing exception specifications; and
</LI>

<LI>
if F2 has a non-object parameter of type const C&amp;, the
corresponding non-object parameter of F1 may be of type C&amp;.
</LI>
</UL>

If <DEL>T1</DEL> <INS>the type of F1</INS> differs
from <DEL>T2</DEL> <INS>the type of F2</INS> in a way other than as
allowed by the preceding rules, then:

<UL>
<LI>
if F1 is an assignment operator, and the return type of
<DEL>T1</DEL> <INS>F1</INS> differs from the return type
of <DEL>T2</DEL> <INS>F2</INS> or F1 's non-object parameter type is
not a reference, the program is ill-formed;
</LI>

<LI>otherwise,
if F1 is explicitly defaulted on its first declaration, it is defined
as deleted;</LI>

<LI>
otherwise, the program is ill-formed.
</LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2647"></A><H4>2647.
  
Fix for "needed for 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>NB
 &#160;&#160;&#160;

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US17-047">P2720R0 comment
  US&#160;17-047<BR></A>

<P>The criteria for a variable to be needed for constant evaluation
are inconsistent with those for it to be usable in constant
expressions (/4).</P>

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

<OL>

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

<BLOCKQUOTE>

A variable is <I>potentially-constant</I> if it is constexpr or it has
reference or <INS>non-volatile</INS> const-qualified integral or
enumeration type.

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

A function or variable is needed for constant evaluation if it is:
<UL>
<LI>
a constexpr function that is named by an expression (6.3) that is
potentially constant evaluated, or
</LI>

<LI>
a <INS>potentially-constant</INS> variable named by a potentially
constant evaluated expression <DEL>that is either a constexpr variable
or is of non-volatile const-qualified integral type or of reference
type</DEL>.

</LI>
</UL>

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2648"></A><H4>2648.
  
Correspondence of surrogate call function and conversion function
</H4>
<B>Section: </B>12.4.4&#160; [<A href="https://wg21.link/over.call">over.call</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#CA063">P2720R0 comment
  CA&#160;063<BR></A>

<P>
Post-Prague "editorial" change cplusplus/draft#3625 removed the
normative text supporting the interpretation that surrogate call
functions, when chosen, call the functions they were formed from.
</P>

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

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

<BLOCKQUOTE>

If a surrogate call function <DEL>for a conversion function named
operator <I>conversion-type-id</I></DEL> is selected, <INS>let <I>e</I> be the result of invoking the corresponding conversion operator function on the <I>postfix-expression</I>; </INS> <DEL>is invoked</DEL> the expression is
interpreted as

<PRE>
<DEL><I>postfix-expression</I> . operator <I>conversion-type-id</I> ()</DEL> <INS><I>e</I></INS> ( <I>expression-list</I><SUB>opt</SUB> )
</PRE>

Otherwise, ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2649"></A><H4>2649.
  
Incorrect note about implicit conversion sequence
</H4>
<B>Section: </B>12.2.2.2.3&#160; [<A href="https://wg21.link/over.call.object">over.call.object</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#CA064">P2720R0 comment
  CA&#160;064<BR></A>

<P>
Contrary to the note in the subject paragraph, overload resolution in
selecting a surrogate call function can prefer a different conversion
operator for the implicit conversion sequence because the conversion
function from which the surrogate call function was derived is not the
best viable function.
</P>

<P>
For example, noting that surrogate call functions are not generated
from conversion function templates, the single surrogate call function
derived from the (non-template) conversion function below is the sole
candidate for the call; however, the specialization of the conversion
function template is a better candidate f or the implicit conversion
sequence during overload resolution:
</P>

<PRE>
  using ff = int (*)(int);
  constexpr int ffimpl0(int x) {
   return x;
  }
  constexpr int ffimpl1(int x) {
   return x + 1;
  }
  struct A {
   template &lt;typename T&gt; constexpr operator T() const { return ffimpl0; }
   constexpr operator ff() const volatile { return ffimpl1; }
  };
  char x[A()(42.f)];
  extern char x[43];
</PRE>

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

<P>Change in 12.2.2.2.3 [<A href="https://wg21.link/over.call.object#3">over.call.object</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

[<I>Note 1:</I> When comparing the call against the function call
operators, the implied object argument is compared against the object
parameter of the function call operator. When comparing the call
against a surrogate call function, the implied object argument is
compared against the first parameter of the surrogate call
function. <DEL>The conversion function from which the surrogate call
function was derived will be used in the conversion sequence for that
parameter since it converts the implied object argument to the
appropriate function pointer or reference required by that first
parameter.</DEL> &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2650"></A><H4>2650.
  
Incorrect example for ill-formed non-type template arguments
</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>NB
 &#160;&#160;&#160;

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US28-068">P2720R0 comment
  US&#160;28-068<BR></A>

<P>
The example intends to illustrate that a class type cannot be the type
of a non-type template parameter (although the example is still
ill-formed because "T()" is interpreted as a function type).
</P>

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

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

<UL>
<LI>...</LI>
<LI>
Attempting to give an invalid type to a non-type template parameter.
[Example 13:

<PRE>
  template &lt;class T, T&gt; struct S {};
  template &lt;class T&gt; int f(S&lt;T, <DEL>T()</DEL><INS>T{}</INS>&gt;*);   <INS>//<SPAN CLASS="cmnt"> #1</SPAN></INS>
  class X {
    <INS>int m;</INS>
  };
  int i0 = f&lt;X&gt;(0);   <INS>//<SPAN CLASS="cmnt"> #1 uses a value of non-structural type </SPAN>X<SPAN CLASS="cmnt"> as a non-type template argument</SPAN></INS>
</PRE>

-- end example ]
</LI>

<LI>...</LI>

</UL>

<BR><BR><HR>
<A NAME="2651"></A><H4>2651.
  
Conversion function templates and "noexcept"
</H4>
<B>Section: </B>13.10.3.4&#160; [<A href="https://wg21.link/temp.deduct.conv">temp.deduct.conv</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US29-069">P2720R0 comment
  US&#160;29-069<BR></A>

<P>The rule in 13.10.3.4 [<A href="https://wg21.link/temp.deduct.conv#5.2">temp.deduct.conv</A>] bullet 5.2 seems to allow</P>

<PRE>
template&lt;class T,bool B&gt;
using get=T(*)() noexcept(B);

struct A {
 template&lt;class T&gt;
 operator get&lt;T,false&gt;() const;
};

auto *p=A().operator get&lt;int,true&gt;();
</PRE>

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

<P>Change in 13.10.3.4 [<A href="https://wg21.link/temp.deduct.conv#1">temp.deduct.conv</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>
... If the <I>conversion-function-id</I> is constructed during overload
resolution ([over.match.funcs]), the <DEL>following transformations</DEL>
<INS>rules in the remainder of this subclause</INS> apply.
</BLOCKQUOTE>

<P>Change in 13.10.3.4 [<A href="https://wg21.link/temp.deduct.conv#5.2">temp.deduct.conv</A>] bullet 5.2 as follows:</P>

<BLOCKQUOTE>

However, certain attributes of A may be ignored:

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

<LI>If the original A is a function pointer or
pointer-to-member-function type <INS>with a potentially-throwing exception
specification (14.5 [<A href="https://wg21.link/except.spec">except.spec</A>])</INS>, <DEL>its
noexcept</DEL> <INS>the exception specification</INS>.</LI>

<LI>...</LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2652"></A><H4>2652.
  
Overbroad definition of <TT>__STDCPP_BFLOAT16_T__</TT>
</H4>
<B>Section: </B>15.11&#160; [<A href="https://wg21.link/cpp.predefined">cpp.predefined</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US31-071">P2720R0 comment
  US&#160;31-071<BR></A>

<P>
The wording for the predefined macro <TT>__STDCPP_BFLOAT16_T__</TT> added by
P1467 can be interpreted more broadly than was intended.
</P>

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

<P>Change in 15.11 [<A href="https://wg21.link/cpp.predefined#1">cpp.predefined</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<P><TT>__STDCPP_BFLOAT16_T__</TT></P> Defined as the integer literal 1
if and only if the implementation supports an extended floating-point
type with the properties <INS>of the <I>typedef-name</I>
<TT>std::bfloat16_t</TT> as</INS> described in
6.8.3 [<A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>].

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2653"></A><H4>2653.
  
Can an explicit object parameter have a default argument?
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#GB051">P2720R0 comment
  GB&#160;051<BR></A>

<P>
The syntax and semantics appear to allow:
<PRE>
  struct S { void f(this const S&amp; = S{}); };
</PRE>

This is probably no more than an oddity, but perhaps it should be prevented.
</P>

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

<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#3">dcl.fct</A>] paragraph 3 as follows:</P>

<PRE>
<I>parameter-declaration:
    attribute-specifier-seq<SUB>opt</SUB></I> this<SUB>opt</SUB> <I>decl-specifier-seq declarator
    attribute-specifier-seq<SUB>opt</SUB></I> <DEL>this<SUB>opt</SUB></DEL> <I>decl-specifier-seq declarator = initializer-clause
    attribute-specifier-seq<SUB>opt</SUB></I> this<SUB>opt</SUB> <I>decl-specifier-seq abstract-declarator<SUB>opt</SUB>
    attribute-specifier-seq<SUB>opt</SUB></I> <DEL>this<SUB>opt</SUB></DEL> <I>decl-specifier-seq abstract-declarator<SUB>opt</SUB> = initializer-clause</I>
</PRE>

<BR><BR><HR>
<A NAME="2654"></A><H4>2654.
  
Un-deprecation of compound volatile assignments
</H4>
<B>Section: </B>7.6.19&#160; [<A href="https://wg21.link/expr.ass">expr.ass</A>]
 &#160;&#160;&#160;

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

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

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


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2720r0.pdf#US16-045">P2720R0 comment
  US&#160;16-045<BR></A>

<P>
Many functions of volatile were deprecated in C++20. In C++23,
volatile compound operations were de-deprecated by P2327. The
rationale for this de-deprecation is lacking.</P>

<P>
Deprecation is not removal. P2327 in C++23 is stopping the change that
we began with C++20, mere moments ago if counting by adoption time. It
primarily argued that it's an inconvenient change, and that some of
the audience would just not cooperate with WG21's indicated direction,
so WG21 should compromise the technical consistency of the Standard so
they could continue to not cooperate.
</P>

<P>
The paper did not bring new information on the technical merits of the
case, and net the result of applying it was a technically dissonant
Standard specification --- a strictly worse specification than
C++20. Bitwise compound operations are not special for any technical
reason, they are only special because making them special shields some
from deprecation diagnostics.
</P>

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

<P>Contrary to the direction desired in the NB comment, EWG resolved
to un-deprecate all volatile compound assignments.</P>

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

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

<BLOCKQUOTE>

The behavior of an expression of the form E1 op= E2 is equivalent to
E1 = E1 op E2 except that E1 is evaluated only once.
<INS>[ Note: The object designated by E1 is accessed twice. -- end note ]</INS>
<DEL>Such expressions
are deprecated if E1 has volatile-qualified type and op is not one of
the bitwise operators |, &amp;, ^; see D.5.</DEL>

</BLOCKQUOTE>

<P>Change in D.5 [<A href="https://wg21.link/depr.volatile.type#2">depr.volatile.type</A>] paragraph 2 as follows:</P>

<PRE>
  brachiosaur += neck;                //<SPAN CLASS="cmnt"> <DEL>deprecated</DEL><INS>OK</INS></SPAN>
  <DEL>brachiosaur = brachiosaur + neck;   //<SPAN CLASS="cmnt"> OK</SPAN></DEL>
  <DEL>brachiosaur |= neck;                //<SPAN CLASS="cmnt"> OK, bitwise compound expression</SPAN></DEL>
</PRE>

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