Why is the type of a name determined during the first phase of template evaluation, even for dependent names?

Question

As a corollary to a question I asked previously, I am curious why the type of the type of a name ('category' of that name) in a template is set in the first phase of the 2 phase lookup, when the category itself can also depend on the template parameter. What is the real gain of this behavior?

A little clarification - I think I have a fair understanding of how the 2 phase look-up works; what I'm trying to understand is why a category of a token is definitively determined in phase 1, which differs from when dependent types are determined (in phase 2). My argument is that there is a very real gain in simplifying a difficult syntax, to make code easier to write and to read, so I am curious what the compelling reason to restrict category evaluation to phase 1 is. Is it simply for better template validation/error messages before template instantiation, or a marginal increase in speed? Or is there some fundamental attribute of templates that makes phase 2 category evaluation unfeasible?

Answer 1

The question could be two fold: why do we want two phase lookup in the first place, and given that we have two phase lookup, why are the interpretation of the tokens fixed during the first phase. The first is the harder question to answer, as it is a design decision in the language and as such it has its advantages and disadvantages and depending on where you stand the ones or the others will have more weight.

The second part, which is what you are interested in, is actually much simpler. Why, in a C++ language with two phase lookup are the token meaning fixed during the first phase and cannot be left to be interpreted in the second phase. The reason is that C++ has a contextual grammar, and the interpretation of the tokens is highly dependent on the context. Without fixating the meaning of the tokens during the first phase you won't even know what names need to be looked up in the first place.

Consider a slightly modified version of your original code, where the literal 5 is substituted by a constant expression, and assuming that you did not need to provide the template or typename keywords that bit you the last time:

const int b = 5;
template<typename T>
struct Derived : public Base<T> {
    void Foo() { 
       Base<T>::Bar<false>(b);   // [1]
       std::cout << b;           // [2]
    }
};

What are the possible meanings of [1] (ignoring the fact that in C++ this is determined by adding typename and template)?

1. Bar is a static template function that takes a single bool as template argument and an integer as argument. b is a non-dependent name that refers to the constant 5. ^*

2. Bar is a nested template type that takes a single bool as template argument. b is an instance of that type defined inside the function Derived<T>::Foo and not used.

3. Bar is a static member variable of a type X for which there is a comparison operator< that takes a bool and yields as result an object of type U that can be compared with operator> with an integer.

Now the question is how do we proceed resolving the names before the template arguments are substituted in (i.e. during the first phase). If we are in case 1. or 3. then b needs to be looked up and the result can be substituted in the expression. In the first case yielding your original code: Base<T>::template Bar<false>(5), in the latter case yielding operator>( operator<( Base<T>::Bar,false ), 5 ). In the third case (2.) the code after the first phase would be exactly the same as the original code: Base<T>::Bar<false> b; (removing the extra ()).

The meaning of the second line [2] is then dependent on how we interpreted the first one [1]. In the 2. case it represents a call to operator<<( std::cout, Base<T>::Bar<false> & ), while in the other two cases it represents operator<<( std::cout, 5 ). Again the implications extend beyond what type is the second argument, as in the 2. case name b within Derived<T>::Foo is dependent, and thus it cannot be resolved during the first phase but rather postponed to the second phase (where it will also affect lookup by adding the namespaces of Base and the instantiating type T to the Argument Dependent Lookup).

As the example shows, the interpretation of the tokens impact the meaning of the names, and that in turn affects what the rest of the code means, what names are dependent or not and thus what else needs to be looked up or not during the first phase. At the same time, the compiler does perform checks during the first pass, and if the tokens could be reinterpreted during the second pass, then the checks and the results of the lookup during the first pass would be rendered useless (imagine that during the first pass b had been substituted with 5 only to find out that we are in case 2. during the second phase!), and everything would have to be checked during the second phase.

The existence of two phase lookup depends on the tokens being interpreted and it's meaning selected during the first phase. The alternative is a single pass lookup as VS does.

---

^* I am simplifying the cases here, in the Visual Studio compiler, that does not implement two-phase lookup, b could also be a member of Base<T> for the currently instantiating type T (i.e. it can be a dependent name)

Answer 2

Much of the advantages of C++ is that it's a strictly checked language. You express the intent of your program as clearly as possible, and the compiler tells you if that intent is violated.

I can't imagine that you would ever write Base<T>::Bar<false>(b); (from Dribeas's example) and not have a particular interpretation that you want. By telling the interpretation to the compiler (Base<T>::typename Bar<false>(b);), it can generate a meaningful error if someone provides a type that has a static member Bar or a nested template type instead of a member function template.

Other languages are designed to stress terseness over static analysis; for example many dynamic languages have a great number of "do what I mean" rules. Which causes fun when the compiler turns non-sensible code into something unpredictable, with no errors. (Case in point: Perl. I love it for text manipulation, but goodness DWIM is annoying. Almost everything is a runtime error, there's barely any static checking to speak of)