note sundialsvc4 And I, for one, still will go on-record as having rejected in code review every piece of logic I have ever encountered (other than in profoundly specialized cases such as device-drivers and parsers) that contained a <tt>goto</tt>.   And here’s the very-simple reason why: <blockquote>The program’s internal state, at the point of the label, is solely determined by the internal state at every point that “goes to” that label ... not (only) by the statements which surround it or precede it.   You can, intentionally or worse-yet unintentionally, introduce an error of the most-undebuggable kind at any point in the future ... and if what you did is syntactically acceptable, the compiler won’t say a word of warning to the effect that you just planted a high explosive device with a hair-trigger underneath your foot.</blockquote> This causes the software complexity meter to spike “infinity,” and for no purpose that cannot be better-achieved in some other way.   Even the “toy” example in the OP is effectively impossible to understand ... even as-written, and only if some other <tt>goto</tt> is not later added, somewhere, anywhere, anytime.   (Yes, I am intentionally stretching syntactic truth slightly to make a point ...)   You have to think to realize that what this logic is actually doing is <tt>if ($arg != 1)</tt>. The Perl language evolved a number of constructs, such as <tt>last LABELNAME</tt>, specifically to accommodate the control-constructs that do indeed occur from time to time in production programs, and to handle them in a way that still affords for efficient code-generation and pragmatic goof-detection.   But <tt>goto</tt>, except in the edge-cases I previously mentioned, is an unnecessary bad-idea that should never be accepted in production code.   (The edge-case exceptions are not frequent-enough to justify softening the word, “never.”) 1013574 1013574