On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
Plus, I don't like the fact that when you see something like
"MyIterator!forward" by itself in code, there is no obvious
clue that forward is an enum value and not a class name or a
variable. So there is a sort of decrease in clarity of the
entire language by increasing the total number of possible
meanings that an identifier can have.
But, if you use the explicit "MyIterator!(MyDirection.forward)"
in your code, I don't think that's any more clear about what
"forward" actually is. It could be anything:
struct MyDirection
{
struct forward {}
// ... or:
static @property int forward() { return 42; }
// ... or:
static enum forward = 1.5;
}
Only extra clue that get with the the explicit form
(EnumType.enumerationName) is the name of the enum type. If it
makes the code clearer, then use explicit form. But more often
than not, the combination of the enumeration name and the context
where it is used makes the intention clear enough.
On 9/29/12, David Piepgrass <qwertie...@gmail.com> wrote:
It could also cause subtle problems because enum values are
implicitly
convertible to the enum's base type. Take this for example:
void test(bool state) { }
enum Foo { no, yes }
class Class
{
enum Bar { yes, no }
void test() { .test(no); } // pass Foo.no (true) or Bar.no
(false) ?
}
But that's not what I'm suggesting. The feature suggested is:
"Try to perform implicit scoping (as a last resort), if a named
enum variable is expected". Your function "void test(bool state)"
doesn't *expect* a named enum as an argument. If it did expect,
say Foo, as an argument, then Foo.no would be passed.
