Scope of template parameter names
17.1 [temp.param]
John Spicer

Created on 1999-11-15.00:00:00 last changed 208 months ago


Date: 2000-04-15.00:00:00

Proposed resolution (10/00):

[Note: This resolution supersedes the resolution to issue 22.]

Replace 17.1 [temp.param] paragraph 14 as follows:

A template parameter shall not be used in its own default argument.
Date: 2000-04-15.00:00:00

Notes from 04/00 meeting:

The core working group did not reach consensus on the suggested approach to issue 22. However, it was agreed that the intent expressed in the earlier resolution would be better served by different wording.

Date: 1999-04-15.00:00:00

At the Dublin meeting (04/99), the Committee proposed to resolve issue 22 by simply changing the wording to make clear that a template parameter cannot be used in its own default argument. This creates a third treatment of this kind of situation, in addition to 6.3.2 [basic.scope.pdecl] paragraph 1, where declarators are in scope and can be used in their initializers, and paragraph 3, where an enumerator is not in scope until after its complete enumerator-definition. The Dublin resolution is for the template parameter to be in scope in its default argument but not usable. It would be more consistent to treat template parameters like enumerators: simply not in scope until the entire template-parameter declaration is seen.

On a related note, 17.1 [temp.param] paragraph 14 should be rewritten to connect the prohibition with visibility rules; otherwise, it sounds as if the following example is not permitted:

    const int Z = 1;
    template <int X = Z, int Z> class A {};
Date User Action Args
2003-04-25 00:00:00adminsetstatus: dr -> tc1
2000-11-18 00:00:00adminsetstatus: ready -> dr
2000-05-21 00:00:00adminsetmessages: + msg324
2000-05-21 00:00:00adminsetmessages: + msg323
2000-05-21 00:00:00adminsetstatus: open -> ready
1999-11-15 00:00:00admincreate