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

[Bill Baxter]

Hasan Aljudy wrote:
> 
> 
> 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.

I didn't really get his argument either, so it's possible my 
paraphrasing of it somehow missed his real point.  Or maybe it's just 
that he didn't like the idea of changing it to the point where 'break' 
was implicit and a fall-through keyword was required.  But with your 
suggestion, as you say, the compiler will tell you if you're falling 
into C/C++ habits.


> 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;

I didn't realize that worked. =)  Actually I was thinking to suggest 
that, but figured that was a bigger lump of coal to swallow than just 
allowing adjacent cases to fall through.  :-)

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

I agree.  I think it was one of the first things that came to my mind 
when first looking into D, when I read the mantra on the D intro page 
about fixing design flaws in C/C++.  "Oh great, that must mean the 
switch/break debacle is fixed ... hmm and what else I wonder".  Come to 
find out that my first guess was wrong.


--bb
(P.S. This still ain't gonna happen in the next 3 days.  ;-))