No more fall through in case statement?

[S.]

Bruce Adams Wrote:

> On Mon, 07 Jan 2008 22:51:31 -0000, S. <S at s.com> wrote:
> 
> > Bruce Adams Wrote:
> >
> >> On Fri, 04 Jan 2008 00:15:25 -0000, S. <S at s.com> wrote:
> >>
> >> > Carlos Santander Wrote:
> >> >>
> >> >> How about using existing D syntax?
> >> >>
> >> >> switch (s[i]) {
> >> >>       case ' ', '\t', '\f', '\r', '\n', '\v':
> >> >>           if (inword) {
> >> >>               r ~= capitalize(s[istart .. i]);
> >> >>               inword = false;
> >> >>           }
> >> >>           break;
> >> >>
> >> >>       default:
> >> >>           if (!inword) {
> >> >>               if (r.length)
> >> >>               r ~= ' ';
> >> >>               istart = i;
> >> >>               inword = true;
> >> >>           }
> >> >>           break;
> >> >> }
> >> >
> >> > This whole conversation about switch was kind of lost on me, but I  
> >> have
> >> > to contribute this.
> >> >
> >> > I, at various times, have written code that depends on case statements
> >> > falling through, while not being identical!
> >> >
> >> > For example:
> >> >
> >> > switch(foo)
> >> > {
> >> > case 'bob':
> >> >     //Do bob stuff
> >> >     //Fall through and doo bar stuff too.
> >> > case 'bar':
> >> >     //Do bar stuff and exit
> >> >     break;
> >> >
> >> > case 'baz':
> >> >    //Do some baz stuff
> >> >    break;
> >> > }
> >> >
> >> > Whatever is changed shouldn't break this.
> >>
> >> This whole conversation boggles me. cases should *never* fall through  
> >> its
> >> dangerous.
> >
> > In other news, it has been discovered that the risk of choking is  
> > greatly increased by eating anything that is not pureed.  As a result,  
> > lawmakers have outlawed solid food.
> >
> Is that an example of Ignoratio elenchi?  
> (http://en.wikipedia.org/wiki/Ignoratio_elenchi)
> Lawmakers never actually outlawed goto but you don't see it used very  
> often.
> That's because putting glass in your food is not a good idea.

Well one probably not.  For one, there isn't a formal definition given for that term on your cited page. 

Secondly, my point is that most things that are generic enough to be useful, are inherently dangerous if misused.    Consider most kitchen utensils.  The ones that are "safe" only do one thing, and if you want a "safe" kitchen then you need hundreds of these gadgets.  

goto, and break, are defined in such general terms that they are useful over a wide range of constructs.  If you want to make things "safe" you need to pollute your "kitchen" with gadgets.

I would like to see the specification stay simple enough that know what exactly each "tool" does in a general sense and then apply it in a specific way.  Now sometimes, if something is used enough, then it makes sense to have a special tool for it.  (Like having a coffee pot instead of just boiling grounds and straining them out later.)  This is why I like D instead of just straight up C.


> > Programming requires a brain.
> >
> Working in a team requires respecting other people's Brains and level of  
> development.
> Fall through unnecessarily complicates things without adding much if  
> indeed any power.
> I'd rather use my brain on the important things.
> 

And calling into another function in order to duplicate functionality requires introduce a new scope....  

If the specification is easily understood then there isn't much problem here...

> > You should go read DailyWTF for awhile.  It is possible to do the most  
> > ridiculous things no matter how carefully the language is crafted.  We  
> > should just stay away from hand-holding and focus on making things  
> > easier.
> >
> Its a matter of perspective. Is it easier to debug or easier to read or  
> easier
> to write safe code?

It should be easier to write safe code, and easier to debug and easier to read.   Sometimes though, the compiler should just warn you when you're using a construct incorrectly.   For example, a return statement can cause unreachable code.  Should we get rid of the return statement in favor of 15 different keywords to do similar (but specific) things, or make it an error when it produces unreachable code?

I think my take on how I run my kitchen is applicable to D.

> 
> > I agree with measures that make debugging easier when dealing with  
> > naming and hijacking.  However, a simple step-through will reveal a case  
> > falling through when it shouldn't.  The aforementioned issues are not as  
> > easily caught.
> >
> True but its easier still if you don't need to step through at all. Its  
> easy enough to
> find the source and targets of a goto with a find in your code. Okay its  
> nowhere near
> in the same league as goto but the point's still valid.

By aforementioned issues I meant hijacking and protection levels.  Which are basically the same reason we require our variables to be defined instead of just implying them when they're used.

Is the trade off of having to declare your variables worth not having to figure out what is going on when you mistype a variable name?   Yes, most certainly.     I don't think switch, goto, break, and the like are anything like that.


-S.