Question

I have tried the following code both with g++ and clang++. Both cannot distinguish the type foo and the function name foo inside the body of foo. Why is this the case? Does the C++ standard mandates this? Shouldn’t the compiler at least try both?

enum foo {
    FOO = 0,
    BAR,
    BAZ
};

class Bar {
    public:

    foo foo () const
    {
        // does not compile if I write static_cast<foo>(...)
        return static_cast< ::foo>(m_bar);
    }

    int m_bar;
};

int main ()
{
    Bar bar;
    bar.m_bar = 0;
    foo foo_bar = bar.foo(); 
    return 0;
}

I can replace ::foowith enum foo, and it will compile just fine. However, if I change enum foo {...} to typedef enum _foo {...} foo, the same problem remains (http://ideone.com/d1GiO).

Answer 1

In C and in C++ (this was inherited) there are two separate identifier spaces: one for general symbols, including variables, functions… and a separate one for user defined types (enums, structs). A typedef expression creates an alias to a user defined type inside the general identifier space.

Because the identifier spaces are kept separate, the language allows you to define a function and a type of the same name even in the same context:

enum foo { no, yes };
void foo() {}

In C you were forced to qualify identifiers in the user defined types space explicitly, so in the previous example, to use the foo type you would have to do enum foo:

void foo( enum foo ) {} 

Now, a typedef creates an alias in the global identifier space, so by using a typedef you can get away without qualification:

typedef enum bar { no, yes } bar;
void foo( bar ) {}                     // uses the typedef

Moving forward in time to C++^[*], both identifier spaces are still in the language, what has changed are the lookup rules. When looking for an identifier in the global identifier space (i.e. without a preceding enum, struct or class keyword, and in a context where non-types are allowed), the compiler will start lookup from the inner most scope to the outer scope, and for each scope it will lookup first in the global identifier space, and if nothing is found there, then it will also look in the user defined types. This is what makes the enum, struct or class optional. In most cases, that is.

In your particular case, you are doing a couple of things that can make the outcome surprising. First, you have a declaration that uses the same identifier to refer to two different things. This is fine, because until the name of the function is reached, the only entity called foo is the enum:

foo         // No need for 'enum', at this point function 'foo' is not declared
foo();      // No collision, this is 'foo' in global id space, not 'enum foo'

Now, inside Bar::foo, if you use foo by itself it will start looking in the scope of the function, where it will not find anything. It will then move out to the Bar class scope, where it will see that there is a foo function and lookup will stop there. Note that whether you have the typedef or not for the enumerator does not make a difference, as lookup stops before leaving the Bar class, and thus before potentially finding either identifier at namespace level.

As you noted, if you add the enum keyword, then suddenly you change the rules. You are now looking for a user defined type, and the search will follow the same scopes, but will only look in the identifier space for user defined types. So it will go out of Bar::foo, into Bar, where there is no enum foo, so it will continue outwards until it finds the enumeration at namespace level.

If you provide namespace qualification, the same thing happens: prepending foo with :: requires lookup to start at the global namespace level. In that level, the only foo that is defined is the user defined type enum foo. Note that this is orthogonal to the adding or not the enum keyword. In the original code, you could have a function foo at namespace level, and that would cause a similar issue:

enum foo { no, yes };
void foo() {}
class Bar {
   foo foo() {                            // Error [1]
      return static_cast<::foo>(0);       // Error [2]
   }
};

In this example there are two errors. When declaring the return type, the function Bar::foo is not yet declared, but there is ::foo(), and following the rules above lookup will go outwards until the global namespace and find ::foo() before checking for enum foo. The second error, which is the basically the same, is that the qualification in the static_cast requesting the global namespace will not help here. The reason is that lookup will again find ::foo() before it finds enum foo. The correct code for this would be:

class Bar {
   enum foo foo() {
      return static_cast<enum ::foo>(0);  // :: is optional!
   }
};

In this case, the namespace qualification is again optional, but only because there is no foo user defined type that will be found by lookup. But we can make the code a bit more convoluted…

enum foo { no, yes };
void foo() {}
class Bar {
   struct foo {};
   enum ::foo foo() { 
      return static_cast<enum ::foo>(0);
   }
};

Without the :: qualification, both the Bar::foo() declaration and the static_cast would fail because there is a user defined type Bar::foo that will be hit before the enum ::foo is found. Without the enum, the code will also fail to compile, as the global function ::foo() will be considered before the enum.

Summing up, and after a long explanation: don’t. Avoid creating functions that have the same name that types, as that will most probably just cause confusion.

---

^[*] After rereading the standard, the C++ language does not define separate identifier spaces for user defined types. On the other hand, the rules in the standard are consistent with the description above. The main difference is that in C++ a typedef alias cannot be the same as any existing type other than the type it is aliasing:

struct foo {};
typedef int foo; // Error

But for most other purposes, the behavior is consistent. There are a couple of corner cases that I did not mention in the body of the answer, but that are well beyond the scope of this question.