🚀 go-pugleaf

A number of authors have expressed their comments on this topic.  Without
trying to quote them all, I'd like to add a couple of missed points.

1)  This was discussed under a different title 3-4 weeks ago (or more?).
    I don't have a copy of that string, but I believe it would add a
    little to this one.

2)  Perl has the proposed construct.  So does an old, goto-free dialect
    of XPL, XPL/S.  (XPL is a PL/1 subset, sort of, for those who don't
    recognize it from McKeeman's book.)  It was not at all difficult to
    implement complex applications (including its own compiler) using
    it.  (And XPL/S only had break, not continue.)

3)  This kind of label, if distinguished from an ordinary goto label, is
    particularly easy to generate code for because it has "conventional"
    scope rules (that is, it is declared before it is used.)  (It can
    be easily generated by a 1-pass compiler with fixup; continues don't
    even need the fixup.)

4)  On the issue of where to place the label:  label compound
    statements.  Not for or while loops, but simply the compound
    statement.  It should parse in all cases, but I havn't tested that.
    This then allows breaks/continues out of non-iterative statements.
    (Or switches.)

    (I'm not sure what continue out of a switch or non-iterative
    statement means, but it's no worse than currently where break and
    continue use different scopes when a switch is enclosed in a for.
    (At least using labeled blocks, it would either have a meaning or be
    an error, rather that silently doing something that isn't all that
    intuitive.))

5)  Break/continue <number> (where hopefully <number> is a constant) is
    very dangerous, and I'd rather not see any multi-level break than
    have it introduced.  The reason it is dangerous is that if I
    introduce a loop lexically "very far" from either enclosing loops or
    the break (or continue), I may not see the break, and consequently
    change the meaning of the break in ways I'd not intended, and it
    would not be detected.  A labeled compound statement is relatively
    immune to accidental errors in this area, and it's very easy to find
    the uses because the label is unique.

I realize that it's possible to only rarely use gotos in C now, but it
sometimes leads to convoluted code for a simple meaning.  (Personally, I
consider introducing a variable where one isn't needed at least as
convoluted as a well-considered goto.)  Without a big change to the
language (and one that's fully forward compatible), the number of
convoluted programs can be somewhat reduced.

There are more powerful constructs that might be considered (exit conditions,
termination blocks, and the like).  However they introduce more mechanism,
while this meets one of the basic conditions of the design of C: there's not
a lot magic going on under the table.  

Donn Terry
HP Ft. Collins