cpp/language/dependent name

Inside the definition of a (both  and ), the meaning of some constructs may differ from one instantiation to another. In particular, types and expressions may depend on types of type template parameters and values of non-type template parameters.

Name lookup and binding are different for dependent names and non-dependent names.

Binding rules
Non-dependent names are looked up and bound at the point of template definition. This binding holds even if at the point of template instantiation there is a better match:

If the meaning of a non-dependent name changes between the definition context and the point of instantiation of a specialization of the template, the program is ill-formed, no diagnostic required. This is possible in the following situations:
 * a type used in a non-dependent name is at the point of definition but complete at the point of instantiation


 * an instantiation uses a default argument or default template argument that had not been defined at the point of definition
 * a at the point of instantiation uses the value of a const object of integral or unscoped enum type, and that object was not defined at the point of definition
 * the template uses a non-dependent class template specialization at the point of instantiation, and this template it uses is either instantiated from a partial specialization that was not defined at the point of definition or names an explicit specialization that was not declared at the point of definition

Binding of dependent names is postponed until lookup takes place.

Lookup rules
As discussed in, the lookup of a dependent name used in a template is postponed until the template arguments are known, at which time (in other words, adding a new function declaration after template definition does not make it visible, except via ADL).
 * non-ADL lookup examines function declarations with external linkage that are visible from the template definition context
 * examines function declarations with external linkage that are visible from either the template definition context or the template instantiation context

The purpose of this rule is to help guard against violations of the for template instantiations:

In the above example, if non-ADL lookup for were allowed from the instantiation context, the instantiation of  would have two different definitions: one using  and one using. Such ODR violation may not be detected by the linker, leading to one or the other being used in both instances.

To make ADL examine a user-defined namespace, either should be replaced by a user-defined class or its element type should be a user-defined class:

Note: this rule makes it impractical to overload operators for standard library types:

Note: limited lookup (but not binding) of dependent names also takes place at template definition time, as needed to distinguish them from non-dependent names and also to determine whether they are members of the current instantiation or members of unknown specialization. The information obtained by this lookup can be used to detect errors, see below.

Dependent types
The following types are dependent types:
 * template parameter
 * a member of an unknown specialization (see below)
 * a nested class/enum that is a dependent member of unknown specialization (see below)
 * a cv-qualified version of a dependent type
 * a compound type constructed from a dependent type
 * an array type whose element type is dependent or whose bound (if any) is value-dependent


 * a function type whose exception specification is value-dependent
 * a where either
 * the template name is a template parameter, or
 * any of template arguments is type-dependent, or value-dependent (even if the template-id is used without its argument list, as )

Note: a typedef member of a current instantiation is only dependent when the type it refers to is.

Type-dependent expressions
The following expressions are type-dependent:
 * an expression whose any subexpression is a type-dependent expression
 * , if the class is a dependent type.
 * an that
 * contains an identifier for which name lookup finds at least one dependent declaration
 * contains a dependent


 * contains the name of to a dependent type
 * contains a nested name specifier or that is a member of unknown specialization
 * names a dependent member of the current instantiation which is a static data member of type "array of unknown bound"


 * any cast expression to a dependent type
 * that creates an object of a dependent type
 * member access expression that refers to a member of the current instantiation whose type is dependent
 * member access expression that refers to a member of unknown specialization

Note: literals, pseudo-destructor calls,, , , and -expressions are never type-dependent because the types of these expressions cannot be.

Value-dependent expressions

 * an expression used in context where is required, and whose any subexpression is value-dependent
 * an that


 * is type-dependent
 * is a name of a non-type template parameter
 * names a static data member that is a dependent member of the current instantiation and is not initialized.
 * names a static member function that is a dependent member of the current instantiation
 * is a constant with a type, initialized from a value-dependent expression


 * , -expressions where the argument is a type-dependent expression or a dependent type-id
 * any cast expression to a dependent type or from a value-dependent expression
 * address-of expression where the argument is that names a dependent member of the current instantiation
 * address-of expression where the argument is any expression which, evaluated as a core, refers to a that is an object with static  duration or a member function.

Current instantiation
Within a class template definition (including its member functions and nested classes) some names may be deduced to refer to the current instantiation. This allows certain errors to be detected at the point of definition, rather than instantiation, and removes the requirement on the and  disambiguators for dependent names, see below.

Only the following names can refer to the current instantiation:
 * in a class template definition:
 * a nested class, a member of class template, a member of a nested class, the injected-class-name of the template, the injected-class-name of a nested class.


 * in a primary class template definition or in the definition of its member:
 * name of the class template followed by template argument list (or an equivalent alias template specialization) for the primary template where each argument is equivalent (defined below) to its corresponding parameter.


 * in the definition of a nested class or class template:
 * name of the nested class used as a member of the current instantiation.


 * in the definition of a partial specialization or of a member of a partial specialization:
 * the name of the class template followed by template argument list for the partial specialization, where each argument is equivalent to its corresponding parameter.

A template argument is equivalent to a template parameter if
 * for a, the template argument denotes the same type as the template parameter.
 * for a, the template argument is an that names a variable that is equivalent to the template parameter. A variable is equivalent to a template parameter if
 * it has the same type as the template parameter (ignoring cv-qualification) and
 * its initializer consists of a single identifier that names the template parameter or, recursively, such a variable.

Note that a base class can be the current instantiation if a nested class derives from its enclosing class template. Base classes that are dependent types but aren't the current instantiation are dependent base classes:

A name is classified as a member of the current instantiation if it is
 * an unqualified name that is found by in the current instantiation or in its non-dependent base.
 * , if the qualifier (the name to the left of ) names the current instantiation and lookup finds the name in the current instantiation or in its non-dependent base
 * a name used in a class member access expression ( in or ), where the object expression ( or ) is the current instantiation and lookup finds the name in the current instantiation or in its non-dependent base

Members of the current instantiation may be both dependent and non-dependent.

If the lookup of a member of current instantiation gives a different result between the point of instantiation and the point of definition, the lookup is ambiguous. Note however that when a member name is used, it is not automatically converted to a class member access expression, only explicit member access expressions indicate members of current instantiation:

Unknown specializations
Within a template definition, certain names are deduced to belong to an unknown specialization, in particular,


 * a, if any name that appears to the left of is a dependent type that is not a member of the current instantiation
 * a, whose qualifier is the current instantiation, and the name is not found in the current instantiation or any of its non-dependent base classes, and there is a dependent base class
 * a name of a member in a class member access expression (the in  or ), if the type of the object expression ( or ) is a dependent type and is not the current instantiation
 * a name of a member in a class member access expression (the in  or ), if the type of the object expression  ( or ) is the current instantiation, and the name is not found in the current instantiation or any of its non-dependent base classes, and there is a dependent base class

This classification allows the following errors to be detected at the point of template definition (rather than instantiation):


 * If any template definition has a in which the qualifier refers to the current instantiation and the name is neither a member of current instantiation nor a member of unknown specialization, the program is ill-formed (no diagnostic required) even if the template is never instantiated.


 * If any template definition has a member access expression where the object expression is the current instantiation, but the name is neither a member of current instantiation nor a member of unknown specialization, the program is ill-formed even if the template is never instantiated.

Members of unknown specialization are always dependent, and are looked up and bound at the point of instantiation as all dependent names (see above)

The disambiguator for dependent names
In a declaration or a definition of a template, including alias template, a name that is not a member of the current instantiation and is dependent on a template parameter is not considered to be a type unless the keyword is used or unless it was already established as a type name, e.g. with a typedef declaration or by being used to name a base class.

The keyword may only be used in this way before qualified names (e.g. ), but the names need not be dependent.

Usual is used for the identifier prefixed by. Unlike the case with, the lookup rules do not change despite the qualifier:

The keyword can be used even outside of templates.

The disambiguator for dependent names
Similarly, in a template definition, a dependent name that is not a member of the current instantiation is not considered to be a template name unless the disambiguation keyword is used or unless it was already established as a template name:

The keyword may only be used in this way after operators  (scope resolution),  (member access through pointer), and  (member access), the following are all valid examples:



As is the case with, the prefix is allowed even if the name is not dependent or the use does not appear in the scope of a template.

Even if the name to the left of refers to a namespace, the template disambiguator is allowed: