<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core NB Comment Resolutions
   </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
       &#160;P2103R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2020-02-14</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 Changes for NB Comments
     at the
     February, 2020 (Prague) 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/2020/n4849.pdf">WG21 N4849</A>.
   </P>
<HR><A NAME="US028"></A><H4>US028.
  
Define grammar for "punctuator"
</H4>


<OL><LI><P>Change 5.4 [lex.pptoken] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

Each preprocessing token that is converted to a token
(5.6 [lex.token]) shall have the lexical form of a
keyword, an identifier, a literal, <SPAN style="font-weight:bold;background-color:#A0FFA0">or</SPAN> an
operator<SPAN style="text-decoration:line-through;background-color:#FFA0A0">, or a</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">or</SPAN> punctuator.

</BLOCKQUOTE>

<LI><P>Change the grammar in 5.6 [lex.token] as follows:</P></LI>

<UL><I>token</I>:
<UL><I>identifier</I><BR>
<I>keyword</I><BR>
<I>literal</I><BR>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>operator</I><BR>
<I>punctuator</I></SPAN><BR>
<I><SPAN style="font-weight:bold;background-color:#A0FFA0">operator-or-punctuator</SPAN></I>
</UL>
</UL>

<LI><P>Change 5.11 [lex.key] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

Furthermore, the alternative representations shown in Table
6 for certain operators and punctuators
(5.5 [lex.digraph]) are reserved and shall not be
used otherwise<SPAN style="text-decoration:line-through;background-color:#FFA0A0">:</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 5.12 [lex.operators] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>The lexical representation of C++ programs includes a
number of preprocessing tokens <SPAN style="text-decoration:line-through;background-color:#FFA0A0">which</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">that</SPAN> are used in the syntax
of the preprocessor or are converted into tokens for
operators and punctuators:</P>

<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>preprocessing-operator</I>: one of</SPAN>
<UL><PRE>
<TT><SPAN style="font-weight:bold;background-color:#A0FFA0">#       ##      %:      %:%:</SPAN></TT>
</PRE>
</UL>
</UL>

<UL><I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">preprocessing-op-or-punc</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">operator-or-punctuator</SPAN></I>: one of
<UL><PRE>
{       }       [       ]       <SPAN style="text-decoration:line-through;background-color:#FFA0A0">#       ##</SPAN>      (       )
&lt;:      :&gt;      &lt;%      %&gt;      <SPAN style="text-decoration:line-through;background-color:#FFA0A0">%:      %:%:</SPAN>    ;       :       ...
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">new     delete</SPAN>  ?       ::      .       .*      -&gt;      -&gt;*     ~
!       +       -       *       /       %       ^       &amp;       |
=       +=      -=      *=      /=      %=      ^=      &amp;=      |=
==      !=      &lt;       &gt;       &lt;=      &gt;=      &lt;=&gt;     &amp;&amp;      ||
&lt;&lt;      &gt;&gt;      &lt;&lt;=     &gt;&gt;=     ++      --      ,
and     or      xor     not     bitand  bitor   compl
and_eq  or_eq   xor_eq  not_eq
</PRE></UL>
</UL>
<BR>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>preprocessing-op-or-punc</I>:</SPAN>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>preprocessing-operator</I><BR>
<I>operator-or-punctuator</I></SPAN>
</UL>
</UL>

<P>Each <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">preprocessing-op-or-punc</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">operator-or-punctuator</SPAN></I> is converted to a
single token in translation phase 7
(5.2 [lex.phases]).</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="US033"></A><H4>US033.
  
Allow "import" inside linkage-specifications [dcl.link]
</H4>


<OL><LI><P>Change the grammar in 6.6 [basic.link]
paragraph 1 as follows:</P></LI>

<UL><I>translation-unit</I>
<UL><I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq<SUB>opt</SUB></I><BR>
<I>global-module-fragment<SUB>opt</SUB> module-declaration <SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq<SUB>opt</SUB> private-module-fragment<SUB>opt</SUB></I>
</UL>
</UL>
<BR>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>top-level-declaration-seq</I>:</SPAN>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>top-level-declaration</I></SPAN><BR>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>top-level-declaration-seq top-level-declaration</I></SPAN>
</UL>
</UL>
<BR>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>top-level-declaration</I>:</SPAN>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>module-import-declaration</I></SPAN><BR>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>declaration</I></SPAN>
</UL>
</UL>

<LI><P>Change 6.6 [basic.link] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

A token sequence beginning
with <TT>export</TT><SUB><I>opt</I></SUB> <TT>module</TT>
and not immediately followed by <TT>::</TT> is never
interpreted as <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the <I>declaration</I> of</SPAN>
a <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration</I>.

</BLOCKQUOTE>

<P><I>[Note: 
<A HREF="http://wiki.edg.com/pub/Wg21prague/StrawPolls/p1857r3.html">
P1857R3</A> deletes this paragraph, which supersedes this change.
It is to be applied only if P1857R3 is not adopted.]</I></P>

<LI><P>Change the grammar and paragraph 1 of
10.4 [module.global] as follows:</P></LI>

<BLOCKQUOTE>

<UL><I>global-module-fragment</I>:
<UL><TT>module ;</TT> <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq<SUB>opt</SUB></I>
</UL>
</UL>
<BR>
[<I>Note:</I> Prior to phase 4 of translation, only
preprocessing directives can appear in
the <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq</I>
(15.5 [cpp.glob.frag]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 10.4 [module.global] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

A declaration <TT>D</TT>
in a global module fragment of a module unit
is <I>discarded</I> if <TT>D</TT>
is not decl-reachable from
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">any <I>top-level-declaration</I> in</SPAN>
the <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq</I> of
the <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>translation unit</I></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>translation-unit</I></SPAN>. [<I>Note:</I> A
discarded declaration...

</BLOCKQUOTE>

<LI><P>Change the grammar in 10.5 [module.context] as follows:</P></LI>

<UL><I>private-module-fragment</I>:
<UL><TT>module : private ;</TT> <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq<SUB>opt</SUB></I>
</UL>
</UL>

<LI><P>Change 10.6 [module.reach] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

During the implicit instantiation of a template whose point
of instantiation is specified as that of an enclosing
specialization (13.8.4.1 [temp.point]), the
instantiation context is the union of the instantiation
context of the enclosing specialization and, if the template
is defined in a module interface unit of a module <I>M</I>
and the point of instantiation is not in a module interface
unit of <I>M</I>, the point at the end of
the <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq</I> of the
primary module interface unit of <I>M</I> (prior to
the <I>private-module-fragment</I>, if any).

</BLOCKQUOTE>

<LI><P>Change 13.8.4.1 [temp.point] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

<P>A specialization for a function template, a member function
template, or of a member function or static data member of a
class template may have multiple points of instantiations
within a translation unit, and in addition to the points of
instantiation described above,</P>

<UL><LI><P>for any such specialization that has a point of
instantiation within the <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq</I> of
the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">translation unit</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>translation-unit</I></SPAN>, prior to
the <I>private-module-fragment</I> (if any), the point after
the <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq</I> of
the <I>translation-unit</I> is also considered a point of
instantiation, and</P></LI>

<LI><P>for any such specialization...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change the grammar in 9.1 [dcl.pre] paragraph 1
as follows:</P></LI>

<UL><I>declaration</I>:
<UL><I>block-declaration</I><BR>
<I>nodeclspec-function-declaration</I><BR>
<I>function-definition</I><BR>
<I>template-declaration</I><BR>
<I>deduction-guide</I><BR>
<I>explicit-instantiation</I><BR>
<I>explicit-specialization</I><BR>
<I>export-declaration</I><BR>
<I>linkage-specification</I><BR>
<I>namespace-definition</I><BR>
<I>empty-declaration</I><BR>
<I>attribute-declaration</I><BR>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>module-import-declaration</I></SPAN>
</UL>
</UL>

<LI><P>Change 10.3 [module.import] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">A <I>module-import-declaration</I> shall only appear at
global namespace scope.</SPAN> In a module unit,
all <I>module-import-declaration</I>s shall precede all
other <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration</I>s in
the <I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">top-level-</SPAN>declaration-seq</I> of
the <I>translation-unit</I> and of
the <I>private-module-fragment</I> (if any). The
optional <I>attribute-specifier-seq</I> appertains to
the <I>module-import-declaration</I>.

</BLOCKQUOTE>

<LI><P>Add the following as a new paragraph after 9.11 [dcl.link]
paragraph 3:</P></LI>

<BLOCKQUOTE>

<P>Every implementation shall provide for linkage to functions
written in the C programming language, <TT>"C"</TT>, and
linkage to C++ functions, <TT>"C++"</TT>. [<I>Example:</I>
... &#8212;<I>end example</I>]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">A <I>module-import-declaration</I> shall not be
directly contained in
a <I>linkage-specification</I>. A <I>module-import-declaration</I>
appearing in a linkage specification with other than C++
language linkage is conditionally-supported with
implementation-defined semantics.</SPAN></P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="US041"></A><H4>US041.
  
Enforce correspondence of containing objects for pointer values / aliasing
</H4>


<P>Change 6.7.3 [basic.life] paragraph 8 as follows:</P>

<BLOCKQUOTE>

<P>If, after the lifetime of an object has ended and before
the storage which the object occupied is reused or released,
a new object is created at the storage location which the
original object occupied, a pointer that pointed to the
original object, a reference that referred to the original
object, or the name of the original object will
automatically refer to the new object and, once the lifetime
of the new object has started, can be used to manipulate the
new object, if<SPAN style="text-decoration:line-through;background-color:#FFA0A0">:</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the original object is
transparently replaceable (see below) by the new
object.</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">An original object is <I>transparently replaceable</I>
by a new object if:</SPAN></P>

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

<LI><P>neither the original object nor the new object is a
potentially-overlapping subobject
(6.7.2 [intro.object])<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">, and</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">neither the original object nor the new object
are subobjects or both are subobjects, and</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">the (unique) object (if any) that contains the
original object as a subobject (6.7.2 [intro.object])
is transparently replaceable by the (unique) object (if any)
that contains the new object.</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="CA104"></A><H4>CA104.
  
Clarify declaration matching and partial ordering requiring substitution into constraints
</H4>


<OL><LI><P>Add the following as a new paragraph at the end of
13.5.2 [temp.constr.decl]:</P>
</LI>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">When determining whether a given
introduced <I>constraint-expression</I> <I>C1</I> of a
declaration in an instantiated specialization of a templated
class is equivalent (13.7.6.1 [temp.over.link]) to the
corresponding <I>constraint-expression</I> <I>C2</I> of a
declaration outside the class body, <I>C1</I> is
instantiated. If the instantiation results in an invalid
expression, the <I>constraint-expression</I>s are not
equivalent. [<I>Note:</I> This can happen when determining
which member template is specialized by an explicit
specialization declaration. &#8212;<I>end note</I>]
[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">    template &lt;class T&gt; concept C = true;
    template &lt;class T&gt; struct A {
      template &lt;class U&gt; U f(U) requires C&lt;typename T::type&gt;; //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
      template &lt;class U&gt; U f(U) requires C&lt;T&gt;;                //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
    };

    template &lt;&gt; template &lt;class U&gt; U A&lt;int&gt;::f(U u) requires C&lt;int&gt; { return u; } //<SPAN style="font-family:Times;font-style:italic"> OK, specializes #2</SPAN></SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">Substituting <TT>int</TT> for <TT>T</TT> in
<TT>C&lt;typename T::type&gt;</TT> produces an invalid
expression, so the specialization does not match
#1. Substituting <TT>int</TT> for <TT>T</TT>
in <TT>C&lt;T&gt;</TT> produces <TT>C&lt;int&gt;</TT>, which
is equivalent to the <I>constraint-expression</I> for the
specialization, so it does match #2. &#8212;<I>end
example</I>]</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 13.9.1 [temp.inst] paragraph 17 as follows:</P></LI>

<BLOCKQUOTE>

The <I>type-constraint</I>s and <I>requires-clause</I> of a
template specialization or member function are not
instantiated along with the specialization or function
itself, even for a member function of a local class;
substitution into the atomic constraints formed from them is
instead performed as specified in
13.5.2 [temp.constr.decl] and
13.5.1.2 [temp.constr.atomic] when determining whether the
constraints are satisfied <SPAN style="font-weight:bold;background-color:#A0FFA0">or as specified in
13.5.2 [temp.constr.decl] when comparing
declarations</SPAN>. [<I>Note:</I> The satisfaction of
constraints

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="CA107"></A><H4>CA107.
  
Parameter mapping for non-dependent entities<BR>
US117. Comparing types and type-constraints
</H4>


<OL><LI><P>Change 13.5.1.2 [temp.constr.atomic] paragraph 1
as follows:</P></LI>

<BLOCKQUOTE>

An <I>atomic constraint</I> is formed from an
expression <TT>E</TT> and a mapping from the template
parameters that appear within <TT>E</TT> to template
arguments <SPAN style="text-decoration:line-through;background-color:#FFA0A0">involving</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">that are formed via
substitution during constraint normalization in the
declaration of a constrained entity (and, therefore, can
involve</SPAN> the <SPAN style="font-weight:bold;background-color:#A0FFA0">unsubstituted</SPAN> template
parameters of the constrained entity<SPAN style="font-weight:bold;background-color:#A0FFA0">)</SPAN>, called
the <I>parameter mapping</I>
(13.5.2 [temp.constr.decl]). [<I>Note:</I> Atomic
constraints are formed by constraint normalization
(13.5.3 [temp.constr.normal]).  <TT>E</TT> is never a
logical AND expression (7.6.14 [expr.log.and]) nor a
logical OR expression
(7.6.15 [expr.log.or]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 13.5.1.2 [temp.constr.atomic] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

<P>Two atomic constraints<SPAN style="font-weight:bold;background-color:#A0FFA0">, <I>e1</I> and <I>e2</I>,</SPAN>
are <I>identical</I> if they are formed from the same
<I>expression</I> and <SPAN style="font-weight:bold;background-color:#A0FFA0">if, given a hypothetical
template <TT>A</TT> whose <I>template-parameter-list</I>
consists of <I>template-parameter</I>s corresponding and
equivalent (13.7.6.1 [temp.over.link]) to those mapped
by the parameter mappings of the expression,
a <I>template-id</I> naming <TT>A</TT>
whose <I>template-argument</I>s are</SPAN> the targets of the
parameter <SPAN style="text-decoration:line-through;background-color:#FFA0A0">mappings are equivalent according to the rules for
expressions described in 13.7.6.1 [temp.over.link].</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">mapping of <I>e1</I> is the same
(13.6 [temp.type]) as a <I>template-id</I>
naming <TT>A</TT> whose <I>template-argument</I>s are the
targets of the parameter mapping of <I>e2</I>. [<I>Note:</I>
The comparison of parameter mappings of atomic constraints
operates in a manner similar to that of declaration matching
with alias template substitution
(13.7.7 [temp.alias]). [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template &lt;unsigned N&gt; constexpr bool Atomic = true;
  template &lt;unsigned N&gt; concept C = Atomic&lt;N&gt;;
  template &lt;unsigned N&gt; concept Add1 = C&lt;N + 1&gt;;
  template &lt;unsigned N&gt; concept AddOne = C&lt;N + 1&gt;;
  template &lt;unsigned M&gt; void f()
    requires Add1&lt;2 * M&gt;;
  template &lt;unsigned M&gt; int f()
    requires AddOne&lt;2 * M&gt; &amp;&amp; true;

  int x = f&lt;0&gt;(); //<SPAN style="font-family:Times;font-style:italic"> OK, the atomic constraints from concept </SPAN>C<SPAN style="font-family:Times;font-style:italic"> in both </SPAN>f<SPAN style="font-family:Times;font-style:italic">s are </SPAN>Atomic&lt;N&gt;
                  //<SPAN style="font-family:Times;font-style:italic"> with mapping similar to </SPAN>N &#8614; 2 * M + 1

  template &lt;unsigned N&gt; struct WrapN;
  template &lt;unsigned N&gt; using Add1Ty = WrapN&lt;N + 1&gt;;
  template &lt;unsigned N&gt; using AddOneTy = WrapN&lt;N + 1&gt;;
  template &lt;unsigned M&gt; void g(Add1Ty&lt;2 * M&gt; *);
  template &lt;unsigned M&gt; void g(AddOneTy&lt;2 * M&gt; *);

  void h() {
    g&lt;0&gt;(nullptr); //<SPAN style="font-family:Times;font-style:italic"> OK, there is only one </SPAN>g
  }</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">This similarity includes the situation where a program is ill-formed, no diagnostic required, when the meaning of the program depends on whether two constructs are equivalent, and they are functionally equivalent but not equivalent. [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template &lt;unsigned N&gt; void f2()
    requires Add1&lt;2 * N&gt;;
  template &lt;unsigned N&gt; int f2()
    requires Add1&lt;N * 2&gt; &amp;&amp; true;
  void h2() {
    f2&lt;0&gt;(); //<SPAN style="font-family:Times;font-style:italic"> ill-formed, no diagnostic required:</SPAN>
             //<SPAN style="font-family:Times;font-style:italic"> required determination of subsumption between atomic constraints that are</SPAN>
             //<SPAN style="font-family:Times;font-style:italic"> functionally equivalent but not equivalent</SPAN>
  }</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>] &#8212;<I>end note</I>]</SPAN></P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="US115"></A><H4>US115.
  
Hidden non-template friends need a <I>requires-clause</I>
</H4>


<OL><LI><P>Add the following after 3.20 [defns.signature]:</P></LI>

<BLOCKQUOTE>

<TABLE STYLE="WIDTH:100%">
<TR><TD><H2><SPAN style="font-weight:bold;background-color:#A0FFA0">3.21</SPAN></H2></TD>
<TD ALIGN="RIGHT"><H2><SPAN style="font-weight:bold;background-color:#A0FFA0">[defns.signature.friend]</SPAN></H2></TD></TR></TABLE>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><B>signature</B><BR>
&#8249;non-template friend function with trailing
<I>requires-clause</I>&#8250; name, parameter-type-list
(9.3.3.5 [dcl.fct]), enclosing class, and
trailing <I>requires-clause</I> (9.3 [dcl.decl])</SPAN>

</BLOCKQUOTE>

<LI><P>Add the following after 3.21 [defns.signature.templ]:</P></LI>

<BLOCKQUOTE>

<TABLE STYLE="WIDTH:100%">
<TR><TD><H2><SPAN style="font-weight:bold;background-color:#A0FFA0">3.23</SPAN></H2></TD>
<TD ALIGN="RIGHT"><H2><SPAN style="font-weight:bold;background-color:#A0FFA0">[defns.signature.templ.friend]</SPAN></H2></TD></TR></TABLE>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><B>signature</B><BR>
&#8249;friend function template with constraint involving 
enclosing template parameters&#8250; name, parameter-type-list
(9.3.3.5 [dcl.fct]), return type, enclosing class,
<I>template-head</I>, and trailing <I>requires-clause</I></SPAN>

</BLOCKQUOTE>

<LI><P>Change 13.7.4 [temp.friend] paragraph 9 as follows:</P></LI>

<BLOCKQUOTE>

A non-template friend declaration <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall not have</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">with</SPAN> a <I>requires-clause</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">shall be a
definition. A friend function template with a constraint
that depends on a template parameter from an enclosing
template shall be a definition. Such a constrained friend
function or function template declaration does not declare
the same function or function template as a declaration in
any other scope</SPAN>.

</BLOCKQUOTE>

</OL>

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