Comment by bluecalm
4 days ago
Looking at my own code one case I wouldn't get with defer and better switch is avoiding a flag pattern.
For example when you iterate over a block and check if positions are 0 (+ do some work) and once you encounter a non zero you jump to a different "non-empty" section but if it's zeros to the end you jump over non-empty to go to end section. Without goto you need to set a flag and add another conditional there.
Other than that what you mentioned: flatting the if structure is nice. When you have a few simple cases and then a complicated one and a finishing session at the end it's just cleaner and easier to read with goto. It could be handled with a switch statement but not everything is "switchable" and the way most people write it it's another 2 indentation levels (1 with a convention of not indenting cases but I see C3 docs avoid it).
I get it's rare but goto (other than error handling) is rare and I don't think people have a tendency to abuse it. If anything people abuse "structured" construct building an arrow pattern with multiple indentation levels for no good reason.
That's the kind of thing I was thinking about. You can solve that with a switch in C3, but it's not as nice. However, this accounts for no more than 1% of all my goto uses (from a quick inspection), which is too little to build a feature from (discipline is needed to prevent a language from ballooning, it's hard to say no). I am looking for some use for it that can redeem its inclusion.
I agree it's very rare. I have this goto. A few that go to common return block that can be handled by other means and the rest is either error handling or things handled by labelled break or switch.
I mean we know you can program without it and defer/labelled switch and labelled break/continue cover 99%+ of use cases of it. I am still not convinced those are in fact easier to read but I get it's a reasonable design choice to make.
They have different wins. I think labelled break/continue help because they are clearer in locally expressing what the point is. If you see `goto NEXT;` you can kind of guess the intention, but `continue OUTER;` doesn't require you to read the code at the label and check what's happening there. `defer catch` and `defer try` helps avoiding some booleans otherwise needed with just a basic defer. `defer` on its own otherwise sometimes needs booleans to track what should be closed. With goto those naturally go to different cleanup sections.
I keep revisiting goto though. I like it a lot for its simplicity.