|Date:||September 19, 2003|
|Author:||John Spicer, Edison Design Group|
This is a revision to issue 96 in the core issues list and a follow-up to an earlier discussion of the issue in N1231.
In my original reflector posting on this subject I recommended that
the standard be changed to require that the
keyword be followed by a template-id (i.e., a name followed by
The following example gives the rationale for this recommendation.
template keyword is only supposed to provide syntactic
disambiguation, not affect name lookup (just as is the case with the
typename keyword). This results in the surprising behavior
that call #2 does not call the template function.
templatekeyword is needed in the default argument to indicate that
T::Cis a template, just as
typenamewould be required if
T::Cwere a type.
templatekeyword without a following
If we allow the template keyword to be followed by a name without a template-argument-list 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 template-argument-list, it refers to a specialization of the class template, if not, it refers to the class template itself).
There are two possible interpretations that I can think of:
templatekeyword 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 template-argument-list (i.e.,
templatekeyword is followed by a name that does not have a template-argument-list, the name must refer to a class template and be used in a context in which a class template is valid (i.e., the example above would be ill-formed).
Existing practice seems to favor #2. The Microsoft, g++, and EDG compilers
a.template f<>(t), and all reject
When this was last discussed, a few issues were raised:
templatekeyword interact with using-declarations.
templatewhen naming a dependent template template argument?
The first issue has now been dealt with by issue #109 (
is not permitted before the final component of a qualified-name in
As for the second issue, the
template keyword is not
required in order for syntactic purposes, so in theory it would be
possible to not require its use when naming a dependent template template
argument. However, the same statement could be made about certain uses
typename that are not strictly required.
I've personally gone back and forth on the issue of permitting
template in a class member access that does not include a
template argument list. My summary of the strongest arguments on both
templateto make their use simpler. It would be nice if we could allow
templatein places where it is not required to make life easier on less sophisticated users.
templatewere to affect the set of names considered by overload resolution in a reference like "
p->template f()", the keyword would have subtle semantic effects, something that we've been avoiding for both
What looks like an advantage to the user (being able to liberally use
template) can actually have surprising semantic consequences.
In other words, both of these would be valid:
While I would like to make use of
template easier for users,
I think the cost of understanding the subtle semantic impact outweighs
Consequently, the recommendation of this paper is:
template keyword is followed by a name that does
not have a template-argument-list, the name must refer to
a class template and be used in a context in which a class template
is valid, otherwise the program is ill-formed.