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

Tommi tommitissari at hotmail.com
Sat Sep 29 16:50:13 PDT 2012


Although it's not very obvious what is a "hot-spot" and what is 
not.

enum Char { a, b, c, d }

Char a = c; // OK: 'c' is in a "hot-spot"

Char b = c + 1; // ERROR: 'c' is undefined, because it's not in
                 // a "hot-spot" and therefore Char enumerations
                 // aren't visible. The expression c + 1 is
                 // expected to return Char but there's no reason
                 // to expect the arguments of that expression to
                 // be of type Char. (Another error would be that
                 // c + 1 doesn't even return Char, but we never
                 // get that far because the name lookup fails)

int c = 42;

void test(Char ch) {}
void test(int val) {}

void main()
{
     test(c); // OK: calls test(.c) because arg 'c' is not in a
              // "hot-spot". Function 'test' isn't expecting a
              // Char variable as an argument, it's expecting a
              // type chosen from set of types (among which Char
              // just so happens to be). But, if you remove the
              // test(int) specialization, this function call
              // fails, and the one on the next line succeeds.

     test(d); // ERROR: 'd' is undefined, because it's not in a
              // "hot-spot" for the reason specified above, and
              // therefore enumerations of Char are not brought
              // into the module scope.
}

It is quite a mess. I think I'm ready to admit that this is not a 
feature we'd like to have in this language (probably not in any 
language for that matter).



More information about the Digitalmars-d mailing list