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

  • Thread starter Thread starter Andrew Ducker
  • Start date Start date
A

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
 
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.
 
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.
 
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,
 
Andrew Ducker said:
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
Click to expand...

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.
 
Andrew Ducker said:
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
Click to expand...

An answer you can find on this site:
http://www.gotdotnet.com/team/csharp/learn/columns/ask.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.
 
Scott Roberts said:
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.
Click to expand...

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.
 
Scott Roberts said:
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.
Click to expand...
Well, it wouldn't prevent anything. intentional "flow through" would be as
possible
as it is know via goto case
 
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.
Click to expand...

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.
 
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.
 
Bruce Wood said:
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.
Click to expand...


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.
 
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. :-)
 
Bruce Wood said:
Well, yes, I realize that... in theory. However, in practice they
almost always line up nicely... except in the case of select. :-)
Click to expand...

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.
 
Back
Top