Bug 16437 – Enum type inference

inference of the enum type in function calls, allowing to type only the member Enum A{a0} void foo(A a); a0.foo; // OK void bar(T)(T t); a0.bar; // ERROR void baz(A[] a); [a0].baz; //OK void cli(A a)(); cli!a0; // OK This could be accepted as long as the parameter type is not inferred since the parameter type will have to be used to find a match in the enum.

Other possible cases: SomeEnum {se1, se2} SomeEnum x = se1 | se2; // OK, there's a hint to solve se1 and se2 auto y = se1 | se2; // Error (unless se1/se2 exist as var in the scope.

So I started implementing the stuff yesterday and unfortunately the inference cannot be limited to the function call. Only simpler cases such as initializers would work with inference limited to the scope of the current declaration/ expression statement. The problem with calls is that parameters must be solved to find the function to call (because remember : overload sets...). But to infer the enum parent of an unqualified member, the function is required. This lead to a kind of paradox that's only solvable using a two steps resolution. The first step uses a list of enum that's stored in the scope to solve the parameter, the second step would verify that the solved parameter is well a child of the enum indicated in the function type, since the scope contain possibly unrelated enums, with identical member names... More concretly, the current test: https://github.com/dlang/dmd/compare/master...Basile-z:enum-parent-inference-in-calls