🚀 go-pugleaf

In article <48bq4l$lmf@news.mel.aone.net.au>,
andrewd@agnus.livewire.com.au (Andrew Dunbar) wrote:

>   block1: {
>       block2: {
>           break block1;
>       }
>   }
...
>Ignoring continue, might this not lead to abuse of break to jump out
>of any block, much as return is overused by some today? 

In what sense is it abuse?  Given that there are many instances that
multiple block (possibly loops) processing must be terminated, is the
use of an extended break worse than the alternatives?

Alternative 1:
    int exit_block = 0;
    ...
    block1: {
        block2: {
            if (condition) exit_block = 1;
            else {
                /* rest of block 2 */
            }
        }
        if (! exit_block) {
            /* rest of block 1 */
        }
    }

In this case, an additional variable is defined, extra runtime tests
are required, extra nesting is used, and extra coding lines are
required.  Notice that if the break is being added to existing
nested blocks, each level of nesting must be modified, although that
level is not directly involved in the modification involving the
break.  Is this alternative better?

Alternative 2:  Use a goto.  This is straight-forward, just requiring
a label at the destination.  It seems natural for the escape, since
the label precedes the next statement to be executed.  I don't see it
being much different than an extended break, although it is perhaps
less error-prone, due to the unambiguity of the destination label vs.
locating of the end of labelled block.

Alternative 3:  Embed block 1 in a function and terminate via return.
This is OK, but imposes a function call and parameter passing
overhead, as well as the additional textual overhead of a separate
function.

Alternative 4:  Use a longjmp.  This imposes execution time penalty
and makes the code even harder to follow, IMHO.

Of the four, the extended break and goto seem the most natural and
least disruptive.

Thad