Oh that's an interesting thought. Goto's are considered harmful, because holy hell as a human trying to understand and reason about code, the spaghettifcation if someone else used gotos all over the place and I have to reconstruct their thought process just doesn't sound like fun. But if we're no longer writing code by hand (which, I gotta be honest, I'm using AI to write a lot of code for me these days), then does that still matter? If a human isn't going to have to understand the code, can we get more performance out of existing systems by considering goto's useful?
goto is already useful as an end-of-function cleanup. You pop one at the end of each function (the naming is local to the function) and that's the place where you free ram if the pointer's not null and close the file if the handle is not null and so on.
Then you don't have to litter all of your if/else clauses with hundreds of memory frees and cleanups - you just "goto"
The fact that this is controversial to some people just shows how rules like "Dont use goto" become stupid - if one is trying to make code simpler then there are cases were not using it is the more confusing and error prone choice.
As for "can we now do anything" well if you don't ever need to debug "anything" then yes and if you have any small doubts about your LLM then no.
I assume there's a clear technical reason why GOTO is harmful, it adds to the complexity of the code, makes it harder to understand and fix and evolve. Wouldn't the same difficulties affect the LLMs ability to understand and fix and evolve the code as well?
loading story #48900619
Compilers only really use them for things like break and the end if blocks. There isn't much to gain by being able to execute anything arbitrarily, and then go...where? There might be places here and there within a function where compilers already take advantage of it, but I doubt it's useful in the way you think.
loading story #48899346