I have a feature request: "Named enum scope inference"

[Tommi]

But, if we were allowed to make a breaking change, then this is 
how I think it should work:

// in a module scope...

enum E { foo, bar };

-------------------------------------------------------------

// These cause a compile error "foo is ambiguous":
1) E foo = E.bar;
2) E foo = E.foo;
3) enum foo = E.bar;
4) immutable foo = E.bar;
5) immutable foo = initFoo(); // if we can't CTFE initFoo()

// These are fine:
1) enum foo = E.foo;
2) immutable foo = E.foo;
3) int foo = 42; // int isn't implicitly convertible to E
4) E Foo = E.bar;

-------------------------------------------------------------

struct Convertible
{
     E _value;

     alias _value this;
}

Convertible foo; // Compile error: foo is ambiguous

-------------------------------------------------------------

struct MyStruct(T)
{
     T foo = 123; // Fine, hides E.foo inside MyStruct scope

     void fun()
     {
         T foo = 42 // Fine, hides both MyStruct.foo and
                    // E.foo inside this function scope
     }
}

Here's the logic of it:
-----------------------
An enumeration of type E should be visible (like it was a module 
scope variable) if, and only if, it occurs in one of these 
"hot-spots" where a value of type E is expected (e.g. it could be 
in a template parameter list, function argument list, or in a 
case expression of a switch).

Inside these "hot-spots" the enumeration fights over visibility 
against variables. It loses that fight against function local and 
class/struct local variables which have the same name (and 
whatever type). But it wins the battle over visibility against 
module scope variables which have the same name but are not 
implicitly convertible to type E. Against global variables which 
are of type E or are implicitly convertible to type E, the battle 
over visibility ends in a tie, and that's a compile-time 
ambiguity error.