Can someone explain why switch syntax is the way it is?

[Andrew Ducker]

And no, this isn't a complaint about break - I'm very happy to make
things explicit.

However, why isn't the format something like:

switch(myVariable)
{
case 1:
{
//Do Something
}
case 2:
{
//Do Something Else
}
default
// Do Nothing at all
}

That way the 'break' is subsumed into the closing curly brackets, and
it follows the same way of grouping commands as the rest of the
language does.

Andy D

[Nicholas Paldino [.NET/C# MVP]]

Andrew,

It's actually not a bad idea. If you put a suggestion on the product
feedback site, I would be more than happy to vote for it.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Andrew Ducker" <an****@ducker.org.uk> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

And no, this isn't a complaint about break - I'm very happy to make
things explicit.

However, why isn't the format something like:

switch(myVariable)
{
case 1:
{
//Do Something
}
case 2:
{
//Do Something Else
}
default
// Do Nothing at all
}

That way the 'break' is subsumed into the closing curly brackets, and
it follows the same way of grouping commands as the rest of the
language does.

Andy D

[rmacias]

I think the reason is that it might make it look a little cleaner for
something like this:

switch(myVariable)
{
case 1:
case 2:
//do something if myVariable is 1 or 2;
break;
case 3:
case 4:
//do something if myVariable is 3 or 4;
break;
default:
}

Although, I think it would even look nicer if you could do "case 1, 2: ".
It probably goes back to the roots of the C language.

"Andrew Ducker" wrote:

And no, this isn't a complaint about break - I'm very happy to make
things explicit.

However, why isn't the format something like:

switch(myVariable)
{
case 1:
{
//Do Something
}
case 2:
{
//Do Something Else
}
default
// Do Nothing at all
}

That way the 'break' is subsumed into the closing curly brackets, and
it follows the same way of grouping commands as the rest of the
language does.

Andy D

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Honestly I prefer the break , it not that much longer and is VERY clear
the use,

If a C person see it, he knows that to expect.

If a C person see your proposal , well it's not explicit :)

also maybe it's easier for the compiler writers, in your case depending of
where the } is found it means more than a closing context.
I prefer the way it's now :)

cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Andrew Ducker" <an****@ducker.org.uk> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

And no, this isn't a complaint about break - I'm very happy to make
things explicit.

However, why isn't the format something like:

switch(myVariable)
{
case 1:
{
//Do Something
}
case 2:
{
//Do Something Else
}
default
// Do Nothing at all
}

That way the 'break' is subsumed into the closing curly brackets, and
it follows the same way of grouping commands as the rest of the
language does.

Andy D

[Scott Roberts]

"Andrew Ducker" <an****@ducker.org.uk> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

And no, this isn't a complaint about break - I'm very happy to make
things explicit.

However, why isn't the format something like:

switch(myVariable)
{
case 1:
{
//Do Something
}
case 2:
{
//Do Something Else
}
default
// Do Nothing at all
}

That way the 'break' is subsumed into the closing curly brackets, and
it follows the same way of grouping commands as the rest of the
language does.

Andy D

Well, it would certainly be more "C# like" that way, but it would prevent
intentional "flow through" from one case to another. While I think such
"flow through" is a horrible, horrible idea, I'm sure someone out there
thinks it's absolutely necessary.

[Christof Nordiek]

"Andrew Ducker" <an****@ducker.org.uk> schrieb im Newsbeitrag
news:11*********************@f14g2000cwb.googlegro ups.com...

And no, this isn't a complaint about break - I'm very happy to make
things explicit.

However, why isn't the format something like:

switch(myVariable)
{
case 1:
{
//Do Something
}
case 2:
{
//Do Something Else
}
default
// Do Nothing at all
}

That way the 'break' is subsumed into the closing curly brackets, and
it follows the same way of grouping commands as the rest of the
language does.

Andy D

An answer you can find on this site:
http://www.gotdotnet.com/team/csharp...sk.aspx#switch

The sentence that answers your question is at the end of the paragraph:
The reason this wasnt done was so that developers who were very used to C++
wouldnt have a hard time understanding what a switch statement was doing.

But I agree with you: Simply exiting a switch statement on reaching the end
of a case is much more usefull.

A good message:
This behavior could be added to C# without breaking existing programms. So,
if C#-Designers in future will agree with this, they could simply enhance C#
in that way.

[Jeremy Williams]

"Scott Roberts" <sc***********@no-spam.intelebill.com> wrote in message
news:OX***************@TK2MSFTNGP15.phx.gbl...

"Andrew Ducker" <an****@ducker.org.uk> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

And no, this isn't a complaint about break - I'm very happy to make
things explicit.

However, why isn't the format something like:

switch(myVariable)
{
case 1:
{
//Do Something
}
case 2:
{
//Do Something Else
}
default
// Do Nothing at all
}

That way the 'break' is subsumed into the closing curly brackets, and
it follows the same way of grouping commands as the rest of the
language does.

Andy D

Well, it would certainly be more "C# like" that way, but it would prevent
intentional "flow through" from one case to another. While I think such
"flow through" is a horrible, horrible idea, I'm sure someone out there
thinks it's absolutely necessary.

Since C# does not support the C++ style of "flow through" by leaving out the
break statement between cases (except when multiple cases pertain to the
exact same block of code), this is really not a big problem. Something like
this would work:

switch(val)
{
case 1:
case 2:
{
textBox1.Text = "Nothing";
}
case 3:
{
textBox1.Text = "Answer";
}
default:
{
}
}

I like it. It is definitely more consistent. Having this style as an
alternative format really does not seem to add any confusion - it is just as
clear what is being done.

[Christof Nordiek]

"Scott Roberts" <sc***********@no-spam.intelebill.com> schrieb im
Newsbeitrag news:OX***************@TK2MSFTNGP15.phx.gbl...

"Andrew Ducker" <an****@ducker.org.uk> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

And no, this isn't a complaint about break - I'm very happy to make
things explicit.

However, why isn't the format something like:

switch(myVariable)
{
case 1:
{
//Do Something
}
case 2:
{
//Do Something Else
}
default
// Do Nothing at all
}

That way the 'break' is subsumed into the closing curly brackets, and
it follows the same way of grouping commands as the rest of the
language does.

Andy D

Well, it would certainly be more "C# like" that way, but it would prevent
intentional "flow through" from one case to another. While I think such
"flow through" is a horrible, horrible idea, I'm sure someone out there
thinks it's absolutely necessary.

Well, it wouldn't prevent anything. intentional "flow through" would be as
possible
as it is know via goto case

[Scott Roberts]

"Jeremy Williams" <je*********@netscape.net> wrote in message
news:Oq**************@TK2MSFTNGP12.phx.gbl...

Since C# does not support the C++ style of "flow through" by leaving out the break statement between cases (except when multiple cases pertain to the
exact same block of code), this is really not a big problem.

As soon as I posted something in the back of my brain told me that C#
doesn't support C++ style flow-through. However, since I never, ever use
flow-through I never bothered to check it.

[Bruce Wood]

I like this idea. At first I was skeptical, but today I realized that
it would clear up the scoping stupidity that currently plagues switch,
to wit:

switch (myVariable)
{
case 1:
int result = 15;
...
break;
case 2:
int result = 12;
...
break;
}

currently causes a compiler error, the compiler complaining that
"result" is defined twice in the same scope. However, simply removing
the "int" definition on the second "result" line seems unsatisfactory:
how can declaring a variable in one case make it available in other
cases? Suddenly declaration scope and execution flow are strangely
divorced. (Yes, I realize that they really are different things, but
one can usually ignore that difference, except in this one case where
it jumps out at you.)

Enclosing case code in curlies would solve this problem, and make the
declaration scopes more intuitive:

switch (myVariable)
{
case 1:
{
int result = 15;
...
}
case 2:
{
int result = 12;
...
}
}

would now compile just fine, which is, I would argue, more what one
would expect.

[Daniel O'Connell [C# MVP]]

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

I like this idea. At first I was skeptical, but today I realized that
it would clear up the scoping stupidity that currently plagues switch,
to wit:

switch (myVariable)
{
case 1:
int result = 15;
...
break;
case 2:
int result = 12;
...
break;
}

currently causes a compiler error, the compiler complaining that
"result" is defined twice in the same scope. However, simply removing
the "int" definition on the second "result" line seems unsatisfactory:
how can declaring a variable in one case make it available in other
cases? Suddenly declaration scope and execution flow are strangely
divorced. (Yes, I realize that they really are different things, but
one can usually ignore that difference, except in this one case where
it jumps out at you.)

Enclosing case code in curlies would solve this problem, and make the
declaration scopes more intuitive:

switch (myVariable)
{
case 1:
{
int result = 15;
...
}
case 2:
{
int result = 12;
...
}
}

would now compile just fine, which is, I would argue, more what one
would expect.

Of course, this is an artifact of block scoping itself. in this case result
is not available outside of your switch block, but in the former case it is.
Seperate case labels aren't seperate scopes, they are just seperate
execution paths, different from a collection of labels and matching gotos
only in clarity.

You shouldn't ever be considering execution flow when considering scope
anyway. The compiler isn't that sophisticated, it never knows where
execution will actually end. Building an ambigious execution path isn't
terribly hard.

[Bruce Wood]

> You shouldn't ever be considering execution flow when considering scope anyway.

Well, yes, I realize that... in theory. However, in practice they
almost always line up nicely... except in the case of select. :-)

[Daniel O'Connell [C# MVP]]

"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

You shouldn't ever be considering execution flow when considering scope
anyway.

Well, yes, I realize that... in theory. However, in practice they
almost always line up nicely... except in the case of select. :-)

Only because if statements don't allow declarations outside of blocks, if it
made sense to do so you'd see the same thing there as well.