switch break/fall (last minute request ... )

[Hasan Aljudy]

Bill Baxter wrote:
> %u wrote:
>> == Quote from Hasan Aljudy (hasan.aljudy at gmail.com)'s article
>>>    case C:
>>>         //something
>>>    case D:      <-- error, no break or fall statement before case
>> D
>>
>> So:
>>>    case C:
>>           if( b1 )
>>               { fall; break;}
>>           else
>>               if( b2)
>>                   goto case C;
>>               else
>>                  { break; fall;}
>>>    case D:
>>
>> would be legal?
> 
> I'm pretty sure this one has been discussed to death in the past, so I 
> doubt any last minute plea is going to change anything,  for 1.0 at 
> least. :-)
> 
> Walter's position previously has been that he didn't want to confuse the 
> poor C/C++/Java converts regardless of how error-prone default fall 
> through is.

This is so against the philosophy of D.

Nothing should be confusing, as the compiler would explicitly state in 
the error message that either "fall" or "break" must be present.

Plus, Already many parts of D would confuse new comers, think about:

foreach( item; items ) { ... } // Wait .. where was item defined?

void func(X)(X y) { .. } // Wait .. why two sets of parameters?

class X(Y) { .. } // Hmm .. is this D's way of defining inheritance? 
huh? like python??

class D : X { .. } // Hmm .. guess that X(Y) wasn't inheritance

class A(B) : B, C, D // Now that's just plain confusing

None of these examples is anymore confusing than requiring a "fall" or 
"break" for switch cases.

> 
> If you look at the kind of code Walter writes (see parse.c in the DMD 
> source in particular), you'll see that he  is quite fond of stacking up 
> multiple case labels, so I doubt he'd ever agree to make
>         case TOKstruct:
>         case TOKunion:
>         case TOKclass:
>         case TOKinterface:
>         s = parseAggregate();
>         break;
> an error.

Walter already solved this, in D you can do:

     case TOKstruct, TOKunion, TOKclass, TOKinterface:
        s = parseAggregate();
        break;


> 
> However, what if you modify the rule slightly so that if a case follows 
> another case immediately, then a 'fall' is not required?  Then Walter 
> may yet find it palatable.
> 
> I'm all for it, though.  I've been debugging my own missing 'break' 
> statements for 20 years now, and I still never seem to learn.

Thanks for the testimony.
I think this is true for *all* C/C++ programmers. I feel that fighting 
this common source of bug should've been one of the first things that D 
had done.

> 
> --bb