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