Bug 6557 – Inplace enum literals

This is a low-priority additive enhancement request, maybe for D3. This is a commonly asked enhancement. I add it here because it's good to have this entry as a reference place for present and future discussions about this idea, and because I think I have found a way to solve one downside usual found in this idea. Note: this enhancement request does _not_ replace the usefulness of named arguments, it's more like a complement of them. Nude boolean arguments are often ambiguous for the people that read the code. Some examples of lines from real code of real frameworks in other languages: widget.repaint(false); var opacitySlider = new Slider(true); stackView.updateHeight(false); widget.next(true); The idea to avoid such ambiguity is to use one enum. But it's more handy to define the enum in-place in the function/method signature: void foo(enum {a, b} arg) { if (arg == b) {} if (arg == foo.a) {} // alternative syntax } void main() { foo(a); // OK, allowed foo(foo.a); // alternative syntax auto input = foo.b; // OK foo(input); // OK alias typeof(foo.a) E; // OK } The simple syntax functionName.enumEntry solves the problem of referencing enum entries from outside the function. Some special cases. This is acceptable, they are two overloads of foo() (this needs strongly typed enums, see issue 3999 ): void foo(int arg) {} void foo(enum {a, b} arg) {} If enums are not strongly typed then I presume that overload needs to be statically refused. This is not acceptetable, it's compile-time error: void bar(enum {a, b} arg) {} void bar(enum {a, c, d} arg) {}

> void foo(enum {a, b} arg) { > if (arg == b) {} > if (arg == foo.a) {} // alternative syntax > } I have one question. In following case, what does foo receive as arg? void main() { typeof(foo.a) E; E a = foo.b; foo(a); // == foo(foo.a) or foo(foo.b) ? } I think the enum scope inference from their member name is nearly impossible, because D has template function. The feature requires a function signature to determine the argument types, but template function call requires argument types to determine the function signature!

(In reply to comment #1) > In following case, what does foo receive as arg? > > void main() > { > typeof(foo.a) E; > E a = foo.b; > foo(a); // == foo(foo.a) or foo(foo.b) ? > } Thank you for finding this problem. I think that's a quite uncommon case, it's a bug of the programmer. So this bad corner case is not enough to kill the whole idea. In this case of actual ambiguity I think D has to act like in this case: struct Foo { int x; } void main() { int x; Foo f; with (f) x++; // line 8, error with (f) {} // no error here, no actual ambiguity } test.d(8): Error: with symbol test.Foo.x is shadowing local symbol test.main.x void foo(enum {a, b} arg) {} void main() { auto a = foo.b; foo(a); // Error: ambiguity... }

(In reply to comment #1) > I think the enum scope inference from their member name is nearly impossible, > because D has template function. > The feature requires a function signature to determine the argument types, but > template function call requires argument types to determine the function > signature! Do you mean this problem? void foo(T)(T x, enum : T { A, B }) {} void main() { typeof(foo.A) a = foo.B; foo(a); }

My thought case is following code. void foo()(int n){} // 1 void foo()(enum {a, b} arg) {} // 2 void main() { int a; foo(a); // 1 or 2 ? } To determine the signature of foo, 'a' is judged as integer typed variable, and 1st foo overload is selected. 2nd version of foo is never selected. And this is natural behavior guided from the current specification. But this enhancement is require to determine foo's signature *before* argument types. This is a serious conflict.

The basic idea is cute, but I think it currently doesn't work. So I close this enhancement request, to be reopened if better ideas come.