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

[Tommi]

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 <qwertie256 at 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.