Title
Template parameters are not allowed in nested-name-specifiers
Status
cd1
Section
13.2 [temp.param]
Submitter
Martin von Loewis

Created on 2000-03-13.00:00:00 last changed 161 months ago

Messages

Date: 2007-04-15.00:00:00

[Voted into WP at April, 2007 meeting.]

Date: 2006-04-15.00:00:00

Proposed resolution (April, 2006):

Change 6.5.5 [basic.lookup.qual] paragraph 1 as follows:

The name of a class or namespace member can be referred to after the :: scope resolution operator (_N4567_.5.1.1 [expr.prim.general]) applied to a nested-name-specifier that nominates its class or namespace. During the lookup for a name preceding the :: scope resolution operator, object, function, and enumerator names are ignored. If the name found is not a class-name (clause Clause 11 [class]) or namespace-name (9.8.2 [namespace.def]) does not designate a namespace or a class or dependent type, the program is ill-formed. [...]
Date: 2005-04-15.00:00:00

Notes from the April, 2005 meeting:

The 10/2004 resolution does not take into account the fact that template type parameters do not designate class types in the context of the template definition. Further drafting is required.

Date: 2004-10-15.00:00:00

Proposed resolution (October, 2004):

Change 6.5.5 [basic.lookup.qual] paragraph 1 as follows:

The name of a class or namespace member can be referred to after the :: scope resolution operator (_N4567_.5.1.1 [expr.prim.general]) applied to a nested-name-specifier that nominates its class or namespace. During the lookup for a name preceding the :: scope resolution operator, object, function, and enumerator names are ignored. If the name found is not a class-name (clause Clause 11 [class]) or namespace-name (9.8.2 [namespace.def]) does not designate a class or namespace, the program is ill-formed. [...]
Date: 2003-04-15.00:00:00

Notes from April 2003 meeting:

This was partly resolved by the changes for issue 125. However, we also need to add a semantic check in 6.5.5 [basic.lookup.qual] to allow T::foo and we need to reword the first sentence of 6.5.5 [basic.lookup.qual].

Date: 2001-10-15.00:00:00

Notes from 10/01 meeting:

There was some sentiment for going with simply identifier in front of the "::", and stronger sentiment for going with something with a more descriptive name if possible. See also issue 180.

Date: 2001-04-15.00:00:00

Proposed resolution (04/01):

Change _N4567_.5.1.1 [expr.prim.general] paragraph 7 and A.5 [gram.expr] from

    nested-name-specifier:
      class-or-namespace-name :: nested-name-specifieropt
      class-or-namespace-name :: template nested-name-specifier
    class-or-namespace-name:
      class-name
      namespace-name

to

    nested-name-specifier:
      type-or-namespace-name :: nested-name-specifieropt
      type-or-namespace-name :: template nested-name-specifier
    type-or-namespace-name:
      type-name
      namespace-name

This resolution depends on the resolutions for issues 245 (to change the name lookup rules in elaborated-type-specifiers to include all type-names) and 283 (to categorize template type-parameters as type-names).

Date: 2000-04-15.00:00:00

Notes from 04/00 meeting:

The discussion at the meeting revealed a self-contradiction in the current IS in the description of nested-name-specifiers. According to the grammar in _N4567_.5.1.1 [expr.prim.general] paragraph 7, the components of a nested-name-specifier must be either class-names or namespace-names, i.e., the constraint is syntactic rather than semantic. On the other hand, 6.5.5 [basic.lookup.qual] paragraph 1 describes a semantic constraint: only object, function, and enumerator names are ignored in the lookup for the component, and the program is ill-formed if the lookup finds anything other than a class-name or namespace-name. It was generally agreed that the syntactic constraint should be eliminated, i.e., that the grammar ought to be changed not to use class-or-namespace-name.

A related point is the explicit prohibition of use of template parameters in elaborated-type-specifiers in 9.2.9.4 [dcl.type.elab] paragraph 2. This rule was the result of an explicit Committee decision and should not be unintentionally voided by the resolution of this issue.

Date: 2017-02-06.00:00:00

According to 13.2 [temp.param] paragraph 3, the following fragment is ill-formed:

    template <class T>
    class X{
      friend void T::foo();
    };

In the friend declaration, the T:: part is a nested-name-specifier (9.3 [dcl.decl] paragraph 4), and T must be a class-name or a namespace-name (_N4567_.5.1.1 [expr.prim.general] paragraph 7). However, according to 13.2 [temp.param] paragraph 3, it is only a type-name. The fragment should be well-formed, and instantiations of the template allowed as long as the actual template argument is a class which provides a function member foo. As a result of this defect, any usage of template parameters in nested names is ill-formed, e.g., in the example of 13.8 [temp.res] paragraph 2.

History
Date User Action Args
2008-10-05 00:00:00adminsetstatus: wp -> cd1
2007-08-05 00:00:00adminsetstatus: dr -> wp
2007-05-06 00:00:00adminsetmessages: + msg1508
2007-05-06 00:00:00adminsetstatus: ready -> dr
2006-11-05 00:00:00adminsetstatus: review -> ready
2006-04-22 00:00:00adminsetmessages: + msg1326
2006-04-22 00:00:00adminsetstatus: drafting -> review
2005-05-01 00:00:00adminsetmessages: + msg1164
2005-05-01 00:00:00adminsetstatus: review -> drafting
2004-11-07 00:00:00adminsetmessages: + msg1064
2004-11-07 00:00:00adminsetstatus: drafting -> review
2003-04-25 00:00:00adminsetmessages: + msg840
2001-11-09 00:00:00adminsetstatus: review -> drafting
2000-11-18 00:00:00adminsetmessages: + msg414
2000-11-18 00:00:00adminsetmessages: + msg413
2000-11-18 00:00:00adminsetstatus: drafting -> review
2000-05-21 00:00:00adminsetmessages: + msg347
2000-03-13 00:00:00admincreate