<!-- saved from url=(0022)http://internet.e-mail -->
<HTML>
<HEAD>
   <style>
     <!--
       P.indented {margin-left: 4em}
       XMP.indented {margin-left: 4em}
     -->
   </style>
   <TITLE>
       Miscellaneous Template Issues for Tokyo Meeting
   </TITLE>
</HEAD>

<BODY>

<TABLE ALIGN=RIGHT CELLSPACING=0 CELLPADDING=0 >
<TR>
<TD ALIGN=RIGHT>Document number:</TD>

<TD>&nbsp;00-0008/N1231</TD>
</TR>

<TR>
<TD ALIGN=RIGHT>Date:</TD>

<TD>&nbsp;March 7, 2000</TD>
</TR>

<TR>
<TD ALIGN=RIGHT>Author:</TD>

<TD>&nbsp;John Spicer, Edison Design Group</TD>
</TR>

<TR>
<TD></TD>

<TD>&nbsp;<TT>jhs@edg.com</TT></TD>
</TR>
</TABLE>

<BR CLEAR=ALL>

<CENTER>
<H2>
Miscellaneous Template Issues for Tokyo Meeting
</H2>
</center>

<h3>Introduction</h3>
<p>
This document discusses several issues that I volunteered to work on
between meetings:

<ol>
<li><a href="#issue96">Syntactic disambiguation using the template keyword (issue 96)</a>
<li><a href="#issue108">Are classes nested in templates dependent?</a>
<li><a href="#new1">Definition of dependent name (possibly new)</a>
</ol>

<h3>
<a name="issue96">96. Syntactic disambiguation using the template keyword.</a>
</h3>
This is a revision to issue 96 in the core issues list.  As described
below, experience with template template parameters has resulted in a
change in my recommendation with respect to this issue.
<p>
In my original reflector posting on this subject I recommended that
the standard be changed to require that the <code>template</code>
keyword be followed by a <i>template-id</i> (i.e., a name followed by
a <i>template-argument-list</i>).
<p>
The following example gives the rationale for this recommendation.
The <code>template</code> keyword is only supposed to provide syntactic
disambiguation, not affect name lookup (just as is the case with the
<code>typename</code> keyword).  This results in the surprising behavior
that call #2 does <em>not</em> call the template function.

<xmp class=indented>
struct A {
	void f(int);
	template <class T> void f(T);
};

template <class T> void f(T t)
{
	A a;
	a.template f<>(t); // #1 calls template
	a.template f(t);   // #2 but does this call the template?
}
</xmp>

The counter example came up while we were implementing template
template parameters.  In this example, the <code>template</code> keyword
is needed in the default argument to indicate that <code>T::C</code> is
a template, just as <code>typename</code> would be required if
<code>T::C</code> were a type.

<xmp class=indented>
template <class T> struct A {template <class T2> struct C {}; };
template <class T, template <class X> class TT = T::template C> struct B {};
</xmp>

In other words, there are cases where we need to permit the
<code>template</code> keyword without a following <code>template-id</code>.
<p>
If we allow the template keyword to be followed by a name without a
<i>template-argument-list</i> we must then decide what it means 
for functions in such cases (i.e., we must resolve the issue illustrated
by the first example above).  For classes it is not an issue
(if the name is followed by a <i>template-argument-list</i>, it refers
to a specialization of the class template, if not, it refers to the
class template itself).
<p>
There are two possible interpretations that I can think of:
<ol>
<li>
When the <code>template</code> keyword is applied to an overload set
containing both template and non-templates, the non-templates are ignored.
In other words, it is treated as if the name were followed by an
empty <i>template-argument-list</i> (i.e., <code>&lt;></code>).
<li>
If the <code>template</code> keyword is followed by a name that does
not have a <i>template-argument-list</i>, the program is ill-formed
if the name refers to anything except a class template (i.e., it cannot
refer to a function, function template, or overload set).
</ol>
Note that a name that refers to a class template (and not to a specialization
of the class template) must be a template
argument associated with a template template parameter, because there is
no other context in which a template name without a
<i>template-argument-list</i> is permitted).
<p>
The first option has the benefit of being (presumably) what people would
find most natural.  The second has the benefit of retaining the
property that the <code>template</code> keyword is for syntactic guidance
without semantic implications.

<h3>
<a name="issue108">Are classes nested in templates dependent?</a>
</h3>

<p>
This is the proposed wording change for core issue 108.

<p>Add after 14.6.1 paragraph 2:
<blockquote>
Within the scope of a class template, when the unqualified name of a nested
class of the class template is referred to, it is equivalent to the name of
enclosing class template followed by the name of the nested class.
[<i>Example:</i>
<xmp class=indented>
template <class T> struct A {
	class B {};
	// B is equivalent to A::B, which is equivalent to A<T>::B
	// which is dependent.
	class C : B { };
};
</xmp>
<i>--end example</i>]
</blockquote>

<h3>
<a name="new1">Definition of dependent name</a>
</h3>

<p>
This issue was discussed on the reflector and may already be in the
updated core issues list.
<p>
There is a problem with the dependency rules when referring to members of
the "current instantiation" of a class template.
The example below (a modified version of Derek Inglis' example from
core-8387) illustrates that the name used to refer to an entity
can render the same entity either dependent or non-dependent.
<p>
I believe this behavior is surprising, and that programmers would expect
that whether you refer to the members as <code>A</code>,
<code>a</code>, and <code>a2</code> or <code>S::A</code>,
<code>S::a</code> and <code>S::a2</code> or <code>S&lt;T>::A</code>,
<code>S&lt;T>::a</code> and <code>S&lt;T>::a2</code>, the behavior should be
the same.
<p>
Note that the behavior should only be the same when you refer
to the <i>template-id</i> that is equivalent to the unqualified template name
as described in 14.6.1p1.  Something like <code>S&lt;T*>::A</code> would not be
equivalent to <code>S::A</code> or <code>A</code>.

<xmp class=indented>
void foo(char);
template <class T> struct S {
	typedef int A;
	int    a;
	A      a2;
	S::A   a3;
	void bar() {
		foo( S<T>::A() );  // #1
		foo( A() );        // #2
		foo( S<T>::a );    // #3
		foo( a );          // #4
		foo( a2 );         // #5
		foo( a3 );         // #6
	}
};
   
void foo(int);
   
int main() {
	S<int> s;
	s.bar();
}
</xmp>

But according to the standard, these are not actually equivalent.
<p>   
<code>S&lt;T>::a</code> is dependent because the <i>id-expression</i>
contains a <i>template-id</i> that is dependent.  Likewise,
<code>S::a</code> is dependent because it is defined as being
equivalent to <code>S&lt;T>::a</code>.  As far as I can tell, plain
<code>a</code> is not dependent while <code>this->a</code> is.  If
plain <code>a</code> is not dependent then neither is plain
<code>A</code>, making <code>a2</code> also non-dependent.
<code>a3</code> <em>is</em> dependent though, because its type was declared
using a dependent syntax.
<p>   
I don't think these rules are reasonable.
<p>
An id-expression should be dependent if its type is dependent.  The
form of the identifier reference should not make a difference.
Similarly, the type of <code>a</code>, <code>a2</code>, and
<code>a3</code> should be known to be <code>int</code>, and none of
them should be considered dependent.
<p>
The standard would need to be clarified to say that within the scope
of <code>S</code> you can look up things like <code>S::A</code> or
<code>S&lt;T>::A</code> to find out the type denoted by <code>A</code>
(note that this does <em>not</em> apply to looking up something like
<code>S&lt;T*>::A</code>).
<p>
<h3>End of document.</h3>

</body>
