Proposal: Implicit Enums

[alrz]

With inline enumerations (#3497) one can define an enum within parameter declaration,

void F(enum {Yes, No} option) { ... }

and with #952 you can simply call it,

F(Yes);

But the question is, how are you going to use it? Perhaps with a switch statement or expression,

void F(enum {Yes, No} option) { 
  switch(option) {
    case Yes: ... break;
    case No: ... break;
  }
} 

As you can see, you have to repeat all the enum members in switch cases and in parameter type itself which might get long and turn into an ugly parameter list. To address this, I want to propose implicit enums in method parameters which can infer members from the switch statement,

void F(enum option) {
  switch(option) {
    case Yes: ... break;
    case No: ... break;
  }
} 

With enum records (#6739) you can use pattern matching to destruct the input,

void F(enum option) {
  switch(option) {
    case Foo(int x): ... break;
    case Bar(string x): ... break;
  }
}

In this case an enum class would be generated by the compiler,

enum class _CompilerGeneratedName_ {
  Foo(int),
  Bar(string)
}

F(Foo(42));

DRY.

[HaloFour]

Public contract should never be inferred from usage. It would be too difficult to discern and too easy to break accidentally.

[alrz]

@HaloFour So if you actually declare it like

void F(Options options) { 
  enum Options { Yes, No } // ideally, nested
  switch(options) { ... }
 }

did you change anything?

[HaloFour]

@alrz I'm not aware of any other place in C# where something declared within a method would leak out of that method as part of a public contract. C# has no concept of local types, but if it did why should it differ from, say, local classes in Java, where they can't be referenced outside of their declaring method, and you cannot define parameters of that method of that class?

I don't see what having the declaration nested gets you. The enum (or any other type) would have to be moved to the parent type and given an official name. What if two methods in the same type define enums of the same name, but different values? If the name of the enum is mangled in a manner to guard against that being an issue that could result in consumers being broken if the method name changes, even consumers that never invoke that method.