Comment Re:I miss GOTO...there I said it (Score 5, Informative) 353
[citations needed]
Citations won't be found, because the explanation is incorrect. There is no technical issue with compilers implementing 'goto' so long as the destination is in the same lexical scope (C has this limitation). Nor is it worth considering execution context at the level of the CPU, as any high-level loop or branch instruction must be translated into one of a limited number of conditional or non-conditional, relative or absolute jumps. Ultimately whether you use 'goto' or some other control construct you are attempting to express the same programmatic flow, and the compiled instruction stream will be sufficiently similar that it's not worth splitting hairs over.
The reason 'goto' is "considered harmful" is because structured programming theorizes that any computable function can be expressed by combining simpler programs using sequence, selection and iteration; and this provides the opportunity for a constructive approach to program correctness. Dijkstra argues that we are cognitively limited and can benefit from code that is structured so that we can tell at any point where we are and where we have come from (a gross paraphrasing of what Dijkstra calls "coordinates"). But "[t]he unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress". In other words careless use of 'goto' makes it hard to reason about your code.
Knuth contended that one could created structured programs with 'goto' statements, and provided examples of how 'goto' make the program more elegant.
It is important to realise that the claimed advantages of structured programming are undone by the use of break, continue, or exception handling. There are limited forms of goto, and using them prevents proofs of correctness (under the assumptions of structured programming; other techniques may be available) and reasoning using Dijkstra's "coordinates".