Improvement to switch-case statement

[BCS]

Reply to Stewart,

> BCS wrote:
> 
>> Reply to Stewart,
>> 

>> I for one don't like that proposal for a few reasons:
>> 
>> Because it looses fall through and adding it back in with "goto case
>> n;" gets messy in generated code. I use fall through an some of my
>> template code.
>> 
> Please read that proposal properly.  You'll see that it supports
> something more general than fall through.  Unless your primary reason
> for using switch is to implement Duff's device or something like that.
> 

Duff's device is actualy one of the use cases I'm thinking of. However mor 
generaly I have use for the ability of C's switch to do a "jump into this 
block at point n" for some runtime n. This is the central device that dparse 
uses for backtracking. Another use case I can see right off is yield.

> Notice also that nowhere did I propose removing the old switch syntax.
> So if you still want it, it's still there.
> 

Ah. I guess I eroneusly assumed that from this threads context.

>> Because it can lead to hard to understand code.
>> 
> I'm sure you could, if you want, write code that is just as obfuscated
> with the switch we have.
> 

Any obfuscation the current switch can do, the proposal can do as well, however 
the proposal can do some that the current form can't. Also, the intended 
use of the proposal tends to add obfuscation IMHO.

>> you need to examine all cases to find the code path rather than just
>> find a single case with the given value.
>> 
> No I don't.  Once I've found a path that matches, I need only to
> examine those remaining that aren't preceded by else in order to
> determine whether there are any more.
> 

that's still more than one.
Also you just pointed out another concern: you need to look at all cases 
to tell if an else section gets executed. With good tools, not a big problem, 
OTOH...

>> Allowing the same case in more than one place could lead to some
>> extremely hard to find bugs where the same case is added more than
>> once in error.
>> 
> Only if you carry on thinking in terms of C switch.  If you think of
> it as syntactic sugar for if, then it might be easier.

What I'm thinking of it as has no bearing on this. Ending up with a second 
instance of code for a given value when that is incorrect is a bug. If you 
are pointing out that it can be used as a sequence of "execute this if the 
value is in this set" blocks then you may have a point, however in that cases 
I'd say that proposing this in connection with switch is a bad idea as it 
is to different from switch, and it would tent to imply a "false friend" 
( http://en.wikipedia.org/wiki/False_friend )