<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;P2922R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2023-06-16</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
     June, 2023 meeting
    </H2></CENTER>
<BR><P>
    References in this document reflect the section and paragraph
    numbering of document
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4944.pdf">WG21 N4944</A>.
   </P>
<HR>
<A NAME="170"></A><H4>170.
  
Pointer-to-member conversions
</H4>
<B>Section: </B>7.3.13&#160; [<A href="https://wg21.link/conv.mem">conv.mem</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>16 Sep 1999





<P>The descriptions of explicit
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast#9">expr.static.cast</A>] paragraph 9)
 and
implicit (7.3.13 [<A href="https://wg21.link/conv.mem#2">conv.mem</A>] paragraph 2)

pointer-to-member conversions differ in two significant ways:</P>

<OL>
<LI>In a <TT>static_cast</TT>, a conversion in which the class in
the target pointer-to-member type is a base of the class in which
the member is declared is permitted and required to work correctly,
as long as the resulting pointer-to-member is eventually
dereferenced with an object whose dynamic type contains the
member.  That is, the class of the target pointer-to-member type
is not required to contain the member referred to by the value
being converted.  The specification of implicit pointer-to-member
conversion is silent on this question.

<P>(This situation cannot arise in an implicit pointer-to-member
conversion where the source value is something like <TT>&amp;X::f</TT>,
since you can only implicitly convert from pointer-to-base-member
to pointer-to-derived-member.  However, if the source value is
the result of an explicit "up-cast," the target type of the
conversion might still not contain the member referred to by the
source value.)</P>
</LI>

<LI>The target type in a <TT>static_cast</TT> is allowed to be
more cv-qualified than the source type; in an implicit conversion,
however, the cv-qualifications of the two types are required to
be identical.</LI>
</OL>

<P>The first difference seems like an oversight.  It is not clear
whether the latter difference is intentional or not.</P>

<P>(See also issue 794.)</P>

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

<P>The second concern is NAD; implicit conversions allow chaining a
pointer-to-member conversion with a qualification conversion.</P>

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

<OL>

<LI>
<P>Change in 7.3.13 [<A href="https://wg21.link/conv.mem#2">conv.mem</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A prvalue of type &#8220;pointer to member of B of type cv T&#8221;,
where B is a class type, can be converted to a prvalue of type
&#8220;pointer to member of D of type cv T&#8221;, where D is a
complete class derived (11.7 [<A href="https://wg21.link/class.derived">class.derived</A>]) from B. If B is an
inaccessible (11.8 [<A href="https://wg21.link/class.access">class.access</A>]), ambiguous
(6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]), or virtual (11.7.2 [<A href="https://wg21.link/class.mi">class.mi</A>])
base class of D, or a base class of a virtual base class of D, a
program that necessitates this conversion is ill-formed.
<INS>If class D does not contain the original member and is not a base class of the class containing the original member, the behavior is undefined.  Otherwise,</INS>
<DEL>The</DEL> <INS>the</INS> result of
the conversion refers to the same member as the pointer to member
before the conversion took place, but it refers to the base class
member as if it were a member of the derived class. The result refers
to the member in D's instance of B. Since the result has type
&#8220;pointer to member of D of type cv T&#8221;, indirection through
it with a D object is valid. The result is the same as if indirecting
through the pointer to member of B with the B subobject of D.  The
null member pointer value is converted to the null member pointer
value of the destination type. [ Footnote: ... ]

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

... If class B contains the original member, or is a base <DEL>or
derived</DEL> class of the class containing the original member, the
resulting pointer to member points to the original member. ...

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="1353"></A><H4>1353.
  
Array and variant members and deleted special member functions
</H4>
<B>Section: </B>11.4.5&#160; [<A href="https://wg21.link/class.ctor">class.ctor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-08-16




<P>The specification of when a defaulted special member function is to
be defined as deleted sometimes overlooks variant and array members.</P>

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

<OL>

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

<BLOCKQUOTE>

A defaulted default constructor for class X is defined as deleted if:
<UL>
<LI>
<DEL>X is a union that has a variant member with a non-trivial
default constructor and no variant member of X has a default member
initializer,</DEL>
</LI>
<LI>
<DEL>X is a non-union class that has a variant member M
with a non-trivial default constructor and no variant member of the
anonymous union containing M has a default member initializer,</DEL>
</LI>
<LI>
any non-static data member with no default member initializer
(11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]) is of reference type,
</LI>
<LI>
any non-variant non-static data member of const-qualified type
(or <INS>possibly multi-dimensional</INS> array thereof)
with no <I>brace-or-equal-initializer</I> is not
const-default-constructible (9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]),
</LI>
<LI>
X is a union and all of its variant members are of const-qualified type (or
<INS>possibly multi-dimensional</INS> array thereof),
</LI>
<LI>
X is a non-union class and all members of any
anonymous union member are of const-qualified type (or <INS>possibly multi-dimensional</INS> array thereof),
</LI>
<LI>
any potentially constructed subobject, except for a non-static data
member with a <I>brace-or-equal-initializer</I> <INS>or a variant
member of a union where another non-static data member has
a <I>brace-or-equal-initializer</I></INS>, has class type M
(or <INS>possibly multi-dimensional</INS> array thereof)
and <DEL>either M has no default constructor or</DEL> overload
resolution (12.2 [<A href="https://wg21.link/over.match">over.match</A>]) as applied to find M's
corresponding constructor <DEL>results in an ambiguity or in a
function that is deleted or inaccessible from the defaulted default
constructor</DEL> <INS>either does not result in a usable candidate
(12.2.1 [<A href="https://wg21.link/over.match.general">over.match.general</A>]) or, in the case of a variant member, selects a
non-trivial function</INS>, or
</LI>
<LI>
any potentially constructed subobject has <DEL>a type with</DEL>
<INS>class type M (or possibly multi-dimensional array thereof) and M has</INS>
a destructor that is deleted or inaccessible from the defaulted default
constructor.
</LI>
</UL>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

... A defaulted copy/move constructor for a class X is
defined as deleted (9.5.3 [<A href="https://wg21.link/dcl.fct.def.delete">dcl.fct.def.delete</A>]) if X has:
<UL>
<LI>
a potentially constructed subobject of type M (or <INS>possibly multi-dimensional</INS> array thereof)
<DEL>that cannot be copied/moved because</DEL> <INS>for which</INS>
overload resolution (12.2 [<A href="https://wg21.link/over.match">over.match</A>]), as applied to find
M's corresponding constructor, <DEL>results in an ambiguity or a
function that is deleted or inaccessible from the defaulted
constructor</DEL> <INS>either does not result in a usable candidate
(12.2.1 [<A href="https://wg21.link/over.match.general">over.match.general</A>]) or, in the case of a variant member, selects a
non-trivial function</INS>,
</LI>
<LI>
<DEL>a variant member whose corresponding constructor as selected by
overload resolution is non-trivial,</DEL>
</LI>
<LI>
any potentially constructed subobject of <DEL>a type with</DEL>
<INS>class type M (or possibly multi-dimensional array thereof) where M has</INS> a
destructor that is deleted or inaccessible from the defaulted
constructor, or,
</LI>
<LI>
for the copy constructor, a non-static data member of rvalue reference type.
</LI>
</UL>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

A defaulted copy/move assignment operator for class X is defined as
deleted if X has:
<UL>
<LI>
<DEL>a variant member with a non-trivial
corresponding assignment operator and X is a union-like class, or</DEL>
</LI>
<LI>
a non-static data member of const non-class type (or
<INS>possibly multi-dimensional</INS> array thereof), or
</LI>
<LI>
a non-static data member of reference type, or
</LI>
<LI>
a direct non-static data member of class type M (or <INS>possibly
multi-dimensional</INS> array thereof) or a direct base class M that
cannot be copied/moved because overload resolution
(12.2 [<A href="https://wg21.link/over.match">over.match</A>]), as applied to find M's corresponding
assignment operator, <DEL>results in an ambiguity or a function that
is deleted or inaccessible from the defaulted assignment
operator</DEL> <INS>either does not result in a usable candidate
(12.2.1 [<A href="https://wg21.link/over.match.general">over.match.general</A>]) or, in the case of a variant member,
selects a non-trivial function</INS>.
</LI>
</UL>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

A defaulted destructor for a class X is defined as deleted if:
<UL>
<LI>
<DEL>X is a union-like class that has a variant member with a non-trivial
destructor,</DEL>
</LI>
<LI>
any potentially constructed subobject has class
type M (or <INS>possibly multi-dimensional</INS> array thereof) and M has a <DEL>deleted</DEL> destructor <INS>that is deleted</INS> or <DEL>a
destructor that</DEL> is inaccessible from the defaulted destructor
<INS>or, in the case of a variant member, is non-trivial</INS>,
</LI>
<LI>
or, for a virtual destructor, lookup of the non-array deallocation
function results in an ambiguity or in a function that is deleted or
inaccessible from the defaulted destructor.
</LI>
</UL>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="1642"></A><H4>1642.
  
Missing requirements for prvalue operands
</H4>
<B>Section: </B>7.6&#160; [<A href="https://wg21.link/expr.compound">expr.compound</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Joseph Mansfield
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-15


<P>Although the note in 7.2.1 [<A href="https://wg21.link/basic.lval#1">basic.lval</A>] paragraph 1
states that</P>

<BLOCKQUOTE>

The discussion of each built-in operator in
Clause 7 [<A href="https://wg21.link/expr">expr</A>] indicates the category of the value
it yields and the value categories of the operands it
expects

</BLOCKQUOTE>

<P>in fact, many of the operators that take prvalue operands
do not make that requirement explicit.  Possible approaches
to address this failure could be a blanket statement that an
operand whose value category is not stated is assumed to be
a prvalue; adding prvalue requirements to each operand
description for which it is missing; or changing the
description of the usual arithmetic conversions to state
that they imply the lvalue-to-rvalue conversion, which would
cover the majority of the omissions.</P>

<P>(See also issue 1685, which deals with
an inaccurately-specified value category.)</P>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

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

<BLOCKQUOTE>

Whenever a glvalue appears as an operand of an operator
that <DEL>expects</DEL> <INS>requires</INS> a prvalue for that
operand, the lvalue-to-rvalue (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]),
array-to-pointer (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]), or function-to-pointer
(7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]) standard conversions are applied to
convert the expression to a prvalue. ...

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

... A standard conversion sequence will be applied to an expression if
necessary to convert it to <INS>an expression having</INS> a required
destination type <INS>and value category</INS>. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Add to the bulleted list in 7.4 [<A href="https://wg21.link/expr.arith.conv#1">expr.arith.conv</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... This pattern is called the usual arithmetic conversions, which are
defined as follows:
<UL>
<LI class="ins">
The lvalue-to-rvalue conversion (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]) is
applied to each operand and the resulting prvalues are used in place
of the original operands for the remainder of this section.</LI>
<LI>If either operand is of scoped enumeration
type (9.7.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]), no conversions are performed; if
the other operand does not have the same type, the expression is
ill-formed.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

... For a call to a non-member function or to a static member
function, the postfix expression shall <INS>be</INS>
either <DEL>be</DEL> an lvalue that refers to a function (in which
case the function-to-pointer standard conversion
(7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]) is suppressed on the postfix expression),
or <DEL>have</DEL> <INS>a prvalue of</INS> function pointer type.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#7">expr.unary.op</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

The operand of the unary + operator shall <DEL>have</DEL> <INS>be a
prvalue of</INS> arithmetic, unscoped enumeration, or pointer type and
the result is the value of the argument. Integral promotion is
performed on integral or enumeration operands. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#8">expr.unary.op</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

The operand of the unary - operator shall <DEL>have</DEL> <INS>be a
prvalue of</INS> arithmetic or unscoped enumeration type and the
result is the negative of its operand. Integral promotion is performed
on integral or enumeration operands. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#10">expr.unary.op</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

The operand of the ~ operator shall <DEL>have</DEL> <INS>be a prvalue
of</INS> integral or unscoped enumeration type. Integral promotions
are performed. ...

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

... <DEL>The operand shall be of pointer to object type or of class
type.</DEL> If <INS>the operand is</INS> of class type, <DEL>the
operand</DEL> <INS>it</INS> is contextually implicitly converted
(7.3 [<A href="https://wg21.link/conv">conv</A>]) to a pointer to object type. [ Footnote:
... ] <INS>Otherwise, it shall be a prvalue of pointer to object
type.</INS> The <I>delete-expression</I> has type void.

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

<P>The binary operator .* binds its second operand, which shall
be <INS>a prvalue</INS> of type &#8220;pointer to member of T&#8221;
to its first operand, which shall be ...</P>

<P>The binary operator -&gt;* binds its second operand, which shall be
<INS>a prvalue</INS> of type &#8220;pointer to member of T&#8221; to
its first operand, which shall be ...</P>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

The additive operators + and - group left-to-right.
<DEL>The</DEL> <INS>Each operand shall be a prvalue. If both operands
have arithmetic or unscoped enumeration type, the</INS> usual
arithmetic conversions (7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are performed
<DEL>for operands of arithmetic or enumeration type</DEL>.
<INS>Otherwise, if one operand has arithmetic or unscoped enumeration
type, integral promotion is applied (7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>]) to
that operand.  A converted or promoted operand is used in place of the
corresponding original operand for the remainder of this
section.</INS> ...
For addition, either both operands shall
have arithmetic <DEL>or unscoped enumeration</DEL> type, or one operand shall be
a pointer to a completely-defined object type and the other shall have
integral <DEL>or unscoped enumeration</DEL> type.

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>

For subtraction, one of the following shall hold:
<UL>
<LI>both operands have arithmetic <DEL>or unscoped enumeration</DEL>
type; or</LI>
<LI>both operands are pointers to cv-qualified or cv-unqualified
versions of the same completely-defined object type; or</LI>
<LI>the left operand is a pointer to a completely-defined object type
and the right operand has integral <DEL>or unscoped enumeration</DEL>
type.</LI>
</UL>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

... The operands shall be <INS>prvalues</INS> of integral or unscoped
enumeration type and integral promotions are performed. ...

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
Otherwise, the initial value of the object being initialized is the
(possibly converted) value of the initializer expression. A standard
conversion sequence (7.3 [<A href="https://wg21.link/conv">conv</A>]) <DEL>will
be</DEL> <INS>is</INS> used<DEL>, if necessary,</DEL> to convert the
initializer expression to <INS>a prvalue of</INS> the cv-unqualified
version of the destination type; no user-defined conversions are
considered. ...</LI>

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

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="1973"></A><H4>1973.
  
Which <I>parameter-declaration-clause</I> in a <I>lambda-expression</I>?
</H4>
<B>Section: </B>7.5.5.2&#160; [<A href="https://wg21.link/expr.prim.lambda.closure">expr.prim.lambda.closure</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dinka Ranns
 &#160;&#160;&#160;

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




<P>According to 7.5.5.2 [<A href="https://wg21.link/expr.prim.lambda.closure#3">expr.prim.lambda.closure</A>] paragraph 3,</P>

<BLOCKQUOTE>

The closure type for a <I>lambda-expression</I> has a public inline
function call operator (for a non-generic lambda) or function call
operator template (for a generic lambda) (12.4.4 [<A href="https://wg21.link/over.call">over.call</A>])
whose parameters and return type are described by
the <I>lambda-expression</I>'s <I>parameter-declaration-clause</I>
and <I>trailing-return-type</I> respectively, and
whose <I>template-parameter-list</I> consists of the
specified <I>template-parameter-list</I>, if any.

</BLOCKQUOTE>

<P>This is insufficiently precise because the <I>trailing-return-type</I>
might itself contain a <I>parameter-declaration-clause</I>.</P>

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

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

<BLOCKQUOTE>

If
a <I>lambda-declarator</I> does not <DEL>include a</DEL>
<INS>start with a parenthesized</INS>
<I>parameter-declaration-clause</I>, it is as if <TT>()</TT> were
inserted at the start of the <I>lambda-declarator</I>.
<INS>A <I>lambda-expression</I>'s <I>parameter-declaration-clause</I>
is the (possibly empty) <I>parameter-declaration-clause</I> of
the <I>lambda-expression</I>'s <I>lambda-declarator</I>.</INS>
If the <I>lambda-declarator</I> does not include
a <I>trailing-return-type</I>, the lambda return type is auto, which
is deduced from return statements as described in
9.2.9.6 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>].

</BLOCKQUOTE>

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

<OL>

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

<BLOCKQUOTE>

The closure type for a <I>lambda-expression</I> has a public inline
function call operator (for a non-generic lambda) or function call
operator template (for a generic lambda) (12.4.4 [<A href="https://wg21.link/over.call">over.call</A>])
whose parameters and return type are <DEL>described by</DEL> <INS>those of</INS>
the <I>lambda-expression</I>'s <I>parameter-declaration-clause</I>
and <I>trailing-return-type</I> respectively, and
whose <I>template-parameter-list</I> consists of the
specified <I>template-parameter-list</I>, if any.

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

<DEL>If a <I>lambda-declarator</I> does not include
a <I>parameter-declaration-clause</I>, it is as if <TT>()</TT> were
inserted at the start of the <I>lambda-declarator</I>.</DEL>
<INS>A <I>lambda-expression</I>'s <I>parameter-declaration-clause</I>
is the <I>parameter-declaration-clause</I> of
the <I>lambda-expression</I>'s <I>lambda-declarator</I>, if any, or empty otherwise.</INS>
If the <I>lambda-declarator</I> does not include
a <I>trailing-return-type</I>, the lambda return type is auto, which
is deduced from return statements as described in
9.2.9.6 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>].

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2485"></A><H4>2485.
  
Bit-fields in integral promotions
</H4>
<B>Section: </B>7.3.7&#160; [<A href="https://wg21.link/conv.prom">conv.prom</A>]
 &#160;&#160;&#160;

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

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

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


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

<BLOCKQUOTE>

A prvalue for an integral bit-field
(11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>]) can be converted to a prvalue
of type <TT>int</TT> if <TT>int</TT> can represent all the
values of the bit-field; otherwise, it can be converted
to <TT>unsigned int</TT> if <TT>unsigned int</TT> can
represent all the values of the bit-field. If the bit-field
is larger yet, no integral promotion applies to it. If the
bit-field has an enumerated type, it is treated as any other
value of that type for promotion purposes.

</BLOCKQUOTE>

<P>This description has several problems. First, the
&#8220;bit-field&#8221; semantic property only makes sense
for glvalue expressions, so it's unclear why these rules are
described as applying to a prvalue. Perhaps this should be
rephrased as something like &#8220;An expression that was a
bit-field glvalue prior to the application of the
lvalue-to-rvalue conversion&#8221;?</P>

<P>Second, suppose that <TT>char32_t</TT> is wider than
<TT>int</TT>. Per paragraph 2, a <TT>char32_t</TT> prvalue
promotes to <TT>unsigned long</TT> (because <TT>unsigned
long</TT> is necessarily at least 32 bits wide). But per
paragraph 5, a <TT>char32_t : 32</TT> bitfield does not
promote. This seems inconsistent.</P>

<P>Finally, it is not clear that the usual integral
promotions are not applied to bit-fields. This should be
made explicit.</P>

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

<OL>

<LI>
<P>Insert a paragraph before 7.3.7 [<A href="https://wg21.link/conv.prom#1">conv.prom</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE class="ins">
For the purposes of 7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>], a <I>converted bit-field</I>
is a prvalue that is the result of an lvalue-to-rvalue conversion
(7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]) applied to a bit-field
(11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>]).
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.3.7 [<A href="https://wg21.link/conv.prom#1">conv.prom</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A prvalue <DEL>of</DEL> <INS>that is not a converted bit-field and
has</INS> an integer type other than bool, char8_t, char16_t,
char32_t, or wchar_t whose integer conversion rank
(6.8.6 [<A href="https://wg21.link/conv.rank">conv.rank</A>]) is less than the rank of int can be
converted to a prvalue of type int if int can represent all the values
of the source type; otherwise, the source prvalue can be converted to
a prvalue of type unsigned int.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.3.7 [<A href="https://wg21.link/conv.prom#4">conv.prom</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A prvalue of an unscoped enumeration type whose underlying type is
fixed (9.7.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]) can be converted to a prvalue of
its underlying type. Moreover, if integral promotion can be applied to
its underlying type, a prvalue of an unscoped enumeration type whose
underlying type is fixed can also be converted to a prvalue of the
promoted underlying type.
<INS>[ Note: A converted bit-field of enumeration type is treated as
any other value of that type for promotion purposes. -- end note
]</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.3.7 [<A href="https://wg21.link/conv.prom#5">conv.prom</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

A <DEL>prvalue for an integral bit-field
(11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>])</DEL> <INS>converted bit-field of
integral type</INS> can be converted to a prvalue of type int if int
can represent all the values of the bit-field; otherwise, it can be
converted to unsigned int if unsigned int can represent all the values
of the bit-field. <DEL>If the bit-field is larger yet, no integral
promotion applies to it. If the bit-field has enumeration type, it is
treated as any other value of that type for promotion purposes.</DEL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Move 7.3.7 [<A href="https://wg21.link/conv.prom#2">conv.prom</A>] paragraph 2 after paragraph 5 and
change as follows:</P>

<BLOCKQUOTE>

A prvalue of type char8_t, char16_t, char32_t, or wchar_t
(6.8.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>])
<INS>(including a converted bit-field that was not already promoted to
int or unsigned int according to the rules above)</INS> can be
converted to a prvalue of the first of the following types that can
represent all the values of its underlying type: int, unsigned int,
long int, unsigned long int, long long int, <DEL>or</DEL> unsigned
long long int<DEL>. If none of the types in that list can represent
all the values of its underlying type, a prvalue of type char8_t,
char16_t, char32_t, or wchar_t can be converted to a prvalue
of</DEL> <INS>, or</INS> its underlying type.

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2519"></A><H4>2519.
  
Object representation of a bit-field
</H4>
<B>Section: </B>6.8.1&#160; [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]
 &#160;&#160;&#160;

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

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

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


<P>6.7.2 [<A href="https://wg21.link/intro.object">intro.object</A>] clearly implies that bit-fields
are objects; paragraphs 8-9 contain phrases like
&#8220;unless an object is a bit-field...&#8221; and
&#8220;a non-bit-field subobject&#8221;. However, the
definition of &#8220;object representation&#8221; in
6.8.1 [<A href="https://wg21.link/basic.types.general#4">basic.types.general</A>] paragraph 4 is,</P>

<BLOCKQUOTE>

The <I>object representation</I> of an object of
type <TT>T</TT> is the sequence of <I>N</I> <TT>unsigned
char</TT> objects taken up by the object of type <TT>T</TT>,
where <I>N</I> equals <TT>sizeof(T)</TT>.

</BLOCKQUOTE>

<P>and thus fails to address bit-fields, which are not
necessarily composed of a sequence of complete bytes.</P>

<P>The C Standard (6.2.6.1 paragraph 4) says,</P>

<BLOCKQUOTE>

Values stored in bit-fields consist of <I>m</I> bits, where
<I>m</I> is the size specified for the bit-field.  The
object representation is the set of <I>m</I> bits the
bit-field comprises in the addressable storage unit holding
it.

</BLOCKQUOTE>

<P>Presumably similar wording could be adopted for C++.</P>

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

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

<BLOCKQUOTE>

The <I>object representation</I> of <DEL>an object
of</DEL> <INS>a</INS> type <TT>T</TT> is the sequence of
<I>N</I> <TT>unsigned char</TT> objects taken up by
<DEL>the</DEL> <INS>a non-bit-field complete</INS> object of type
<TT>T</TT>, where <I>N</I> equals <TT>sizeof(T)</TT>.  The <I>value
representation</I> of <DEL>an object of</DEL> <INS>a</INS>
type <TT>T</TT> is the set of bits <INS>in the object representation
of T</INS> that participate in representing a value of type <TT>T</TT>.
<INS>The object and value representation of a non-bit-field complete
object of type <TT>T</TT> are the bytes and bits, respectively, of the
object corresponding to the object and value representation of its
type. The object representation of a bit-field object is the sequence
of <I>N</I> bits taken up by the object, where <I>N</I> is the width
of the bit-field (11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>]).  The value
representation of a bit-field object is the set of bits in the object
representation that participate in representing its value. </INS> Bits
in the object representation <INS>of a type or object</INS> that are
not part of the value representation are padding bits. For trivially
copyable types, the value representation is a set of bits in the
object representation that determines a value, which is one discrete
element of an implementation-defined set of values. [ Footnote: ... ]

</BLOCKQUOTE>

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

<P>Additional drafting is needed to constrain the definition to
complete object types.</P>

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

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

<BLOCKQUOTE>

The <I>object representation</I> of <DEL>an object
of</DEL> <INS>a complete object</INS> type <TT>T</TT> is the sequence of
<I>N</I> <TT>unsigned char</TT> objects taken up by
<DEL>the</DEL> <INS>a non-bit-field complete</INS> object of type
<TT>T</TT>, where <I>N</I> equals <TT>sizeof(T)</TT>.  The <I>value
representation</I> of <DEL>an object of</DEL> <INS>a</INS>
type <TT>T</TT> is the set of bits <INS>in the object representation
of T</INS> that participate in representing a value of type <TT>T</TT>.
<INS>The object and value representation of a non-bit-field complete
object of type <TT>T</TT> are the bytes and bits, respectively, of the
object corresponding to the object and value representation of its
type. The object representation of a bit-field object is the sequence
of <I>N</I> bits taken up by the object, where <I>N</I> is the width
of the bit-field (11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>]).  The value
representation of a bit-field object is the set of bits in the object
representation that participate in representing its value. </INS> Bits
in the object representation <INS>of a type or object</INS> that are
not part of the value representation are padding bits. For trivially
copyable types, the value representation is a set of bits in the
object representation that determines a value, which is one discrete
element of an implementation-defined set of values. [ Footnote: ... ]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2542"></A><H4>2542.
  
Is a closure type a structural type?
</H4>
<B>Section: </B>7.5.5.2&#160; [<A href="https://wg21.link/expr.prim.lambda.closure">expr.prim.lambda.closure</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>Consider:</P>

<PRE>
  template &lt;auto V&gt;
  void foo() {}

  void bar() {
    foo&lt;[i = 3] { return i; }&gt;();
  }
</PRE>

<P>It is unclear whether the data members of a closure type are public
or private. This makes a difference, since it affects whether a
closure type is a structural type or not
(13.2 [<A href="https://wg21.link/temp.param#7">temp.param</A>] paragraph 7:</P>

<BLOCKQUOTE>

A <I>structural type</I> is one of the following:

<UL>
<LI>
a scalar type, or</LI>

<LI>
an lvalue reference type, or</LI>

<LI>a literal class type with the following properties:

<UL>
<LI>
all base classes and non-static data members are public and non-mutable and
</LI>
<LI>the types of all
bases classes and non-static data members are structural types or
(possibly multi-dimensional) array thereof.
</LI>
</UL>

</LI>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-03-30):</B></P>

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

<BLOCKQUOTE>

... The closure type is not an aggregate type
(9.4.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]) <INS>and not a structural type
(13.2 [<A href="https://wg21.link/temp.param">temp.param</A>])</INS>. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2550"></A><H4>2550.
  
Type "reference to <I>cv</I> <TT>void</TT>" outside of a declarator
</H4>
<B>Section: </B>9.3.4.3&#160; [<A href="https://wg21.link/dcl.ref">dcl.ref</A>]
 &#160;&#160;&#160;

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

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

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


<P>9.3.4.3 [<A href="https://wg21.link/dcl.ref#1">dcl.ref</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

A declarator that specifies the type &#8220;reference to <I>cv</I>
<TT>void</TT>&#8221; is ill-formed.

</BLOCKQUOTE>

<P>A <I>declarator</I> does not contain the
leading <I>decl-specifier-seq</I> of a declaration, so the following
example is not covered by the prohibition:</P>

<PRE>
  void f(void&amp; x);
</PRE>

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

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

<BLOCKQUOTE>

<DEL>A declarator that specifies</DEL> <INS>Forming</INS> the type
&#8220;reference to <I>cv</I> <TT>void</TT>&#8221; is ill-formed.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2552"></A><H4>2552.
  
Constant evaluation of non-defining variable declarations
</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-03-21


<P>Paper
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2242r3.html">P2242</A>
(Non-literal variables (and labels and gotos) in constexpr functions)
added 7.7 [<A href="https://wg21.link/expr.const#5.2">expr.const</A>] bullet 5.2:</P>

<BLOCKQUOTE>

<UL>
<LI>
a control flow that passes through a declaration of a variable with
static (6.7.5.2 [<A href="https://wg21.link/basic.stc.static">basic.stc.static</A>]) or thread
(6.7.5.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]) storage duration;
</LI>
</UL>

</BLOCKQUOTE>

<P>It seems that block-scope extern (i.e. non-defining) declarations
are covered by the above bullet, but only definitions should be in
view here.</P>

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

<OL>
<LI>

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

<BLOCKQUOTE>

<UL>
<LI>
a control flow that passes through a declaration of a <INS>block</INS>
variable <INS>(6.4.3 [<A href="https://wg21.link/basic.scope.block">basic.scope.block</A>])</INS> with static
(6.7.5.2 [<A href="https://wg21.link/basic.stc.static">basic.stc.static</A>]) or thread
(6.7.5.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]) storage duration;
</LI>
</UL>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2663"></A><H4>2663.
  
Example for member redeclarations with <I>using-declaration</I>s
</H4>
<B>Section: </B>9.9&#160; [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]
 &#160;&#160;&#160;

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

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

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


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

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

<OL>

<LI>
<P>Add an example to 9.9 [<A href="https://wg21.link/namespace.udecl#8">namespace.udecl</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE class="ins">

[ Example:

<PRE>
struct C {
  int i;
};

struct D1 : C { };
struct D2 : C { };

struct D3 : D1, D2 {
  using D1::i;   //<SPAN CLASS="cmnt"> OK, equivalent to </SPAN>using C::i
  using D1::i;   //<SPAN CLASS="cmnt"> error: duplicate</SPAN>
  using D2::i;   //<SPAN CLASS="cmnt"> error: duplicate, also names </SPAN>C::i
};
</PRE>

-- end example ]
</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

<PRE>
  using B::x;
  using A::x;              //<SPAN CLASS="cmnt"> OK, hides </SPAN>struct B::x
  <INS>using A::x;              //<SPAN CLASS="cmnt"> OK, does not conflict with previous </SPAN>using A::x</INS>
  x = 99;                  //<SPAN CLASS="cmnt"> assigns to </SPAN>A::x
  struct x x1;             // x1<SPAN CLASS="cmnt"> has class type </SPAN>B::x
}
</PRE>

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

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

<P>There is implementation divergence in handling this example.</P>

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

<P>P1787R6 clarified that the example added to 9.9 [<A href="https://wg21.link/namespace.udecl#10">namespace.udecl</A>] paragraph 10 is accepted, even in the non-function case.</P>

<BR><BR><HR>
<A NAME="2683"></A><H4>2683.
  
Default arguments for member functions of templated nested classes
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#160;&#160;&#160;

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

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

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


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

<BLOCKQUOTE>

Except for member functions of class templates, the default arguments
in a member function definition that appears outside of the class
definition are added to the set of default arguments provided by the
member function declaration in the class definition; the program is
ill-formed if a default constructor (11.4.5.2 [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>]),
copy or move constructor (11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]), or copy or
move assignment operator (11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]) is so
declared. Default arguments for a member function of a class template
shall be specified on the initial declaration of the member function
within the class template.

</BLOCKQUOTE>

<P>That rule appears to allow adding default arguments for member
functions of classes that are nested within class templates, for
example:</P>

<PRE>
  template&lt;class&gt; struct A { struct B { void c(int); }; };
  template&lt;class T&gt; void A&lt;T&gt;::B::c(int = 0) {}
</PRE>

<P>MSVC accepts; gcc and clang reject.</P>

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

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

<BLOCKQUOTE>

Except for member functions of <DEL>class
templates</DEL> <INS>templated classes</INS>, the default arguments in
a member function definition that appears outside of the class
definition are added to the set of default arguments provided by the
member function declaration in the class definition; the program is
ill-formed if a default constructor (11.4.5.2 [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>]),
copy or move constructor (11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]), or copy or
move assignment operator (11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]) is so
declared. Default arguments for a member function of
a <INS>templated</INS> class <DEL>template</DEL> shall be specified on
the initial declaration of the member function within
the <INS>templated</INS> class <DEL>template</DEL>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2697"></A><H4>2697.
  
Deduction guides using abbreviated function syntax
</H4>
<B>Section: </B>13.7.2.3&#160; [<A href="https://wg21.link/temp.deduct.guide">temp.deduct.guide</A>]
 &#160;&#160;&#160;

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

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

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


<P>It is unclear whether deduction guides can be expressed using
abbreviated function syntax.  Subclause 13.7.2.3 [<A href="https://wg21.link/temp.deduct.guide#3">temp.deduct.guide</A>] paragraph 3 refers to the <I>restrictions</I> of a
function's <I>parameter-declaration-clause</I>:</P>

<BLOCKQUOTE>

The same restrictions apply to the <I>parameter-declaration-clause</I>
of a deduction guide as in a function declaration
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]). ...

</BLOCKQUOTE>

<P>However, that subclause is silent on the meaning of abbreviated
function syntax when used for deduction guides.  Furthermore,
9.3.4.6 [<A href="https://wg21.link/dcl.fct#22">dcl.fct</A>] paragraph 22 explicitly restricts the
definition to function templates, which deduction guides are not:</P>

<BLOCKQUOTE>

An <I>abbreviated function template</I> is a function declaration that
has one or more generic parameter type placeholders
(9.2.9.6 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]). ...

</BLOCKQUOTE>

<P>Arguably, the lack of template parameter names in abbreviated
function syntax makes it less suitable to specifiy deduction
guides.</P>

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

<P>CWG solicits input from EWG whether abbreviated function syntax is
intended to be used for deduction guides.

See <A HREF="https://github.com/cplusplus/papers/issues/1465">cplusplus/papers#1465</A>.
</P>

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

<P>CWG should clarify that abbreviated function syntax should not be
permitted in deduction guides.</P>

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

<P>Change in 13.7.2.3 [<A href="https://wg21.link/temp.deduct.guide#3">temp.deduct.guide</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

The same restrictions apply to the <I>parameter-declaration-clause</I>
of a deduction guide as in a function declaration
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>])<INS>, except that a generic parameter
type placeholder (9.2.9.6 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]) shall not appear in
the <I>parameter-declaration-clause</I> of a deduction guide</INS>.
The <I>simple-template-id</I> shall name a class template
specialization. The <I>template-name</I> shall be the same identifier
as the <I>template-name</I> of
the <I>simple-template-id</I>. A <I>deduction-guide</I> shall inhabit
the scope to which the corresponding class template belongs and, for a
member class template, have the same access. Two deduction guide
declarations for the same class template shall not have
equivalent <I>parameter-declaration-clause</I>s if either is reachable
from the other.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2698"></A><H4>2698.
  
Using extended integer types with <TT>z</TT> suffix
</H4>
<B>Section: </B>5.13.2&#160; [<A href="https://wg21.link/lex.icon">lex.icon</A>]
 &#160;&#160;&#160;

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

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

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


<P>Subclause 5.13.2 [<A href="https://wg21.link/lex.icon#4">lex.icon</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

If an <I>integer-literal</I> cannot be represented by any type in its
list and an extended integer type (6.8.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) can
represent its value, it may have that extended integer type. If all of
the types in the list for the <I>integer-literal</I> are signed, the
extended integer type shall be signed. If all of the types in the list
for the <I>integer-literal</I> are unsigned, the extended integer type
shall be unsigned. If the list contains both signed and unsigned
types, the extended integer type may be signed or unsigned. A program
is ill-formed if one of its translation units contains
an <I>integer-literal</I> that cannot be represented by any of the
allowed types.

</BLOCKQUOTE>

<P>This implies that an <I>integer-literal</I> with a <TT>z</TT>
suffix can be of extended integer type, if the literal is larger than
what is representable in <TT>std::size_t</TT>.</P>

<P>According to the author of the paper
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0330r8.html">P0330R8</A>
(Literal Suffix for (signed) size_t) introducing the feature, this is
unintentional; <TT>z</TT> should only yield <TT>std::size_t</TT> and
its corresponding signed integer type.</P>

<P>See also the corresponding WG14 paper
<A HREF="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2998.htm">N2998
Literal Suffixes for size_t</A>.</P>

<P><B>Proposed resolution (reviewed by CWG 2023-03-03, approved by CWG 2023-05-12):</B></P>

<P>Change in 5.13.2 [<A href="https://wg21.link/lex.icon#4">lex.icon</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<DEL>If</DEL> <INS>Except for <I>integer-literal</I>s containing
a <I>size-suffix</I>, if the value of</INS> an <I>integer-literal</I>
cannot be represented by any type in its list and an extended integer
type (6.8.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) can represent its value, it may have
that extended integer type. If all of the types in the list for
the <I>integer-literal</I> are signed, the extended integer type
<DEL>shall be </DEL> <INS>is</INS> signed. If all of the types in the
list for the <I>integer-literal</I> are unsigned, the extended integer
type <DEL>shall be</DEL> <INS>is</INS> unsigned. If the list contains
both signed and unsigned types, the extended integer type may be
signed or unsigned. <DEL>A program is ill-formed if one of its
translation units contains</DEL> <INS>If</INS> an
<I>integer-literal</I> <DEL>that</DEL> cannot be represented by any
of the allowed types<INS>, the program is ill-formed</INS>.
<INS>[ Note: An <I>integer-literal</I> with a <TT>z</TT> or <TT>Z</TT>
suffix is ill-formed if it cannot be represented by
<TT>std::size_t</TT>.  -- end note ]</INS>

</BLOCKQUOTE>

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

<P>Alerted the chair of SG22 (C/C++ Liaison).</P>

<P>Forwarded to EWG at the request of the EWG chair via
<A HREF="https://github.com/cplusplus/papers/issues/1467">cplusplus/papers#1467</A>.</P>

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

<P>The "z" suffixes mean <TT>std::size_t</TT> (or its corresponding
signed type) only.  The proposed resolution is accepted by EWG.</P>

<BR><BR><HR>
<A NAME="2699"></A><H4>2699.
  
Inconsistency of <I>throw-expression</I> specification
</H4>
<B>Section: </B>7.6.18&#160; [<A href="https://wg21.link/expr.throw">expr.throw</A>]
 &#160;&#160;&#160;

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

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

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


<P>Subclause 7.6.18 [<A href="https://wg21.link/expr.throw#2">expr.throw</A>] paragraph 2 and 3 specify:</P>

<BLOCKQUOTE>

<P>Evaluating a <I>throw-expression</I> with an operand throws an
exception (14.2 [<A href="https://wg21.link/except.throw">except.throw</A>]); the type of the exception
object is determined by removing any top-level cv-qualifier s from the
static type of the operand and adjusting the type from &#8220;array of
T&#8221; or function type T to &#8220;pointer to T&#8221;.</P>

<P>A <I>throw-expression</I> with no operand rethrows the currently
handled exception (14.4 [<A href="https://wg21.link/except.handle">except.handle</A>]). The exception is
reactivated with the existing exception object; no new exception
object is created. The exception is no longer considered to be caught.</P>

</BLOCKQUOTE>

<P>This means that throwing a value of type <TT>const char[3]</TT>
would throw a <TT>char*</TT> rather than <TT>const char*</TT>, which
is not intended.</P>

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

<P>Change in 7.6.18 [<A href="https://wg21.link/expr.throw#2">expr.throw</A>] paragraph 2 through 4 as follows:</P>

<BLOCKQUOTE>

<P>
<DEL>Evaluating a</DEL> <INS>A</INS> <I>throw-expression</I> with
an operand throws an exception (14.2 [<A href="https://wg21.link/except.throw">except.throw</A>])<DEL>;
the</DEL><INS>. The array-to-pointer (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]) and
function-to-pointer (7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]) standard conversions
are performed on the operand.  The</INS> type of the exception object
is determined by removing any top-level cv-qualifiers from
the <DEL>static</DEL> type of the <INS>(possibly converted)</INS>
operand <DEL>and adjusting the type from &#8220;array of T&#8221; or
function type T to &#8220;pointer to T&#8221;</DEL>.</P>

<P>A <I>throw-expression</I> with no operand rethrows the currently
handled exception (14.4 [<A href="https://wg21.link/except.handle">except.handle</A>]).
<INS>
If no exception is presently being handled, the function <TT>std::
terminate</TT> is invoked (14.6.2 [<A href="https://wg21.link/except.terminate">except.terminate</A>]).
</INS>

<DEL>The</DEL> <INS>Otherwise, the</INS> exception is
reactivated with the existing exception object; no new exception
object is created. The exception is no longer considered to be caught.</P>

<P><DEL>If no exception is presently being handled, evaluating
a <I>throw-expression</I> with no operand calls std:: terminate()
(14.6.2 [<A href="https://wg21.link/except.terminate">except.terminate</A>]).</DEL></P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2708"></A><H4>2708.
  
Parenthesized initialization of arrays
</H4>
<B>Section: </B>9.4.1&#160; [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>]
 &#160;&#160;&#160;

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

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

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


<P>Consider:</P>

<PRE>
  const int arr[2](1,2);
</PRE>

<P>This is accepted by all major implementations, yet
9.4.1 [<A href="https://wg21.link/dcl.init.general#13">dcl.init.general</A>] paragraph 13 prohibits it:</P>

<BLOCKQUOTE>

If the entity being initialized does not have class type,
the <I>expression-list</I> in a parenthesized initializer shall be a
single expression.

</BLOCKQUOTE>

<P>Presumably, this was an oversight when adding parenthesized
aggregate initialization.</P>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

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

<BLOCKQUOTE>

If the entity being initialized does not have class <INS>or
array</INS> type, the <I>expression-list</I> in a parenthesized
initializer shall be a single expression.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2710"></A><H4>2710.
  
Loops 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>Daniel Kr&#252;gler
 &#160;&#160;&#160;

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




<P>Iteration statements such as <TT>while</TT> and <TT>for</TT> loops
are specified by equivalent code involving <TT>goto</TT>
(8.6.2 [<A href="https://wg21.link/stmt.while#2">stmt.while</A>] paragraph 2, 8.6.4 [<A href="https://wg21.link/stmt.for#1">stmt.for</A>] paragraph 1, 8.6.5 [<A href="https://wg21.link/stmt.ranged#1">stmt.ranged</A>] paragraph 1).  The <TT>goto</TT>
statement cannot be evaluated in constant expressions
(7.7 [<A href="https://wg21.link/expr.const#5.30">expr.const</A>] bullet 5.30), thus <TT>while</TT>
and <TT>for</TT> loops cannot be evaluated in constant expressions.
Similar concerns arise for <TT>continue</TT>
(8.7.3 [<A href="https://wg21.link/stmt.cont#1">stmt.cont</A>] paragraph 1).</P>

<P>However, that is neither intended nor existing practice.</P>

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

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

<BLOCKQUOTE>
An expression E is a <I>core constant expression</I> unless the
evaluation of E, following the rules of the abstract machine
(6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]), would evaluate one of the following:
<UL>
<LI>...</LI>
<LI>a goto statement (8.7.6 [<A href="https://wg21.link/stmt.goto">stmt.goto</A>])
<INS>unless it is introduced by replacing
an <I>iteration-statement</I> (8.6 [<A href="https://wg21.link/stmt.iter">stmt.iter</A>]) or
a <TT>continue</TT> statement (8.7.3 [<A href="https://wg21.link/stmt.cont">stmt.cont</A>]) with its
equivalent</INS>.
</LI>
</UL>

</BLOCKQUOTE>

<P><B>CWG 2023-03-30</B></P>

<P>Keep the rule non-normative and non-exhaustive.</P>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

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

<BLOCKQUOTE>
An expression E is a <I>core constant expression</I> unless the
evaluation of E, following the rules of the abstract machine
(6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]), would evaluate one of the following:
<UL>
<LI>...</LI>
<LI>a goto statement (8.7.6 [<A href="https://wg21.link/stmt.goto">stmt.goto</A>]).
<INS>[ Note: A <TT>goto</TT> statement introduced by equivalence
(Clause 8 [<A href="https://wg21.link/stmt.stmt">stmt.stmt</A>]) is not in scope.  For example,
a <TT>while</TT> statement (8.6.2 [<A href="https://wg21.link/stmt.while">stmt.while</A>]) can be
executed during constant evaluation. -- end note ]</INS>.
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2711"></A><H4>2711.
  
Source for copy-initializing the exception object
</H4>
<B>Section: </B>7.6.18&#160; [<A href="https://wg21.link/expr.throw">expr.throw</A>]
 &#160;&#160;&#160;

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

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

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




<P>Neither 14.2 [<A href="https://wg21.link/except.throw">except.throw</A>] nor 7.6.18 [<A href="https://wg21.link/expr.throw">expr.throw</A>]
specifiy the source for copy-initializing the exception object.</P>

<P><B>Proposed resolution (based on the resolution of
issue 2699; approved by CWG
2023-06-12):</B></P>

<OL>

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

<BLOCKQUOTE>

Evaluating a <I>throw-expression</I> with an operand throws an
exception (14.2 [<A href="https://wg21.link/except.throw">except.throw</A>]); the type of the exception
object is determined by removing any top-level <I>cv-qualifier</I>s
from the static type of the operand and adjusting the type from
&#8220;array of T&#8221; or function type T to &#8220;pointer to
T&#8221;.
<INS>The exception object is copy-initialized
(9.4.1 [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>]) from the (possibly converted) operand.</INS>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

Throwing an exception <DEL>copy-</DEL>initializes
<DEL>(9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>], 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>])</DEL>
a temporary object, called the exception object. If the type of the
exception object would be an incomplete type
<INS>(6.8.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>])</INS>, an abstract class type
(11.7.4 [<A href="https://wg21.link/class.abstract">class.abstract</A>]), or a pointer to an incomplete type
other than cv void <INS>(6.8.4 [<A href="https://wg21.link/basic.compound">basic.compound</A>]),</INS>
the program is ill-formed.

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="2712"></A><H4>2712.
  
Simplify restrictions on built-in assignment operator candidates
</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>Brian Bi
 &#160;&#160;&#160;

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


<P>Subclause 12.2.2.3 [<A href="https://wg21.link/over.match.oper#5">over.match.oper</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

For the built-in assignment operators, conversions of the left operand
are restricted as follows:
<UL>
<LI>no temporaries are introduced to hold the left operand, and</LI>

<LI>
no user-defined conversions are
applied to the left operand to achieve a type match with the left-most
parameter of a built-in candidate.
</LI>
</UL>

</BLOCKQUOTE>

<P>The first bullet is redundant, because standard conversion
sequences cannot bind "vq <TT>T&amp;</TT>" (the type of the first
parameter of a built-in assignment operator) to a temporary.</P>

<P><B>Proposed resolution (approved by CWG 2023-03-30):</B></P>

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

<BLOCKQUOTE>

For <INS>the first parameter of</INS> the built-in assignment
operators, <INS>only standard conversion sequences
(12.2.4.2.2 [<A href="https://wg21.link/over.ics.scs">over.ics.scs</A>]) are considered.</INS>
<DEL>conversions of the left operand
are restricted as follows:</DEL>
<UL>
<LI><DEL>no temporaries are introduced to hold the left operand, and</DEL></LI>

<LI>
<DEL>no user-defined conversions are
applied to the left operand to achieve a type match with the left-most
parameter of a built-in candidate.</DEL>
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2713"></A><H4>2713.
  
Initialization of reference-to-aggregate from designated initializer list
</H4>
<B>Section: </B>9.4.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

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

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




<P>Aggregates can be initialized by a designated initializer list, but
references to aggregates cannot, although list-initialization of such
with a regular <I>braced-init-list</I> is fine.</P>

<P>Subclause 9.4.5 [<A href="https://wg21.link/dcl.init.list#3">dcl.init.list</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

List-initialization of an object or reference of type T is defined as
follows:

<UL>
<LI>If the <I>braced-init-list</I> contains
a <I>designated-initializer-list</I>, T shall be an aggregate class. ...</LI>

<LI>...</LI>

<LI>Otherwise, if T is a reference type, a prvalue is generated. The
prvalue initializes its result object by copy-list-initialization from
the initializer list. The prvalue is then used to direct-initialize
the reference.  The type of the prvalue is the type referenced by T,
unless ...</LI>

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

</BLOCKQUOTE>

<P>Subclause 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#2">over.ics.list</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

If the initializer list is a <I>designated-initializer-list</I>, a
conversion is only possible if the parameter has an aggregate type
that can be initialized from the initializer list according to the
rules for aggregate initialization (9.4.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]), in
which case the implicit conversion sequence is a user-defined
conversion sequence whose second standard conversion sequence is an
identity conversion.

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

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

<BLOCKQUOTE>

<UL>
<LI>If the <I>braced-init-list</I> contains
a <I>designated-initializer-list</I> <INS>and <TT>T</TT> is not a
reference type</INS>, T shall be an aggregate class. ...</LI>

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

</BLOCKQUOTE>
</LI>


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

<BLOCKQUOTE>

Otherwise, if the initializer list <INS>is not
a <I>designated-initializer-list</I> and</INS> has a single element of
type E and ...

</BLOCKQUOTE>

</LI>

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

<BLOCKQUOTE>
[ Example:
<PRE>
  ...
  const B&amp; b2{a};  //<SPAN CLASS="cmnt"> error: cannot copy-list-initialize B temporary from A</SPAN>
<INS>  struct C { int x; };
  C&amp;&amp; c = { .x = 1 };  //<SPAN CLASS="cmnt"> OK</SPAN></INS>
</PRE>
-- end example ]
</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#2">over.ics.list</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If the initializer list is a <I>designated-initializer-list</I>
<INS>and the parameter is not a reference</INS>, a conversion is only
possible if the parameter has an aggregate type that can be
initialized from the initializer list according to the rules for
aggregate initialization (9.4.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]), in which case
the implicit conversion sequence is a user-defined conversion sequence
whose second standard conversion sequence is an identity conversion.

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

<BR><BR><HR>
<A NAME="2715"></A><H4>2715.
  
"calling function" for parameter initialization may not exist
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

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

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


<P>Subclause 7.6.1.3 [<A href="https://wg21.link/expr.call#6">expr.call</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

... The initialization and destruction of each parameter occurs within the
context of the calling function.  [<I>Example 2:</I> The access of the
constructor, conversion functions or destructor is checked at the
point of call in the calling function. If a constructor or destructor
for a function parameter throws an exception, the search for a handler
starts in the calling function; in particular, if the function called
has a <I>function-try-block</I> (14.1 [<A href="https://wg21.link/except.pre">except.pre</A>]) with a
handler that can handle the exception, this handler is not
considered. &#8212;<I>end example</I>]

</BLOCKQUOTE>

<P>However, there is no calling function in the case where a function
call appears in the initializer of a namespace-scope
variable. Likewise, some constant expressions appearing in
a <I>type-id</I> do not have calling functions, either.  For
example:</P>

<PRE>
  class C {
   private:
    constexpr int C(int) {}
    friend void foo(int (*a)[1]) noexcept;
  };

  constexpr int bar(C) { return 1; }

  void foo(int (&amp;a)[bar(1)]) noexcept(bar(2) &gt; 0); //<SPAN CLASS="cmnt"> presumably OK because of friendship</SPAN>
</PRE>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

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

<BLOCKQUOTE>

...  The initialization and destruction of each parameter occurs
within the context of the <DEL>calling
function</DEL> <INS>full-expression (6.9.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) where
the function call appears</INS>.  [<I>Example 2:</I> The access
<INS>(11.8.1 [<A href="https://wg21.link/class.access.general">class.access.general</A>])</INS> of the constructor,
conversion functions<INS>,</INS> or destructor is checked at the point
of call <DEL>in the calling function</DEL>. If a constructor or
destructor for a function parameter throws an exception, <DEL>the
search for a handler starts in the calling function; in particular, if
the function called has a</DEL>
<INS>any</INS> <I>function-try-block</I>
(14.1 [<A href="https://wg21.link/except.pre">except.pre</A>]) <INS>of the called function</INS> with a
handler that can handle the exception<DEL>, this handler</DEL> is not
considered. &#8212;<I>end example</I>]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2716"></A><H4>2716.
  
Rule about self-or-base conversion is normatively redundant
</H4>
<B>Section: </B>11.4.8.3&#160; [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]
 &#160;&#160;&#160;

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

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

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


<P>The rule in 11.4.8.3 [<A href="https://wg21.link/class.conv.fct#4">class.conv.fct</A>] paragraph 4 is normatively
redundant explanation:</P>

<BLOCKQUOTE>

A conversion function is never used to convert a (possibly
cv-qualified) object to the (possibly cv-qualified) same object type
(or a reference to it), to a (possibly cv-qualified) base class of
that type (or a reference to it), or to cv void.
[ Footnote:
These conversions are considered as standard conversions for the
purposes of overload resolution (12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>],
12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>]) and therefore initialization
(9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) and explicit casts
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]). A conversion to void does not invoke
any conversion function (7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]).  Even though
never directly called to perform a conversion, such conversion
functions can be declared and can potentially be reached through a
call to a virtual conversion function in a base class.  -- end footnote ]

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

<P>Change in 11.4.8.3 [<A href="https://wg21.link/class.conv.fct#4">class.conv.fct</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<INS>[ Note:</INS> A conversion function is never <DEL>used
to convert</DEL> <INS>invoked for implicit or explicit conversions of an</INS>
<DEL>a (possibly cv-qualified)</DEL> object to the <DEL>(possibly
cv-qualified)</DEL> same object type (or a reference to it), to a <DEL>(possibly
cv-qualified)</DEL> base class of that type (or a reference to it), or to cv
void.
<DEL>[ Footnote:</DEL>
<DEL>These conversions are considered as standard conversions for the
purposes of overload resolution (12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>],
12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>]) and therefore initialization
(9.4 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) and explicit casts
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]). A conversion to void does not invoke
any conversion function (7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]).</DEL>  Even though
never directly called to perform a conversion, such conversion
functions can be declared and can potentially be reached through a
call to a virtual conversion function in a base class.
<DEL>-- end footnote ]</DEL> <INS>-- end note ]</INS>

<P>[ Example: ... ]</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2717"></A><H4>2717.
  
Pack expansion for <I>alignment-specifier</I>
</H4>
<B>Section: </B>13.7.4&#160; [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]
 &#160;&#160;&#160;

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

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

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


<P>Subclause 13.7.4 [<A href="https://wg21.link/temp.variadic#11">temp.variadic</A>] paragraph 11 specifies:</P>

<BLOCKQUOTE>

The instantiation of any other pack expansion produces a list of
elements E1, E2, ... , EN.

</BLOCKQUOTE>

<P>Consider this example:</P>

<PRE>
  template&lt;class ...T&gt;
  struct Align{
   alignas(T...) unsigned char buffer[128];
  };
  Align&lt;int, short&gt; a;
</PRE>

<P>The pack expansion of the <I>alignment-specifier</I>
yields <TT>alignas(int), alignas(short)</TT>, an ill-formed list per
the grammar in 9.12.1 [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>].</P>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

<P>Insert a new paragraph after 13.7.4 [<A href="https://wg21.link/temp.variadic#9">temp.variadic</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

<P>The instantiation of a sizeof... expression
(7.6.2.5 [<A href="https://wg21.link/expr.sizeof">expr.sizeof</A>]) produces an integral constant with
value N.</P>

<P class="ins">
The instantiation of an <I>alignment-specifier</I> with an ellipsis
produces <TT>E<sub>1</sub> E<sub>2</sub>
... E<sub><I>N</I></sub></TT>.
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2718"></A><H4>2718.
  
Type completeness for derived-to-base conversions
</H4>
<B>Section: </B>7.6.1.9&#160; [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
 &#160;&#160;&#160;

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

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

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


<P>Issue 2310 clarified class
completeness requirements for derived-to-base pointer conversions, but
neglected the corresponding lvalue conversion.</P>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

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

<BLOCKQUOTE>

An lvalue of type &#8220;cv1 B&#8221;, where B is a class type, can be
cast to type &#8220;reference to cv2 D&#8221;, where D is
a <INS>complete</INS> class derived (11.7 [<A href="https://wg21.link/class.derived">class.derived</A>]) from
B, if cv2 is the same cv-qualification as, or greater cv-qualification
than, cv1. ...

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="2719"></A><H4>2719.
  
Creating objects in misaligned storage
</H4>
<B>Section: </B>6.7.6&#160; [<A href="https://wg21.link/basic.align">basic.align</A>]
 &#160;&#160;&#160;

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

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

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




<P>A non-allocating form of <TT>operator new</TT> can be used to
create an object in storage that is not suitably aligned for the type
of the object.  Such attempts ought to be undefined behavior.</P>

<P><B>Proposed resolution (approved by CWG 2023-04-28):</B></P>

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

<BLOCKQUOTE>

Object types have alignment requirements (6.8.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>],
6.8.4 [<A href="https://wg21.link/basic.compound">basic.compound</A>]) which place restrictions on the addresses
at which an object of that type may be allocated. An alignment is an
implementation-defined integer value representing the number of bytes
between successive addresses at which a given object can be
allocated. An object type imposes an alignment requirement on every
object of that type; stricter alignment can be requested using the
alignment specifier (9.12.2 [<A href="https://wg21.link/dcl.align">dcl.align</A>]). <INS>Attempting to
create an object (6.7.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) in storage that does not
meet the alignment requirements of the object's type is undefined
behavior.</INS>

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

[<I>Note 11:</I> When the allocation function returns a value other
than null, it must be a pointer to a block of storage in which space
for the object has been reserved. The block of storage is assumed to
be appropriately aligned <INS>(6.7.6 [<A href="https://wg21.link/basic.align">basic.align</A>])</INS> and
of the requested size. The address of the created object will not
necessarily be the same as that of the block if the object is an
array. &#8212;<I>end note</I>]

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

<BR><BR><HR>
<A NAME="2720"></A><H4>2720.
  
Template validity rules for templated entities and alias templates
</H4>
<B>Section: </B>13.8.1&#160; [<A href="https://wg21.link/temp.res.general">temp.res.general</A>]
 &#160;&#160;&#160;

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

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

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


<P>Subclause 13.8.1 [<A href="https://wg21.link/temp.res.general#6">temp.res.general</A>] paragraph 6 specifies rules to
determine when a template is valid, but the specification is in terms
of "instantiation".  However, some kinds of templates (namely alias
templates) are not instantiated.</P>

<P>Further, the rule discusses only templates, but should apply to any
templated entity.</P>

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

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

<BLOCKQUOTE>

<P>
The validity of a <DEL>template</DEL> <INS>templated entity</INS> may
be checked prior to any instantiation.  [<I>Note 3:</I> Knowing which
names are type names allows the syntax of every template to be checked
in this way. &#8212;<I>end note</I>]
</P>

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

<LI><INS>no specialization of an alias template
(13.7.8 [<A href="https://wg21.link/temp.alias">temp.alias</A>]) is valid and no specialization of the
alias template is named in the program, or</INS></LI>

<LI>any <I>constraint-expression</I> in the program, introduced or
otherwise, has (in its normal form) an atomic constraint A where no
satisfaction check of A could be well-formed and no satisfaction check
of A is performed, or</LI>

<LI>every valid specialization of a variadic template requires an
empty template parameter pack, or</LI>

<LI>a hypothetical instantiation of
a <DEL>template</DEL> <INS>templated entity</INS> immediately
following its definition would be ill-formed due to a
construct <INS>(other than a <TT>static_assert</TT>-declaration that
fails)</INS> that does not depend on a
template parameter, or</LI>

<LI>the interpretation of such a construct in the hypothetical
instantiation is different from the interpretation of the
corresponding construct in any actual instantiation of
the <DEL>template</DEL> <INS>templated entity</INS>.
</LI>
</UL>
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2721"></A><H4>2721.
  
When exactly is storage reused?
</H4>
<B>Section: </B>6.7.3&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

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

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


<P>Subclause 6.7.3 [<A href="https://wg21.link/basic.life#1.5">basic.life</A>] bullet 1.5 specifies:</P>

<BLOCKQUOTE>

The lifetime of an object o of type T ends when:
<UL>
<LI>if T is a non-class type, the object is destroyed, or</LI>
<LI>if T is a class type, the destructor call starts, or</LI>
<LI>the storage which the object occupies is released, or is reused by
an object that is not nested within o
(6.7.2 [<A href="https://wg21.link/intro.object">intro.object</A>]).</LI>
</UL>

</BLOCKQUOTE>

<P>Consider the expression <TT>new (p) T(x)</TT>.  Does the lifetime
of <TT>*p</TT> end when <TT>p</TT> is returned from the allocation
function, before <TT>x</TT> is evaluated?  Or does the lifetime end
when the constructor body starts executing, after <TT>x</TT> is
evaluated?</P>

<P>The second option is conceivable for initialization by constructor
and non-class types; for aggregate initialization, the first option
must be used, because evaluation of <TT>x</TT> directly initializes a
part of the resulting object.  The first option is simpler to
implement for constant evaluation.</P>

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

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

<BLOCKQUOTE>

The lifetime of an object o of type T ends when:
<UL>
<LI>if T is a non-class type, the object is destroyed, or</LI>
<LI>if T is a class type, the destructor call starts, or</LI>
<LI>the storage which the object occupies is released, or is reused by
an object that is not nested within o
(6.7.2 [<A href="https://wg21.link/intro.object">intro.object</A>]).</LI>
</UL>

<INS>When evaluating a <I>new-expression</I>, storage is considered
reused after it is returned from the allocation function, but before
the evaluation of the <I>new-initializer</I>
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]). [ Example:</INS>

<PRE class="ins">
  struct S {
    int m;
  };

  void f() {
    S x{1};
    new(&amp;x) S(x.m);  // <SPAN CLASS="cmnt">undefined behavior</SPAN>
  }
</PRE>

<INS>-- end example ]</INS>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2722"></A><H4>2722.
  
Temporary materialization conversion for <TT>noexcept</TT> operator
</H4>
<B>Section: </B>7.6.2.7&#160; [<A href="https://wg21.link/expr.unary.noexcept">expr.unary.noexcept</A>]
 &#160;&#160;&#160;

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

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

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


<P>It is unclear whether <TT>noexcept(A())</TT> applies the temporary
materialization conversion to the prvalue <TT>A()</TT>.  The
resolution of issue 1354 suggests that it
does so that the destructor is (notionally) invoked.</P>

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

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

<BLOCKQUOTE>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2723"></A><H4>2723.
  
Range of representable values for floating-point types
</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>Jiang An
 &#160;&#160;&#160;

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


<P>The range of representable values is defined for integer types, but
not for floating-point types.  This term is used in
5.13.4 [<A href="https://wg21.link/lex.fcon#3">lex.fcon</A>] paragraph 3 as well as in the library,
e.g. in 22.13.3 [<A href="https://wg21.link/charconv.from.chars">charconv.from.chars</A>] and
30.4.3.2.3 [<A href="https://wg21.link/facet.num.get.virtuals">facet.num.get.virtuals</A>].</P>

<P>The C standard contains a suitable definition that we should
inherit.</P>

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

<P>Add a new paragraph after 6.8.2 [<A href="https://wg21.link/basic.fundamental#12">basic.fundamental</A>] paragraph 12 as follows:</P>

<BLOCKQUOTE>

<P>... Except as specified in 6.8.3 [<A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>], the object and
value representations and accuracy of operations of floating-point
types are implementation-defined.</P>

<P class="ins">
The minimum range of representable values for a floating-point type is
the most negative finite floating-point number representable in that
type through the most positive finite floating-point number
representable in that type. In addition, if negative infinity is
representable in a type, the range of that type is extended to all
negative real numbers; likewise, if positive infinity is representable
in a type, the range of that type is extended to all positive real
numbers. [ Note: Since negative and positive infinity are
representable in ISO/IEC/IEEE 60559 formats, all real numbers lie
within the range of representable values of a floating-point type
adhering to ISO/IEC/IEEE 60559. ]
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2724"></A><H4>2724.
  
Clarify rounding for arithmetic right shift
</H4>
<B>Section: </B>7.6.7&#160; [<A href="https://wg21.link/expr.shift">expr.shift</A>]
 &#160;&#160;&#160;

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

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

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


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

<P>Subclause 7.6.7 [<A href="https://wg21.link/expr.shift#3">expr.shift</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

The value of E1 &gt;&gt; E2 is E1/2<sup>E2</sup>, rounded down.

</BLOCKQUOTE>

<P>It is unclear whether "rounded down" means "towards zero" or
"towards negative infinity".</P>

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

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

<BLOCKQUOTE>

The value of E1 &gt;&gt; E2 is E1/2<sup>E2</sup>,
rounded <DEL>down</DEL> <INS>towards negative infinity</INS>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2729"></A><H4>2729.
  
Meaning of <I>new-type-id</I>
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

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

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


<P>Subclause 7.6.2.8 [<A href="https://wg21.link/expr.new#1">expr.new</A>] paragraph 1 introduces the
grammar non-terminal <I>new-type-id</I>, but never specifies its
meaning.</P>

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

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

<BLOCKQUOTE>

The <I>new-expression</I> attempts to create an object of
the <I>type-id</I> <DEL>(9.3.2 [<A href="https://wg21.link/dcl.name">dcl.name</A>])</DEL>
or <I>new-type-id</I> <INS>(9.3.2 [<A href="https://wg21.link/dcl.name">dcl.name</A>])</INS> to which it is
applied.  The type of that object is the allocated type. This type
shall be a complete object type (6.8.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]), but not
an abstract class type (11.7.4 [<A href="https://wg21.link/class.abstract">class.abstract</A>]) or array thereof
(6.7.2 [<A href="https://wg21.link/intro.object">intro.object</A>]).

</BLOCKQUOTE>
</LI>

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

<BLOCKQUOTE>

To specify type conversions explicitly, and as an argument of sizeof,
alignof, new, or typeid, the name of a type shall be specified. This
can be done with a <I>type-id</I> <INS>or <I>new-type-id</I>
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>])</INS>, which is syntactically a
declaration for a variable or function of that type that omits the
name of the entity.

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2732"></A><H4>2732.
  
Can importable headers react to preprocessor state from point of import?
</H4>
<B>Section: </B>10.3&#160; [<A href="https://wg21.link/module.import">module.import</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Xu Chuanqi
 &#160;&#160;&#160;

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




<P>Subclause 10.3 [<A href="https://wg21.link/module.import#5">module.import</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

A <I>module-import-declaration</I> that specifies a <I>header-name</I>
H imports a synthesized header unit, which is a translation unit
formed by applying phases 1 to 7 of translation
(5.2 [<A href="https://wg21.link/lex.phases">lex.phases</A>]) to the source file or header nominated by
H, which shall not contain a <I>module-declaration</I>.

[<I>Note 2:</I> All declarations within a header unit are implicitly
exported (10.2 [<A href="https://wg21.link/module.interface">module.interface</A>]), and are attached to the global
module (10.1 [<A href="https://wg21.link/module.unit">module.unit</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>It is unclear whether the contents of header units can vary
depending on the set of defined macros at the point where
the <TT>import</TT> (or <TT>#include</TT>) appears.</P>

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

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

<BLOCKQUOTE>

[<I>Note 2:</I>
<INS>A header unit is a separate translation unit with an
independent set of defined macros.</INS> All declarations within a
header unit are implicitly exported (10.2 [<A href="https://wg21.link/module.interface">module.interface</A>]), and
are attached to the global module
(10.1 [<A href="https://wg21.link/module.unit">module.unit</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2750"></A><H4>2750.
  
construct_at without constructor call
</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>CWG
 &#160;&#160;&#160;

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


<P>Subclause 7.7 [<A href="https://wg21.link/expr.const#6">expr.const</A>] paragraph 6 talks about invoking
the "underlying constructor", but there is no constructor when
creating an aggregate or a scalar type.</P>

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

<BLOCKQUOTE>

For the purposes of determining whether an expression E is a core
constant expression, the evaluation of the body of a member function
of std::allocator&lt;T&gt; as defined in
20.2.10.2 [<A href="https://wg21.link/allocator.members">allocator.members</A>], where T is a literal type, is
ignored. Similarly, the evaluation of the body of std::construct_at or
std::ranges::construct_at is considered to include only the
<DEL>underlying constructor call</DEL> <INS>initialization of
the <TT>T</TT> object</INS> if the first argument (of type T*) points
to storage allocated with std::allocator&lt;T&gt; or to an object
whose lifetime began within the evaluation of E.

</BLOCKQUOTE>

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