<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>
Consolidated edits for core issues 245, 254, et al.
</title>
</head>
<body>

<h1>Consolidated edits for core issues 245, 254, et al.</h1>

<table>
<tr>
<td><strong>Doc. No.:</strong></td>
<td>WG21/N1376<br />J16/02-0034</td>
</tr>
</table>

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

<table>
<tr>
<td><strong>Date:</strong></td>
<td>2002-08-08</td>
</tr>
<tr>
<td><strong>Reply to:</strong></td>
<td>Clark Nelson</td>
</tr>
<tr>
<td><strong>Phone:</strong></td>
<td>+1 503 712-8433</td>
</tr>
<tr>
<td><strong>email:</strong></td>
<td>clark.nelson@intel.com</td>
</tr>
</table>
<hr />
<h2>Introduction</h2>

<p>
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&ccedil;ao meeting, the core working group requested a
consolidated presentation of the edits.
This document is that presentation.
</p>

<p>
This document also incorporates edits for issues 283 and 180.
</p>

<p>
Issue 283 was promoted to ready status in Cura&ccedil;ao.
I have included the issue 283 edits (unaltered from Cura&ccedil;ao)
because they affect one of the paragraphs modified for issue 245.
</p>

<p>
Issue 180 was promoted to DR status in Cura&ccedil;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.
</p>

<p>
For rationale and background, see the issues list.
</p>

<h2>The edits</h2>

<h3>3.3.1 [basic.scope.pdecl] paragraph 5</h3>
<blockquote>
<p>
The point of declaration of a class first declared in an
<var>elaborated-type-specifier</var> is as follows:
</p>
<ul>
<li>
for <del>an <var>elaborated-type-specifier</var></del>
<ins>a declaration</ins> of the form
<p>
<var>class-key identifier</var> <code>;</code>
</p>
<del>the <var>elaborated-type-specifier</var> declares</del>
the <var>identifier</var>
<ins>is declared</ins>
to be a <var>class-name</var> in the scope that contains the
declaration, otherwise
</li>
<li>
for an <var>elaborated-type-specifier</var> of the form
<p>
<var>class-key identifier</var>
</p>
if the <var>elaborated-type-specifier</var> is used in the
<var>decl-specifier-seq</var> or
<var>parameter-declaration-clause</var> of a
function defined in namespace scope, the <var>identifier</var> is
declared as a <var>class-name</var> in the namespace that
contains the declaration; otherwise, except as a friend declaration, the
<var>identifier</var> is declared in the smallest
non-class, non-function-prototype scope that contains the declaration.
[<var>Note:</var>
<del>if the <var>elaborated-type-specifier</var> designates
an enumeration, the <var>identifier</var> must refer to an
already declared <var>enum-name</var>. If
the <var>identifier</var> in the <var>elaborated-type-specifier</var> is
a <var>qualified-id</var>, it
must refer to an already declared
<var>class-name</var> or <var>enum-name</var>. See 3.4.4.</del>
<ins>Other forms of <var>elaborated-type-specifier</var> do not declare
a new name, and therefore must refer to an existing
<var>type-name</var>.
See 3.4.4 [basic.lookup.elab] and 7.1.5.3 [dcl.type.elab].</ins>
]
</li>
</ul>
</blockquote>

<h3>3.4.4 [basic.lookup.elab] paragraph 1</h3>
<blockquote>
<p>
An <var>elaborated-type-specifier</var> <ins>(7.1.5.3
[dcl.type.elab])</ins> may be used to refer to a
previously declared <var>class-name</var> or <var>enum-name</var> even
though the name has been hidden by a non-type declaration (3.3.7).
<del>The
<var>class-name</var> or <var>enum-name</var> in the
<var>elaborated-type-specifier</var> may be either
be a simple
<var>identifer</var> or be a
<var>qualified-id</var>.</del>
</p>
</blockquote>

<h3>3.4.4 [basic.lookup.elab] paragraph 2</h3>
<blockquote>
<p>
If <del>the name in</del> the <var>elaborated-type-specifier</var>
<del>is a simple
<var>identifer</var></del> <ins>has no
<var>nested-name-specifier</var></ins>, and
unless the <var>elaborated-type-specifier</var>
<del>has</del> <ins>appears in a declaration with</ins> the following form:
</p>
<p>
<var>class-key identifier</var> <code>;</code>
</p>
<p>
the <var>identifier</var> is looked up according to 3.4.1 but ignoring
any non-type
names that have been declared. <del>If
this name lookup finds a <var>typedef-name</var>, the
<var>elaborated-type-specifier</var> is
ill-formed.</del> If the <var>elaborated-type-specifier</var>
<del>refers to an <var>enum-name</var></del> <ins>is introduced by the
<code>enum</code> keyword</ins> and this lookup does not find a
previously declared <del><var>enum-name</var></del>
<ins><var>type-name</var></ins>, the
<var>elaborated-type-specifier</var> is ill-formed. If the
<var>elaborated-type-specifier</var> <del>refers to an
<var>class-name</var></del> <ins>is introduced by a
<var>class-key</var></ins>
and this
lookup does not find a previously declared
<del><var>class-name</var></del> <ins><var>type-name</var></ins>, or if
the <var>elaborated-type-specifier</var> <del>has</del> <ins>appears in a
declaration with</ins> the form:
</p>
<p>
<var>class-key identifier</var> <code>;</code>
</p>
<p>
the <var>elaborated-type-specifier</var> is a declaration that introduces the
<var>class-name</var> as described in 3.3.1.
</p>
</blockquote>

<h3>3.4.4 [basic.lookup.elab] paragraph 3</h3>
<p>
Note: the example is not touched.
</p>
<blockquote>
<p>
If the <del>name is a <var>qualified-id</var>, the name is looked up
according its qualifications</del>
<ins><var>elaborated-type-specifier</var> has a
<var>nested-name-specifier</var>, qualified name lookup is
performed</ins>, as described in 3.4.3, but
ignoring any non-type names that have been declared.  <del>If this name
lookup finds a <var>typedef-name</var>, the
<var>elaborated-type-specifier</var> is ill-formed.</del>  If this name
lookup does not find a previously declared <del><var>class-name</var>
or <var>enum-name</var></del> <ins><var>type-name</var></ins>, the
<var>elaborated-type-specifier</var> is ill-formed.
</p>
</blockquote>

<h3>5.2 [expr.post] grammar rule <var>postfix-expression</var></h3>
<blockquote>
<dl>
<dt>
<var>postfix-expression:</var>
</dt>
<dd>
<var>primary-expression</var>
</dd>
<dd>
<var>postfix-expression</var> <code>[</code> <var>expression</var>
<code>]</code>
</dd>
<dd>
<var>postfix-expression</var> <code>(</code>
<var>expression-list<sub>opt</sub> </var> <code>)</code>
</dd>
<dd>
<var>simple-type-specifier</var> <code>(</code>
<var>expression-list<sub>opt</sub></var> <code>)</code>
</dd>
<dd>
<del><code>typename ::</code><var><sub>opt</sub> nested-name-specifier
identifier</var> <code>(</code> <var>expression-list<sub>opt</sub></var>
<code>)</code></del>
</dd>
<dd>
<del><code>typename ::</code><var><sub>opt</sub>
nested-name-specifier</var> <code>template</code><var><sub>opt</sub>
template-id</var> <code>(</code>
<var>expression-list<sub>opt</sub></var> <code>)</code></del>
</dd>
<dd>
<ins><var>typename-specifier</var> <code>(</code>
<var>expression-list<sub>opt</sub></var> <code>)</code></ins>
</dd>
<dd>
<var>postfix-expression</var> <code>. template</code><var><sub>opt</sub>
id-expression</var>
</dd>
<dd>
<var>postfix-expression</var> <code>-&gt;
template</code><var><sub>opt</sub> id-expression</var>
</dd>
<dd>
<var>postfix-expression</var> <code>.</code>
<var>pseudo-destructor-name</var>
</dd>
<dd>
<var>postfix-expression</var> <code>-&gt;</code>
<var>pseudo-destructor-name</var>
</dd>
<dd>
<var>postfix-expression</var> <code>++</code>
</dd>
<dd>
<var>postfix-expression</var> <code>--</code>
</dd>
<dd>
<code>dynamic_cast &lt;</code> <var>type-id</var> <code>&gt; (</code>
<var>expression</var> <code>)</code>
</dd>
<dd>
<code>static_cast &lt;</code> <var>type-id</var> <code>&gt; (</code>
<var>expression</var> <code>)</code>
</dd>
<dd>
<code>reinterpret_cast &lt;</code> <var>type-id</var> <code>&gt; (</code>
<var>expression</var> <code>)</code>
</dd>
<dd>
<code>const_cast &lt;</code> <var>type-id</var> <code>&gt; (</code>
<var>expression</var> <code>)</code>
</dd>
<dd>
<code>typeid (</code> <var>expression</var> <code>)</code>
</dd>
<dd>
<code>typeid (</code> <var>type-id</var> <code>)</code>
</dd>
</dl>
</blockquote>

<h3>7.1.5 [dcl.type] grammar rule <var>type-specifier</var></h3>
<blockquote>
<dl>
<dt>
<var>type-specifier:</var>
</dt>
<dd>
<var>simple-type-specifier</var>
</dd>
<dd>
<var>class-specifier</var>
</dd>
<dd>
<var>enum-specifier</var>
</dd>
<dd>
<var>elaborated-type-specifier</var>
</dd>
<dd>
<ins><var>typename-specifier</var></ins>
</dd>
<dd>
<var>cv-qualifier</var>
</dd>
</dl>
</blockquote>

<h3>7.1.5.3 [dcl.type.elab] grammar rule
<var>elaborated-type-specifier</var></h3>
<p>
Note: a TC1 change is here considered part of the original, and is
therefore not indicated as part of this edit.
</p>
<blockquote>
<dl>
<dt>
<var>elaborated-type-specifier:</var>
</dt>
<dd>
<var>class-key</var> <code>::</code><var><sub>opt</sub>
nested-name-specifier<sub>opt</sub> identifier</var>
</dd>
<dd>
<var>class-key</var> <code>::</code><var><sub>opt</sub>
nested-name-specifier<sub>opt</sub></var>
<code>template</code><var><sub>opt</sub> template-id</var>
</dd>
<dd>
<code>enum ::</code><var><sub>opt</sub>
nested-name-specifier<sub>opt</sub> identifier</var>
</dd>
<dd>
<del><code>typename ::</code><var><sub>opt</sub> nested-name-specifier
identifier</var></del>
</dd>
<dd>
<del><code>typename ::</code><var><sub>opt</sub>
nested-name-specifier</var> <code>template</code><var><sub>opt</sub>
template-id</var></del>
</dd>
</dl>
</blockquote>

<h3>7.1.5.3 [dcl.type.elab] paragraph 2</h3>
<p>
Note: a change for issue 283 is incorporated here.
</p>
<blockquote>
<p>
3.4.4 describes how name lookup proceeds for the <var>identifier</var>
in an <var>elaborated-type-specifier</var>. If the
<var>identifier</var> resolves to a <var>class-name</var> or
<var>enum-name</var>, the
<var>elaborated-type-specifier</var> introduces it into the declaration
the same way a <var>simple-type-specifier</var> introduces its
<var>type-name</var>.  If the
<var>identifier</var> resolves to a <var>typedef-name</var> <del>or a
template <var>type-parameter</var></del>, the
<var>elaborated-type-specifier</var> is ill-formed.  [<var>Note:</var>
this implies that,
within a class template with a template <var>type-parameter</var>
<code>T</code>, the declaration
</p>
<p>
<code>friend class T;</code>
</p>
<p>
is ill-formed.
]
<del>If name lookup does not find a declaration for the
name, the <var>elaborated-type-specifier</var> is
ill-formed unless it is of the simple form <var>class-key
identifier</var> in which
case the <var>identifier</var> is declared as
described in 3.3.1.</del>
</p>
</blockquote>

<h3>9.1 [class.name] paragraph 3</h3>
<p>
Note: this paragraph becomes a note; the example is not touched.
</p>
<blockquote>
<p>
<ins>[<var>Note:</var></ins>
An <var>elaborated-type-specifier</var> (7.1.5.3) can also be used as a
<var>type-specifier</var> 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.
<ins>]</ins>
</p>
</blockquote>

<h3>9.1 [class.name] paragraph 5</h3>
<p>
Note: this paragraph becomes a note.
</p>
<blockquote>
<p>
<ins>[<var>Note:</var></ins>
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.
<ins>]</ins>
</p>
</blockquote>

<h3>14.1 [temp.param] paragraph 3</h3>
<p>
Note: the note is not touched.
This change is for issue 283.
</p>
<blockquote>
<p>
A <var>type-parameter</var> defines its <var>identifier</var> to be a
<del><var>type-name</var></del> <ins><var>typedef-name</var></ins> (if
declared with <code>class</code> or <code>typename</code>) or
<var>template-name</var> (if declared with <code>template</code>) in the
scope of the template declaration.
</p>
</blockquote>

<h3>14.6 [temp.res] paragraph 3</h3>
<p>
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.
</p>
<blockquote>
<p>
A <var>qualified-id</var> that refers to a type and in which the
<var>nested-name-specifier</var> depends on a
<var>template-parameter</var> (14.6.2) shall be prefixed
by the keyword <code>typename</code> to indicate that the
<var>qualified-id</var> denotes a
type, forming <del>an <var>elaborated-type-specifier</var> (7.1.5.3)</del>
<ins>a <var>typename-specifier</var></ins>.
</p>
<dl>
<dt>
<del><var>elaborated-type-specifier:</var></del>
</dt>
<dt>
<ins><var>typename-specifier:</var></ins>
</dt>
<dd>
<del><code>. . .</code></del>
</dd>
<dd>
<code>typename ::</code><var><sub>opt</sub> nested-name-specifier
identifier</var>
</dd>
<dd>
<code>typename ::</code><var><sub>opt</sub> nested-name-specifier</var>
<code>template</code><var><sub>opt</sub> template-id</var>
</dd>
<dd>
<del><code>. . .</code></del>
</dd>
</dl>
</blockquote>

<h3>14.6 [temp.res] paragraph 5</h3>
<p>
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.
</p>
<blockquote>
<p>
The keyword <code>typename</code> 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 <var>type-specifier</var> for the definition
of a static member of a class template or of a class nested within a
class template. The keyword
<code>typename</code> shall be applied only to qualified names, but
those names need
not be dependent.
The keyword <code>typename</code> 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.
<del>The keyword
<code>typename</code> is not permitted in a <var>base-specifier</var> or
in a <var>mem-initializer</var>;
in these contexts a <var>qualified-id</var>
that depends on a <var>template-parameter</var> (14.6.2) is implicitly
assumed to be a type name.</del>
<ins>A qualified name used as the name in a
<var>mem-initializer-id</var>, a <var>base-specifier</var>, or an
<var>elaborated-type-specifier</var> is implicitly assumed to name a
type, without the use of the <code>typename</code> keyword.
[<var>Note:</var>
the <code>typename</code> keyword is not permitted by the syntax of
these constructs. ]</ins>
</p>
</blockquote>

</body>
</html>
