break

[Checkpoint Technologies]

In article <34473 at ucbvax.BERKELEY.EDU> jwl at ernie.Berkeley.EDU (James Wilbur Lewis) writes:
>In article <SUY1G_Fxds13 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>>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.
>
>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;
>               }
>          }
>     }

	I have my own pet idea for this, if you will all permit me :-)

	I like 'break label' myself, but the label should be positively
identified as a label on a loop or switch construct.  You should not be
able to 'break' to any arbitrary label, 'goto' already does this.
Instead place a label on the loop or switch:

	for label (i = 0...)
		{
		stuff
		switch swname (c)
			{
			cases
			break label;	/* breaks from 'for' loop so
						labelled */
			other cases
			break swname;	/* break from 'switch' */
			}
		}

	The label would have specific scope: only addressable
by 'break' statements inside the loop/switch construct, not by goto's at
all, not by break's outside the particular loop.  Since the label leaves
scope once the loop is closed, the same label could be used on
subsequent loops.  If the same label is used on a nested loop, it's
either illegal or superceeds the prior label, and the outer lable
reappears when the inner loop is closed.

	OK, that's my two cents.  I'm not a language designer; I suspect
that if this idea draws any attention at all it'll get picked apart...