>I think goto's are fine, and they are often more readable than large amounts of indentation. That's _especially_ true if the code flow isn't actually naturally indented (in this case it is, so I don't think using goto is in any way _clearer_ than not, but in general goto's can be quite good for readability).
>Of course, in stupid languages like Pascal, where labels cannot be descriptive, goto's can be bad. But that's not the fault of the goto, that's the braindamage of the language designer.
Goto is absolutely the right tool for: "the instruction pointer finds itself here, and at this critical juncture in the algorithm, one would rather prefer that it were over there, for want of correctness, if not beauty."
One job is when auto-generating source code. It's much, much easier to generate a graph as a collection of blocks connected by various goto's and if statements.
This does not adversely affect modern optimizers - they'll figure out the loops from the goto graph. At least the D compiler does.
See http://blog.regehr.org/archives/894 , http://thread.gmane.org/gmane.linux.kernel/84823/focus=85436 and https://github.com/torvalds/linux/search?q=goto for some discussion and examples.
From Mr Torvalds (as diplomatic as ever...):
>I think goto's are fine, and they are often more readable than large amounts of indentation. That's _especially_ true if the code flow isn't actually naturally indented (in this case it is, so I don't think using goto is in any way _clearer_ than not, but in general goto's can be quite good for readability).
>Of course, in stupid languages like Pascal, where labels cannot be descriptive, goto's can be bad. But that's not the fault of the goto, that's the braindamage of the language designer.