Summary: Inplace enum literals
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD

--- Comment #0 from 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:

var opacitySlider = new Slider(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:
------- You are receiving this mail because: -------

Reply via email to