Why are switch expressions restricted to matching on constants?

[The-Futurist]

Just curious about the reasoning here for this.

var result = operation switch
{
    1 => "Case 1",
    2 => "Case 2",
    3 => "Case 3",
    4 => "Case 4",
    _ => "No case availabe"
};

is equivalent to

if (operation == 1)
   return "Case 1";
else if (operation == 2)
   return "Case 2";
else if (operation == 3)
   return "Case 3";
else if (operation == 4)
   return "Case 4";
else
   return "No case available";

The if has no such restriction, any one of the numeric literals above could be replaced by an identifier or function call or expression, so is the reasoning about avoiding complex behavior? subtle bugs?

[CyrusNajmabadi]

Constants are side-effect-free. So the compiler is free to compile the switch however it wants. If there are side effects, then it's not at all clear what the semantics would be for what does or does not get executed.

[HaloFour]

The same applies to pattern matching today. Right now the only values you can compare in patterns are constants. This enables the compiler to be loose with how it evaluates each condition, reordering or reusing comparisons for the sake of improving performance.

You'd definitely find others who find that this behavior is limiting and should be reconsidered, that it's worth it to potentially sacrifice efficiency in those cases for the sake of flexibility and expressiveness.

[The-Futurist]

Yes, optimizing in the cases of constants being used makes total sense. But that could be done as needed. If the code did use constants then do as we do now, but one could still allow expressions without impacting the behavior when constants alone are used.

I'm just curious as to the reasoning though, not suggesting it change, the implications are significant, side effects are an ever present worry/hindrance.

[CyrusNajmabadi]

Why could the semantics not be exactly the same as that equivalent if statement though?

The argument isn't "why could ... not". As with practically everything in the language, all things are possible. The question though would be "why?" and if the benefits outweigh the drawbacks. As an example, say you start with:

switch (...)
{
    case Constant1:
    ...
    case ConstantN:
}

This will be emitted efficiently today. And it will be, no matter how you add items to it today.

If, however, we allow arbitrary expressions, then the user risks editing the above to be:

switch (...)
{
    case Constant1:
    ...
    case NonConstantX:
    ...
    case ConstantN:
}

Today, that would be an error. But if we allow fallback to linear processing, then your efficient 'if' now becomes inefficient to have linear semantics. We would have to weigh the benefits of allowing this, versus the potential drawbacks of users now accidentally hitting this.

[CyrusNajmabadi]

I'm just curious as to the reasoning though,

Effectively, we made a judgement call on the pros/cons for something like this if/when someone brings a proposal to change the semantics. The pros would be allowing more expressiveness. The cons would be less clarity about the semantics of code when someone looks at it, with the very real possibility that a minor change may have a highly detrimental perf impact.

There is no 'right' answer to this question. Just a judgement call on where the language would prefer to align.

[The-Futurist]

Thanks, much appreciated.

[The-Futurist]

OK thanks, much appreciated.