Make "break" in switch case clauses optional

[The-Futurist]

That's it really, make these optional, perhaps enforce consistency (if one case has a break they must all have) but just make them optional (i.e. the absence of a final break generates code identical to that generated if the break had been present).

My suggestion is based in the needless noise this adds to code.

[HaloFour]

I'd rather see a statement form of switch expressions that allow for multi-statement arms. Relitigating the explicit design choices of the switch statement seems like a non-starter. Implementing this would only lead to confusion.

[CyrusNajmabadi]

My suggestion is based in the needless noise this adds to code.

The noise is intentional to avoid errors that happen at a reasonably common pace in languages that have implicit fallthrough. I've personally had this save my butt quite a few times.

Given that this was a very intentional language decision, and changing now would likely be a large negative for people who want this behavior, i can't see this going anywhere.

[The-Futurist]

My suggestion is based in the needless noise this adds to code.

The noise is intentional to avoid errors that happen at a reasonably common pace in languages that have implicit fallthrough. I've personally had this save my butt quite a few times.

What error does this avoid? I think you didn't read what I wrote @CyrusNajmabadi.

Given that this was a very intentional language decision, and changing now would likely be a large negative for people who want this behavior, i can't see this going anywhere.

What negative could you possibly be referring to?

[CyrusNajmabadi]

What negative could you possibly be referring to?

The negative that the break is not explicit in source.

[CyrusNajmabadi]

What error does this avoid?

In traditional C-like langauges with implicit fallthrough, it's not uncommon for unintentional fallthrough to happen. As such, explicit fallthrough, and explicit breaking was chosen for C#. To make it very clear in the code what the intention was. The goal is not to keep C#'s semantics. The goal is to keep C#'s explicitness. The explicitness itself is the feature, and it was very intentionally designed and implemented that way.

Removing the explicitness, but keeping semantics, isn't seen as a positive as it just means that the code becomes more confusing for readers. It's especially confusing/misleading for users coming from the languages C# built from. They will see C#'s switches with breaks, and your new switches without breaks, and they'll likely think teh latter have implicit fallthrough, like those other languages.

This will likely lead to errors in coding because people are led astray by this strange deviance in syntax/behavior.

[The-Futurist]

@CyrusNajmabadi you don't credit developers with much intelligence. We deal with far more abstruse characteristics than this without any trouble. The break isnt good at all as it implies one can omit it, clearly you're prepared to tolerate that confusion! This is a no brainer, case doesn't support fall through period and you may add a break if you want to - there that wasn't hard was it?

[canton7]

This is a no brainer, case doesn't support fall through period and you may add a break if you want to - there that wasn't hard was it?

As a complete outsider, can I recommend that you dial the attitude back a bit? Being constructive tends to make people want to cooperate with you a bit more.

case doesn't support fall through period and you may add a break if you want to

Note that you can already omit the break and fallthrough, in one specific case:

case A:
case B:
    // Stuff
    break;

Under your proposal, that becomes ambiguous. So your rule is actually "Case doesn't support fall-through period unless the case is empty and is above another case. Break is never required unless you want to avoid this fall-through." Suddenly life got a bit more complex.

Imagine that you, as a developer coming from another C-like language, see this:

case A:
    Console.WriteLine("A");
case B:
case C:
    Console.WriteLine("C");

That's confusing, right? You would expect cases A and B to fall through into C. If you then learnt that C# doesn't support fall-through, you would then adjust your expectations and not expect B to fall through into C. You then get a nasty surprise when you realise that, actually, C# does fall through in this case. There's no way that you wouldn't come away with a nasty taste in your mouth.

I'd rather see a statement form of switch expressions that allow for multi-statement arms

Agreed. It's doing to be much easier to invest in our new switch expression syntax, rather than butcher the legacy syntax.

[HaloFour]

@Korporal

No, case does support fall-through, as is evidenced by the fact that the language allows this when there are no statements within a case arm.

[The-Futurist]

@Korporal

No, case does support fall-through, as is evidenced by the fact that the language allows this when there are no statements within a case arm.

@HaloFour - In which case someone needs to get the documentation and the diagnostic message corrected:

Only one switch section in a switch statement executes. C# doesn't allow execution to continue from one switch section to the next. Because of this, the following code generates a compiler error, CS0163: "Control cannot fall through from one case label (<case label>) to another."

[canton7]

@Korporal Read the top of this section

Each switch section contains one or more case labels (either a case or default label) followed by one or more statements.

That document doesn't explicitly call it falling through, but it is clear that you're allowed to stack case labels on top of each other, which is what @HaloFour was referring to, and what I also referred to in my comment above.

The documentation is correct that execution cannot pass from one switch section to another, but you can have multiple case labels on a switch section.

[The-Futurist]

@canton7 - Learning a new language often includes being surprised, all I'm suggesting is we make this optional, a decorative keyword (it has no functionality) to be used IF someone so chooses.

The keyword private is optional on class members - one may be explicit if they wish or they may not so the concept I'm advocating is hardly radical here.

case A:
    Console.WriteLine("A");
case B:
case C:
    Console.WriteLine("C");

Err - no, that isn't confusing to me I know exactly what it does.

[The-Futurist]

@Korporal Read a little further down

Each switch section contains one or more case labels (either a case or default label) followed by one or more statements.

That document doesn't explicitly call it falling through, but it is clear that you're allowed to stack case labels on top of each other, which is what @HaloFour was referring to, and what I also referred to in my comment above.

The documentation is correct that execution cannot pass from one switch section to another, but you can have multiple case labels on a switch section.

Why are you arguing and what are you arguing about? It doesn't matter what he may have meant, he called me out as being incorrect and I chose to rebut that.

[canton7]

Learning a new language often includes being surprised

A good aim, though, is to decrease the number of surprises which might cause bugs.

Err - no, that isn't confusing to me I know exactly what it does.

I specifically said:

Imagine that you, as a developer coming from another C-like language, see this:

I didn't ask whether you, with all of the C# knowledge that you currently have, would find this confusing. I asked you to imagine that you were a new C# developer coming from another C-like language. I'm pretty confident in saying that most people would find the complex rule of "break statements are implicit unless two case labels are stacked on top of each other, in which case there is no implicit break statement" unnecessarily confusing. It's hardly the pit of success.

We've got a brand new opportunity now, in the form of switch expressions (which, importantly, don't have break statements). It would IMO be a much better effort to get multi-statement arms on these.

[canton7]

Why are you arguing and what are you arguing about? It doesn't matter what he may have meant, he called me out as being incorrect and I chose to rebut that.

Your point was "it can never be confusing to omit break, because there are no cases in C# where fallthrough is allowed". His point was, I believe, the same as mine -- fall-through is allowed in the case of multiple case statements stacked on top of each other, and this fact makes your proposal confusing. This is fairly clear from (emphasis mine):

No, case does support fall-through, as is evidenced by the fact that the language allows this when there are no statements within a case arm.

Your message very clearly said that he was wrong, and cited the documentation as evidence. I pointed you to the bit of the document which said that, of course, he was right.

I think we all know that you can stack case statements on top of each other, so it came as a surprise when you appeared to claim that @HaloFour was wrong to state it.

[The-Futurist]

@canton7 - I will tell you that the choice to make explicit accessibility optional was a source of confusion for me very early on. Look at a simple console app - the Main method is private yet is obviously invoked externally.

When I first looked at a console app in 2003 or whenever it was I assumed default accessibility was public because I assumed Main must be public because it is invoked from outside the class.

All I'm saying here is the potential to confuse the newcomer is ever present, people learn, we're not dummies.

[The-Futurist]

Well, braces in a case aren't really part of the case -- they're just a way of introducing a new scope, the same as if you introduced them in lots of other places. This is perfectly legal:

case A:
    Console.WriteLine("First")
    {
        Console.WriteLine("Second");
    }
    Console.WriteLine("Third");
    break;

Given this, I'm afraid I'm unclear on what point you were trying to make with cases and closing braces.

But this will never change now, its too late.

Right, so why raise it? Lots of things will never change.

I raised making break optional, not making braces compulsory. The former is not a breaking change, the latter would be.

[canton7]

I don't get why you raised braces at all. This entire comment was about braces, and I still don't understand the point you were trying to make.

[The-Futurist]

@canton7 - Really? I showed you a loop and how we do not enforce that we write continue at the end, the continue is a natural defined behavior for a loop when control reaches the closing brace. My point there was that just as we can omit continue in the loop and remain explicit we can do the same for a case.

The continue would be redundant the break however is enforced (yet functionally redundant).

[canton7]

Right - you talked about the closing brace of a loop. Case statements don't have closing braces. I don't see why an argument about closing braces in loops applies to case statements which don't have braces.

Case statements are much more akin to goto labels. There are no braces with goto either, and you always "fall across" a goto label.

[HaloFour]

There also isn't consensus as to what C# should do if break could be omitted: #603

[The-Futurist]

@HaloFour - Well that's a separate thing altogether, not sure I'm a fan...let me look...

[CyrusNajmabadi]

This is a no brainer, case doesn't support fall through period and you may add a break if you want to - there that wasn't hard was it?

That would likely cause confusion. Which is something we wanted to avoid here.

[CyrusNajmabadi]

@HaloFour - In which case someone needs to get the documentation and the diagnostic message

That documentation is correct. It specifically discusses a switch section. One switch section cannot fall through to another, ever. Within a single switch section though, you could have a case label fall through to the next case label (if it has no statements).

Sections and case labels are different things

[CyrusNajmabadi]

you don't credit developers with much intelligence. We deal with far more abstruse characteristics than this without any trouble.

It's not a matter of intelligence. It's a matter of avoiding common problems, mistakes and confusion.

[HaloFour]

@CyrusNajmabadi

And that's technically correct (the best kind of correct), but that may not be how developers intuit the behavior of the feature. Either way, I prefer that the explicitness that the compiler forces prevents said misinterpretation from resulting in bugs.

[CyrusNajmabadi]

Either way, I prefer that the explicitness that the compiler forces prevents said misinterpretation from resulting in bugs.

Me too! :-D

[theunrepentantgeek]

@Korporal, you wrote

@CyrusNajmabadi you don't credit developers with much intelligence.

Most developers are quite intelligent.

They're also some combination of one or more of overly stressed, recently distracted, ravenously hungry, deadline pressured, under caffeinated, confused by the test results, toddler tired, regrettably hungover, time conscious, new to the language, recently promoted, intending to quit, justifiably angry, secretly delighted, clinically depressed, and under appreciated.

Any one of which can easily result in minor syntactic details being overlooked.

The explicitness of requiring each switch section to finish with break, return or throw helps to ensure that the most common failure modes result in compilation errors, not subtle bugs.

[The-Futurist]

@theunrepentantgeek - It's interesting to see that other languages like PL/I, Pascal, COBOL, Visual Basic, Eiffel, RPG and FORTRAN never supported "fall through" in any way, the designers clearly recognized there was no value in such a capability, it was an alien concept except in C.

The C language was the first to do this and it has contaminated later derivatives even C#.

Developers using non-C languages never had any problems because the concept of "fall through" was never even an option, confusion simply did not arise.

Basing a new language on one of the weakest high level languages carries a cost and C# is paying that cost.

[theunrepentantgeek]

The C language was the first to do this and it has contaminated later derivatives even C#.
Basing a new language on one of the weakest high level languages carries a cost and C# is paying that cost.

You're just about making my point for me.

Experienced developers see "C style syntax" and expect case fall-through unless the code explicitly says otherwise. This is true whether their experience is with C itself, or with one of the big three C-derived languages (C++, Java, C#).

The contamination has already happened. It can't be undone.

[CyrusNajmabadi]

Basing a new language on one of the weakest high level languages carries a cost and C# is paying that cost.

And? This is where we are. We can't re-litigate the past. The choices have been made with full understanding of hte details you've brought up and with a clear understanding of the user base and lineage of our language.

This is not PL/1#. If you want that, you'd likely have a better chance just building it yourself. This is C# and C# is going to continue it's development in this way for the foreseeable future.

Perhaps this just isn't the right language for you? You might want to consider many of the others out there. VB, as you mentioned, behaves in the manner you like here. It has full access to the wealth of functionality on the .net platform if htat matters to you. If you'd prefer a more functional language, F# might be right up your alley as well.