On 29/09/2012 04:11, Andrej Mitrovic wrote:
On 9/29/12, David Piepgrass <qwertie...@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 :)
