http://d.puremagic.com/issues/show_bug.cgi?id=6557
Summary: Inplace enum literals Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2011-08-26 04:33:05 PDT --- 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) {} -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------