Scratch my previous post. It had a weird rule where the types of
identifiers had a say in whether or not there's ambiguity in the
name lookup. That's just silly. It should always be an ambiguity
error if the names are identical.
This new rule is easier to conceptualize too. Basically you just
think that there are these "hot-spots" (they're red, I think) in
your code wherever named enum values are expected. Inside each
"hot-spot", the name lookup is allowed to think that all the
enumerations (the enumerated identifiers) of that particular
named enum type are in module scope. And that's it.
So, again... if we were allowed to make a breaking change, this
is how I think it should work:
// in a module scope...
enum Char { a, b, c, d, e }
Char a = Char.c; // OK
auto b = a; // OK: .b == Char.c
Char c = Char.a; // OK: .c == Char.a
Char d = a; // ERROR: 'a' could be either 'Char.a' or '.a'
// because now 'a' is in a "hot-spot", where a
// value convertible to type Char is expected,
// and thus all Char enumerations can be seen
// as if they were in module scope
int e = 42; // OK
void test(Char ch) {}
struct MyStruct
{
int a = 1; // OK: hides '.a'
void fun()
{
Char a = Char.e; // OK: hides 'MyStruct.a' and '.a'
test(a); // OK: calls 'test(Char.e)' although the test
// argument 'a' is now in a "hot-spot" where
// all the enumerations of Char (a, b, c, d, e)
// are considered to be in module scope. But
// the function local 'a' hides anything that
// might be in module scope, so the name lookup
// doesn't even bother looking at module scope.
test(e); // ERROR: 'e' could be either 'Char.e' or '.e'
// because now the name lookup has to look at
// the module scope, where we have also Char.e
// visible due to the fact that argument 'e'
// is in a "hot-spot". It doesn't matter from
// our name-lookup's point of view that test
// is not callable with an int value.
}
}
