<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core "ready" Issues
   </TITLE>
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  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;P2796R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2023-02-07</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
     February, 2023 meeting
    </H2></CENTER>
<BR><P>
    References in this document reflect the section and paragraph
    numbering of document
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/n4917.pdf">WG21 N4928</A>.
   </P>
<HR>
<A NAME="2072"></A><H4>2072.
  
Default argument instantiation for member functions of templates
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Maxim Kartashev
 &#160;&#160;&#160;

 <B>Date: </B>2015-01-19




<P>Default argument instantiation is described in
13.9.2 [<A href="https://wg21.link/temp.inst#12">temp.inst</A>] paragraph 12, and although instantiation
of default arguments for member functions of class templates is
mentioned elsewhere a number of times, this paragraph only describes
default argument instantiation for function templates.</P>

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

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

<BLOCKQUOTE>

If a <INS>templated</INS> function <DEL>template</DEL>
f is called in a way that requires a default
argument to be used, the dependent names are looked up, the semantics
constraints are checked, and the instantiation of any template used in
the default argument is done as if the default argument had been an
initializer used in a function template specialization with the same
scope, the same template parameters and the same access as that of the
function template f used at that point, except that the scope in which
a closure type is declared (7.5.5.2 [<A href="https://wg21.link/expr.prim.lambda.closure">expr.prim.lambda.closure</A>]) --- and
therefore its associated namespaces --- remain as determined from the
context of the definition for the default argument.  This analysis is
called default argument instantiation. The instantiated default
argument is then used as the argument of f.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2475"></A><H4>2475.
  
Object declarations of type <I>cv</I> <TT>void</TT>
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Krystian Stasiowski
 &#160;&#160;&#160;

 <B>Date: </B>2020-04-22


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

<P>Although an object cannot be defined with a type of
<I>cv</I> <TT>void</TT>, there is nothing preventing a
non-defining declaration of an object with that type. Should
it be disallowed?</P>

<P><B>Notes from the December, 2020 teleconference:</B></P>

<P>Such declarations are permitted in C, so this question was
referred to the C liaison for investigation.</P>

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

<P>CWG resolved to making such declarations ill-formed.</P>

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

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

<BLOCKQUOTE>

If the <I>decl-specifier-seq</I> contains the <TT>typedef</TT>
specifier, the declaration is <DEL>called</DEL> a <I>typedef declaration</I> and
each <I>declarator-id</I> is declared to be a <I>typedef-name</I>,
synonymous with its associated type (9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]).
[ <I>Note 4</I>: Such a <I>declarator-id</I> is an
identifier (11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]). &#8212;<I>end note</I>]
<DEL>If the <I>decl-specifier-seq</I> contains no typedef specifier,</DEL>
<INS>Otherwise, if the type associated
with a <I>declarator-id</I> is a function type
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]),</INS>
the declaration is <DEL>called</DEL> a <I>function declaration</I>
<DEL>if the type associated with a <I>declarator-id</I> is a function type
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]) and</DEL>
<INS>. Otherwise, if the type associated with a <I>declarator-id</I>
is an object or reference type, the declaration is</INS> an <I>object declaration</I>
<DEL>otherwise</DEL>.
<INS>Otherwise, the program is ill-formed.</INS>

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

<PRE class="ins">
int f(), x;            //<SPAN CLASS="cmnt"> OK, function declaration for </SPAN>f<SPAN CLASS="cmnt"> and object declaration for </SPAN>x
extern void g(),       //<SPAN CLASS="cmnt"> OK, function declaration for </SPAN>g
  y;                   //<SPAN CLASS="cmnt"> error: </SPAN>void<SPAN CLASS="cmnt"> is not an object type</SPAN>
</PRE>
<P class="ins">
-- end example ]
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2478"></A><H4>2478.
  
Properties of explicit specializations of implicitly-instantiated class templates
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mark Hall
 &#160;&#160;&#160;

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


<P>According to 13.9.4 [<A href="https://wg21.link/temp.expl.spec#16">temp.expl.spec</A>] paragraph 16,</P>

<BLOCKQUOTE>

A member or a member template of a class template may be
explicitly specialized for a given implicit instantiation of
the class template, even if the member or member template is
defined in the class template definition. An explicit
specialization of a member or member template is specified
using the syntax for explicit specialization.

</BLOCKQUOTE>

<P>The relationship between this construct and paragraph
14 is not clear:</P>

<BLOCKQUOTE>

Whether an explicit specialization of a function or variable
template is inline, constexpr, or an immediate function is
determined by the explicit specialization and is independent
of those properties of the template.

</BLOCKQUOTE>

<P>(See also 9.2.6 [<A href="https://wg21.link/dcl.constexpr#1">dcl.constexpr</A>] paragraph 1, note
1.)  Is this intended to apply to explicit specializations
of members of implicitly-instantiated class templates? For
example:</P>

<PRE>
  template&lt;typename T&gt; struct S {
    int f();
    constexpr int g();
  };
  template&lt;&gt; constexpr int S&lt;int&gt;::f() {  //<SPAN CLASS="cmnt"> OK, constexpr?</SPAN>
    return 0;
  }
  template&lt;&gt; int S&lt;int&gt;::g() {            //<SPAN CLASS="cmnt"> OK, not constexpr?</SPAN>
    return 0;
  }
</PRE>

<P>There is implementation divergence on the treatment of
this example. This divergence may relate to interpretation
of the requirement in 9.2.6 [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>] paragraph
1,</P>

<BLOCKQUOTE>

If any declaration of a function or function template has a
<TT>constexpr</TT> or <TT>consteval</TT> specifier, then
all its declarations shall contain the same specifier.

</BLOCKQUOTE>

<P>Is an explicit specialization of a member of an
implicitly-instantiated class template a declaration of
that member? A similar question also applies to the
<TT>constinit</TT> specifier as specified in
9.2.7 [<A href="https://wg21.link/dcl.constinit#1">dcl.constinit</A>] paragraph 1:</P>

<BLOCKQUOTE>

If the specifier is applied to any declaration of a
variable, it shall be applied to the initializing
declaration.

</BLOCKQUOTE>

<P>(Note that <TT>constinit</TT> is not mentioned in
13.9.4 [<A href="https://wg21.link/temp.expl.spec#14">temp.expl.spec</A>] paragraph 14.)  For example:</P>

<PRE>
  template&lt;typename T&gt; struct S {
    static constinit T x;
  };
  template&lt;&gt; int S&lt;int&gt;::x = 10;    //<SPAN CLASS="cmnt"> </SPAN>constinit<SPAN CLASS="cmnt"> required?</SPAN>
  extern char c;
  template&lt;&gt; short S&lt;char&gt;::x = c;  //<SPAN CLASS="cmnt"> error, </SPAN>c<SPAN CLASS="cmnt"> not constant?</SPAN>
</PRE>

<P>(Possibly relevant is the fact that default arguments are
prohibited in explicit specializations of member functions
of implicitly-instantiated class templates, per
13.9.4 [<A href="https://wg21.link/temp.expl.spec#21.3">temp.expl.spec</A>] bullet 21.3.)</P>

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

<P>A specialization of a member of a class template redeclares the
member of the primary template and thus the redeclaration rules
apply. In passing, it was noticed that the rule governing explicit
specializations in general omitted treatment of <TT>constinit</TT>,
which was considered an oversight.</P>

<P><B>Proposed resolution (approved 2023-02-09):</B></P>

<P>Change in 13.9.4 [<A href="https://wg21.link/temp.expl.spec#13">temp.expl.spec</A>] paragraph 13 as follows:</P>

<BLOCKQUOTE>

Whether an explicit specialization of a function or variable template
is inline, constexpr, <INS>constinit,</INS> or <INS>consteval</INS> <DEL>an immediate function</DEL>
is determined by the explicit specialization and is independent of
those properties of the template.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2483"></A><H4>2483.
  
Language linkage of static member functions
</H4>
<B>Section: </B>9.11&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

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

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


<P>According to 9.11 [<A href="https://wg21.link/dcl.link#5">dcl.link</A>] paragraph 5,</P>

<BLOCKQUOTE>

A C language linkage is ignored in determining the language
linkage of class members, friend functions with a
trailing <I>requires-clause</I>, and the function type of
class member functions.

</BLOCKQUOTE>

<P>It doesn't make sense that static member functions should
behave like non-static member functions in this regard:</P>

<PRE>
   extern "C" {
     struct A {
       static void f();
       constexpr static void (*p)()=f; //<SPAN CLASS="cmnt"> error: must point to a function whose type has C language linkage</SPAN>
     };
   }
</PRE>

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

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

<BLOCKQUOTE>

A C language linkage is ignored in determining the language
linkage of class members, friend functions with a
trailing <I>requires-clause</I>, and the function type of
<INS>non-static</INS> class member functions.

</BLOCKQUOTE>

<P><B>Notes from the August, 2021 teleconference:</B></P>

<P>There was some question as to whether a linkage
specification should affect the language linkage of any
function declarators within class scope. The question was
also raised as to whether some non-typedef syntax should be
available for affecting language linkage, which would be a
question for EWG.</P>

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

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

<BLOCKQUOTE>

A C language linkage is ignored in determining the language
linkage of class members, friend functions with a
trailing <I>requires-clause</I>, and the function type of
<INS>non-static</INS> class member functions.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2489"></A><H4>2489.
  
Storage provided by array of <TT>char</TT>
</H4>
<B>Section: </B>6.7.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2021-04-15


<P>According to 6.7.2 [<A href="https://wg21.link/intro.object#3">intro.object</A>] paragraph 3,</P>

<BLOCKQUOTE>

If a complete object is created
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]) in storage associated with
another object <I>e</I> of type &#8220;array of <I>N</I>
<TT>unsigned char</TT>&#8221; or of type &#8220;array of <I>N</I>
<TT>std::byte</TT>&#8221; (17.2.1 [<A href="https://wg21.link/cstddef.syn">cstddef.syn</A>]),
that array <I>provides storage</I> for the created object if...

</BLOCKQUOTE>

<P>However, note 4 in paragraph 13 indicates that a
<TT>char</TT> array can also provide storage:</P>

<BLOCKQUOTE>

<P>An operation that begins the lifetime of an array
of <TT>char</TT>, <TT>unsigned char</TT>, or
<TT>std::byte</TT> implicitly creates objects within the
region of storage occupied by the array.</P>

<P>[<I>Note 4</I>: The array object provides storage for
these objects. &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

<P>The normative text and the note should be reconciled.</P>

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

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

<BLOCKQUOTE>

An operation that begins the lifetime of an array
of <DEL><TT>char</TT>,</DEL> <TT>unsigned char</TT><DEL>,</DEL>
or <TT>std::byte</TT> implicitly creates objects within the region of
storage occupied by the array.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2516"></A><H4>2516.
  
Locus of <I>enum-specifier</I> or <I>opaque-enum-declaration</I>
</H4>
<B>Section: </B>6.4.2&#160; [<A href="https://wg21.link/basic.scope.pdecl">basic.scope.pdecl</A>]
 &#160;&#160;&#160;

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

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

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


<P>According to 6.4.2 [<A href="https://wg21.link/basic.scope.pdecl#3">basic.scope.pdecl</A>] paragraph 3,</P>

<BLOCKQUOTE>

The locus of an <I>enum-specifier</I>
or <I>opaque-enum-declaration</I> is immediately after the
identifier (if any) in it (9.7.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]).

</BLOCKQUOTE>

<P>Equivalent wording has been present for a very long time;
see, for instance, issue 1482.
However, most or all implementations reject the example from
that issue:</P>

<PRE>
   template&lt;typename T&gt; struct S { typedef char I; };
   enum E: S&lt;E&gt;::I { e };   //<SPAN CLASS="cmnt"> Implementations say </SPAN>E<SPAN CLASS="cmnt"> is undeclared in </SPAN>S&lt;E&gt;
</PRE>

<P>In addition to recognizing current implementation
practice, it would be practically useful if the locus were
specified instead as after the <I>enum-head</I> or complete
<I>opaque-enum-declaration</I>, as it would allow use of
SFINAE in <TT>std::is_scoped_enum</TT> to distinguish between
scoped and unscoped enumerations rather than requiring
special compiler support.</P>

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

<P>Move the locus to immediately after the <I>enum-head</I>.</P>

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

<BLOCKQUOTE>

The locus of an <I>enum-specifier</I>
<DEL>or <I>opaque-enum-declaration</I></DEL> is immediately after <DEL>the <I>identifier</I>
(if any) in it</DEL> <INS>its <I>enum-head</I>; the locus of an <I>opaque-enum-declaration</I> is immediately after it</INS> (9.7.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]).

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2517"></A><H4>2517.
  
Useless restriction on use of parameter in <I>constraint-expression</I>
</H4>
<B>Section: </B>7.5.7.5&#160; [<A href="https://wg21.link/expr.prim.req.nested">expr.prim.req.nested</A>]
 &#160;&#160;&#160;

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

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

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




<P>According to 7.5.7.5 [<A href="https://wg21.link/expr.prim.req.nested#2">expr.prim.req.nested</A>] paragraph 2,</P>

<BLOCKQUOTE>

<P>A local parameter shall only appear as an unevaluated
operand (7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]) within
the <I>constraint-expression</I>.  [<I>Example 2</I>:</P>

<PRE>
  template&lt;typename T&gt; concept C = requires (T a) {
    requires sizeof(a) == 4; //<SPAN CLASS="cmnt"> OK</SPAN>
    requires a == 0; //<SPAN CLASS="cmnt"> error: evaluation of a constraint variable</SPAN>
  };
</PRE>

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

</BLOCKQUOTE>

<P>However, <TT>a</TT> can't be used in a constant
expression in any event, so the restriction is
meaningless, except for ruling out an expression like
<TT>true ? true : a</TT>, but there seems no reason to
have a special rule for such a case.</P>

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

Remove 7.5.7.5 [<A href="https://wg21.link/expr.prim.req.nested#2">expr.prim.req.nested</A>] paragraph 2, including its example:

<BLOCKQUOTE>

<P><DEL>A local parameter shall only appear as an unevaluated
operand (7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]) within
the <I>constraint-expression</I>.  [<I>Example 2</I>:</DEL></P>

<PRE>
  <DEL>template&lt;typename T&gt; concept C = requires (T a) {
    requires sizeof(a) == 4; //<SPAN CLASS="cmnt"> OK</SPAN>
    requires a == 0; //<SPAN CLASS="cmnt"> error: evaluation of a constraint variable</SPAN>
  };</DEL>
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2518"></A><H4>2518.
  
Conformance requirements and <TT>#error</TT>/<TT>#warning</TT>
</H4>
<B>Section: </B>4.1.1&#160; [<A href="https://wg21.link/intro.compliance.general">intro.compliance.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-01-13


<P>According to 4.1.1 [<A href="https://wg21.link/intro.compliance.general#2.2">intro.compliance.general</A>] bullet 2.2,</P>

<BLOCKQUOTE>

a conforming implementation shall issue at least one diagnostic message

</BLOCKQUOTE>

<P>for an ill-formed program that is not &#8220;no
diagnostic required.&#8221; The relationship between this
diagnostic message and the ones required by
the <TT>#error</TT> and <TT>#warning</TT> preprocessor
directives is not clear. For example, is an implementation
required to emit multiple diagnostics if
multiple <TT>#error</TT> directives are encountered, even
though conformance requires only one?  Could an
implementation count the diagnostic emitted by
<TT>#warning</TT> as satisfying the requirement for an
ill-formed program?</P>

<P>See also issue 745.</P>

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

<P>Add a new paragraph after 4.1.1 [<A href="https://wg21.link/intro.compliance.general#2">intro.compliance.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Although this document states only requirements on C++
implementations, those requirements are often easier to understand if
they are phrased as requirements on programs, parts of programs, or
execution of programs. Such requirements have the following meaning:

<UL>
<LI>
If a program contains no violations of the rules in Clause
Clause 5 [<A href="https://wg21.link/lex">lex</A>] through Clause Clause 33 [<A href="https://wg21.link/thread">thread</A>] and
Annex D, a conforming implementation shall, within its resource limits
as described in Annex B, accept and correctly execute
[ <I>Footnote:</I> ... ] that program.</LI>

<LI>
If a program contains a violation of any diagnosable rule or an
occurrence of a construct described in this document as
&#8220;conditionally-supported&#8221; when the implementation does not
support that construct, a conforming implementation shall issue at
least one diagnostic message.
</LI>

<LI>
If a program contains a violation of a rule for which no diagnostic is
required, this document places no requirement on implementations with
respect to that program.
</LI>

</UL>

<P>[<I>Note</I>: ... &#8212; <I>end note</I>]</P>

<P><INS>Furthermore, a conforming implementation</INS></P>
<UL>
<LI>
<INS>shall not accept a translation unit containing a <TT>#error</TT>
preprocessing directive (15.8 [<A href="https://wg21.link/cpp.error">cpp.error</A>]) unless it is part
of a group skipped by conditional inclusion
(15.2 [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]) and</INS>
</LI>

<LI>
<INS>shall issue at least one diagnostic message for
each <TT>#warning</TT> or <TT>#error</TT> preprocessing directive not
following a <TT>#error</TT> preprocessing directive,
ignoring <TT>#warning</TT> and <TT>#error</TT> preprocessing
directives appearing in groups skipped by conditional inclusion.</INS>
</LI>

</UL>

<P>For classes and class templates, ...</P>

</BLOCKQUOTE>

<P><B>Notes from the November, 2022 meeting</B></P>

<P>EWG review solicited via
<A HREF="https://github.com/cplusplus/papers/issues/1366">cplusplus/papers#1366</A>.</P>

<P><B>EWG 2023-02-06</B></P>

<P>EWG agreed with the suggested resolution, but resolved to amend it
to treat <TT>static_assert</TT> similarly.</P>

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

<OL>

<LI>
<P>Change and add a new paragraph after 4.1.1 [<A href="https://wg21.link/intro.compliance.general#2">intro.compliance.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Although this document states only requirements on C++
implementations, those requirements are often easier to understand if
they are phrased as requirements on programs, parts of programs, or
execution of programs. Such requirements have the following meaning:

<UL>
<LI>
If a program contains no violations of the rules in Clause
Clause 5 [<A href="https://wg21.link/lex">lex</A>] through Clause Clause 33 [<A href="https://wg21.link/thread">thread</A>] and
Annex D, a conforming implementation shall, within its resource limits
as described in Annex B, accept and correctly execute
[ <I>Footnote:</I> ... ] that program.</LI>

<LI class="ins">
If a program contains a violation of a rule for which no diagnostic is
required, this document places no requirement on implementations with
respect to that program.
</LI>

<LI>
<INS>Otherwise, if</INS> <DEL>If</DEL> a program contains a violation of any diagnosable rule or an
occurrence of a construct described in this document as
&#8220;conditionally-supported&#8221; when the implementation does not
support that construct, a conforming implementation shall issue at
least one diagnostic message.
</LI>

<LI>
<DEL>If a program contains a violation of a rule for which no diagnostic is
required, this document places no requirement on implementations with
respect to that program.</DEL>
[<I>Note</I>: During template argument deduction and substitution, certain constructs that in other contexts require a diagnostic are treated differently; see [temp.deduct] &#8212; <I>end note</I>]
</LI>

<P><INS>Furthermore, a conforming implementation</INS></P>
<UL class="ins">
<LI>
shall not accept a preprocessing translation unit containing a <TT>#error</TT>
preprocessing directive (15.8 [<A href="https://wg21.link/cpp.error">cpp.error</A>]),
</LI>

<LI>
shall issue at least one diagnostic message for each <TT>#warning</TT>
or <TT>#error</TT> preprocessing directive not following
a <TT>#error</TT> preprocessing directive in a preprocessing
translation unit, and
</LI>

<LI>
shall not accept a translation unit with
a failed <I>static_assert-declaration</I> (9.1 [<A href="https://wg21.link/dcl.pre">dcl.pre</A>])
<INS>outside an uninstantiated template</INS>.
</LI>

</UL>

</UL>

<P>For classes and class templates, ...</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 5.1 [<A href="https://wg21.link/lex.separate#1">lex.separate</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The text of the program is kept in units called source files in this
document. A source file together with all the headers
(16.4.2.3 [<A href="https://wg21.link/headers">headers</A>]) and source files included
(15.3 [<A href="https://wg21.link/cpp.include">cpp.include</A>]) via the preprocessing directive #include,
less any source lines skipped by any of the conditional inclusion
(15.2 [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]) preprocessing directives, is called a
<I><INS>preprocessing</INS> translation unit</I>.

</BLOCKQUOTE>
</LI>

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


<BLOCKQUOTE>

... The resulting tokens <INS>constitute a <I>translation unit</I>
and</INS> are syntactically and semantically analyzed and
translated <DEL>as a translation unit</DEL>.

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

In a <I><TT>static_assert</TT>-declaration</I>, the
constant-expression is contextually converted to bool and the
converted expression shall be a constant expression
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). If the value of the expression when so
converted is true, the declaration has no
effect. Otherwise, <INS>the <I><TT>static_assert</TT>-declaration</I> has
<I>failed</I>,</INS> the program is ill-formed, and the resulting
diagnostic message (4.1 [<A href="https://wg21.link/intro.compliance">intro.compliance</A>]) should include the text
of the string-literal, if one is supplied.

</BLOCKQUOTE>
</LI>

</OL>

<P><B>CWG 2023-02-10</B></P>

<P>CWG decided to fold P2593R1 (static_assert(false)) into the
proposed resolution.</P>

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

<OL>

<LI>
<P>Change and add a new paragraph after 4.1.1 [<A href="https://wg21.link/intro.compliance.general#2">intro.compliance.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Although this document states only requirements on C++
implementations, those requirements are often easier to understand if
they are phrased as requirements on programs, parts of programs, or
execution of programs. Such requirements have the following meaning:

<UL>
<LI>
If a program contains no violations of the rules in Clause
Clause 5 [<A href="https://wg21.link/lex">lex</A>] through Clause Clause 33 [<A href="https://wg21.link/thread">thread</A>] and
Annex D, a conforming implementation shall, within its resource limits
as described in Annex B, accept and correctly execute
[ <I>Footnote:</I> ... ] that program.</LI>

<LI class="ins">
If a program contains a violation of a rule for which no diagnostic is
required, this document places no requirement on implementations with
respect to that program.
</LI>

<LI>
<INS>Otherwise, if</INS> <DEL>If</DEL> a program contains a violation of any diagnosable rule or an
occurrence of a construct described in this document as
&#8220;conditionally-supported&#8221; when the implementation does not
support that construct, a conforming implementation shall issue at
least one diagnostic message.
</LI>

<LI>
<DEL>If a program contains a violation of a rule for which no diagnostic is
required, this document places no requirement on implementations with
respect to that program.</DEL>
[<I>Note</I>: During template argument deduction and substitution, certain constructs that in other contexts require a diagnostic are treated differently; see [temp.deduct] &#8212; <I>end note</I>]
</LI>

<P><INS>Furthermore, a conforming implementation</INS></P>
<UL class="ins">
<LI>
shall not accept a preprocessing translation unit containing a <TT>#error</TT>
preprocessing directive (15.8 [<A href="https://wg21.link/cpp.error">cpp.error</A>]),
</LI>

<LI>
shall issue at least one diagnostic message for each <TT>#warning</TT>
or <TT>#error</TT> preprocessing directive not following
a <TT>#error</TT> preprocessing directive in a preprocessing
translation unit, and
</LI>

<LI>
shall not accept a translation unit with
a <I>static_assert-declaration</I> that fails (9.1 [<A href="https://wg21.link/dcl.pre">dcl.pre</A>]).
</LI>

</UL>

</UL>

<P>For classes and class templates, ...</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 5.1 [<A href="https://wg21.link/lex.separate#1">lex.separate</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The text of the program is kept in units called source files in this
document. A source file together with all the headers
(16.4.2.3 [<A href="https://wg21.link/headers">headers</A>]) and source files included
(15.3 [<A href="https://wg21.link/cpp.include">cpp.include</A>]) via the preprocessing directive #include,
less any source lines skipped by any of the conditional inclusion
(15.2 [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]) preprocessing directives, is called a
<I><INS>preprocessing</INS> translation unit</I>.

</BLOCKQUOTE>
</LI>

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


<BLOCKQUOTE>

... The resulting tokens <INS>constitute a <I>translation unit</I>
and</INS> are syntactically and semantically analyzed and
translated <DEL>as a translation unit</DEL>.

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

In a <I><TT>static_assert</TT>-declaration</I>, the
constant-expression is contextually converted to bool and the
converted expression shall be a constant expression
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). If the value of the expression when so
converted is true <INS>or the expression is evaluated in the context
of a template definition</INS>, the declaration has no
effect. Otherwise, <INS>the <I><TT>static_assert</TT>-declaration</I>
<I>fails</I>,</INS> the program is ill-formed, and the resulting
diagnostic message (4.1 [<A href="https://wg21.link/intro.compliance">intro.compliance</A>]) should include the text
of the string-literal, if one is supplied.

[ Example:

<PRE>
  static_assert(sizeof(int) == sizeof(void*), "wrong pointer size");
  static_assert(sizeof(int[2]));   //<SPAN CLASS="cmnt"> OK, narrowing allowed</SPAN>
<DIV class="ins">
  template &lt;class T&gt;
  void f(T t) {
    if constexpr (sizeof(T) == sizeof(int)) {
      use(t);
    } else {
      static_assert(false, "must be int-sized");
    }
  }
  
  void g(char c) {
    f(0); //<SPAN CLASS="cmnt"> OK</SPAN>
    f(c); //<SPAN CLASS="cmnt"> error: must be int-sized</SPAN>
  }
  </DIV>
</PRE>
-- end example ]
</BLOCKQUOTE>
</LI>

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


<BLOCKQUOTE>

... The program is ill-formed, no diagnostic required, if:
<UL>
<LI>
no valid specialization<INS>, ignoring
<I><TT>static_assert</TT>-declarations</I> that fail,</INS> can be
generated for a template or a substatement of a constexpr if statement
(8.5.2 [<A href="https://wg21.link/stmt.if">stmt.if</A>]) within a template and the template is not
instantiated, or
</LI>

<LI>...</LI>

</UL>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2520"></A><H4>2520.
  
Template signature and default template arguments
</H4>
<B>Section: </B>3.54&#160; [<A href="https://wg21.link/defns.signature.templ">defns.signature.templ</A>]
 &#160;&#160;&#160;

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

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

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


<P>According to 3.54 [<A href="https://wg21.link/defns.signature.templ">defns.signature.templ</A>], the signature of a
function template includes:</P>

<BLOCKQUOTE>

name, parameter-type-list, enclosing namespace, return
type, <I>template-head</I>, and
trailing <I>requires-clause</I> (if any)

</BLOCKQUOTE>

<P>The mention of the <I>template-head</I> is a change
from previous versions of the Standard, which referred to
the &#8220;template parameter list&#8221;, in order to
include the <I>requires-clause</I> in the signature.
However, <I>template-head</I> is a syntactic nonterminal
and thus includes everything in that production, including
default template arguments. It seems undesirable to make
the default arguments part of the template signature.</P>

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

<P>CWG agrees with the suggested direction.</P>

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

<OL>

<LI>
<P>Change in 3.53 [<A href="https://wg21.link/defns.signature.friend">defns.signature.friend</A>] as follows:</P>

<BLOCKQUOTE>

signature<BR>
&lt;function template&gt;<BR>
name, <I>parameter-type-list</I>,
enclosing namespace, return type, <INS>signature of the</INS> <I>template-head</I>, and
trailing <I>requires-clause</I> (if any)

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 3.54 [<A href="https://wg21.link/defns.signature.templ">defns.signature.templ</A>] as follows:</P>

<BLOCKQUOTE>

signature<BR>
&lt;friend function template with constraint involving enclosing template parameters&gt;<BR>
name, parameter-type-list,
return type, enclosing class, <INS>signature of the</INS> <I>template-head</I>, and trailing <I>requires-clause</I> (if any)

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 3.57 [<A href="https://wg21.link/defns.signature.member">defns.signature.member</A>] as follows:</P>

<BLOCKQUOTE>

signature<BR>
&lt;class member function template&gt;<BR>
name, <I>parameter-type-list</I>, class of which the function is a
member, <I>cv-qualifier</I>s (if any), <I>ref-qualifier</I> (if any),
return type (if any), <INS>signature of the</INS> <I>template-head</I>, and
trailing <I>requires-clause</I> (if any)

</BLOCKQUOTE>

</LI>

<LI>
<P>Add a new section in Clause 3 [<A href="https://wg21.link/intro.defs">intro.defs</A>] as follows:</P>

<BLOCKQUOTE class="ins">

signature<BR>
&lt;<I>template-head</I>&gt;<BR>
template parameter list, excluding template parameter names and default arguments, and <I>requires-clause</I> (if any)

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2521"></A><H4>2521.
  
User-defined literals and reserved identifiers
</H4>
<B>Section: </B>12.6&#160; [<A href="https://wg21.link/over.literal">over.literal</A>]
 &#160;&#160;&#160;

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

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

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


<P>The example in 12.6 [<A href="https://wg21.link/over.literal#8">over.literal</A>] paragraph 8
has the following lines:</P>

<PRE>
  double operator""_Bq(long double);  //<SPAN CLASS="cmnt"> OK: does not use the reserved identifier </SPAN>_Bq<SPAN CLASS="cmnt"> (5.10)</SPAN>
  double operator"" _Bq(long double); //<SPAN CLASS="cmnt"> ill-formed, no diagnostic required:</SPAN>
                                      //<SPAN CLASS="cmnt"> uses the reserved identifier </SPAN>_Bq<SPAN CLASS="cmnt"> (5.10)</SPAN>
</PRE>

<P>The referenced rule in 5.10 [<A href="https://wg21.link/lex.name">lex.name</A>] is in
bullet 3.1:</P>

<BLOCKQUOTE>

Each identifier that contains a double
underscore <TT>__</TT> or begins with an underscore followed
by an uppercase letter is reserved to the implementation for
any use.

</BLOCKQUOTE>

<P>The distinction being drawn in the user-defined literal
example apparently relies on the grammar for
<I>literal-operator-id</I> at the beginning of
12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]:</P>

<UL>
<I>literal-operator-id:</I>
<UL>
<TT>operator</TT> <I>string-literal identifier</I><BR>
<TT>operator</TT> <I>user-defined-string-literal</I>
</UL>
</UL>

<P>The second production does not mention the syntactic
non-terminal <I>identifier</I>, so
the <I>literal-operator-id</I> <TT>operator""_Bq</TT>
presumably does not run afoul of the restriction in
5.10 [<A href="https://wg21.link/lex.name">lex.name</A>]. However, the grammar for
<I>user-defined-string-literal</I> in
5.13.8 [<A href="https://wg21.link/lex.ext">lex.ext</A>] is:</P>

<UL>
<I>user-defined-string-literal:</I>
<UL>
<I>string-literal ud-suffix</I>
</UL>
<BR>
<I>ud-suffix:</I>
<UL>
<I>identifier</I>
</UL>
</UL>

<P>There doesn't seem to be a rule that exempts the
<I>identifier</I> that is the <I>ud-suffix</I> of a
<I>user-defined-string-literal</I> from the restriction in
5.10 [<A href="https://wg21.link/lex.name">lex.name</A>]. Either the example is incorrect
or there needs to be a refinement of the rule in
5.10 [<A href="https://wg21.link/lex.name">lex.name</A>].</P>

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

<P>CWG feels that the ostensible significance of whitespace in this
context is unfortunate. In addition, since the normative rule is not
consistent with the example, CWG solicits EWG input on the handling of
this issue via
<A HREF="https://github.com/cplusplus/papers/issues/1367">cplusplus/papers#1367</A>.</P>

<P><B>EWG 2023-02-06</B></P>

<P>EWG had consensus on "The form of User Defined Literals that
permits a space between the quotes and the name of the literal should
be deprecated, and eventually removed. Additionally, the UDL name
should be excluded from the restriction in 5.10 [<A href="https://wg21.link/lex.name">lex.name</A>] in the
non-deprecated form (sans space)."</P>

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

<OL>

<LI>

<P>Change in 5.10 [<A href="https://wg21.link/lex.name#3">lex.name</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

In addition, some identifiers <INS>appearing as a <I>token</I>
or <I>pp-token</I></INS> are reserved for use by C++ implementations
and shall not be used otherwise; no diagnostic is required.

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

The <I>string-literal</I> or <I>user-defined-string-literal</I> in
a <I>literal-operator-id</I> shall have no <I>encoding-prefix</I> and
shall contain no characters other than the implicit terminating
'\0'. The <I>ud-suffix</I> of the <I>user-defined-string-literal</I>
or the identifier in a <I>literal-operator-id</I> is called
a <I>literal suffix identifier</I>. <INS>The first form
of <I>literal-operator-id</I> is deprecated.</INS> Some literal suffix
identifiers are reserved for future standardization; see
16.4.5.3.6 [<A href="https://wg21.link/usrlit.suffix">usrlit.suffix</A>]. A declaration
whose <I>literal-operator-id</I> uses such a literal suffix identifier
is ill-formed, no diagnostic required.

</BLOCKQUOTE>

</LI>

<LI>

<P>Change in 12.6 [<A href="https://wg21.link/over.literal#8">over.literal</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>
<PRE>
  void operator ""<DEL> </DEL>_km(long double);         //<SPAN CLASS="cmnt"> OK</SPAN>
  string operator "" _i18n(const char*, std::size_t); //<SPAN CLASS="cmnt"> OK<INS>, deprecated</INS></SPAN>
  template &lt;char...&gt; double operator ""<DEL> </DEL>_\u03C0();  //<SPAN CLASS="cmnt"> OK, UCN for lowercase pi</SPAN>
  float operator ""_e(const char*);          //<SPAN CLASS="cmnt"> OK</SPAN>
  float operator ""E(const char*);          //<SPAN CLASS="cmnt"> ill-formed, no diagnostic required:</SPAN>
			    //<SPAN CLASS="cmnt"> reserved literal suffix ([usrlit.suffix], [lex.ext])</SPAN>
  double operator""_Bq(long double);         //<SPAN CLASS="cmnt"> OK, does not use the reserved identifier _Bq ([lex.name])</SPAN>
  double operator"" _Bq(long double);         //<SPAN CLASS="cmnt"> ill-formed, no diagnostic required:</SPAN>
			    //<SPAN CLASS="cmnt"> uses the reserved identifier _Bq ([lex.name])</SPAN>
  float operator " "<DEL> </DEL>B(const char*);         //<SPAN CLASS="cmnt"> error: non-empty string-literal</SPAN>
  string operator ""<DEL> </DEL>5X(const char*, std::size_t);  //<SPAN CLASS="cmnt"> error: invalid literal suffix identifier</SPAN>
  double operator ""<DEL> </DEL>_miles(double);         //<SPAN CLASS="cmnt"> error: invalid parameter-declaration-clause</SPAN>
  template &lt;char...&gt; int operator ""<DEL> </DEL>_j(const char*); //<SPAN CLASS="cmnt"> error: invalid parameter-declaration-clause</SPAN>
  extern "C" void operator ""<DEL> </DEL>_m(long double);    //<SPAN CLASS="cmnt"> error: C language linkage</SPAN>
</PRE>

</BLOCKQUOTE>

</LI>

<LI>

<P>Add a new subclause after D.8 [<A href="https://wg21.link/depr.impldec">depr.impldec</A>]:</P>

<BLOCKQUOTE class="ins">

<P><B>D.9 Literal operator function declarations using an identifier
[depr.lit]</B></P>

<P>A <I>literal-operator-id</I> (12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]) of the form</P>
<PRE>
    <TT>operator</TT> <I>string-literal identifier</I>
</PRE>
is deprecated.
</BLOCKQUOTE>

</LI>

</OL>

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

<P>Some implementers are concerned about the lack of space for
implementation extensions.  The suggestion is to reserve literal
suffix identifiers starting with two underscores for the
implementation in 16.4.5.3.6 [<A href="https://wg21.link/usrlit.suffix">usrlit.suffix</A>]. EWG is invited to
comment on that direction.</P>

<P><B>EWG / LEWG 2023-02-07</B></P>

<P>EWG and LEWG resolved to amend the proposed resolution for CWG2521
to reserve literal suffix identifiers with double underscores anywhere
for implementation use.</P>

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

<OL>

<LI>

<P>Change in 5.10 [<A href="https://wg21.link/lex.name#3">lex.name</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

In addition, some identifiers <INS>appearing as a <I>token</I>
or <I>pp-token</I></INS> are reserved for use by C++ implementations
and shall not be used otherwise; no diagnostic is required.

</BLOCKQUOTE>

</LI>

<LI>

<P>In 5.13.8 [<A href="https://wg21.link/lex.ext">lex.ext</A>], modify all occurrences as follows:</P>

<BLOCKQUOTE>

<PRE>
operator ""<DEL> </DEL><I>X</I>
</PRE>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 5.13.8 [<A href="https://wg21.link/lex.ext#7">lex.ext</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>
<PRE>
long double operator ""<DEL> </DEL>_w(long double);
std::string operator ""<DEL> </DEL>_w(const char16_t*, std::size_t);
unsigned operator ""<DEL> </DEL>_w(const char*);
int main() {
  1.2_w;      //<SPAN CLASS="cmnt"> calls </SPAN>operator ""<DEL> </DEL>_w(1.2L)
  u"one"_w;   //<SPAN CLASS="cmnt"> calls </SPAN>operator ""<DEL> </DEL>_w(u"one", 3)
  12_w;       //<SPAN CLASS="cmnt"> calls </SPAN>operator ""<DEL> </DEL>_w("12")
  "two"_w;    //<SPAN CLASS="cmnt"> error: no applicable literal operator</SPAN>
}
</PRE>
</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

The <I>string-literal</I> or <I>user-defined-string-literal</I> in
a <I>literal-operator-id</I> shall have no <I>encoding-prefix</I> and
shall contain no characters other than the implicit terminating
'\0'. The <I>ud-suffix</I> of the <I>user-defined-string-literal</I>
or the identifier in a <I>literal-operator-id</I> is called
a <I>literal suffix identifier</I>. <INS>The first form
of <I>literal-operator-id</I> is deprecated.</INS> Some literal suffix
identifiers are reserved for future standardization; see
16.4.5.3.6 [<A href="https://wg21.link/usrlit.suffix">usrlit.suffix</A>]. A declaration
whose <I>literal-operator-id</I> uses such a literal suffix identifier
is ill-formed, no diagnostic required.

</BLOCKQUOTE>

</LI>

<LI>

<P>Change in 12.6 [<A href="https://wg21.link/over.literal#8">over.literal</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>
<PRE>
  void operator ""<DEL> </DEL>_km(long double);         //<SPAN CLASS="cmnt"> OK</SPAN>
  string operator "" _i18n(const char*, std::size_t); //<SPAN CLASS="cmnt"> OK<INS>, deprecated</INS></SPAN>
  template &lt;char...&gt; double operator ""<DEL> </DEL>_\u03C0();  //<SPAN CLASS="cmnt"> OK, UCN for lowercase pi</SPAN>
  float operator ""_e(const char*);          //<SPAN CLASS="cmnt"> OK</SPAN>
  float operator ""E(const char*);          //<SPAN CLASS="cmnt"> ill-formed, no diagnostic required:</SPAN>
			    //<SPAN CLASS="cmnt"> reserved literal suffix ([usrlit.suffix], [lex.ext])</SPAN>
  double operator""_Bq(long double);         //<SPAN CLASS="cmnt"> OK, does not use the reserved identifier _Bq ([lex.name])</SPAN>
  double operator"" _Bq(long double);         //<SPAN CLASS="cmnt"> ill-formed, no diagnostic required:</SPAN>
			    //<SPAN CLASS="cmnt"> uses the reserved identifier _Bq ([lex.name])</SPAN>
  float operator " "<DEL> </DEL>B(const char*);         //<SPAN CLASS="cmnt"> error: non-empty string-literal</SPAN>
  string operator ""<DEL> </DEL>5X(const char*, std::size_t);  //<SPAN CLASS="cmnt"> error: invalid literal suffix identifier</SPAN>
  double operator ""<DEL> </DEL>_miles(double);         //<SPAN CLASS="cmnt"> error: invalid parameter-declaration-clause</SPAN>
  template &lt;char...&gt; int operator ""<DEL> </DEL>_j(const char*); //<SPAN CLASS="cmnt"> error: invalid parameter-declaration-clause</SPAN>
  extern "C" void operator ""<DEL> </DEL>_m(long double);    //<SPAN CLASS="cmnt"> error: C language linkage</SPAN>
</PRE>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 16.4.5.3.6 [<A href="https://wg21.link/usrlit.suffix">usrlit.suffix</A>] as follows:</P>

<BLOCKQUOTE>

Literal suffix identifiers (12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]) that do not
start with an underscore are reserved for future standardization.
<INS>Literal suffix identifiers that contain a double
underscore <TT>__</TT> are reserved for use by C++ implementations.</INS>

</BLOCKQUOTE>
</LI>

<LI>

<P>Add a new subclause after D.8 [<A href="https://wg21.link/depr.impldec">depr.impldec</A>]:</P>

<BLOCKQUOTE class="ins">

<P><B>D.9 Literal operator function declarations using an identifier
[depr.lit]</B></P>

<P>A <I>literal-operator-id</I> (12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]) of the form</P>
<PRE>
    <TT>operator</TT> <I>string-literal identifier</I>
</PRE>
is deprecated.
</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2523"></A><H4>2523.
  
Undefined behavior via omitted destructor call in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

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




<P>According to 7.7 [<A href="https://wg21.link/expr.const#5.8">expr.const</A>] bullet 5.8,
one criterion that disqualifies an expression from
being a core constant expression is:</P>

<BLOCKQUOTE>

an operation that would have undefined behavior as specified
in Clause 4 [<A href="https://wg21.link/intro">intro</A>] through
Clause 15 [<A href="https://wg21.link/cpp">cpp</A>]

</BLOCKQUOTE>

<P>One potential source of undefined behavior is the
omission of a call to a destructor for a constructed object,
as described in 6.7.3 [<A href="https://wg21.link/basic.life#5">basic.life</A>] paragraph 5:</P>

<BLOCKQUOTE>

A program may end the lifetime of an object of class type
without invoking the destructor, by reusing or releasing the
storage as described above.  [<I>Note 3:</I>
A <I>delete-expression</I> (7.6.2.9 [<A href="https://wg21.link/expr.delete">expr.delete</A>])
invokes the destructor prior to releasing the
storage. &#8212;<I>end note</I>] In this case, the
destructor is not implicitly invoked and any program that
depends on the side effects produced by the destructor has
undefined behavior.

</BLOCKQUOTE>

<P>For example:</P>

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

  constexpr int test_basic_life_p5() {
    class guard_t {
      int &amp;ref_;
    public:
      explicit constexpr guard_t(int &amp;i) : ref_{i} {}
      constexpr ~guard_t() { ref_ = 42; }
    };

    int result = 0;

    auto alloc = std::allocator&lt;guard_t&gt;{};
    auto pguard = alloc.allocate(1);
    std::construct_at(pguard, result);
    // std::destroy_at(pguard);
    alloc.deallocate(pguard, 1);

    return result;  //<SPAN CLASS="cmnt"> value depends on destructor execution</SPAN>
  }

  int main() {
    constexpr auto v = test_basic_life_p5();
    return v;
  }
</PRE>

<P>It is not clear that it is reasonable to require
implementations to diagnose this form of undefined
behavior in constant expressions.</P>

<P>A somewhat related question is raised by the
restrictions on the use of <TT>longjmp</TT> in
17.13.3 [<A href="https://wg21.link/csetjmp.syn#2">csetjmp.syn</A>] paragraph 2:</P>

<BLOCKQUOTE>

A <TT>setjmp</TT>/<TT>longjmp</TT> call pair has undefined
behavior if replacing the <TT>setjmp</TT>
and <TT>longjmp</TT> by <TT>catch</TT> and <TT>throw</TT>
would invoke any non-trivial destructors for any objects
with automatic storage duration.

</BLOCKQUOTE>

<P>Here the undefined behavior occurs for any non-trivial
destructor that is skipped, not just one for which the
program depends on its side effects, as in
6.7.3 [<A href="https://wg21.link/basic.life#5">basic.life</A>] paragraph 5. Perhaps these two
specifications should be harmonized.</P>

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

<P>The phrase "[a] program that depends on the side effects" may have
these meanings:</P>

<UL>
<LI>the program depends on the side effects if it would have undefined
behavior if they don't happen (which they don't): this would mean the
second half of the sentence has no normative effect and can be
struck</LI>
<LI>the program depends on the side effects if it would have different
observable behavior if (in violation of the standard) the destructor
were actually invoked by the implementation when the object's lifetime
ended</LI>
<LI>something else</LI>
</UL>

<P>The second option would need a fork in the evaluation of constant
expressions to determine whether undefined behavior occurs.</P>

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

<P>Change in 6.7.3 [<A href="https://wg21.link/basic.life#5">basic.life</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

A program may end the lifetime of an object of class type
without invoking the destructor, by reusing or releasing the
storage as described above.  [<I>Note 3:</I>
A <I>delete-expression</I> (7.6.2.9 [<A href="https://wg21.link/expr.delete">expr.delete</A>])
invokes the destructor prior to releasing the
storage. &#8212;<I>end note</I>] In this case, the
destructor is not implicitly invoked<DEL> and any program that
depends on the side effects produced by the destructor has
undefined behavior</DEL>.
<INS>[<I>Note:</I> The correct behavior of a program often depends on
the destructor being invoked for each object of class type.  -- <I>end
note</I>]</INS>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2526"></A><H4>2526.
  
Relational comparison of <TT>void*</TT> pointers
</H4>
<B>Section: </B>7.6.9&#160; [<A href="https://wg21.link/expr.rel">expr.rel</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2020-06-15




<P>Prior to the adoption of paper N3624 (resolving
issue 1512), comparison of
<TT>void*</TT> pointers was explicitly unspecified. The
current wording of 7.6.9 [<A href="https://wg21.link/expr.rel">expr.rel</A>], however,
describes only comparison of &#8220;pointers to
objects&#8221; (paragraphs 4 and 5), but a pointer
to <TT>void</TT> is not a pointer to an object, only an
object pointer type (as opposed to a function pointer type).
Formally, that means that comparing <TT>void*</TT> pointers
is undefined behavior, which seems undesirable.</P>

<P>As a related note, there is implementation divergence
over whether relational comparisons of <TT>void*</TT> pointers
are accepted in constant expressions (when the <TT>void*</TT>
values are converted from pointers that would otherwise be
comparable in constant expressions).</P>

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

<P>Paper N3624 erroneously removed support for <TT>void*</TT> and
function pointer relational comparisons.  That ought to be restored.</P>

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

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

<BLOCKQUOTE>

... Otherwise, the result of each of the operators is unspecified.
<INS>[ Note: A relational operator applied to unequal function
pointers or to unequal pointers to <TT>void</TT> yields an unspecified
result. -- end note ]</INS>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2528"></A><H4>2528.
  
Three-way comparison and the usual arithmetic conversions
</H4>
<B>Section: </B>7.4&#160; [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Cameron DaCamara
 &#160;&#160;&#160;

 <B>Date: </B>2022-01-26




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

<PRE>
  void f(unsigned char i, unsigned ui) {
    i &lt;=&gt; ui;
  }
</PRE>

<P>According to 7.6.8 [<A href="https://wg21.link/expr.spaceship">expr.spaceship</A>] paragraph
4, the usual arithmetic conversions are applied to the
operands. According to 7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>] bullet
1.5, the integral promotions are performed on both
operands, resulting in <TT>i</TT> being converted from
<TT>unsigned char</TT> to <TT>int</TT>. The operands
are then of types <TT>int</TT> and <TT>unsigned int</TT>,
so bullet 1.5.5 applies, further converting <TT>i</TT>
to type <TT>unsigned int</TT>.</P>

<P>Unfortunately, that latter conversion, from <TT>int</TT>
to <TT>unsigned int</TT>, is a narrowing conversion, which
runs afoul of 7.6.8 [<A href="https://wg21.link/expr.spaceship#4.1">expr.spaceship</A>] bullet 4.1, which
prohibits narrowing conversions other than integral to
floating in three-way comparisons.</P>

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

<P>Change 7.4 [<A href="https://wg21.link/expr.arith.conv#1.5">expr.arith.conv</A>] bullet 1.5 as follows:</P>

<BLOCKQUOTE>

<P>Otherwise, <DEL>the integral promotions
(7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>]) shall be performed on both
operands</DEL> <INS>each operand shall be converted to a
common type <I>C</I>. The integral promotion rules
(7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>] shall be used to determine a
type <I>T1</I> and type <I>T2</I> for each
operand</INS>.<SUP>50</SUP> Then the following rules shall
be applied to <DEL>the promoted operands</DEL>
<INS>determine <I>C</I></INS>:</P>

<UL>
<LI><P>If <DEL>both operands have</DEL> <INS><I>T1</I>
and <I>T2</I> are</INS> the same type, <DEL>no further
conversion is needed</DEL> <INS><I>C</I> shall
be that type</INS>.</P></LI>

<LI><P>Otherwise, if <DEL>both operands have</DEL>
<INS><I>T1</I> and <I>T2</I> are both</INS> signed integer
types or both <DEL>have</DEL> <INS>are</INS> unsigned
integer types, <DEL>the operand with the type of lesser
integer conversion rank shall be converted to the type of
the operand</DEL> <INS><I>C</I> shall be the type</INS> with
greater rank.</P></LI>

<LI><P>Otherwise, if the <DEL>operand that has</DEL>
<INS>the type <I>U</I> that is an</INS> unsigned integer
type has rank greater than or equal to the rank of
the <INS>other</INS> type<DEL> of the other operand, the
operand with signed integer type shall be converted to the
type of the operand with unsigned integer
type</DEL><INS>, <I>C</I> shall be <I>U</I></INS>.</P></LI>

<LI><P>Otherwise, if the type <DEL>of the operand with</DEL>
<INS><I>S</I> that is a</INS> signed integer type can
represent all of the values of the <INS>other</INS>
type<DEL> of the operand with unsigned integer type, the
operand with unsigned integer type shall be converted to the
type of the operand with signed integer
type</DEL><INS>, <I>C</I> shall be <I>S</I></INS>.</P></LI>

<LI><P>Otherwise, <DEL>both operands shall be converted to</DEL>
<INS><I>C</I> shall be</INS> the unsigned integer type
corresponding to the <DEL>type of the operand with</DEL>
signed integer type.</P></LI>

</UL>

</BLOCKQUOTE>

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

<P>Change in 7.4 [<A href="https://wg21.link/expr.arith.conv#1.3">expr.arith.conv</A>] bullet 1.3 as follows, adding sub-bullets:</P>

<BLOCKQUOTE>

Otherwise, <DEL>the integral promotions (7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>]) are
performed on both operands</DEL>
<INS>each operand is converted to a common type C. The integral
promotion rules (7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>]) are used to determine a
type T1 and type T2 for each operand</INS>. [ Footnote: ... ] Then the
following rules are applied to <DEL>the promoted
operands</DEL> <INS>determine C</INS>:
<UL>
<LI>If <DEL>both operands have</DEL> <INS>T1 and T2 are</INS> the same type,
<DEL>no further conversion is needed</DEL> <INS>C is that type</INS>.
</LI>
<LI>Otherwise, if <INS>T1 and T2 are</INS> both <DEL>operands have</DEL> 
signed integer types or <INS>are</INS> both <DEL>have</DEL> unsigned
integer types, <DEL>the operand with the type of lesser integer
conversion rank is converted to the type of the operand</DEL> <INS>C
is the type</INS> with greater rank.
</LI>
<LI>Otherwise, <DEL>if the operand that has</DEL> <INS>let U be
the</INS> unsigned integer type <INS>and S be the signed integer type.</INS>
<UL>
<LI>
<INS>If U</INS> has rank greater than or equal to the
rank of <DEL>the type of the other operand, the operand with signed integer
type is converted to the type of the operand with unsigned integer
type</DEL>
<INS>S, C is U</INS>.
</LI>
<LI>Otherwise, if <DEL>the type of the operand with signed integer type</DEL> <INS>S</INS> can
represent all of the values of <DEL>the type of the operand with unsigned
integer type, the operand with unsigned integer type is converted to
the type of the operand with signed integer type</DEL> <INS>U, C is S</INS>.
</LI>
<LI>Otherwise, <DEL>both operands are converted to</DEL> <INS>C is</INS> the
unsigned integer type corresponding to <DEL>the type of the operand with
signed integer type</DEL> <INS>S</INS>.
</LI>
</UL>
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2529"></A><H4>2529.
  
Constant destruction of constexpr references
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

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


<P>According to 9.2.6 [<A href="https://wg21.link/dcl.constexpr#10">dcl.constexpr</A>] paragraph 10,
a constexpr variable must have constant destruction.
However, 7.7 [<A href="https://wg21.link/expr.const#7">expr.const</A>] paragraph 7 only defines
constant destruction for objects, not for references.
Presumably constexpr references should also be able to
have constant destruction, and any temporary object to
which such a reference is bound should also be required
to have constant destruction.</P>

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

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

<BLOCKQUOTE>

A <TT>constexpr</TT> specifier used in an object declaration declares
the object as const. Such an object shall have literal type and shall
be initialized. In any constexpr variable declaration, the
full-expression of the initialization shall be a constant expression
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). A constexpr variable <INS>that is an
object, as well as any temporary to which a constexpr reference is
bound,</INS> shall have constant destruction. [ Example: ... ]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2530"></A><H4>2530.
  
Multiple definitions of enumerators
</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>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Naiver Miigon
 &#160;&#160;&#160;

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




<P>Issue 2494 specified a list of
definable items and required that no translation unit
contain more than one definition of any of those
items. However, the list omits enumeration constants,
implicitly allowing an example like:</P>

<PRE>
  enum E { e, e };
</PRE>

<P>According to 6.1 [<A href="https://wg21.link/basic.pre#3">basic.pre</A>] paragraph 3, an
enumerator is an entity. According to
6.2 [<A href="https://wg21.link/basic.def#2">basic.def</A>] paragraph 2,</P>

<BLOCKQUOTE>

Each entity declared by a <I>declaration</I> is
also <I>defined</I> by that declaration unless: ...

</BLOCKQUOTE>

<P>and enumerators are not on the list of excluded cases, so
an <I>enumerator-definition</I> is a definition.
Furthermore, 6.6 [<A href="https://wg21.link/basic.link#8">basic.link</A>] paragraph 8 says,</P>

<BLOCKQUOTE>

<P>Two declarations of entities declare the same entity if,
considering declarations of unnamed types to introduce their
names for linkage purposes, if any
(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>], 9.7.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]),
they correspond (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]), have the same
target scope that is not a function or template parameter
scope, and either</P>

<UL>
<LI><P>they appear in the same translation unit, or</P></LI>

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

</UL>

</BLOCKQUOTE>

<P>In the example above, both enumerators thus define the
same entity, so the one-definition rule is responsible for
excluding the duplicate definitions but does not do so.</P>

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

Change 6.3 [<A href="https://wg21.link/basic.def.odr#1">basic.def.odr</A>] paragraph 1 as follows:

<BLOCKQUOTE>

Each of the following is termed a <I>definable item</I>:

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

<LI>an enumeration type (9.7.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]),</LI>

<LI><INS>an enumerator,</INS></LI>

<LI>a function (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]),</LI>

<LI>...</LI>

</UL>

</BLOCKQUOTE>

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

<P>Change in 9.7.1 [<A href="https://wg21.link/dcl.enum#2">dcl.enum</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

... The identifiers in an <I>enumerator-list</I> are declared as
constants, and can appear wherever constants are required.
<INS>The same identifier shall not appear as the name of multiple
enumerators in an <I>enumerator-list</I>.</INS>
An <I>enumerator-definition</I> with = gives the associated
<I>enumerator</I> the value indicated by the <I>constant-expression</I>. If
the first <I>enumerator</I> has no <I>initializer</I>, the value of the
corresponding constant is zero. An <I>enumerator-definition</I>
without an <I>initializer</I> gives the enumerator the value obtained by
increasing the value of the previous enumerator by one.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2539"></A><H4>2539.
  
Three-way comparison requiring strong ordering for floating-point types
</H4>
<B>Section: </B>11.10.3&#160; [<A href="https://wg21.link/class.spaceship">class.spaceship</A>]
 &#160;&#160;&#160;

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

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

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




<P>Consider:</P>

<PRE>
  struct MyType {
    int i;
    double d;
    std::strong_ordering operator&lt;=&gt; (const MyType&amp; c) const = default;
  };
</PRE>

<P>The defaulted three-way comparison operator is defined only if it is used, per 11.10.1 [<A href="https://wg21.link/class.compare.default#1">class.compare.default</A>] paragraph 1:</P>

<BLOCKQUOTE>

A comparison operator function for class C that is defaulted on its
first declaration and is not defined as deleted is implicitly defined
when it is odr-used or needed for constant evaluation.

</BLOCKQUOTE>

<P>The current rules make an odr-use of the three-way comparison
operator ill-formed, but it would be preferable if it were deleted
instead.  In particular, 11.10.3 [<A href="https://wg21.link/class.spaceship#2.2">class.spaceship</A>] bullet 2.2 specifies</P>

<BLOCKQUOTE>

If the synthesized three-way comparison of type R between any objects
x<sub>i</sub> and x<sub>i</sub> is not defined, the operator function
is defined as deleted.

</BLOCKQUOTE>

<P>This refers to bullets 1.2 and 1.3 of
11.10.3 [<A href="https://wg21.link/class.spaceship#1">class.spaceship</A>] paragraph 1:</P>

<BLOCKQUOTE>

The <I>synthesized three-way comparison</I> of type R
(17.11.2 [<A href="https://wg21.link/cmp.categories">cmp.categories</A>]) of glvalues a and b of the same type is
defined as follows:
<UL>
<LI>
If <TT>a &lt;=&gt; b</TT> is usable (11.10.1 [<A href="https://wg21.link/class.compare.default">class.compare.default</A>]),
<TT>static_cast&lt;R&gt;(a &lt;=&gt; b)</TT>.</LI>
<LI>Otherwise, if overload
resolution for a &lt;=&gt; b is performed and finds at least one
viable candidate, the synthesized three-way comparison is not defined.</LI>
<LI>
Otherwise, if R is not a comparison category type, or either
the expression a == b or the expression a &lt; b is not usable, the
synthesized three-way comparison is not defined.</LI>

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

</BLOCKQUOTE>

<P>However, <TT>a &lt;=&gt; b</TT> is actually usable, because
11.10.1 [<A href="https://wg21.link/class.compare.default#3">class.compare.default</A>] paragraph 3 defines:</P>

<BLOCKQUOTE>

A binary operator expression <TT>a @ b</TT> is <I>usable</I> if either
<UL>
<LI> a or b
is of class or enumeration type and overload resolution
(12.2 [<A href="https://wg21.link/over.match">over.match</A>]) as applied to <TT>a @ b</TT> results in a usable
candidate, or</LI>

<LI>neither a nor b is of class or enumeration type
and <TT>a @ b</TT> is a valid expression.</LI>
</UL>

</BLOCKQUOTE>

<TT>MyType().d &lt;=&gt; MyType().d</TT> is a valid expression.

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

<BLOCKQUOTE>

The <I>synthesized three-way comparison</I> of type R
(17.11.2 [<A href="https://wg21.link/cmp.categories">cmp.categories</A>]) of glvalues a and b of the same type is
defined as follows:
<UL>
<LI>
If <TT>a &lt;=&gt; b</TT> is usable (11.10.1 [<A href="https://wg21.link/class.compare.default">class.compare.default</A>])
<INS>and</INS>

<UL>
<LI>
<INS>if overload resolution for a direct-initialization of an object
or reference of type R from <TT>a &lt;=&gt; b</TT> results in a usable
candidate</INS>,
<TT>static_cast&lt;R&gt;(a &lt;=&gt; b)</TT><INS>,</INS>
</LI>

<LI>
<INS>otherwise,
the synthesized three-way comparison is not defined</INS>.</LI>
</UL>
</LI>

<LI>Otherwise, if overload
resolution for a &lt;=&gt; b is performed and finds at least one
viable candidate, the synthesized three-way comparison is not defined.</LI>

<LI>
Otherwise, if R is not a comparison category type, or either
the expression a == b or the expression a &lt; b is not usable, the
synthesized three-way comparison is not defined.</LI>

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

</BLOCKQUOTE>

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

<P>A simplification of the wording is sought.</P>

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

<BLOCKQUOTE>

The <I>synthesized three-way comparison</I> of type R
(17.11.2 [<A href="https://wg21.link/cmp.categories">cmp.categories</A>]) of glvalues a and b of the same type is
defined as follows:
<UL>
<LI>
If <TT>a &lt;=&gt; b</TT> is usable (11.10.1 [<A href="https://wg21.link/class.compare.default">class.compare.default</A>])
<INS>and can be explicitly converted to <TT>R</TT> using <TT>static_cast</TT>,</INS>
<TT>static_cast&lt;R&gt;(a &lt;=&gt; b)</TT>.
</LI>

<LI>Otherwise, if overload
resolution for a &lt;=&gt; b is performed and finds at least one
viable candidate, the synthesized three-way comparison is not defined.</LI>

<LI>
Otherwise, if R is not a comparison category type, or either
the expression a == b or the expression a &lt; b is not usable, the
synthesized three-way comparison is not defined.</LI>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2543"></A><H4>2543.
  
<TT>constinit</TT> and optimized dynamic initialization
</H4>
<B>Section: </B>9.2.7&#160; [<A href="https://wg21.link/dcl.constinit">dcl.constinit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Zhihao Yuan
 &#160;&#160;&#160;

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




<P>Subclause 9.2.7 [<A href="https://wg21.link/dcl.constinit#2">dcl.constinit</A>] paragraph 2 states:</P>

<BLOCKQUOTE>

If a variable declared with the <TT>constinit</TT> specifier has
dynamic initialization (6.9.3.3 [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>]), the program is
ill-formed.  [ <I>Note</I>: The constinit specifier ensures that the
variable is initialized during static initialization
(6.9.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>Subclause 6.9.3.2 [<A href="https://wg21.link/basic.start.static#3">basic.start.static</A>] paragraph 3 gives permission
for an implementation to perform static initialization in lieu of
dynamic initialization:</P>

<BLOCKQUOTE>

An implementation is permitted to perform the initialization of a
variable with static or thread storage duration as a static
initialization even if such initialization is not required to be done
statically, provided that ...

</BLOCKQUOTE>

<P>
<TT>constinit</TT> will assuredly not give a diagnostic for
variables that are constant initialized (7.7 [<A href="https://wg21.link/expr.const#2">expr.const</A>] paragraph 2), because those are required to be statically initialized
and thus will never be dynamically initialized.  Conversely,
<TT>constinit</TT> is guaranteed to give a diagnostic for variables
that cannot be statically initialized, for example those with an
initializer whose value depends on runtime conditions.</P>

<P>Between those boundaries, it is unclear whether <TT>constinit</TT>
ought to give a diagnostic for variables whose initializer does
not satisfy the constraints of constant-initialized, yet the
implementation takes advantage of the permission to turn dynamic
initialization into static initialization.  For example,</P>

<PRE>
  float f;
  constinit int * pi = (int*) &amp;f;    // reinterpret_cast<SPAN CLASS="cmnt">, not constant-initialized</SPAN>
</PRE>

<P>The current wording seems to imply that <TT>constinit</TT>
accurately reflects whether dynamic initialization was turned into
static initialization by the implementation.  However, that is
impossible to implement, because such decisions are often made by the
optimizer, which runs later than the compiler front-end
interpreting the program text containing <TT>constinit</TT>.</P>

<P>There is value in permitting <TT>constinit</TT> not to diagnose
some of the dynamic initializations that are turned into static
initializations.</P>

<P>There is also value in having portable semantics of <TT>constinit</TT>.</P>

<P>See also issue 2536.</P>

<P><B>Notes from the November, 2022 meeting</B></P>

<P>CWG seeks the advice of EWG how to proceed with this issue,
via
<A HREF="https://github.com/cplusplus/papers/issues/1379">cplusplus/papers#1379</A>.
</P>

<P><B>EWG 2023-01-19</B></P>

<P>EWG resolved to desire portable, guaranteed semantics
for <TT>constinit</TT>.  That means, <TT>constinit</TT> should produce
a diagnostic if de-jure dynamic initialization is turned into de-facto
static initialization as permitted by
6.9.3.2 [<A href="https://wg21.link/basic.start.static#3">basic.start.static</A>] paragraph 3.</P>

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

<P>Change in 9.2.7 [<A href="https://wg21.link/dcl.constinit#2">dcl.constinit</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If a variable declared with the <TT>constinit</TT> specifier has
dynamic initialization (6.9.3.3 [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>]), the program is
ill-formed<INS>, even if the implementation would perform that
initialization as a static initialization
(6.9.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>])</INS>.  [Note 1: The constinit
specifier ensures that the variable is initialized during static
initialization <DEL>(6.9.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>])</DEL>. &#8212;<I>end
note</I>]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2558"></A><H4>2558.
  
Uninitialized subobjects as a result of an immediate invocation
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

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




<P>Consider:</P>

<PRE>
  struct A {
    int n;
    consteval A() {}
  };
  constexpr A a; //<SPAN CLASS="cmnt"> implementations reject</SPAN>
</PRE>

<P>Paper
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1331r2.pdf">P1331R2</A>
(Permitting trivial default initialization in
constexpr contexts) dropped the restriction that immediate invocations
cannot yield results with some subobjects left uninitialized. It is
unclear whether that change was intentional or accidental.
</P>
<P>
Furthermore, indeterminate values of pointer type are currently not
permitted as the result of a constant expression per
7.7 [<A href="https://wg21.link/expr.const#12.2">expr.const</A>] bullet 12.2; indeterminate values of scalar
types are permitted only due to the absence of a restriction.</P>

<P>This issue is closely related to issue 2536.</P>

<P><B>2022-12-03</B></P>

<P>Forwarded to EWG with
<A HREF="https://github.com/cplusplus/papers/issues/1380">cplusplus/papers#1380</A>.</P>

<P><B>EWG 2023-01-19</B></P>

<P>Uninitialized non-variant direct subobjects should not be allowed
to appear in the result of a constant expression.  There was no
consensus in support of the statements "Union types shall be
initialized such that they have an active member in the result of a
constant expression" and "EWG confirms that padding bits and data
belonging to non-active variant members are permitted to have
indeterminate values in the static initialization of objects".</P>

<P><B>Proposed resolution (approved by CWG 2023-01-27):</B></P>

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

<BLOCKQUOTE>

A constant expression is either a glvalue core constant expression
that refers to an entity that is a permitted result of a constant
expression (as defined below), or a prvalue core constant expression
whose value satisfies the following constraints:

<UL>
<LI>if the value is an object of class type, each non-static data
member of reference type refers to an entity that is a permitted
result of a constant expression,</LI>

<LI><INS>if the value is an object of scalar type, it does not have
indeterminate value (6.7.4 [<A href="https://wg21.link/basic.indet">basic.indet</A>]),</INS></LI>

<LI>...</LI>

<LI>if the value is an object of class or array type, each subobject
satisfies these constraints for the value.</LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2602"></A><H4>2602.
  
consteval defaulted functions
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

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

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




<P>It is not clear whether a defaulted consteval function is still an
immediate function even if it is not a valid constexpr function. For
example:</P>

<PRE>
  template &lt;typename Ty&gt;
  struct A {
    Ty n;
    consteval A() {}
  };

  template &lt;typename Ty&gt;
  struct B {
    Ty n;
    consteval B() = default;
  };

  A&lt;int&gt; a;
  B&lt;int&gt; b;
</PRE>

<P>The declarations of <TT>a</TT> and <TT>b</TT> should both fail due
to an uninitialized member <TT>n</TT> in each of <TT>A</TT>
and <TT>B</TT>. The <TT>= default</TT>; should not make a
difference. However, there is implementation divergence. We should be
able to lean on 7.7 [<A href="https://wg21.link/expr.const#5.5">expr.const</A>] bullet 5.5 to handle this
when the immediate invocation is required.</P>

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

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

<BLOCKQUOTE>

If the instantiated template specialization of a
constexpr <INS>templated</INS> function <DEL>template or member
function of a class template</DEL> would fail to satisfy the
requirements for a constexpr function, that specialization is still a
constexpr function, even though a call to such a function cannot
appear in a constant expression.
<INS>Similarly, if the instantiated template specialization of a
consteval <INS>templated</INS> function would fail to satisfy the
requirements for a consteval function, that specialization is still an
immediate function, even though an immediate invocation would be
ill-formed.</INS> If no specialization of the template would satisfy
the requirements for a constexpr <INS>or consteval</INS> function when
considered as a non-template function, the template is ill-formed, no
diagnostic required.

</BLOCKQUOTE>

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

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

<BLOCKQUOTE>

If the instantiated template specialization of a
constexpr <INS>templated</INS> function <DEL>template or member
function of a class template</DEL> would fail to satisfy the
requirements for a constexpr function, that specialization is still a
constexpr function, even though a call to such a function cannot
appear in a constant expression.
<INS>Similarly, if the instantiated template specialization of a
consteval <INS>templated</INS> function would fail to satisfy the
requirements for a consteval function, that specialization is still an
immediate function, even though an immediate invocation would be
ill-formed.</INS>

</BLOCKQUOTE>

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

<P>The proposed wording is possibly not addressing the point of the
issue; the issue has been retracted from the WG21 plenary straw polls
for further consideration in CWG.</P>

<P><B>Proposed resolution (approved by CWG 2023-01-27):</B></P>

<OL>

<LI>

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

<BLOCKQUOTE>

<DEL>The definition of a constexpr function shall satisfy the following
requirements:</DEL>

<INS>A function is <I>constexpr-suitable</I> if:</INS>

<UL>
<LI>it <DEL>shall</DEL> <INS>is</INS> not <DEL>be</DEL> a coroutine
(9.5.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>])<DEL>;</DEL> <INS>, and</INS>
</LI>

<LI>if the function is a constructor or destructor, its
class <DEL>shall</DEL> <INS>does</INS> not have any virtual base
classes.</LI>
</UL>

<INS>Except for instantiated constexpr functions, non-templated
constexpr functions shall be constexpr-suitable.</INS>

</BLOCKQUOTE>

</LI>

<LI>

<P>Delete 9.2.6 [<A href="https://wg21.link/dcl.constexpr#4">dcl.constexpr</A>] paragraph 4:</P>

<BLOCKQUOTE>

<DEL>If the instantiated template specialization of a constexpr
function template or member function of a class template would fail to
satisfy the requirements for a constexpr function, that specialization
is still a constexpr function, even though a call to such a function
cannot appear in a constant expression.</DEL>

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

... The function call operator or any given operator template
specialization is a constexpr function if either the
corresponding <I>lambda-expression</I>'s <I>parameter-declaration-clause</I>
is followed by constexpr or consteval, or it <DEL>satisfies the
requirements for a constexpr function</DEL> <INS>is
constexpr-suitable</INS> (9.2.6 [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]). ...

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

<UL>
<LI>an invocation of an instantiated constexpr function
that <DEL>fails to satisfy the requirements for a constexpr
function</DEL> <INS>is not constexpr-suitable</INS>;</LI>
</UL>

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

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

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

A defaulted destructor is a constexpr destructor if it <DEL>satisfies
the requirements for a constexpr function</DEL> <INS>is
constexpr-suitable</INS> (9.2.6 [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]).

</BLOCKQUOTE>

</LI>

</OL>

<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>ready
 &#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 [SUPERSEDED]:</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>

<P><B>CWG 2022-12-02</B></P>

<P>The resolution proposed above is incorrect: T is the parameter for
the overall search and C is the parameter for the S(N,C)
construction. Highlight that fact in paragraph 2.</P>

<P><B>Proposed resolution (approved by CWG 2023-01-06):</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 <DEL>N</DEL> <INS>M</INS> from a
program point P is a single search in X for <DEL>N</DEL> <INS>M</INS>
from P unless X is the scope of a class or class template T, in which
case the following steps define the result of the search.  [<I>Note
1:</I> The result differs only if <DEL>N</DEL> <INS>M</INS> is
a <I>conversion-function-id</I> or if the single search would find
nothing. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>

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

<BLOCKQUOTE>

The lookup set for <INS>a name</INS> N in <INS>a class or class
template</INS> C, called S(N, C), consists of two component sets: the
declaration set, a set of members named N ; and the subobject set, a
set of subobjects where declarations of these members were found
(possibly via <I>using-declaration</I>s). In the declaration set, type
declarations (including injected-class-names) are replaced by the
types they designate. S(N, C) is calculated as follows:

</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(<DEL>N</DEL><INS>M</INS>, T). If it is an invalid set, the program
is ill-formed.  If it differs from the result of a search in T
for <DEL>N</DEL> <INS>M</INS> in a complete-class context
(11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]) of T , 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 <DEL>N</DEL> <INS>M</INS> is a
non-dependent <I>conversion-function-id</I>, conversion function
templates that are members of T are considered. For each such template
F, the lookup set S(t, T) 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>]). The members of the
declaration set of each such lookup set, which shall not be an invalid
set, are included in the result.

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2658"></A><H4>2658.
  
Trivial copying of unions in core constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

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


<P>Consider:</P>

<PRE>
  struct A { char c; int x; };
  union U { A a; };
  constexpr int f() {
    U u;
    u.a.c = 1;
    u.a.x = 2;
    U v = u; //<SPAN CLASS="cmnt"> indeterminate padding bytes read!</SPAN>
    return u.a.x;
  }
  extern constexpr int x = f();
</PRE>

<P>
Subclause 7.7 [<A href="https://wg21.link/expr.const#5.11">expr.const</A>] bullet 5.11 added by
P1331R2 prohibits lvalue-to-rvalue conversion of objects having
indeterminate value during evaluation of a core constant
expression. Trivial copy constructors of unions copy the object
representation (not just the active member). The new prohibition
causes cases where bytes not involved in the value presentation of the
active member and having indeterminate values would prevent a union
from being copied by a trivial copy constructor (for example, the
padding bytes in the above case).</P>

<P>
Note: The source of a union copy is never a prvalue within the
evaluation of a trivial copy constructor because the reference
parameter is bound to a glvalue.</P>

<P><B>Proposed resolution (January, 2023):</B></P>

<P>Add a new paragraph after 7.7 [<A href="https://wg21.link/expr.const#6">expr.const</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<P>... to an object whose lifetime began within the evaluation of E.</P>

<P class="ins">
For the purposes of determining whether <I>E</I> is a core constant
expression, lvalue-to-rvalue conversion of an object of indeterminate
value during the evaluation of a call to a trivial copy/move
constructor or copy/move assignment operator of a union does not
disqualify <I>E</I> from being a core constant expression unless the
active member of the source union object contains a subobject of
indeterminate value.
</P>

</BLOCKQUOTE>

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

<P>Add a new paragraph after 7.7 [<A href="https://wg21.link/expr.const#6">expr.const</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<P>... to an object whose lifetime began within the evaluation of E.</P>

<P class="ins">
For the purposes of determining whether <I>E</I> is a core constant
expression, the evaluation of a call to a trivial copy/move
constructor or copy/move assignment operator of a union is considered
to copy/move the active member of the union, if any.
[ Note: The copy/move of the active member is trivial. -- end note ]</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2659"></A><H4>2659.
  
Missing feature-test macro for lifetime extension in range-for loop
</H4>
<B>Section: </B>15.11&#160; [<A href="https://wg21.link/cpp.predefined">cpp.predefined</A>]
 &#160;&#160;&#160;

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

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

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


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

<P>Paper P2718R0 (Wording for P2644R1 Fix for Range-based for Loop),
adopted at the November, 2022 meeting, omitted a consideration of a
feature-test macro, although one is desirable.</P>

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

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

<PRE>
  __cpp_range_based_for <DEL>201603L</DEL> <INS>202211L</INS>
</PRE>

<BR><BR><HR>
<A NAME="2662"></A><H4>2662.
  
Example for member access control vs. overload resolution
</H4>
<B>Section: </B>11.8.1&#160; [<A href="https://wg21.link/class.access.general">class.access.general</A>]
 &#160;&#160;&#160;

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

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

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


<P>Issue 600 was resolved by P1787R6, but
no example was added.</P>

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

<P>Change in 11.8.1 [<A href="https://wg21.link/class.access.general#4">class.access.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

... When a <I>using-declarator</I> is named, access control is applied to
it, not to the declarations that replace it. For an overload set,
access control is applied only to the function selected by overload
resolution.

<P class="ins">[ Example:</P>
<PRE class="ins">
  struct S {
    void f(int);
  private:
    void f(double);
  };

  void g(S* sp) {
    sp-&gt;f(2);    //<SPAN CLASS="cmnt"> OK, access control applied after overload resolution</SPAN>
  }
</PRE>
<P class="ins">-- end example ]</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2664"></A><H4>2664.
  
Deduction failure in CTAD for alias templates
</H4>
<B>Section: </B>12.2.2.9&#160; [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
 &#160;&#160;&#160;

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

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

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




<P>Subclause 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#3">over.match.class.deduct</A>] paragraph 3 has an exception
only for deduction failure for non-deduced contexts when deducing the
return type from the <I>defining-type-id</I>, but not for other cases
where deduction fails according to 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#2">temp.deduct.type</A>] paragraph 2. For example,</P>

<PRE>
  template &lt;class S1, class S2&gt; struct C {
    C(...);
  };

  template&lt;class T1&gt; C(T1) -&gt; C&lt;T1, T1&gt;;
  template&lt;class T1, class T2&gt; C(T1, T2) -&gt; C&lt;T1 *, T2&gt;;

  template&lt;class V1, class V2&gt; using A = C&lt;V1, V2&gt;;

  C c1{""};
  A a1{""};

  C c2{"", 1};
  A a2{"", 1};
</PRE>

<P>resulting in <TT>A</TT> having neither of these deduction guides.
There is implementation divergence in the handling of this
example.</P>

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

<P>We could say that cases where P involves a template parameter and A
is not of the same form (under 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#8">temp.deduct.type</A>] paragraph 8) are non-deduced contexts for the purpose of these
deductions. That should be enough to make it clear what happens for
a2, where we'd deduce <TT>T2 = V2</TT>, and not deduce anything
for <TT>T1</TT>, but wouldn't fix <TT>a1</TT> due to the inconsistent
deductions for <TT>T1</TT>; maybe this is what MSVC is doing. We could
further fix <TT>a1</TT> by allowing inconsistent deductions and
treating them as if no value was deduced. Another option might be to
do independent deductions for each template argument of the
<I>simple-template-id</I>, and then try to merge the results for template
arguments where deduction was successful; that'd be clearer that
deduction can't fail, but would deduce less.</P>

<P><B>CWG 2023-02-08</B></P>

<P>In the example, <TT>A</TT> is the most trivial alias template
imaginable; having this cause issues depending on the details
of <TT>C</TT> is concerning.</P>

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

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


<BLOCKQUOTE>

... For each function or function template f in the guides of the
template named by the <I>simple-template-id</I> of
the <I>defining-type-id</I>, the template arguments of the return type
of f are deduced from the <I>defining-type-id</I> of A according to
the process in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>] with the exception that
deduction does not fail if not all template arguments are
deduced. <INS>If deduction fails for another reason, proceed with an
empty set of deduced template arguments</INS> Let g denote the result
of substituting these deductions into f. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2667"></A><H4>2667.
  
Named module imports do not import macros
</H4>
<B>Section: </B>15.5&#160; [<A href="https://wg21.link/cpp.import">cpp.import</A>]
 &#160;&#160;&#160;

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

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

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


<P>It should be clarified via an example or a note that named module
imports do not make macros available.</P>

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

<OL>

<LI>

<P>Change in 10.3 [<A href="https://wg21.link/module.import#7">module.import</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

... These rules can in turn lead to the importation of yet more
translation units.
<INS>[ Note: Such indirect importation does not make macros available,
because a translation unit is a sequence of tokens in translation
phase 7 (5.2 [<A href="https://wg21.link/lex.phases">lex.phases</A>]). Macros can be made available by
directly importing header units as described in
15.5 [<A href="https://wg21.link/cpp.import">cpp.import</A>]. -- end note ]</INS>

</BLOCKQUOTE>

</LI>

<LI>

<P>Add to the example in 15.5 [<A href="https://wg21.link/cpp.import#8">cpp.import</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

<PRE>
  import "a.h";  //<SPAN CLASS="cmnt"> point of definition of #1, #2, and #3, point of undefinition of #1 in "e.h"</SPAN>
  import "d.h";  //<SPAN CLASS="cmnt"> point of definition of #4 and #5 in "e.h"</SPAN>
  int a = Y;     //<SPAN CLASS="cmnt"> OK, active macro definitions #2 and #4 are valid redefinitions</SPAN>
  int c = Z;     //<SPAN CLASS="cmnt"> error: active macro definitions #3 and #5 are not valid redefinitions of Z</SPAN>
</PRE>

<INS>Module unit <TT>f</TT>:</INS>

<PRE class="ins">
export module f;
export import "a.h";

int a = Y;    // <SPAN CLASS="cmnt">OK</SPAN>
</PRE>

<INS>Translation unit #1:</INS>

<PRE class="ins">
import f;
int x = Y;   //<SPAN CLASS="cmnt"> error: </SPAN>Y<SPAN CLASS="cmnt"> is neither a defined macro nor a declared name</SPAN>
</PRE>

-- end example ]
</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2673"></A><H4>2673.
  
User-declared spaceship vs. built-in operators
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

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

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




<P>Consider:</P>

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

  enum class E : int {
    Lo = 0,
    Hi = 1
  };

  constexpr auto operator&lt;=&gt;(E lhs, E rhs) -&gt; std::strong_ordering {
    return (int)rhs &lt;=&gt; (int)lhs;
  }

  //<SPAN CLASS="cmnt"> everybody agrees this is true</SPAN>
  static_assert((E::Lo &lt;=&gt; E::Hi) == std::strong_ordering::greater);

  //<SPAN CLASS="cmnt"> gcc rejects this, msvc and clang accept</SPAN>
  static_assert(E::Lo &gt; E::Hi);  // <SPAN CLASS="cmnt">#1</SPAN>
</PRE>

<P>The intent here is for the user-provided <TT>operator&lt;=&gt;</TT>
to suppress the built-in <TT>operator&lt;=&gt;</TT> for <TT>E</TT>.
And gcc, clang, and msvc all agree that this does happen when the
comparison expression explicitly uses <TT>a &lt;=&gt; b</TT>.</P>

<P>But when the comparison expression is a @ b for one of the
relational operators, gcc disagrees, conforming to
12.2.2.3 [<A href="https://wg21.link/over.match.oper#3.3">over.match.oper</A>] bullet 3.3:</P>

<BLOCKQUOTE>

For all other operators, the built-in candidates include all of the
candidate operator functions defined in 12.5 [<A href="https://wg21.link/over.built">over.built</A>]
that, compared to the given operator, ...
do not have the same parameter-type-list as any non-member candidate
that is not a function template specialization.

</BLOCKQUOTE>

<P>The issue is that, for #1, the
user-provided <TT>operator&lt;=&gt;</TT> is not a non-member
candidate, but a rewritten candidate.  A similar situation arises for
a user-declared <TT>operator==</TT>, which will be called for <TT>e1
== e2</TT>, but not for <TT>e1 != e2</TT>.  Again, clang and MSVC
disagree.</P>

<P><B>Proposed resolution (January, 2023) [SUPERSEDED]:</B></P>

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

<UL>

<LI>...</LI>

<LI>do not have the same parameter-type-list as any non-member <INS>or
rewritten</INS> candidate that is not a function template
specialization.
</LI>

</UL>

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

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

<UL>

<LI>...</LI>

<LI>do not have the same parameter-type-list as any non-member candidate <INS>or
rewritten non-member candidate</INS> that is not a function template
specialization.
</LI>

</UL>

<BR><BR><HR>
<A NAME="2674"></A><H4>2674.
  
Prohibit explicit object parameters for constructors
</H4>
<B>Section: </B>11.4.5.1&#160; [<A href="https://wg21.link/class.ctor.general">class.ctor.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Erich Keane
 &#160;&#160;&#160;

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




<P>Constructors are not intended to have explicit object parameters,
but the standard is missing a corresponding prohibition.</P>

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

<P>Add a new paragraph after 11.4.5.1 [<A href="https://wg21.link/class.ctor.general#7">class.ctor.general</A>] paragraph 7 as
follows:</P>

<BLOCKQUOTE>

<P>A constructor shall not be a coroutine.</P>

<P class="ins">A constructor shall not have an explicit object
parameter (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]).</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2678"></A><H4>2678.
  
<TT>std::source_location::current</TT> is unimplementable
</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>ready
 &#160;&#160;&#160;

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

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




<P>Consider:</P>

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

  inline char *f() {
    static char array[std::source_location::current().line()];
    return array;
  }
</PRE>

<P>The sequence of tokens comprising the definition of <TT>f</TT> can
appear in multiple translation units, on different lines. The
one-definition rule is not violated.  Thus, there is a single
function <TT>f</TT> in the program with a unique static local
object <TT>array</TT>, but that object would have a different type in
each translation unit.  It is unclear how to implement this, absent
the conservative approach of always returning a value-initialized
object from <TT>std::source_location::current</TT>, which would defeat
its purpose.</P>

<P>Possible approaches to resolve this issue might include:
<UL>
<LI>Do not mark the <TT>source_location</TT> accessors constexpr; they
are not deterministic.</LI>
<LI>Prohibit calls to <TT>source_location</TT> accessors during
constant evaluation unless the <TT>current()</TT> call happened in a
context that can only appear once in a program.</LI>
<LI>Do not mark the <TT>current</TT> function constexpr / consteval.</LI>
<LI>Change the ODR to prohibit calling the <TT>current</TT> function
in an inline function or in a function template.</LI>
</UL>

</P>

<P><B>2023-01-08</B></P>

<P>Forwarded to LWG / LEWG via
<A HREF="https://github.com/cplusplus/papers/issues/1416">cplusplus/papers#1416</A>,
by decision of the CWG chair.</P>

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

<P>EWG approves of the approach for CWG2678 of changing the ODR to
make use of <TT>source_location</TT> in a way that causes an inline
function/function template/etc to 'be different' be an ODR
violation.</P>

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

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

<BLOCKQUOTE>

<UL>
<LI>
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.</LI>
<LI class="ins">
In each such definition, corresponding manifestly constant-evaluated expressions that are not value-dependent shall have the same value
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>], 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr">temp.dep.constexpr</A>]).
</LI>
<LI>In each such
definition, the overloaded operators referred to, the implicit calls
to conversion functions, constructors, operator new functions and
operator delete functions, shall refer to the same function.
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2681"></A><H4>2681.
  
Deducing member array type from string literal
</H4>
<B>Section: </B>12.2.2.9&#160; [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2020-03-17




<P>Consider:</P>

<PRE>
  template&lt;typename T, std::size_t N&gt;
  struct A {
    T array[N];
  };

  A a = { "meow" };
</PRE>

<P>The current wording says in 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#1.8">over.match.class.deduct</A>] bullet 1.8:</P>

<BLOCKQUOTE>

<UL>

<LI>if ei is of array type and xi is a <I>braced-init-list</I>
or <I>string-literal</I>, Ti is an rvalue reference to the declared
type of ei, and</LI>

<LI>...</LI>

</UL>

</BLOCKQUOTE>

<P>This will fail overload resolution, because a string literal (which
is an lvalue) does not match a parameter of type <TT>T
(&amp;&amp;)[N]</TT>.</P>

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

<OL>

<LI>

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

<BLOCKQUOTE>

<UL>

<LI>if e<sub>i</sub> is of array type and x<sub>i</sub> is
a <I>braced-init-list</I>
<DEL>or <I>string-literal</I></DEL>, T<sub>i</sub> is an rvalue
reference to the declared type of e<sub>i</sub>, and</LI>

<LI><INS>if e<sub>i</sub> is of array type and x<sub>i</sub> is
a <I>string-literal</I>, T<sub>i</sub> is an lvalue reference to
the <INS>const-qualified</INS> declared type of e<sub>i</sub>,
and</INS></LI>

<LI>...</LI>

</UL>

</BLOCKQUOTE>

</LI>

<LI>

<P>Append to the example in 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#2">over.match.class.deduct</A>] paragraph 2 as
follows:</P>

<BLOCKQUOTE>

<PRE>
  G g(true, 'a', 1); //<SPAN CLASS="cmnt"> OK, deduces G&lt;char, bool&gt;</SPAN>
</PRE>
<PRE class="ins">
  template&lt;class T, std::size_t N&gt;
  struct H {
    T array[N];
  };
  template&lt;class T, std::size_t N&gt;
  struct I {
    volatile T array[N];
  };
  template&lt;std::size_t N&gt;
  struct J {
    unsigned char array[N];
  };

  H h = { "abc" };  //<SPAN CLASS="cmnt"> OK, deduces </SPAN>H&lt;char, 4&gt;<SPAN CLASS="cmnt"> (not </SPAN>T = const char<SPAN CLASS="cmnt">)</SPAN>
  I i = { "def" };  //<SPAN CLASS="cmnt"> OK, deduces </SPAN>I&lt;char, 4&gt;
  J j = { "ghi" };  //<SPAN CLASS="cmnt"> error: cannot bind reference to array of unsigned char to array of char in deduction</SPAN>
</PRE>

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2682"></A><H4>2682.
  
Templated function vs. function template
</H4>
<B>Section: </B>13.1&#160; [<A href="https://wg21.link/temp.pre">temp.pre</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Matthew House
 &#160;&#160;&#160;

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


<P>In 13.1 [<A href="https://wg21.link/temp.pre#8">temp.pre</A>] paragraph 8, the phrase "templated
entity" is defined.  The derived term "templated function" is never
actually defined, but is intended to apply to function templates as
well as non-template members of class templates. Similarly, the
phrases "templated variable" and "templated class" should be properly
defined.</P>

<P><B>Proposed resolution (approved by CWG 2023-01-27):</B></P>

<OL>

<LI>

<P>Change in 9.2.9.6.1 [<A href="https://wg21.link/dcl.spec.auto.general#12">dcl.spec.auto.general</A>] paragraph 12 as follows:</P>

<BLOCKQUOTE>

Return type deduction for a templated <DEL>entity that is a</DEL>
function <DEL>or function template</DEL> with a placeholder in its
declared type occurs when the definition is instantiated even if the
function body contains a return statement with a non-type-dependent
operand.

</BLOCKQUOTE>

</LI>

<LI>

<P>Change in 13.1 [<A href="https://wg21.link/temp.pre#8">temp.pre</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

[<I>Note 6:</I> A local class, a local or block variable, or a friend
function defined in a templated entity is a templated
entity. &#8212;<I>end note</I>]<BR>

<INS>A <I>templated function</I> is a function template or a function
that is templated. A <I>templated class</I> is a class template or a
class that is templated. A <I>templated variable</I> is a variable
template or a variable that is templated.</INS>

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2685"></A><H4>2685.
  
Aggregate CTAD, string, and brace elision
</H4>
<B>Section: </B>12.2.2.9&#160; [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2020-07-14




<P>Consider:</P>

<PRE>
  template &lt;class T&gt;
  struct A {
    T ar[4];
  };
  A a = { "foo" }; 
</PRE>

<P>Subclause 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#1.5">over.match.class.deduct</A>] bullet 1.5 specifies:</P>

<BLOCKQUOTE>

For each xi, let ei be the corresponding aggregate element of C or of
one of its (possibly recursive) subaggregates that would be
initialized by xi (9.4.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]) if

<UL>
<LI>
brace elision is not considered for any aggregate element that has a
dependent non-array type or an array type with a value-dependent
bound, and
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>The normative rule does not properly consider arrays with dependent
element type, initialized by a string literal.  MSVC accepts, gcc and
clang reject the example.</P>

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

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

<BLOCKQUOTE>

For each xi, let ei be the corresponding aggregate element of C or of
one of its (possibly recursive) subaggregates that would be
initialized by xi (9.4.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]) if

<UL>
<LI>
brace elision is not considered for any aggregate element that has
<UL>
<LI>a dependent non-array type <DEL>or</DEL> <INS>,</INS>
</LI>
<LI>an array type with a value-dependent bound, <INS>or</INS>
</LI>
<LI>
<INS>a string literal as the corresponding initializer and that
has an array type whose element type is a (possibly cv-qualified)
template parameter or is a dependent type specified with
a <I>qualified-id</I> whose <I>nested-name-specifier</I> is dependent
or with a <I>decltype-specifier</I>;</INS> and</LI>
</UL>

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

</BLOCKQUOTE>

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

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

<BLOCKQUOTE>

For each xi, let ei be the corresponding aggregate element of C or of
one of its (possibly recursive) subaggregates that would be
initialized by xi (9.4.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]) if

<UL>
<LI>
brace elision is not considered for any aggregate element that has
<UL>
<LI>a dependent non-array type <DEL>or</DEL> <INS>,</INS>
</LI>
<LI>an array type with a value-dependent bound, <INS>or</INS>
</LI>
<LI>
<INS>an array type with a dependent array element type
and x<sub>i</sub> is a string literal;</INS> and</LI>
</UL>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2690"></A><H4>2690.
  
Semantics of defaulted move assignment operator for unions
</H4>
<B>Section: </B>11.4.6&#160; [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Cassio Neri
 &#160;&#160;&#160;

 <B>Date: </B>2023-01-20


<P>Subclause 11.4.6 [<A href="https://wg21.link/class.copy.assign#13">class.copy.assign</A>] paragraph 13 does not specify
the semantics of a defaulted move assignment operator:</P>

<BLOCKQUOTE>

The implicitly-defined copy assignment operator for a union <TT>X</TT> copies
the object representation (6.8.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of <TT>X</TT>. ...

</BLOCKQUOTE>

<P>In contrast, the corresponding rule for move constructors is present in 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#15">class.copy.ctor</A>] paragraph 15:</P>

<BLOCKQUOTE>

The implicitly-defined copy/move constructor for a union <TT>X</TT> copies the
object representation (6.8.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of <TT>X</TT>. ...

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-01-27):</B></P>

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

<BLOCKQUOTE>

The implicitly-defined copy<INS>/move</INS> assignment operator for a
union <TT>X</TT> copies the object representation
(6.8.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of <TT>X</TT>. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2691"></A><H4>2691.
  
<I>hexadecimal-escape-sequence</I> is too greedy
</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>Fraser Gordon
 &#160;&#160;&#160;

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




<P>The lexer grammar production <I>hexadecimal-escape-sequence</I>
matches text of the form <TT>\x{20}ab</TT> due to its recursive
definition.</P>

<P><B>Proposed resolution (approved by CWG 2023-01-27):</B></P>

<P>Change in 5.13.3 [<A href="https://wg21.link/lex.ccon">lex.ccon</A>] as follows:</P>

<BLOCKQUOTE>
<PRE>
<I>hexadecimal-escape-sequence</I> :
     \x <DEL><I>hexadecimal-digit</I></DEL> <INS><I>simple-hexadecimal-digit-sequence</I></INS>
     <DEL><I>hexadecimal-escape-sequence hexadecimal-digit</I></DEL>
     \x{ <I>simple-hexadecimal-digit-sequence</I> }
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2695"></A><H4>2695.
  
Semantic ignorability of attributes
</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>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Timur Doumler
 &#160;&#160;&#160;

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


<P>EWG resolved to reflect the understanding of semantic ignorability
of attributes in a note.</P>

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

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

<BLOCKQUOTE>

[<I>Note 4:</I> A program is ill-formed if it contains an attribute
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 can apply or the
syntax rules for the attribute's <I>attribute-argument-clause</I>, if
any.  &#8212;<I>end note</I>]

<INS>[<I>Note:</I> The <I>attribute</I>s specified in
9.12 [<A href="https://wg21.link/dcl.attr">dcl.attr</A>] have optional semantics: given a well-formed
program, removing all instances of any one of those <I>attribute</I>s
results in a program whose set of possible executions
(4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>]) for a given input is a subset of those of
the original program for the same input, absent implementation-defined
guarantees with respect to that <I>attribute</I>. -- end note ]</INS>

</BLOCKQUOTE>

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