new keyword for implicit switch statements

[WarrenFerrell]

There are many good reasons for requiring switch statements to inherit its C equivalent but the statement;
break; syntax is often a strong enough argument for many to forgo using switch statements altogether. Introducing syntactic sugar statement keywords like switchandbreak and switchandreturn that add the break; after your supplied statement during compilation or return the value supplied from the case statement. This would allow developers to produce cleaner code by making use of the often underappreciated switch without ambiguity.

[svick]

How do you supply a value from a case?

[MgSam]

When planning pattern matching in C# 7.0 the LDC discussed using an alternative syntax that would have been less verbose than switch. They choose familiarity over streamlining however, and added the new pattern matching abilities into switch rather than a new statement. I think that decision has pretty much closed the door to replacing the standard switch.

They're now having similar discussions around an expression form. So if you have an opinion about that that's the place to express it.

[stepanbenes]

We could simply make break in switch statement optional to make the code cleaner. I think it would not be ambiguous.

[svick]

@stepanbenes It would not be ambiguous, true. But it would be incredibly confusing to anyone who knows another C-descended language, including C++ and Java.

[jnm2]

See dotnet/roslyn#959.

[DavidArno]

@stepanbenes,

Yes, the language team could make break optional. The day they do, I'd buy and crack open a very expensive bottle of bubbly to toast the death of that syntactic salt that hangs around the neck of switch. Sadly though, my money's likely very safe for there seems no appetite to fix it any time soon.

Whilst the switch/match expression support that we might get as part of the next pattern matching feature set would address some use cases for avoiding break, it won't fix break statements. But it'll be a step in the right direction.

[stepanbenes]

@DavidArno You seem to like the idea. :) However, @svick is right that it would bring confusion (not for me, I hate the fall-through behavior in C++ and never use it). Another reason to use match keyword for expression form of switch statement as some would expect the same fall-through semantics if they see switch...

[yaakov-h]

I wouldn't mind making break optional if there was no implicit fallthrough at all, i.e. if a case body could not be empty. But it can be, and that adds to the confusion @svick mentioned.

[DavidArno]

Sometimes I agree with @svick; sometimes I strongly disagree with him. This is one of those latter cases. "It'll confuse the little bunnies used to how C++ and Java work" is, in my view, the single worst excuse for not fixing a bad feature, ever.

[jnm2]

^ Rude.

[DavidArno]

Only a little bit 😉

[alrz]

Swift has a C-based syntax with a lot of changes like optional parens around if, for, switch expressions plus making fallthrough explicit instead of break. to be honest, I was a little lost once I looked at the syntax and couldn't figure out what's happening for the entire week.

[YairHalberstadt]

I think switch expressions cover this, especially with the proposal to allow a statement form of the switch expression: #3038