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

Tommi tommitissari at hotmail.com
Sat Sep 29 08:10:18 PDT 2012


On Saturday, 29 September 2012 at 07:04:19 UTC, kenji hara wrote:
> After a while, you may add a global variable in module scope.
>
>   enum E { foo ,bar }
>   int foo = 10;
>   void test(E e) {}
>   void main() {
>     test(foo);  // foo is defined, and look up module scope foo.
>     // Then, now the code is broken implicitly!
>   }
>
> This is a hijacking of local scope, and it is awful.

That code doesn't compile anyway, because the global foo is an 
int. But you're right, my suggestion doesn't work. Or, there's no 
way to implement it without breaking existing code. Here's the 
reason again for completeness sake:

enum E { foo, bar };

void test(E e) {}

int intValue = -1;

void main()
{
     int intValue = 42; // Hides the global intValue.

     E foo = E.bar; // This is fine. A local variable foo hides
                    // E.foo from 'implicit global visibility'.
                    // It's effectively same as hiding a global.

     test(foo); // Calls test(E.bar)
}

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

enum E { foo, bar };

void test(E e) {}

void main()
{
     test(foo); // Calls test(E.bar)
}

E foo = E.bar; // This is very bad. A global variable foo hides
                // E.foo from being implicitly globally visible
                // (where applicaple)


On Saturday, 29 September 2012 at 07:04:19 UTC, kenji hara wrote:
>
> It seems to me the root problem is that using a raw-identifier 
> for the start of the inference.
> If there is a symbol literal, the problem may be solved.
>
>   test('bar);  // bar is a symbol, so it does not refer any 
> normal declarations

That would work. I'd be fine with this kind of wild-card enum 
literal.


More information about the Digitalmars-d mailing list