I know very well why one needs to use typename
for dependent types, since the compiler may not be able to disambiguate between a type and a variable declaration when it sees something like T::type
, see e.g. this answer for a great explanation. TL;DR: in an expression like T::type * x;
, the compiler cannot "know" whether T::type
is a type or perhaps a variable declared in some particular specialization for T
.
However, in something like
using type = T::type;
there is nothing ambiguous. IMO, T::type
should always be parsed as a type, as it's part of the RHS of a using
statement. However, we still need to use the typename
here (at least according to gcc and clang),
using type = typename T::type;
Live on Coliru, gcc Live on Coliru, clang
Visual C++ seems to accept the code without a typename
, however I don't have too much faith in the compiler being fully standard compliant (in fact, it has many non-standard extensions, e.g. binding rvalues to non-const references).
Question: Is there any reason why this is not an exception to the typename
rule in C++11 and later?
There is no hard reason. As ralismark said, a paper was discussed this year (for C++20, not 17!). There are concerns, but also counterpoints:
typename
will become rare enough as to have near-consistency in the other direction. (As has been said, there was already an exceptional case in the form of base class names.)The paper has strong support and the new rules will probably appear in the working draft in a few months.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With