Re: goto considered helpful

On 12/12/2024 22:50, Keith Thompson wrote:

Michael S <already5chosen@yahoo.com> writes:

On Wed, 11 Dec 2024 17:27:53 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

bart <bc@freeuk.com> writes:
[...]

My experience of multi-level break is that there are two main
use-cases:
>
  * Used in the current loop only (not necessarily the innermost to
an observer). This is the most common
>
  * Used to exit the outermost loop
>
So to support these, named or even numbered loops are not
necessary. (Eg. I use 'exit' or 'exit all'.)

>
I would oppose a change to C that only applied to innermost and
outermost loops.  For one thing, I'm not aware of any other language
that does this (except perhaps your unnamed one).  For another,
it's easy enough to define a feature that handles any arbitrary
nesting levels, by applying names (labels) to loops.

>
The better solution is education.
Convince teachers in unis and colleges that goto is *not* considered
harmful for this particular use case. Convince them to teach that
attempts to avoid goto [for this particular use case] are really
considered harmful. If you don't believe in authority of yourself then
ask for help from somebody famous that share this view. I would guess
that nearly all famous C programmers share it.

 Backward gotos tend to be dangerous.  Forward gotos are less so.
 Dijkstras original "Go To Statement Considered Harmful" letter was
written in 1968, at a time when many languages didn't necessarily
have the structured control constructs we've come to expect since
then.  Using goto to implement a loop is almost always a bad idea,
but it's something that a modern C programmer probably wouldn't
even consider doing.
 I agree that gotos have valid uses.
 Here's an answer I wrote on Stack Exchange some years ago to the
question "Is using goto ever worthwhile?" :
https://softwareengineering.stackexchange.com/a/133523/33478
 Quoting from that answer :
      The main use of a goto in a reasonably modern language (one that
     supports if/else and loops) is to simulate a control flow construct
     that's missing from the language.
 I would support adding named loops and labeled exit/continue to
a future version of C.  I've used languages that have similar
features, and have found them very useful.  Given that C doesn't
have multi-level break, I tend to agree that a goto statement is a
reasonable way to simulate it, often better than the alternatives.
(It's important to use a meaningful label name.)  Similarly,
the C code in the Linux kernel makes extensive use of gotos for
error handling.
 If C didn't have a break statement at all, it could be simulated
with goto.  If that were the case, I'd still favor adding a break
statement to the language.  I support adding labeled break statements
for the same reason.  Goto is not the root of all evil, but it's
worth some effort to avoid it when other constructs are clearer.
 

I personally have found "goto" in C to be useful on no more than a couple of occasions during my entire career.  I'd find a labelled "break;" statement somewhat more useful - but I think I can confidently say I would never want to use some kind of relative numbered "break 2;" or similar statement.  Such multi-level breaks would be far too rare in code for people to interpret "automatically" - many programmers would need to think hard about whether the number is from the outside in, or inside out, and starting from 0 or starting from 1.  A labelled break would be vastly clearer.
If I find I have such complicated loops and need to break out of them, I will sometimes use local boolean flags - that gives you a convenient place to give a name to the condition, and the compiler turns it all into "gotos" in the generated code.  Alternatively, the function can be split up - multi-level "break" from the inner loop is now just a "return" from the "inner" function.  This would be neater if C supported nested functions of some sort - perhaps a restricted form of lambdas. (For C, it would be natural to limit these to cases where there is never a closure object created.)