🚀 go-pugleaf

<halasz@caip.rutgers.edu> wrote
-In article <1995Aug2.080237.17479@dcs.warwick.ac.uk>, A.Main@dcs.warwick.ac.uk (Zefram) writes
-+ ....
-+ int fn() ret
-+ {
-+  if(some_error_condition()) { ret=-1; goto end; }
-+  /* ... */
-+  end:
-+ }
-+ 
-+ which is much more disgusting....
-
-which is much better, for there openlie is "goto", not one hidden
-under "return".

In article <1995Aug16.040124.24562@dcs.warwick.ac.uk>, A.Main@dcs.warwick.ac.uk (Zefram) writes:
- One might as well insist on rewriting all for loops using while, on the
- grounds that the for is `hiding' a while.  In fact, for and while are
- just hiding a few ifs and gotos!  We obviously must ban the use of
- while, in order to make the gotos explicit.  And the structured ifs are
- just hiding gotos too -- let's make goto the only statement that it's
- legal to put in a conditional!  And ban else!  In summary, your
- proposal naturally leads us to totally abandon structured programming,
- in order to avoid implicit gotos.
No, this comment means that you need to learn structured programming.
The main point behind it is the lack of need to search the code for jumps to
a givven point.  When a loop has one exit, one knows that the condition
wherefor it lasted is changed, and therefore knows that much at that one point.
"return" offers nothing at all by wai of such securitie, in C no more than
"goto".

- By contrast, return -- which has relatively unstructured semantics --
Here I see that you know what is wrong with "return" ...
- won't always perform a jump.  In void functions it almost never will,
- and on platforms where arguments and return values are passed in
- registers very few functions will require more than one machine-code
- instruction in the way of cleanup code.  The chances are, on such an
- implementation, the code you prefer -- with a goto instead of a return
- -- would be optimised to an actual return.  Coding it that way makes
- much more sense.
the rest is not relevant implementational detail.