Proposal: enum argument declaration

[ghost]

There are cases in which an enum makes sense only in the context of a particular method. For example when you need one of three values as an argument instead of a boolean.

My proposal is a way to declare an enum directly in the method signature, and having it be used only by that method, or during calls to that method:

That method can then be called like this:

It would not be possible to access it outside of the method call:

An alternative way to use it would be this one (altough this should be used rarely, since in this case it's probably better to use a normal enum):

In my opinion it should be treated as a special enum, with implicit conversion to and from Int32 (or the user-provided underlying type).
This way all references to those enum would be replaced by their numeric value before compilation.

[MattDillard]

I like the general idea; not sure about the specifics.

This reminds me somewhat of TypeScript's String Literal Types and Numeric Literal Types (see here).

Maybe a C# equivalent would leverage union types in some way, but doing a union of specific values. I can't think of a great syntax, but piggybacking on what you've got:

public void SetState(string state, string target)
    where state: "On" | "Off" | "Standby",
          target: "All" | "Random" | "Selected"
{ ... }

Gosh, that syntax looks ugly, and it's gross that it's using strings and not enums. It might fit more easily into the current ecosystem, though; not sure.

In any case, the idea of having a type constrained (by the compiler) to a specific selection of values is interesting.

[bondsbw]

I also like this idea.

Here's another syntax to consider that I'll call "anonymous enums", which are akin to anonymous types:

public void SetState(enum { On, Off, StandBy } state, enum { All, Random, Selected } target)
{
    ...
}

It could open the door to using anonymous enums outside of parameter lists, though at the moment I can't think of a compelling example.

[CyrusNajmabadi]

Note: i don't like this primarily due to it forcing you to know the enum value at the callsite point. That precludes all sorts of things (like just computing the value a line higher and passing it in).

[MattDillard]

@CyrusNajmabadi

Note: i don't like this primarily due to it forcing you to know the enum value at the callsite point.

Dang it, Cyrus! That makes too much sense.

[theunrepentantgeek]

I like this idea because it makes it even easier for people to avoid writing method signatures like this:

myGrid.ConfigureBehavior(true, true, false, false, true, false, true, true);

(Real world example, taken from my blog)

[CyrusNajmabadi]

The problem there is not knowing what the values correspond to. But there's already a way to address this: use named parameters. i.e.

myGrid.ConfigureBehavior(foo: true, bar: true, baz: false, quux: false, ztesch: true);

Now the code clearly explains what each parameter refers to. I would not define a new way of doing enums just to solve something that already has a reasonable pattern in the language for makign things self documenting.

[theunrepentantgeek]

I took a very different approach in my blog post, introducing an enum specifically to avoid the bool parameters:

myGrid.ConfigureBehavior(
    GridOptions.MultiSelect 
    | GridOptions.DrillDown
    | GridOptions.FixFirstColumn
    | GridOptions.AllowCopy
    | GridOptions.AutoSizeColumns);

Already advocating for use of enum over bool for method arguments, I like the idea of make this even easier to achieve.

That said, I also agree with your earlier point:

i don't like this primarily due to it forcing you to know the enum value at the callsite point. That precludes all sorts of things (like just computing the value a line higher and passing it in).

[DavidArno]

This proposal makes no sense to me. If we take a simplified version with just one enum:

public public void SetState(enum Target target) where Target: { All, Random, Selected }
{
    switch (target)
    {
        case Target.All:
            SetTargetAll();
            break;
        case Target.Random:
            SetTargetRandom();
            break;
        case Target.Selected:
            SetTargetSelected();
            break;
    }
}

That method can only be called either along the lines of:

if (foo)
{
    SetState(Target.All);
}
else if (bar)
{
    SetState(Target.Random);
}
else
{
    SetState(Target.Selected);
}

or

void Foo()
{
    SetState(Target.All);
}

void Bar()
{
    SetState(Target.Random);
}

void Baz()
{
    SetState(Target.Selected);
}

In other words, based on some higher up criteria, I'm selecting one of three ways of calling SetState, which then falls into a switch in order to select the appropriate method to call. In other words, the enum serves no purpose here other than to complicate the process of calling one of those three methods.

So ditch SetState, ditch the enum, ditch this proposal and just make those three methods public:

public void  SetTargetAll() => ...
public void  SetTargetRandom() => ...
public void  HandleTargetSelected() => ...

Likewise with your example. You have nine combinations and those nine combinations have to be hard-coded at the point where the method is called as it's not possible to pass State or Target in from elsewhere. So replace those nine hard-coded calls to SetState with a call to one of nine methods. This will simplify the code and remove the need for adding another complication to the language.