4 ms·

This thread isn't about safety though. It's about readability (spaghetti code). IMHO gotos in C when used for for dealing with errors at the end of the function

This thread isn't about safety though. It's about readability (spaghetti code). IMHO gotos in C when used for for dealing with errors at the end of the function make the code clearer.

jiggawatts 5y ago
I get that, but the comment was specifically about pointers (not gotos or structure), and is interesting in general from a historical perspective. The "goto" keyword is similarly dangerous. I've seen very good arguments for leaving it out, and generally poor arguments for keeping it in a language. "I can use it safely" is not a good argument, because it's just like Jim Jefferies' standup routine linked above: "Why should I have my guns taken away from me?" An example of a good argument for structured programming is the talk "The Forgotten Art of Structured Programming - Kevlin Henney [C++ on Sea 2019]": https://www.youtube.com/watch?v=SFv8Wm2HdNM https://www.youtube.com/watch?v=SFv8Wm2HdNM Similarly, this article makes a very good argument that concurrent or async code is essentially the "goto spaghetti reinvented, but even worse", and that Structured Concurrency is the solution: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
- chrismorgan 5y ago
  > “I can use it safely” is not a good argument Rust could comparatively easily implement goto, and it’d be unconditionally safe (as regards memory safety). I’d even honestly like it to, mostly just because it’s possible rather than because it’d be useful—most prominent goto patterns can be expressed better in other ways in Rust, e.g. RAII (destructors) instead of goto cleanup, and break/continue let you emulate any structured uses of goto. (I live in hope that https://github.com/rust-lang/rust/issues/48594 https://github.com/rust-lang/rust/issues/48594 will one day land, so you can use break to skip the remainder of a labelled block, no loop required.)
  - afiori 5y ago
    I would also like continue to work that way, so that every (labelled) block can be freely looped and exited (with a value)
    - chrismorgan 5y ago
      I don’t think I’d want continue to work on a block. Repeating the block seems different from leaving the block early (which can already be done with return or with panicking). I think it’s better to need to write it as a loop before you can continue.
      - afiori 5y ago
        I completely agree, In rust looping has important semantics with regards to lifetimes and ownership so the continue part would be a bad idea. I think it would be cool in something like javascript (if blocks could return values...)
  - jiggawatts 5y ago
    Read the articles I linked. This is essentially impossible, because Rust has gained features that C doesn't have by giving up goto. Adding goto back in would require those features to be removed, or to be watered down dramatically. You wouldn't be able to goto into or out of most (all?) blocks that would change ownership, for example.
    - varajelle 5y ago
      Why not? C++ still has goto despite also having RTTI. One just need to restrict a bit where we can jump.
      - aix1 5y ago
        Do you mean RAII?
    - ByteJockey 5y ago
- inshadows 5y ago
  You haven't mentioned anything specific about dangerousness of goto. The fact that you heard some conclusion is irrelevant, unless you pass the reasoning behind it. If goto is dangerous, why isn't if statement dangerous. And about async code: Have fun writing bare metal code with that. Because, you know, your compiler will spit gotos anyway, and unlike gotos you write, you'll have little control over that.
mkcg 5y ago
goto statements are also very useful to parse, compress and uncompress data in the critical loop.
Spivak 5y ago
Basically all modern programming control flow paradigms are about finding all the safe patterns of goto and setjmp. Everyone agrees about loops, try catch for goto err; is near ubiquitous, defer and context managers are popular for goto cleanup;, throw is setjmp up the stack, coroutines are setjmp for multitasking.

This thread isn't about safety though. It's about readability (spaghetti code). IMHO gotos in C when used for for dealing with errors at the end of the function make the code clearer.

jiggawatts 5y ago

I get that, but the comment was specifically about pointers (not gotos or structure), and is interesting in general from a historical perspective. The "goto" keyword is similarly dangerous. I've seen very good arguments for leaving it out, and generally poor arguments for keeping it in a language. "I can use it safely" is not a good argument, because it's just like Jim Jefferies' standup routine linked above: "Why should I have my guns taken away from me?" An example of a good argument for structured programming is the talk "The Forgotten Art of Structured Programming - Kevlin Henney [C++ on Sea 2019]": https://www.youtube.com/watch?v=SFv8Wm2HdNM https://www.youtube.com/watch?v=SFv8Wm2HdNM Similarly, this article makes a very good argument that concurrent or async code is essentially the "goto spaghetti reinvented, but even worse", and that Structured Concurrency is the solution: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

chrismorgan 5y ago
> “I can use it safely” is not a good argument Rust could comparatively easily implement goto, and it’d be unconditionally safe (as regards memory safety). I’d even honestly like it to, mostly just because it’s possible rather than because it’d be useful—most prominent goto patterns can be expressed better in other ways in Rust, e.g. RAII (destructors) instead of goto cleanup, and break/continue let you emulate any structured uses of goto. (I live in hope that https://github.com/rust-lang/rust/issues/48594 https://github.com/rust-lang/rust/issues/48594 will one day land, so you can use break to skip the remainder of a labelled block, no loop required.)
- afiori 5y ago
  I would also like continue to work that way, so that every (labelled) block can be freely looped and exited (with a value)
  - chrismorgan 5y ago
    I don’t think I’d want continue to work on a block. Repeating the block seems different from leaving the block early (which can already be done with return or with panicking). I think it’s better to need to write it as a loop before you can continue.
    - afiori 5y ago
      I completely agree, In rust looping has important semantics with regards to lifetimes and ownership so the continue part would be a bad idea. I think it would be cool in something like javascript (if blocks could return values...)
- jiggawatts 5y ago
  Read the articles I linked. This is essentially impossible, because Rust has gained features that C doesn't have by giving up goto. Adding goto back in would require those features to be removed, or to be watered down dramatically. You wouldn't be able to goto into or out of most (all?) blocks that would change ownership, for example.
  - varajelle 5y ago
    Why not? C++ still has goto despite also having RTTI. One just need to restrict a bit where we can jump.
    - aix1 5y ago
      Do you mean RAII?
  - ByteJockey 5y ago
inshadows 5y ago
You haven't mentioned anything specific about dangerousness of goto. The fact that you heard some conclusion is irrelevant, unless you pass the reasoning behind it. If goto is dangerous, why isn't if statement dangerous. And about async code: Have fun writing bare metal code with that. Because, you know, your compiler will spit gotos anyway, and unlike gotos you write, you'll have little control over that.

mkcg 5y ago

goto statements are also very useful to parse, compress and uncompress data in the critical loop.

Spivak 5y ago

Basically all modern programming control flow paradigms are about finding all the safe patterns of goto and setjmp. Everyone agrees about loops, try catch for goto err; is near ubiquitous, defer and context managers are popular for goto cleanup;, throw is setjmp up the stack, coroutines are setjmp for multitasking.