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

[Ben Davis]

On 29/09/2012 04:11, Andrej Mitrovic wrote:
> On 9/29/12, David Piepgrass <qwertie256 at gmail.com> wrote:
>> I like the spirit of this feature, but as Alex pointed out,
>> ambiguity is possible (which could theoretically cause errors in
>> existing code)
>
> 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) ?
> }
>

This isn't an issue with this proposal. There is no enum type available 
to use for inference, so 'no' simply doesn't resolve there.

If you're ever working in Java using Eclipse, you'll notice that Eclipse 
has this very feature in its autocomplete engine. For example, if you write:

if (myEnumValue ==

and then press Ctrl+Space, then it'll list the enum constants. When you 
select one, it'll generate the qualified name because it has to.

The point is to use what we know about the type that is *likely* to 
occur here (by considering assignment LHS, comparison LHS, parameters to 
possibly matching methods, method return type in argument to 'return', 
etc.) to infer which enum type's members to consider (if any).

Hope that clarifies :)