Visual Basic 6 did this, why can't you, C#?

[maze3]

yes, but the "new" switch expression 🤤

[Stacy Dudovitz]

Allowing fall through code was/is a huge source of bugs, and does not fall in line with best practices. During any refactoring, it's not uncommon to move/reorder code. Without close scrutiny, a break in logic flow would be so easily introduced by missing the fall through code. Worse, refactoring/reordering code might be necessary, but now fallthrough code has introduced an artificial constraint. For case statements with few case points, this requirement is a minor inconvenience at best. If, however, you have numerous case points, this might be indicative of a code smell. Such code is both difficult to understand and to follow. Perhaps a different approach might be more appropriate... fi ite state machines, keyword/lambda method dictionaries, etc. Something to consider when designing well crafted code that adheres to best practices.

[gggustafson]

int method ( int integer )
{

return ( 42 );

}

int method ( string trigger )
{

return ( method ( Int32.Parse ( trigger ) ) );

}

Gus Gustafson

[zezba9000]

That isn't true.

switch (value)
{
case 0:
case 1:
case 2:
// do something
break;
}

[realJSOP]

You only need braces in the case when you're creating a new variable in the case. Otherwise, they're unnecessary.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[englebart]

C was just an easier, portable assembly language. I blame the overflow buffer errors on the chip designers that encouraged storing local variables on the call stack! Call stack pointer should be read only except for jsr and ret instructions.

[Mark Starr]

:) As opposed to an undetectable infinite loop?

Time is the differentiation of eternity devised by man to measure the passage of human events. - Manly P. Hall Mark Just another cog in the wheel

[Richard Deeming]

Indeed. The compiler isn't magic, and there are constructs which are obvious infinite loops to a human which the compiler cannot detect as such. For example:

switch (x)
{
case 1:
while (x < 42);
case 2:
return 123;
}

Whilst we can clearly see that the loop is infinite, since x starts as 1 and is never modified within the loop, the compiler still complains:

Quote:

CS0163 Control cannot fall through from one case label ('case 1:') to another

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[kalberts]

In my student days, "correctness proofs" were the rage. Everyone were convinced that soon, a program would be able to prove (or disprove) that a program behaved according to specifications. The first real proof we learned in that course was not a program, but a logical proof that no program analyzer can, in the general case, detect every possible infinte loop. I did understand the proof then; I don't remember the details today, and even if I found the text, I would probably be unable to explain it to someone unfamiliar with it. But I know the proof exists (just like I know that there exists a proof that you cannot trisect an arbitrary angle); I trust the experts that the proof still holds.

[kalberts]

They are "unnecessary" only if you accept indents and undents with no supporting braces. Braces and indents are the 2-factor element of program layout. You can equally well say that 2-factor authentication is "unneccessary" when you have already supplied a password. Some of us nevertheless think 2-factor is a good idea, both in authentication and in code layout.

[Stacy Dudovitz]

Allowing fall through code was/is a huge source of bugs, and does not fall in line with best practices. During any refactoring, it's not uncommon to move/reorder code. Without close scrutiny, a break in logic flow would be so easily introduced by missing the fall through code. Worse, refactoring/reordering code might be necessary, but now fallthrough code has introduced an artificial constraint. For case statements with few case points, this requirement is a minor inconvenience at best. If, however, you have numerous case points, this might be indicative of a code smell. Such code is both difficult to understand and to follow. Perhaps a different approach might be more appropriate... finite state machines, keyword/lambda method dictionaries, etc. Something to consider when designing well crafted code that adheres to best practices.

[vKaras]

well.. you could also use `return`, `throw` or `goto case 3` instead of `break`. I guess they didn't want to define a default behaviour witch needed to be remembered and thought of by of everyone, when writing a switch case.