<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
	"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Proposed resolution of core issue 301</title>
</head>

<body>

<table summary="This table provides identifying information for this
		document.">
  <tr>
    <th>Doc. No.:</th>
    <td>WG21/N1490, J16/03-0073</td>
  </tr>
  <tr>
    <th>Date:</th>
    <td>2003-09-08</td>
  </tr>
  <tr>
    <th>Reply to:</th>
    <td>Clark Nelson</td>
  </tr>
  <tr>
    <th>Phone:</th>
    <td>+1-503-712-8433</td>
  </tr>
  <tr>
    <th>Email:</th>
    <td><a href="mailto:clark.nelson@intel.com">clark.nelson@intel.com</a></td>
  </tr>
</table>
<h1>Proposed resolution of core issue 301</h1>
<h2>Introduction</h2>
<p>It turns out that issue 301 is a duplicate of issue 38, which was resolved in 
the TC. I am reassured by the fact that I independently came up with the same grammar 
change that Jamie Schmeiser did. For reference, here is that grammar change (from 
13.5):</p>
<blockquote>
  <dl>
    <dt><dfn>operator-function-id:</dfn></dt>
    <dd><code>operator</code> <var>operator</var></dd>
    <dd><ins><code>operator</code> <var>operator</var> <code>&lt;</code> <var>template-argument-list<sub>opt</sub></var>
    <code>&gt;</code></ins></dd>
  </dl>
</blockquote>
<p>However, when I looked at the matter carefully, I discovered that there are many 
changes that need to be made to resolve the issue, which were not made as part of 
issue 38. Moreover, for the sake of those changes, and to have a convenient term 
for an important concept, the grammar needs to be tweaked a bit.</p>
<p>In several places, there are restrictions or conditions on &quot;being a <var>template-id</var>&quot;. 
Of course an <var>operator-function-id</var> with a <var>template-argument-list</var> 
isn&#39;t a <var>template-id</var>, but where those restrictions and conditions apply 
to function templates, it shouldn&#39;t matter whether the function has a name or an
<var>operator-function-id</var>. My first thought was to refer instead to the presence 
of a <var>template-argument-list</var>, but of course that&#39;s optional. The restrictions 
and conditions are really syntactic, and actually refer to the presence of the angle 
brackets delimiting the <var>template-argument-list</var>, if present. So I propose 
to add a new production to refer to the delimited (optional) <var>template-argument-list</var>:</p>
<blockquote>
  <dl>
    <dt><dfn>operator-function-id:</dfn></dt>
    <dd><code>operator</code> <var>operator</var></dd>
    <dd><code>operator</code> <var>operator</var> <ins><var>template-argument-clause</var></ins></dd>
  </dl>
  <dl>
    <dt><dfn>template-id:</dfn></dt>
    <dd><var>template-name</var> <ins><var>template-argument-clause</var></ins></dd>
  </dl>
  <dl>
    <dt><ins><dfn>template-argument-clause:</dfn></ins></dt>
    <dd><ins><code>&lt;</code> <var>template-argument-list<sub>opt</sub></var>
    <code>&gt;</code></ins></dd>
  </dl>
</blockquote>
<p>The other necessary changes have to do with some consequences of the grammar 
changes:</p>
<ul>
  <li>Now that it&#39;s possible to name operator function templates, the standard should 
  say something about them -- currently, it says nothing at all.</li>
  <li>There is an additional context in which it is necessary to determine whether
  <code>&lt;</code> is to be parsed as introducing a <var>template-argument-clause</var>, 
  or as being a relational operator (in other words, how to resolve the shift-reduce 
  conflict).</li>
  <li>There is a new context in which a <var>template-argument</var> may appear; 
  formerly, a <var>template-argument</var> appeared only as a part of a <var>template-id</var>.</li>
  <li>Finally, the category of changes mentioned above: dealing correctly with names 
  of specializations of operator function templates.</li>
</ul>
<h2>Operator function template description</h2>
<p>The smallest possible addition would be in 13.51:</p>
<blockquote>
  <p>A function declaration having one of the following <var>operator-function-ids</var> 
  as its name declares an <dfn>operator function</dfn>. <ins>A function template 
  declaration having one of the following <var>operator-function-ids</var> as its 
  name declares an <dfn>operator function template</dfn>. A specialization of an 
  operator function template is also an operator function.</ins> An operator function 
  is said to <dfn>implement</dfn> the operator named in its <var>operator-function-id</var>.</p>
</blockquote>
<p>If any other change were necessary, then it would certainly be necessary to modify 
13.56, which describes operator functions. However, it is at least conceivable 
that the above change would imply everything else that is true of operator function 
templates. But even if so, it may be desirable to be a little more explicit.</p>
<h2>The shift-reduce conflict</h2>
<p>For template names, this is currently addressed in the first sentence of 14.23:</p>
<blockquote>
  <p>After name lookup (3.4) finds that a name is a <var>template-name</var>, if 
  this name is followed by a <code>&lt;</code>, the <code>&lt;</code> is always taken 
  as the beginning of a <var>template-argument-list</var> and never as a name followed 
  by the less-than operator.</p>
</blockquote>
<p>This description seems to be adequate for names of class templates. As far as 
I can tell, the only ambiguity it resolves is from something that starts with
<code>new X &lt;</code>, in the scope of a class template <code>X</code>. But even 
without the grammar change, it was inadequate for names of function templates.</p>
<p>Probably after an identifier <var>I</var>, <code>&lt;</code> should always be interpreted 
as introducing a <var>template-argument-clause</var> if any member of the overload 
set identified by <var>I</var> is a function template. After all, function pointers 
are very rarely compared for ordering, and it&#39;s not clear what other rule might 
be workable.</p>
<p>My proposed revision of 14.23:</p>
<blockquote>
  <p>After name lookup (3.4) finds that a name is a <var>template-name</var>,
  <ins>or refers to a set of overloaded functions any member of which is a function 
  template,</ins> if this name is followed by a <code>&lt;</code>, the <code>&lt;</code> 
  is always taken as the beginning of a <var>template-argument-<ins>clause</ins></var> 
  and never as <del>a name followed by</del> the less-than operator.</p>
</blockquote>
<p>Clearly, this change is technically unrelated to operator functions. But it still 
seems to be necessary.</p>
<p>Getting back to operator function templates, I propose to add the following to 
13.51, between the grammar rules and the note:</p>
<blockquote>
  <p><ins>If any member of the set of overloaded operator functions implementing 
  the <var>operator</var> is a template, any immediately following <code>&lt;</code> 
  is interpreted as introducing a <var>template-argument-clause</var>, and not as 
  a less-than operator.</ins></p>
</blockquote>
<h2><var>Template-arguments</var> can appear other than in <var>template-ids</var></h2>
<p>There are several places where <var>template-id</var> is mentioned as the context 
in which a <var>template-argument</var> or <var>template-argument-list</var> may 
appear. Since that is no longer the only such context, these references are superfluous 
and should be deleted.</p>
<h3>3.4.110</h3>
<blockquote>
  <p>In a <code>friend</code> declaration naming a member function, a name used 
  in the function declarator and not part of a <var>template-argument</var> <del>
  in a <var>template-id</var></del> is first looked up in the scope of the member 
  function&#39;s class. If it is not found, or if the name is part of a <var>template-argument</var>
  <del>in a <var>template-id</var></del>, the look up is as described for unqualified 
  names in the definition of the class granting friendship.</p>
</blockquote>
<h3>3.4.3.11, third bullet</h3>
<blockquote>
  <p><del>the</del> <var>template-arguments</var> <del>of a <var>template-id</var></del> 
  are looked up in the context in which the entire <var>postfix-expression</var> 
  occurs.</p>
</blockquote>
<p><em>Note:</em> I think that this sentence could also stand to be editorially 
improved. In the first place, a <var>template-argument</var> may be an expression 
containing an arbitrary number of names, and of course only names are looked up. 
Also, I don&#39;t understand why we&#39;re talking about a <var>postfix-expression</var> 
here. Here&#39;s how I think it should really read, without markup:</p>
<blockquote>
  <p>names in a <var>template-argument</var> are looked up in the context in which 
  the containing <var>id-expression</var> occurs.</p>
</blockquote>
<h3>3.4.3.21</h3>
<blockquote>
  <p>If the <var>nested-name-specifier</var> of a <var>qualified-id</var> nominates 
  a namespace, the name specified after the <var>nested-name-specifier</var> is 
  looked up in the scope of the namespace, except that <del>the <var>template-arguments</var></del>
  <ins>names in a <var>template-argument</var></ins> <del>of a <var>template-id</var></del> 
  are looked up in the context in which the <del>entire <var>postfix-expression</var></del>
  <ins>containing <var>id-expression</var></ins> occurs.</p>
</blockquote>
<h3>14.31, second sentence</h3>
<blockquote>
  <p>The type and form of each <var>template-argument</var> <del>specified in a
  <var>template-id</var></del> shall match the type and form specified for the corresponding 
  parameter declared by the template in its <var>template-parameter-list</var>.</p>
</blockquote>
<h2>Names of operator function template specializations</h2>
<p>Most of these changes are substantially replacing a reference to <var>template-id</var> 
with a reference to <var>template-argument-clause</var>.</p>
<h3>7.3.1.23, last sentence</h3>
<blockquote>
  <p>When looking for a prior declaration of a class or a function declared as a
  <code>friend</code>, and when the name of the <code>friend</code> class or function
  <del>is neither a qualified name nor a <var>template-id</var></del> <ins>has neither 
  a <var>nested-name-specifier</var> nor a <var>template-argument-clause</var></ins>, 
  scopes outside the innermost enclosing namespace scope are not considered.</p>
</blockquote>
<p>After I came up with this formulation, I realized that it assumes the resolution 
of core issue 355. Here&#39;s a formulation without that dependency:</p>
<blockquote>
  <p>When looking for a prior declaration of a class or a function declared as a
  <code>friend</code>, and when the name of the <code>friend</code> class or function
  <ins>is not a qualified name and does not have a <var>template-argument-clause</var></ins>, 
  scopes outside the innermost enclosing namespace scope are not considered.</p>
</blockquote>
<h3>7.3.35</h3>
<blockquote>
  <p><del>A <var>using-declaration</var> shall not name a <var>template-id</var>.</del>
  <ins>The <var>unqualified-id</var> in a <var>using-declaration</var> shall not 
  include a <var>template-argument-clause</var>.</ins></p>
</blockquote>
<h3>142, second sentence</h3>
<blockquote>
  <p>In a function template declaration, the <var>declarator-id</var> shall <del>
  be a <var>template-name</var> (i.e., not a <var>template-id</var>)</del> <ins>
  not include a <var>template-argument-clause</var></ins>.</p>
</blockquote>
<h3>14.21</h3>
<blockquote>
  <p>A template specialization (14.7) can be referred to by a <var>template-id</var>
  <ins>or by an <var>operator-function-id</var> with a <var>template-argument-clause</var></ins>:</p>
</blockquote>
<h3>14.23, second sentence</h3>
<blockquote>
  <p>When parsing a <var><del>template-id</del> <ins>template-argument-clause</ins></var>, 
  the first non-nested <code>&gt;</code><sup>127)</sup> is taken as the end of the
  <var>template-argument-<ins>clause</ins></var> rather than a greater-than operator.</p>
</blockquote>
<p>Note that the first sentence of this paragraph was modified above (under &quot;The 
shift-reduce conflict&quot;).</p>
<h3>14.37, first sentence</h3>
<blockquote>
  <p><del>When the template in a <var>template-id</var> is an overloaded function 
  template,</del> <ins>When the identifier in a <var>template-id</var> refers to 
  a set of overloaded functions, or an <var>operator-function-id</var> contains 
  a <var>template-argument-clause</var>,</ins> both non-template functions in the 
  overload set and function templates in the overload set for which the <var>template-arguments</var> 
  do not match the <var>template-parameters</var> are ignored.</p>
</blockquote>
<h3>14.3.21, third bullet</h3>
<blockquote>
  <p>the address of an object or function with external linkage, <del>including 
  function templates and function <var>template-ids</var> but excluding non-static 
  class members,</del> expressed as <code>&amp;</code> <var>id-expression</var> where 
  the <code>&amp;</code> is optional if the name refers to a function or array, or if 
  the corresponding <var>template-parameter</var> is a reference; or</p>
</blockquote>
<p>As far as I can tell, the text I&#39;m recommending to delete makes no normative 
difference. In any event, non-static class data member names do not have external 
linkage, so there is no point in specifically excluding them here. Taken on the 
face of it, the exclusion could also be referring to non-static class member functions, 
but that&#39;s clearly not the intention. As far as the inclusion is concerned, I don&#39;t 
think that&#39;s meant to include non-member function templates with internal linkage 
(see 144). So the inclusion seems to be intended only to clarify -- exactly what, 
I can&#39;t tell.</p>
<p>On the other hand, if that text really does perform some necessary function, 
it would probably be improved by replacing &quot;<var>template-ids</var>&quot; with &quot;template 
specializations&quot;.</p>
<h3>14.41, first sentence</h3>
<blockquote>
  <p>Two <var>template-ids</var> <ins>or <var>operator-function-ids</var> with
  <var>template-argument-clauses</var></ins> refer to the same class or function 
  if their <del>template</del> names are <del>identical</del> <ins>the same (clause 
  3)</ins>, they refer to the same template, ....</p>
</blockquote>
<p>The reference is more specifically to 37.</p>
<h3>14.51</h3>
<blockquote>
  <p>A <del><var>template-id</var>, that is, the <var>template-name</var> followed 
  by a <var>template-argument-list</var></del> <ins><var>template-argument-clause</var></ins> 
  shall not be specified in the declaration of a primary template declaration.</p>
</blockquote>
<h3>14.5.31, first bullet</h3>
<blockquote>
  <p>if the name of the friend <del>is a qualified or unqualified <var>template-id</var></del>
  <ins>includes a <var>template-argument-clause</var></ins>, the friend declaration 
  refers to a specialization of a function template, otherwise</p>
</blockquote>
<h3>14.5.32</h3>
<blockquote>
  <p>A friend function declaration that is not a template declaration and in which 
  the name of the friend is an unqualified <del><var>template-id</var></del>
  <ins>name with a <var>template-argument-clause</var></ins> shall refer to a specialization 
  of a function template declared in the nearest enclosing namespace scope.</p>
</blockquote>
<p>This could be formulated differently (better, in my opinion) if core issue 355 
were resolved.</p>
<h3>14.6.4.21, first sentence</h3>
<blockquote>
  <p>For a function call that depends on a template parameter, if the function name 
  is an <var>unqualified-id</var> <del>but not a <var>template-id</var></del>
  <ins>and has no <var>template-argument-clause</var></ins>, the candidate functions 
  are found using the usual lookup rules (3.4.1, 3.4.2) except that:</p>
</blockquote>
<h3>14.73, third and fourth sentences</h3>
<blockquote>
  <p>In an explicit specialization declaration for a class template, a member of 
  a class template or a class member template, the name of the class that is explicitly 
  specialized shall be a <var>template-id</var>. In the explicit specialization 
  declaration for a function template or a member function template, the name of 
  the function or member function explicitly specialized may <del>be a <var>template-id</var></del>
  <ins>have a <var>template-argument-clause</var></ins>.</p>
</blockquote>
<h3>14.7.22, second sentence</h3>
<blockquote>
  <p>If the explicit instantiation is for a class, a function or a member template 
  specialization, the <var>unqualified-id</var> in the declaration shall <del>be 
  either a <var>template-id</var> or, where</del> <ins>have a <var>template-argument-clause</var>, 
  unless</ins> all template arguments can be deduced<del>, a <var>template-name</var></del>.</p>
</blockquote>
<h3>14.7.311</h3>
<blockquote>
  <p>A trailing <var>template-argument</var> can be left unspecified in the <del>
  <var>template-id</var> naming</del> <ins><var>template-argument-clause</var> associated 
  with the name of</ins> an explicit function template specialization provided it 
  can be deduced from the function argument type.</p>
</blockquote>

</body>

</html>