On Thu, Sep 08, 2022 at 08:39:30PM +0000, Dukc via Digitalmars-d wrote:
> On Thursday, 8 September 2022 at 16:33:58 UTC, AnimusPEXUS wrote:
> > There was a discussion sometime ago in a Russian Dlang Telegram chat about 'goto' keyword. And there was some empiric theory, stating 'all good languages support goto statement'. Nor Rust, nor Carbon, nor Zig will never going to overcome D or C++ because of this. Language should give possibilities, not take them away. And in some cases, goto able to make code more readable, more sane and more understandable. Also, goto is much safer in language with GC.
> > 
> > [corresponding section in
> > wikipedia](https://en.wikipedia.org/wiki/Goto#Criticism)
> 
> My personal attitude to `goto` is that it's overhated. While it's true that conditional and loop statements are mostly better, an occasional `goto` is not necessarily a code smell. Also I'd be much more worried about mutable `static`/global variables and oversized functions/types than a few needless `goto`s in a module.
> 
> I suspect it's bad reputation is from the times when some (non-assembly) languages did not have structured programming and everything was done with `goto`s. Going back to that sure would suck, but there's quite a difference between an occasional `goto` and replacing all your loops with it.
[...]

Also keep in mind that `goto` in modern-day languages is a very different thing from `goto` in the old days.  In the old days, it was the equivalent of a `jmp` instruction in assembly language; it could literally jump *anywhere* in the program, including jump from the middle of function A into the middle of function B where B isn't even on the call stack. It would skip variable cleanups and initializations, stack adjustments, etc., and generally produce *really* unreadable code. (See, for example, GOTO in old versions of BASIC, that lets you jump to any arbitrary line in your program.) It's even more powerful (and dangerous) than C's longjmp(), because the destination of the goto doesn't even have to be on the call stack or anywhere near where the history of execution has passed.

The `goto` of today's languages is a much safer, de-fanged version of the original goto. In D, for example, you cannot `goto` out of a function (or into another). The compiler also doesn't let you skip variable initializations / destructions. So it's subject to pretty much the same constraints as "structured" constructs like if, while, for, switch, etc., except it's more low-level and can do a few more things that the other constructs can't do.

So yes, you can overuse `goto` in your function and make it hard to follow, but then nested if-else blocks and loops that span 5000 lines are also hard to read[1], so it's not saying very much.  And today's goto is nowhere near as wild as the original `goto` in the old days.

[1] I'm not making this up, I've actually seen 5000+ line functions in real-world "enterprise" code. They are one of those things you wish you never have to debug, because you just can't fully understand what they do, goto or not.


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com

On Thu, Sep 08, 2022 at 09:30:06PM +0000, Dukc via Digitalmars-d wrote:
> On Thursday, 8 September 2022 at 21:03:04 UTC, H. S. Teoh wrote:
> > The `goto` of today's languages is a much safer, de-fanged version of the original goto. In D, for example, you cannot `goto` out of a function (or into another). The compiler also doesn't let you skip variable initializations / destructions. So it's subject to pretty much the same constraints as "structured" constructs like if, while, for, switch, etc., except it's more low-level and can do a few more things that the other constructs can't do.
> 
> Well if I really wanted to I could do it in 60s style by putting
> everything inside a giant `switch(callStack.pop)` in `main()`.
> "functions" would be just `goto` labels, called like this:
> 
> ```D
> callStack.push(something);
> goto function;
> case something:
> ```
> 
> ...with a jump to the switch at end of each "function" body.

Still can't get around variable initializations / destructions. ;-)

Plus, if your code ever interacts with mine, it would not be able to willy-nilly goto into my function, no matter what other atrocities it's committing inside main().  In 60s style code, you'd just `lea` to get the address of the target function, perform pointer arithmetic, and `jmp` to the destination, whether or not the callee wants to be called that way or not. :-D  Fortunately, such nonsense is blocked at the language level.


> So `goto` does technically have as long fangs as always :D. Of course, modern languages do a good job encouraging better coding habits.

Well, that's kinda an unfair way to look at it. I mean, if I *really* wanted to write code like the above, I don't even need `goto`; it suffices to just write something like this:

	void main() {
		int state = 1;
		int globalVar;
		switch (state) {
			case 1:
				doSomething();
				globalVar++;
				state = 5;
				break;
			case 2:
				doSomethingElse();
				globalVar--;
				state = 3;
				break;
			case 3:
				doYetSomethingElse();
				globalVar += 2;
				state = 6;
				break;
			case 4:
				blahblahblah();
				globalVar -= 2;
				state = 1;
				break;
			case 5:
				andSoOn();
				globalVar *= 2;
				state = 2;
				break;
			case 6:
				justForKicks();
				globalVar /= 3;
				state = uniform(1, 7);
				break;
		}
	}

I mean, I could write an assembly language emulator in main(), and write the worst possible random-jump-ridden, self-mutating virus code that main() would execute, but that doesn't mean D is inherently bad because it's possible to do so.


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall

To be fair, nested functions along with function inlining has eliminated many of the reasons that I use gotos.

Another reason for gotos is for ways of exiting loops without having to set flags that later control the flow.

goto can be handy to avoid needing to refactor a bunch of code when fixing a problem.

The refactoring can come later in its own PR.