Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!ernie.Berkeley.EDU!jwl
From: jwl@ernie.Berkeley.EDU (James Wilbur Lewis)
Newsgroups: comp.lang.c
Subject: break
Message-ID: <34473@ucbvax.BERKELEY.EDU>
Date: 24 Feb 90 01:00:57 GMT
References: <1597@awdprime.UUCP> <8133@hubcap.clemson.edu> <10839@june.cs.washington.edu> <SUY1G_Fxds13@ficc.uu.net>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jwl@ernie.Berkeley.EDU (James Wilbur Lewis)
Organization: University of California, Berkeley
Lines: 39

In article <SUY1G_Fxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>
>The right solution for Next C (whether it be P or D) is to defang break
      In this instance, perhaps C--? :-)      ^^^^^^
>by using a different keyword for breaking from a switch or exiting from
>a loop. I would suggest that 'break' be given a mandatory keyword argument:
>either 'break switch', 'break for', and so on.

Keyword?  Why not a label?  Then you could break all the way out of nested
control structures without undue contortions.  The default action could be
to break out of the innermost appropriate structure, just the way it works now,
so it would be an upward-compatible extension.

The keyword contruction would be error-prone, for example if you change an
inner loop from a for to a while, and forget to change the break keyword.

foo:   
    for( ... )
    {
bar:  
        while( ... )
        {
             switch(c)
             {
                 case GOOD1:   do_something();
                               break;
                 case GOOD2:   do_something_else();
                               break;
                 case FUNNY:   clean_up();
                               break bar;
                 case DISASTER:  
                               die_horribly();
                               break foo;
               }
          }
     }

-- Jim Lewis
   U.C. Berkeley