Consolidated edits for core issues 245, 254, et al.

Accredited Standards Committee*
INCITS, InterNational Committee for Information Technology Standards
*Operating under the procedures of the American National Standards Institute
INCITS Secretariat, Information Technology Industry Council (ITI)
1250 Eye Street NW, Suite 200; Washington DC 20005
Telephone 202-737-8888; Fax 202-638-4922
Email: INCITS@itic.org

Introduction

Core issue 254 was opened in response to looking at the standard text pointed out by issue 245. Although the issues described in 254 are disjoint from those in 245, the changes are to many of the same paragraphs. At the Curaçao meeting, the core working group requested a consolidated presentation of the edits. This document is that presentation.

This document also incorporates edits for issues 283 and 180.

Issue 283 was promoted to ready status in Curaçao. I have included the issue 283 edits (unaltered from Curaçao) because they affect one of the paragraphs modified for issue 245.

Issue 180 was promoted to DR status in Curaçao. However, its resolution was acknowledged to depend on the resolution of issue 254, and the exact nature of the dependency was clearly spelled out in the issue when it was approved by the full committee. Because of the dependency, and in the interests of presenting a complete package, I have included the modified edits here. However, because these edits are clearly implied by what the full committee already approved, it is hopefully not necessary to "demote" issue 180 back from DR status due to the change.

For rationale and background, see the issues list.

The edits

3.3.1 [basic.scope.pdecl] paragraph 5

The point of declaration of a class first declared in an elaborated-type-specifier is as follows:

• for an elaborated-type-specifier a declaration of the form

  class-key identifier ;

  the elaborated-type-specifier declares the identifier is declared to be a class-name in the scope that contains the declaration, otherwise
• for an elaborated-type-specifier of the form

  class-key identifier

  if the elaborated-type-specifier is used in the decl-specifier-seq or parameter-declaration-clause of a function defined in namespace scope, the identifier is declared as a class-name in the namespace that contains the declaration; otherwise, except as a friend declaration, the identifier is declared in the smallest non-class, non-function-prototype scope that contains the declaration. [Note: if the elaborated-type-specifier designates an enumeration, the identifier must refer to an already declared enum-name. If the identifier in the elaborated-type-specifier is a qualified-id, it must refer to an already declared class-name or enum-name. See 3.4.4. Other forms of elaborated-type-specifier do not declare a new name, and therefore must refer to an existing type-name. See 3.4.4 [basic.lookup.elab] and 7.1.5.3 [dcl.type.elab]. ]

3.4.4 [basic.lookup.elab] paragraph 1

An elaborated-type-specifier (7.1.5.3 [dcl.type.elab]) may be used to refer to a previously declared class-name or enum-name even though the name has been hidden by a non-type declaration (3.3.7). The class-name or enum-name in the elaborated-type-specifier may be either be a simple identifer or be a qualified-id.

3.4.4 [basic.lookup.elab] paragraph 2

If the name in the elaborated-type-specifier is a simple identifer has no nested-name-specifier, and unless the elaborated-type-specifier has appears in a declaration with the following form:

class-key identifier ;

the identifier is looked up according to 3.4.1 but ignoring any non-type names that have been declared. If this name lookup finds a typedef-name, the elaborated-type-specifier is ill-formed. If the elaborated-type-specifier refers to an enum-name is introduced by the enum keyword and this lookup does not find a previously declared enum-name type-name, the elaborated-type-specifier is ill-formed. If the elaborated-type-specifier refers to an class-name is introduced by a class-key and this lookup does not find a previously declared class-name type-name, or if the elaborated-type-specifier has appears in a declaration with the form:

class-key identifier ;

the elaborated-type-specifier is a declaration that introduces the class-name as described in 3.3.1.

3.4.4 [basic.lookup.elab] paragraph 3

Note: the example is not touched.

If the name is a qualified-id, the name is looked up according its qualifications elaborated-type-specifier has a nested-name-specifier, qualified name lookup is performed, as described in 3.4.3, but ignoring any non-type names that have been declared. If this name lookup finds a typedef-name, the elaborated-type-specifier is ill-formed. If this name lookup does not find a previously declared class-name or enum-name type-name, the elaborated-type-specifier is ill-formed.

5.2 [expr.post] grammar rule postfix-expression

postfix-expression:

primary-expression

postfix-expression [ expression ]

postfix-expression ( expression-list_opt )

simple-type-specifier ( expression-list_opt )

typename ::_opt nested-name-specifier identifier ( expression-list_opt )

typename ::_opt nested-name-specifier template_opt template-id ( expression-list_opt )

typename-specifier ( expression-list_opt )

postfix-expression . template_opt id-expression

postfix-expression -> template_opt id-expression

postfix-expression . pseudo-destructor-name

postfix-expression -> pseudo-destructor-name

postfix-expression ++

postfix-expression --

dynamic_cast < type-id > ( expression )

static_cast < type-id > ( expression )

reinterpret_cast < type-id > ( expression )

const_cast < type-id > ( expression )

typeid ( expression )

typeid ( type-id )

7.1.5 [dcl.type] grammar rule type-specifier

type-specifier:

simple-type-specifier

class-specifier

enum-specifier

elaborated-type-specifier

typename-specifier

cv-qualifier

7.1.5.3 [dcl.type.elab] grammar rule elaborated-type-specifier

Note: a TC1 change is here considered part of the original, and is therefore not indicated as part of this edit.

elaborated-type-specifier:

class-key ::_opt nested-name-specifier_opt identifier

class-key ::_opt nested-name-specifier_opt template_opt template-id

enum ::_opt nested-name-specifier_opt identifier

typename ::_opt nested-name-specifier identifier

typename ::_opt nested-name-specifier template_opt template-id

7.1.5.3 [dcl.type.elab] paragraph 2

Note: a change for issue 283 is incorporated here.

3.4.4 describes how name lookup proceeds for the identifier in an elaborated-type-specifier. If the identifier resolves to a class-name or enum-name, the elaborated-type-specifier introduces it into the declaration the same way a simple-type-specifier introduces its type-name. If the identifier resolves to a typedef-name or a template type-parameter, the elaborated-type-specifier is ill-formed. [Note: this implies that, within a class template with a template type-parameter T, the declaration

friend class T;

is ill-formed. ] If name lookup does not find a declaration for the name, the elaborated-type-specifier is ill-formed unless it is of the simple form class-key identifier in which case the identifier is declared as described in 3.3.1.

9.1 [class.name] paragraph 3

Note: this paragraph becomes a note; the example is not touched.

[Note: An elaborated-type-specifier (7.1.5.3) can also be used as a type-specifier as part of a declaration. It differs from a class declaration in that if a class of the elaborated name is in scope the elaborated name will refer to it. ]

9.1 [class.name] paragraph 5

Note: this paragraph becomes a note.

[Note: A typedef-name (7.1.3) that names a class is a class-name, but shall not be used in an elaborated-type-specifier; see also 7.1.3. ]

14.1 [temp.param] paragraph 3

Note: the note is not touched. This change is for issue 283.

A type-parameter defines its identifier to be a type-name typedef-name (if declared with class or typename) or template-name (if declared with template) in the scope of the template declaration.

14.6 [temp.res] paragraph 3

Note: TC1 changes are here considered part of the original, and not indicated as part of this edit. Also, the grammar fragment becomes a grammar rule, and must be re-marked as such in order to appear in Annex A.

A qualified-id that refers to a type and in which the nested-name-specifier depends on a template-parameter (14.6.2) shall be prefixed by the keyword typename to indicate that the qualified-id denotes a type, forming an elaborated-type-specifier (7.1.5.3) a typename-specifier.

elaborated-type-specifier:

typename-specifier:

. . .

typename ::_opt nested-name-specifier identifier

typename ::_opt nested-name-specifier template_opt template-id

. . .

14.6 [temp.res] paragraph 5

Note: TC1 changes are here considered part of the original, and not indicated as part of this edit. This change is for issue 180, as modified by the resolution of issue 254.

The keyword typename shall only be used in template declarations and definitions, including in the return type of a function template or member function template, in the return type for the definition of a member function of a class template or of a class nested within a class template, and in the type-specifier for the definition of a static member of a class template or of a class nested within a class template. The keyword typename shall be applied only to qualified names, but those names need not be dependent. The keyword typename shall be used only in contexts in which dependent names can be used. This includes template declarations and definitions but excludes explicit specialization declarations and explicit instantiation declarations. The keyword typename is not permitted in a base-specifier or in a mem-initializer; in these contexts a qualified-id that depends on a template-parameter (14.6.2) is implicitly assumed to be a type name. A qualified name used as the name in a mem-initializer-id, a base-specifier, or an elaborated-type-specifier is implicitly assumed to name a type, without the use of the typename keyword. [Note: the typename keyword is not permitted by the syntax of these constructs. ]