<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core "ready" Issues
   </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
       &#160;P1969R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2019-11-08</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:2017
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD>
<TD>
      &#160;William M. Miller
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;Edison Design Group, Inc.
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;<A HREF="mailto://wmm@edg.com">wmm@edg.com</A></TD>
</TR>
</TABLE><BR CLEAR="ALL"><BR><CENTER>
<H2>
     Core Language Working Group "ready" Issues
     for the
     November, 2019 (Belfast) 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/2019/n4835.pdf">WG21 N4835</A>.
   </P>
<HR><A NAME="2280"></A><H4>2280.
  
Matching a usual deallocation function with placement new
</H4><B>Section: </B>7.6.2.7&#160; [expr.new]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-06-27




<P>The restrictions in 7.6.2.7 [expr.new] against
a placement deallocation function signature matching a usual
deallocation function signature consider only <TT>std::size_t</TT>
parameters, omitting <TT>std::align_val_t</TT> parameters.</P>

<P><B>Proposed resolution (February, 2017):</B></P>

<P>Change 7.6.2.7 [expr.new] paragraph 27 as follows:</P>

<BLOCKQUOTE>

A declaration of a placement deallocation function matches the declaration
of a placement allocation function if it has the same number of parameters
and, after parameter transformations (9.3.3.5 [dcl.fct]), all
parameter types except the first are identical. If the lookup finds a
single matching deallocation function, that function will be called;
otherwise, no deallocation function will be called. If the lookup finds a
usual deallocation function <SPAN style="text-decoration:line-through;background-color:#FFA0A0">with a parameter of
type <TT>std::size_t</TT> (6.7.5.4.2 [basic.stc.dynamic.deallocation])</SPAN> and that
function, considered as a placement deallocation function, would have been
selected as a match for the allocation function, the program is
ill-formed. For a non-placement allocation function, the normal
deallocation function lookup is used to find the matching deallocation
function (7.6.2.8 [expr.delete])<SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN> [<I>Example:</I>...

</BLOCKQUOTE>&gt;

<BR><BR><HR><A NAME="2382"></A><H4>2382.
  
Array allocation overhead for non-allocating placement <TT>new</TT>
</H4><B>Section: </B>7.6.2.7&#160; [expr.new]
 &#160;&#160;&#160;

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

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

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


<P>According to 7.6.2.7 [expr.new] paragraph 12,</P>

<BLOCKQUOTE>

When a <I>new-expression</I> calls an allocation function and that
allocation has not been extended, the <I>new-expression</I> passes the
amount of space requested to the allocation function as the first argument
of type std::size_t . That argument shall be no less than the size of the
object being created; it may be greater than the size of the object being
created only if the object is an array. For arrays
of <TT>char</TT>, <TT>unsigned char</TT>, and <TT>std::byte</TT>, the
difference between the result of the <I>new-expression</I> and the address
returned by the allocation function shall be an integral multiple of the
strictest fundamental alignment requirement (6.7.6 [basic.align]) of
any object type whose size is no greater than the size of the array being
created.

</BLOCKQUOTE>

<P>There is no exemption for the non-allocating <TT>(void*,size_t)</TT>
placement-new allocation function, so programs must allow for the
possibility that the provided buffer may need to be larger (by an
indeterminate amount) than the size of an array placed into existing
storage.</P>

<P>Should the non-allocating placement-new allocation function be
exempt from the array allocation overhead? (This question was explicitly
referred to CWG by the EWG chair.)</P>

<P><B>Proposed resolution (February, 2019):</B></P>

<OL><LI><P>Change 7.6.2.7 [expr.new] paragraph 12
as follows:</P></LI>

<BLOCKQUOTE>

When a <I>new-expression</I> calls an allocation function
and that allocation has not been extended,
the <I>new-expression</I> passes the amount of space
requested to the allocation function as the first argument
of type std::size_t . That argument shall be no less than
the size of the object being created; it may be greater than
the size of the object being created only if the object is
an array <SPAN style="font-weight:bold;background-color:#A0FFA0">and the allocation function is not a
non-allocating form
(17.6.2.3 [new.delete.placement])</SPAN>. For arrays of...

</BLOCKQUOTE>

<LI><P>Change 7.6.2.7 [expr.new] paragraph 16 as follows:</P></LI>

<BLOCKQUOTE>

...Here, each instance of <TT>x</TT> is a non-negative
unspecified value representing array allocation overhead;
the result of the <I>new-expression</I> will be offset by
this amount from the value returned by <TT>operator
new[]</TT>.  This overhead may be applied in all
array <I>new-expression</I>s, including those referencing
<SPAN style="font-weight:bold;background-color:#A0FFA0">a placement allocation function, but not when
referencing</SPAN> the library function <TT>operator
new[](std::size_t, void*)</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0"> and other placement
allocation functions</SPAN>. The amount of overhead may vary
from one invocation of <TT>new</TT> to
another. &#8212;<I>end example</I>]

</BLOCKQUOTE>

</OL>

<P>(This resolution effectively resolves issue 476, which was closed for EWG input.)</P>

<BR><BR><HR><A NAME="2416"></A><H4>2416.
  
Explicit specializations vs <TT>constexpr</TT> and <TT>consteval</TT>
</H4><B>Section: </B>13.9.3&#160; [temp.expl.spec]
 &#160;&#160;&#160;

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

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

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


<P>According to 13.9.3 [temp.expl.spec] paragraph 13,</P>

<BLOCKQUOTE>

An explicit specialization of a function or variable
template is inline only if it is declared with
the <TT>inline</TT> specifier or defined as deleted, and
independently of whether its function or variable template
is inline.

</BLOCKQUOTE>

<P>The current wording does not specify the status of explicit
specializations of <TT>constexpr</TT> and <TT>consteval</TT>
function templates and members of class templates. Should a
similar rule apply in those cases?</P>

<P><B>Proposed resolution (November, 2019):</B></P>

<P>Change 13.9.3 [temp.expl.spec] paragraph 14 as follows:</P>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">An explicit specialization of a function or variable
template is inline only if it is declared with
the <TT>inline</TT> specifier or defined as deleted, and
independently of whether its function or variable template
is inline.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The inline, constexpr, and consteval
properties of an explicit specialization of a function or
variable template are determined by the explicit
specialization and are independent of those properties of
the template.</SPAN> [<I>Example:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2441"></A><H4>2441.
  
Inline function parameters
</H4><B>Section: </B>9.2.7&#160; [dcl.inline]
 &#160;&#160;&#160;

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

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

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


<P>According to 9.2.7 [dcl.inline] paragraph 5,</P>

<BLOCKQUOTE>

The <TT>inline</TT> specifier shall not appear on a block
scope declaration.

</BLOCKQUOTE>

<P>Function parameters, however, are not block scope
declarations, but they should also not be
declared <TT>inline</TT>.</P>

<P><B>Proposed resolution (November, 2019):</B></P>

<P>Change 9.2.7 [dcl.inline] paragraph 5 as follows:</P>

<BLOCKQUOTE>

The inline specifier shall not appear on a block scope
declaration<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SUP>87</SUP> <SPAN style="font-weight:bold;background-color:#A0FFA0">or on the declaration
of a function parameter.</SPAN>

</BLOCKQUOTE>

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