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