Andre Morozov wrote:
> The text of the draft [N1905=05-0165], clause 2, states that the word
> typename followed by a qualified-id denotes the type of a non-type parameter
> declaration:
> ------------------------------------------------------------------------------------------
> 14.1 Template parameters [temp.param]
>     1 The syntax for template-parameters is:
>         template-parameter:
>             type-parameter
>             parameter-declaration
> ..
>     2 There is no semantic difference between class and typename in a
> template-parameter. typename followed by an
> unqualified-id names a template type parameter. *** typename followed by a
> qualified-id denotes the type in a non-type
> 132) parameter-declaration. ***
> -------------------------------------------------------------------------------------------
>
> However, qualified-id is defined as a sequence that either begins with :: or
> nested-name-specifier, which is always followed by ::. The text should
> probably say "typename followed by decl-specifier-seq denotes the type in a
> non-type parameter-declaration".

No, this says what it says intentionally.  The issue is that there is
an
apparent ambiguity between use of the "typename" keyword to declare
a template type parameter and its use to mark a dependent name as a
type (14.6p3).  The latter use can only occur with a qualified-id, so
use
of typename with an unqualified-id is always a declaration of a
template
type parameter, regardless of whether the identifier is a type-name in
the containing scope.  For example:

    struct T { };
    template <typename T> void f(T);

The "T"s in the declaration of "f" are both a template type parameter
and not the class-name ::T.  (Cf 14.1p3.)

On the other hand, in a declaration like

    template <typename T> struct X;
    template <typename T, typename X<T>::type> void g(T);

the second template parameter in the declaration of "g" is an unnamed
non-type parameter; the "typename" keyword identifies X<T>::type as
a type.

I agree that the description in 14.1p2 is not as clear as it should be,
however, so I will open a core language issue suggesting a
clarification.

-- William M. (Mike) Miller
   Edison Design Group

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]