4 ms·

For Zig, note that there's not really a use case for goto that you can't do with other language features. To jump backwards, there's labeled continue. To jump

For Zig, note that there's not really a use case for goto that you can't do with other language features. To jump backwards, there's labeled continue. To jump forwards, there's labeled break. The use case that computed goto tries to solve is addressed with labeled continue on a switch [1] [1]: https://github.com/ziglang/zig/issues/8220 https://github.com/ziglang/zig/issues/8220

nerdponx 5y ago
Maybe labeled break and continue is what Python needs, not goto.
rightbyte 5y ago
All that trouble to avoid proper gotos. Essentially introducing castrated gotos.
- Dylan16807 5y ago
  Isn't that basically every control flow mechanism?
  - rightbyte 5y ago
    Ye sure. I meant that it feels like jumping through hoops to introduce a lot of different mechanisms just to remove goto:s. E.g. "labeled breaks" and using silly loop constructs.
    - AndyKelley 5y ago
      You have it precisely backwards. These features already have reasons to exist, because they solve control flow scenarios. So there they are. And then we are brought the question of introducing goto, and there's just nothing that it adds. It would make the language more complicated for no reason.
    - Dylan16807 5y ago
      They're not set up in the most elegant way, but the concept of leaving a nested loop is very simple and should definitely be possible without a goto. And switching between states in a state machine, where each state has a single entrance like a normal function, should also be simple. With goto you can't know at a glance if the code is following those patterns or doing some kind of spaghetti nonsense. It hurts readability.
  - mumblemumble 5y ago
    That was even the whole point behind Dijkstra's paper. To paraphrase, "Goto is a very powerful language feature. Which is exactly the problem. Less powerful features give programmers less latitude to do clever things their colleagues (and the compiler) can't reason about effectively."
- dragonwriter 5y ago
  “Proper” gotos, like continuations, are hard to reason about and optimize. Restricted versions each covering a major use case are easier to reason about, and to optimize. Anyhow, pretty much every version of “goto” using the name implemented or proposed for Python or other structured languages is castrated: typically, it take only a static label and has restrictions on where it can jump based on structure (out of blocks but not into blocks, within the same function, is pretty typical.) Proper goto can jump anywhere in the program, even dynamically computed at runtime, and if state isn't set up the way the code jumped to expects, too bad. Everything more restricted is just dickering about how much it should be castrated.

nerdponx 5y ago

Maybe labeled break and continue is what Python needs, not goto.

rightbyte 5y ago

All that trouble to avoid proper gotos. Essentially introducing castrated gotos.

Dylan16807 5y ago
Isn't that basically every control flow mechanism?
- rightbyte 5y ago
  Ye sure. I meant that it feels like jumping through hoops to introduce a lot of different mechanisms just to remove goto:s. E.g. "labeled breaks" and using silly loop constructs.
  - AndyKelley 5y ago
    You have it precisely backwards. These features already have reasons to exist, because they solve control flow scenarios. So there they are. And then we are brought the question of introducing goto, and there's just nothing that it adds. It would make the language more complicated for no reason.
  - Dylan16807 5y ago
    They're not set up in the most elegant way, but the concept of leaving a nested loop is very simple and should definitely be possible without a goto. And switching between states in a state machine, where each state has a single entrance like a normal function, should also be simple. With goto you can't know at a glance if the code is following those patterns or doing some kind of spaghetti nonsense. It hurts readability.
- mumblemumble 5y ago
  That was even the whole point behind Dijkstra's paper. To paraphrase, "Goto is a very powerful language feature. Which is exactly the problem. Less powerful features give programmers less latitude to do clever things their colleagues (and the compiler) can't reason about effectively."
dragonwriter 5y ago
“Proper” gotos, like continuations, are hard to reason about and optimize. Restricted versions each covering a major use case are easier to reason about, and to optimize. Anyhow, pretty much every version of “goto” using the name implemented or proposed for Python or other structured languages is castrated: typically, it take only a static label and has restrictions on where it can jump based on structure (out of blocks but not into blocks, within the same function, is pretty typical.) Proper goto can jump anywhere in the program, even dynamically computed at runtime, and if state isn't set up the way the code jumped to expects, too bad. Everything more restricted is just dickering about how much it should be castrated.