Suggestion: new switch statement

[Kristian]

I too think that curly brackets in switch fits nively to the syntax of the  
language, as Mike here demostrated. And I also understand, as Chad said,  
why a new switch statement is a bit too extreme.

Well now, currently there are four solutions:

1) A new switch statement (e.g. jump or branch).
2) The switch statement using different notation (curly brackets).
3) The compiler forces to use breaks etc at the end of cases.
4) A combination of the solutions 2 and 3.

Solution 1:
Pros:
- No breaking through bugs.
- Does not break old code.
- Does not require breaks etc at the end of cases.
- You'll instantly know that breaking always happen at the end of cases  
(if not defined otherwise) when looking at code.
- Does not require brackets (some people don't like them).
- Allows doing complex case structures easily (usually a bad thing, but  
sometimes necessary, maybe).
Cons:
- Two statements that do similar tasks yet differently. (Personally I  
don't think this is a problem though.)
- Allows doing complex case structures easily (sometimes a good thing,  
maybe).

Solution 2:
Pros:
- Does not break old code.
- Fits to the language syntax nicely.
- Only one statement doing switching/jumping/branching.
- Allows doing complex case structures easily (usually a bad thing, but  
sometimes necessary, maybe).
Cons:
- You have to be a little more careful when using it. You may end up  
allowing a break through when not wanted. Will people accustomed to old  
switch syntax adapt to use the new one?
- Uses brackets (some people don't like them). (Personally I don't mind  
using them.)
- Allows doing complex case structures easily (sometimes a good thing,  
maybe).

Solution 3:
Pros:
- No breaking through bugs.
- Does not break old code as _itself_ (see the cons).
- You know instantly that breaking etc always happen at the end of cases  
when looking at code.
- Complex case structures are somewhat harder to do (sometimes a bad  
thing, maybe).
Cons:
- In old code, where breaking through is required, you have to modify the  
code to keep it compiling. This can be considered as "breaking old code".  
And changing old code may introduce new bugs.
- Takes more typing. If you forget a break statement, then you have to  
edit the code and recompile.
- Complex case structures are somewhat harder to do (usually a good thing,  
though).


The simplest and safest solution seems to be 1. The solution 2 is more  
'beautiful' syntaxically (well, at least people who don't like curly  
brackets may disagree with this). However, it's not so safe to use than  
the solution 1, I think. Solution 3 is also safe. However, it requires  
more typing and it may 'break' old code.

Maybe we could have both the solutions 1 and 2? (Or not...) ;)
I think solutions 3 and 2+3 are not accepted (by public) because of this  
old code breaking issue... but maybe it's not an issue at all in practice.


Btw, it's quite funny/sad that (quite) many seem to hate curly brackets.  
C/C++, D, etc, are so called curly brackets languages after all.

Well, I am not fond of them either, pressing AltGr + 7 and AltGr + 0 is  
not so fast/easy as it should be (usually pressing AltGr + 7 requires two  
hands). Fortunately my text editor's macro will add { and } to a statement  
by pressing Ctrl + Enter. Usually it works fine, even.


On Tue, 22 Aug 2006 04:56:40 +0300, Chad J  
<gamerChad at _spamIsBad_gmail.com> wrote:
> Kristian wrote:
>> It would be nice if there was a new statement that acts like 'switch'   
>> except that 'break' will be automatically added at the end of the case   
>> statements. (We don't want to change the behavior of 'switch' because   
>> it'll break old code and confuse people familiar with C/C++.)
>>  Let call this new statement 'jump' (or something), for example:
>>  void func(int val) {
>>     jump(val) {
>>         case 1:
>>             doX();
>>         case 2, 3:
>>             doY();
>>         default:
>>             doZ();
>>     }
>> }
>>  Using 'switch', 'func()' would look, of course, as follows:
>>  void func(int val) {
>>     switch(val) {
>>         case 1:
>>             doX();
>>             break;
>>         case 2, 3:
>>             doY();
>>             break;
>>         default:
>>             doZ();
>>             break;
>>     }
>> }
>>  You could use a 'unbreak' (or something) to allow execution to fall   
>> through to the next case statement.
>>  In addition, falling through should be allowed in the following case:
>>      case 1:
>>     case 2:
>>  which is a longer way to write "case 1, 2:", of course.
>>   I think breaking after a case is (a lot) more common than falling  
>> through.  So this will reduce bugs (a programmer can easily forget to  
>> put the break  statement at the end of a case). Also, it'll make code  
>> shorter and easier  to read.
>
> Creating a new type of switch statement just to change some default
> behavior seems a bit excessive.
>
> At the same time, I can't stand the fall-through default behavior!  It
> is a source of bugs, and I've already been hit by it a few times in D
> and spent hours trying to find the bug in a switch statement that
> behaves subtly different than what I expected.
>
> I've read that this is maintained in D to keep it easy to port C code
> over to D.  That's understandable, especially if you want to make break
> the default, which would change the meaning of code without any warning.
>
> I'd suggest though, that you don't allow a default ending for case
> blocks at all.  Mandate that each case block be followed by an escape
> like 'break', 'return', 'goto', 'throw', etc.  That way, the compiler
> would throw an error when C code that uses fallthroughs is inadvertently
> used as D code.  Also, this is one of those things from C/C++ that is
> bad.  D is supposed to get rid of those bad things even if it means
> losing backwards compatibility, so please get rid of this bad thing that
> comes from C.
>
> I also like Mike's suggestion on this thread a lot.  It could even be  
> combined with my suggestion.  I'd say use Mike's suggestion, and only  
> apply my suggestion to the colon blocks.  Since the brackets and  
> one-liners are not valid C syntax AFAIK, the compiler won't need to  
> mandate anything about them to flush out bugs from incoming C code.  On  
> the developer side, this trades nasty runtime bugs for some small amount  
> of hunting down compiler errors and fixing them.  A good trade IMO.  Not  
> sure what the cost would be to compiler writers like Walter, but please  
> at least implement the mandatory ending on the current case blocks, or  
> something just as good.