Injected-class-names of class templates - c++

Inspired by the code in this answer. Consider:
template<class>
class A { };
int main()
{
A<float> a(A<float>::A<int>());
return 0;
}
Is this code
ill-formed, because A<float>::A names the constructor (per §3.4.3.1 [class.qual]/p2) and cannot be used in this context (plus the <int> would complete fail to parse anyway), or
well-formed, with A<float>::A being the injected-class-name, used as a template-name (§14.6.1 [temp.local]), such that A<float>::A<int> means exactly the same as A<int>, and a being declared as a function (due to the most vexing parse)?
g++ says 1. clang says 2, and so does ICC 13. Which compiler is correct?

gcc is correct; your snippet is ill-formed!
// reduced testcase
template<class T>
class A { };
int main () {
A<float>::A<int> x; // ill-formed, bug in `clang` and `icc`
}
In the above reduced testcase we have a nested-name-specifier, A<float>::, followed by an unqualified-id A, which is then followed by some gibberish (<int>).
This is because the context in which the nested-name-specifier appears mandates that, during a look-up, function names are included (meaning that the constructor is found first, and the expression is ill-formed).
Relevant Bug Reports:
llvm.org/bugs/ - #8263; Incorrect constructor name resolution
How to circumvent the "problem"?
There are contexts in which member names that are looked up through a nested-name-specifier (that nominates a class) shall not include functions (hence, contexts where the constructor is not found), below are a few examples:
template<class T>
struct A {
typedef T value_type;
};
struct A<float>::A<int> x; // ok, context: elaborate-type-specifier
typename A<float>::A<int> (); // ok, context: [expr.type.conv]p1
A<float>::A::value_type x; // ok, context: nested-name-specifier
struct X : A<float>::A<int> { }; // ok, context: base-specifier
What does the Standard say?
3.4.3.1p2 Class members [class.qual]
In a lookup in which function names are not ignored88 and the nested-name-specifier nominates a class C:
if the name specified after the nested-name-specifier, when looked up in C, is the injected-class-name of C (Clause 9), or
in a using-declaration (7.3.3) that is a member-declaration, if the name specified after the nested-name-specifier is the same as the identifier or the simple-template-id's template-name in the last component of the *nested-name-specicifier,
the name is instead considered to name the constructor of class C.
[ Note: ... ]
Such a constructor name shall be used only in the declarator-id of a declaration that names a constructor or in a using-declaration.
88. Lookups in which function names are ignored include names appearing in a nested-name-specifier, an elaborated-type-specifier, or a base-specifier.
14.6.1p2 Locally declared names [temp.local]
Like normal (non-template) classes, class templates have an injected-class-name
(Clause 9). The injected-class-name can be used as a template-name or a
type-name.
When it is used with a template-argument-list, as a
template-argument for a template template-parameter, or as the final
identifier in the elaborated-type-specifier of a friend class template
declaration, it refers to the class template itself.
Otherwise, it is
equivalent to the template-name followed by the template-parameters of the
class template enclosed in <>.

Related

Does the use a simple-template-id in a nested-name-specifier unambiguously mean a class template specialization?

struct A{
template<typename U>
void T(){}
};
struct B{
template<typename U>
struct T{
using type = U;
};
};
struct C:A,B{
};
int main(){
C::T<int>::type d;
}
This example is accepted by neither GCC nor Clang.
As per basic.lookup.qual#1
The name of a class or namespace member or enumerator can be referred to after the​::​ scope resolution operator ([expr.prim.id.qual]) applied to a nested-name-specifier that denotes its class, namespace, or enumeration. If a​::​ scope resolution operator in a nested-name-specifier is not preceded by a decltype-specifier, lookup of the name preceding that ​::​ considers only namespaces, types, and templates whose specializations are types.
That means that when looking up the declarations for the template name T, the specialization of T shall denote a type in this context. On the other hand, as per class.member.lookup#4
If C contains a declaration of the name f, the declaration set contains every declaration of f declared in C that satisfies the requirements of the language construct in which the lookup occurs.
Again, when looking up the template T in the scope of C, only those templates whose specialization is a type should be considered by this lookup. The scope of C does not have any declarations for T, hence the lookup will be performed for S(T,C) in every one of its base classes. The template T in A does not satisfy the requirement. Meanwhile, the template T declared in the scope of B does satisfy the requirement. So the lookup is not ambiguous and the B::T is the unique result. That means C::T<int>::type d should be well-formed. Why do both GCC and Clang reject this example? Can it be considered a bug of in both? If I missed something, what's the reason that this example should be ill-formed?
The lookahead required to have the lookup for T depend on the :: even as the interpretation of < depends on the meaning of T is considered undesirable. As such, lookup for a name followed by < is not restricted to types and namespaces regardless of any >:: found later. P1787R6 fixed this, restricting the special lookup to identifiers immediately followed by :: (since other kinds of names can’t refer to types or namespaces anyway).

Is "typename" allowed/required in C++11 using-declaration?

The following code compiles correctly in g++ and clang:
template<typename T>
struct foo
{
class iterator;
using bar = foo::iterator;
};
int main() {}
however MSVC 2013 gives the following errors:
foo.cpp(9): error C2061: syntax error : identifier 'iterator'
foo.cpp(10) : see reference to class template instantiation 'foo<T>' being compiled
foo.cpp(9): error C2238: unexpected token(s) preceding ';'
If I change that line to:
using bar = typename foo::iterator;
then all three compilers compile it successfully. Is the original version correct? (i.e. is this a MSVC bug, or a gcc/clang extension)
[temp.res]/p3:
When a qualified-id is intended to refer to a type that is not a
member of the current instantiation (14.6.2.1) and its
nested-name-specifier refers to a dependent type, it shall be prefixed by the keyword typename, forming a typename-specifier.
[temp.dep.type]/p1:
A name refers to the current instantiation if it is
in the definition of a class template, a nested class of a class template, a member of a class template, or a member of a nested class
of a class template, the injected-class-name (Clause 9) of the class
template or nested class,
[...]
[temp.dep.type]/p4:
A name is a member of the current instantiation if it is
An unqualified name that, when looked up, refers to at least one member of a class that is the current instantiation or a non-dependent
base class thereof. [ Note: This can only occur when looking up a
name in a scope enclosed by the definition of a class template. —end
note ]
A qualified-id in which the nested-name-specifier refers to the current instantiation and that, when looked up, refers to at least one
member of a class that is the current instantiation or a non-dependent
base class thereof. [ Note: if no such member is found, and the
current instantiation has any dependent base classes, then the
qualified-id is a member of an unknown specialization; see below.
—end note ]
[...]
foo is the current instantiation. foo::iterator is a qualified-id in which the nested-name-specifier (foo::) refers to the current instantiation, and when looked up, "refers to at least one member of a class that is the current instantiation or a non-dependent base class thereof"; it therefore is a member of the current instantiation. Therefore, [temp.res]/p3 does not apply, and no typename is required. You are still allowed to add one - or just use iterator unqualified directly.
From the standard:
14.6.2.1 Dependent types [temp.dep.type]
1 A name refers to the current instantiation if it is
__ in the definition of a class template, a nested class of a class template, a member of a class template, or a member of a nested class of a class template, the injected-class-name (Clause 9) of the class template
or nested class,
The name foo refers to the current instantiation, that is obvious.
Since iterator is declared as a nested class in the definition of the template, iterator refers to the name in the current instantiation of foo. foo::iterator is the same as iterator.
using bar = foo::iterator;
as well as
using bar = iterator;
should work.
It seems to me that you have run into a MSVC defect.

std::is_same for a not yet defined/declared class

Is thw following code, a gcc bug?
Checking if T type is a not defined yet class Circle, returns false.
#include <iostream>
using namespace std;
// uncomment to work
//struct Circle;
struct T_traits
{
template<typename T>
constexpr static id() { return is_same<T, class Circle>(); }
};
struct Circle{};
int main()
{
cout << T_traits::id<Circle>() << "\r\n";
return 0;
}
return is_same<T, class Circle>();
This will actually declare a local class called Circle when you comment out the global declaration. [basic.lookup.elab]/2:
If the elaborated-type-specifier has no nested-name-specifier, and
unless the elaborated-type-specifier appears in a declaration with
the following form: class-key
attribute-specifier-seqopt identifier ; the
identifier is looked up according to 3.4.1 but ignoring any non-type
names that have been declared.[..]
If the elaborated-type-specifier is introduced by the class-key
and this lookup does not find a previously declared type-name
[..] the elaborated-type-specifier is a declaration that
introduces the class-name as described in 3.3.2.
The lookup is simple unqualified name lookup as defined in §3.4.1. Lookup is done in the definition context of T_traits as we are not dealing with dependent stuff, so the declaration of Circle right before main is never considered.
§3.3.2/7 (alias [basic.scope.pdecl]/7):
The point of declaration of a class first declared in an
elaborated-type-specifier is as follows:
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 namespace or block scope that contains the
declaration. [ Note: These rules also apply within templates. — end
note ]
However, removing the class keyword won't work either - as mentioned before, the identifier isn't dependent and thus looked up in the definition context. If no declaration is found by this lookup, a diagnostic must be issued by the compiler - even if no specialization is instantiated.

clang++ - treat template class name as template in the class scope

It seems that clang++ (I tried clang 3.2) treats the name of a template class as a instantiated class, not a template for any occurence within the class scope. For example, the following codes
template <template <class> class T>
class A {};
template <typename T>
class B {
A<B> member;
// ^---- clang++ treats B as an instantiated class
// but I want it to be a template here
// this code could compile in g++
};
int main()
{
B<int> b;
return 0;
}
What should I do to compile that?
C++03
Resolving B that way (called the injected-class-name, an implicitly-declared member of every class including template instantiations) is intended as a convenience. I've never seen it get in the way like that!
To work around, qualify the name by adding :: before it (and if necessary, the name of the namespace).
template <typename T>
class B {
A< ::B> member; // whitespace required to prevent digraph; see comments
};
C++11
C++11 §14.6.1/1 specifies (emphasis mine)
Like normal (non-template) classes, class templates have an injected-class-name (Clause 9). The injected- class-name can be used as a template-name or a type-name. When it is used with a template-argument-list, as a template-argument for a template template-parameter, or as the final identifier in the elaborated-type- specifier of a friend class template declaration, it refers to the class template itself. Otherwise, it is equivalent to the template-name followed by the template-parameters of the class template enclosed in <>.
Therefore, if this problem occurs under C++11 it is a compiler bug. Workaround as above.
Note — for comparison, the corresponding paragraph in C++03 is
Like normal (non-template) classes, class templates have an injected-class-name (clause 9). The injected- class-name can be used with or without a template-argument-list. When it is used without a template- argument-list, it is equivalent to the injected-class-name followed by the template-parameters of the class template enclosed in <>. When it is used with a template-argument-list, it refers to the specified class template specialization, which could be the current specialization or another specialization.
As you can see, there's already one special case allowing the identifier to be a class or template, depending on whether it occurs in a template-name. They just added a couple more cases.
This is nonconformant behavior as of C++11 because C++11 says that the injected class name (which is a name automatically declared within the class body) is a template when it is passed to a template template parameter. So your code should only fail in a C++03 implementation.
However there is no need to open a bug report about this now. I have already done it way back.

Disambiguator template keyword for a template member of a template: when exactly?

A question regarding template disambiguator was given here:
template disambiguator
and in the answer we can read:
ISO C++03 14.2/4
When the name of a member template specialization appears after . or -> in a postfix-expression, or after nested-name-specifier in a qualified-id, and the postfix-expression or qualified-id explicitly depends on a template-parameter (14.6.2), the member template name must be prefixed by the keyword template. Otherwise the name is assumed to name a non-template.
Now here comes my conrete example that I don't quite understand:
template <class T>
class Base {
public:
template <int v>
static int baseGet() {return v;}
class InnerA {
public:
template <int v>
static int aget() {return v;}
};
class InnerB {
public:
typedef Base BaseType;
typedef BaseType::InnerA OtherType;
template <int v>
static int baseGet() {return BaseType::baseGet<v>();} //(A)
template <int v>
static int aget() {return OtherType::aget<v>();} //(B)
};
};
It obviously fails to compile. You need template in the line (B): OtherType::template aget<v>();.
However, both g++ (4.4.3) and clang++ (2.9) don't complain about the lack of template in the line (A). Why? BaseType depends on the type T, does it not? Is it a small depart from the standard by those compilers, or do I misunderstand something in the standard?
They implement the C++0x specification, where Base is the current instantiation. And C++0x allows to omit template keyword in such a case. Since BaseType is a typedef for Base, when you say BaseType, that names the current instantiation too.
To quote the spec, since you seem to be interested in spec refs
A name is a member of the current instantiation if it is [...]
A qualified-id in which the nested-name-specifier refers to the current instantiation and that, when looked up, refers to at least one member of the current instantiation or a non-dependent base class thereof.
and
A name refers to the current instantiation if it is [...]
in the definition of a [...] nested class of a class template, [...], the injected-class-name (Clause 9) of the class template or nested class
and (the modified 14.2/4 that you quoted)
[...] or the nested-name-specifier in the qualified-id refers to a dependent type, but the name is not a member of the current instantiation (14.6.2.1), the member template name must be prefixed by the keyword template. [...]
Note: In C++03 your code is ill-formed because both BaseType and OtherType are dependent. The spec says:
A type is dependent if it is [...]
a template parameter
a qualified-id with a nested-name-specifier which contains a class-name that names a dependent type
a template-id in which either the template name is a template parameter or any of the template arguments is a dependent type
(note that Base is equivalent to Base<T>, which is the base on which Base and BaseType::InnerA are dependent types).
Note that "explicitly depends" in your quote is a pre-standard term, and was gotten rid of fairly lately (I believe it was at December1996). It basically meant (in this context) a qualified-id in which the qualifier is dependent or a class member access (a->x / a.x) where the a was dependent. After "explicitly depends" was removed from the draft, it was still lurking around at some places, and even C++0x has still references to "explicitly depends" in a note at 14.6.2p2:
the base class name B<T>, the type name T::A, the names B<T>::i and pb->j explicitly depend on the template-parameter.
Because OtherType is a nested dependent name while BaseType is not a nested type to begin with.
You need to use template for nested dependent types.
The keywords here are:
Dependent Type
Nested Type
If a type is both, then you've to use template.
OtherType is both dependent type (it depends on T) as well as nested type
BaseType is only dependent type (it depends on T). Its not a nested type.
BaseType does depend on the type T- but so does InnerB. In effect, from the perspective of any code inside BaseType<T>, it does not depend on T.