Pre-Proposal: Switch Case Blocks

[jcdickinson]

One of my major pet peeves with C# is the switch case hold-over from C. Just to make my argument in full, in C cases are allowed to fall-through:

switch (foo)
{
   case 1:
     someWork();
   case 2:
     someMoreWork();
     break;
}

This is not valid in C#: each switch block must conclude with some form of branch (goto, return, break). The entire purpose of case: break; of C is not carried over, but the limitations are. For example the following needs to be used.

var running = true;
while (running)
{
  switch (someEnum)
  {
    case SomeEnum.Break:
      running = false;
      break; // Useless
  }
}

Even worse, variable declarations are scoped according to the switch. In, what is probably, 99% of scenarios this is actually undesirable/annoying behavior (because it's only useful with goto case, and goto is generally discouraged/unused).

In addition, the new val switch {} syntax requires a strict expression for every case (disallowing return, or a block), so it does have some limitations compared to switch (val) {}.

Proposed Changes

The following syntax is currently invalid C# in all possible contexts:

switch (foo)
{
    case "Foo" =>
    {
    }
    case "Bar", "Baz" =>
    {
    }
    case "Zaz" => DoSomething()
}

Updated missing : to explicit =>

This is an "escape hatch" to new syntax and behavior:

• Each case is a normal block, and behaves like the rest of the language.
  • This includes a proper variable scope.
• break does not apply to the switch, instead applying to the containing loop/whatever.
• Multiple matching cases can still be used.
• The lambda syntax can be used.

I'm also wondering if disallowing mixing is a good idea (i.e. you can't use case : and case {} in the same switch), but I'm not convinced either way.

Any thoughts?

[CyrusNajmabadi]

and goto is generally discouraged/unused).

This is not true. goto case is entirely expected and the recommended and supported way to explicitly state that fall through was intended and not accidental.

[jcdickinson]

The irony here is that I am replying to someone who more frequently encounters valid use-cases for fallthrough and goto (a parser maintainer), but there seems to be a lot of sacrificed language ergonomics for what is probably less than 1% of C# switch usage. Fall-through could also be achieved (albeit, with different variable scoping), and the old syntax would still work.

switch (foo)
{
    case "Foo" // NB: missing :
    {
       goto case "Bar";
    }
    case "Bar", "Baz" // NB: , instead of :
    {
    }
    case "Zaz" => DoSomething() // NB: => instead of :
}

Requiring an explicit break; at the end of every case seems a lot like requiring an explicit return; at the end of every method.

[CyrusNajmabadi]

NB: missing :

This feels extremely subtle. I think it would not at all be obvious looking at a switch statement what was going on.

[jcdickinson]

That could lead to confusion, agreed. Another option would be to always require the lambda syntax:

switch (foo)
{
    case "Foo" =>
    {
       goto case "Bar";
    }
    case "Bar", "Baz" =>
    {
    }
    case "Zaz" => DoSomething()
}

[CyrusNajmabadi]

So this just looks like switch expressions (already there) with expression blocks (see #3086) :) I think going that route would be more appropriate (esp. as it allows us to drop the 'case' entirely.

[jcdickinson]

Awesome, I'll contribute to that issue. Thanks!

[CyrusNajmabadi]

This is not valid in C#:

Right. And that's very intentional. Looking at the c code, I can't tell if it intentionally falls through, or is a mistake. C# forces you to be explicit to prevent that confusion.

[jcdickinson]

My proposal hinges on very few people using fallthrough, I'm not proposing that it becomes implicit, I'm proposing that the notion of it goes away.

[CyrusNajmabadi]

I'm proposing that the notion of it goes away.

What would be highly problematic for basic stuff like:

switch (foo)
{
    case A:
    case B:
        // so stuff for A and B
        break;
    case C:
        // so stuff for C
        break;
}

We have always supported implicit fallthrough for obvious cases.

[jcdickinson]

Functionally speaking, case A: case B: is simply a single case that matches multiple values, but with extra ceremony.

[CyrusNajmabadi]

Ok. But... it exists. We cannot change the meaning of it. It's a well known, supported, 20 year old pattern that is in use. Fallthrough is normal and we would nto want to get rid of it.

[CyrusNajmabadi]

This is not valid in C#:

As your proposed solution demonstrates, this is resolvable in the language in the same way today. Just wrap your case sections in. {} to give them their own scope. The ide even has formatting options so that the indentation of the case code stays the same.

[jcdickinson]

That does solve the variable scoping, but the break; problem remains: the keyword is overloaded between switch and loops.

[CyrusNajmabadi]

i'm not sure how it's really overloaded. It breaks you out of the construct taking you to the following statement after the container.

[jcdickinson]

But then if { break; } would break out of the if statement? Cases are an inconsistent part of the language, and I've had to work around the consequences more than once (and have seen code that does also). I have very rarely seen fallthrough, or even other goto case patterns, used in C#.

It's a paper cut for the vast majority of use cases, and favors an extremely narrow line of work.

[CyrusNajmabadi]

But then if { break; } would break out of the if statement?

No. 'break' breaks out of the containing loop or switch.

and I've had to work around the consequences more than once

I'm not certain what you're referring to here. The 'workarounds' appear to be very similar to what you are proposing. For example, adding {} blocks to existing cases just makes the syntax nearly equivalent to what you are proposing here anyways. So i'm not sure why need a lang feature for that when teh language already allows for this :)

I have very rarely seen fallthrough

I think you may be biased by your own experiences here. I've seen tons of code with fallthrough.

[jcdickinson]

@CyrusNajmabadi thanks for the feedback.

[CyrusNajmabadi]

Sure :)

[timcassell]

• This includes a proper variable scope.

As @CyrusNajmabadi already mentioned, this is solved with {}.

• break does not apply to the switch, instead applying to the containing loop/whatever.

This is solvable the same way you break out of nested loops:

for (int i = 0; i < 10; ++i)
{
    switch (i)
    {
        case 4:
            // Do something
            break;
        case 7:
            goto BreakLoop;
    }
}
BreakLoop:
// more code

• Multiple matching cases can still be used.

Also already mentioned as possible today by @CyrusNajmabadi.

• The lambda syntax can be used.

This is too confusing with switch expression syntax. Am I looking at a switch expression or a switch statement?