Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
labeled loops, labeled break, labeled continue #346
EDIT: scroll to current proposal here: #346 (comment)
Remove the current goto and label constructs. Introduce two kinds of labels:
I searched the Zig standard library as well as @andrewrk's tetris and clashos projects, and the only 3 uses of
I think there's a legitimate usecase for labeled blocks, and I'd like to see if I can write some Zig code that needs them. My idea so far is some kind of tokenizer (XML parser perhaps?). It's always possible to avoid
My rationale for proposing that control flow must not fallthrough into or out of a labeled block is to prevent accidents. My idea of a labeled block is a piece of code that exists outside the normal control flow of the function that you want to be able to jump into and out of with special control flow. In this sense, it's a more like a function than like a ... whatever an arbitrary label in the middle of code is. An important difference from a function is that a labeled block can
The real-world usage of
referenced this issue
Apr 27, 2017
There are several useful use cases for
Here goto is more natural than other constructs. Using several named sub-functions to implement these blocks would decrease readability, especially if they need many parameters.
Large functions are not inherently bad, if they can be read (mostly) linearly.
PS: GCC also has "computed goto" feature, which is used to implement fast interpreters (faster than those having big
I think this discussion would benefit from real actual examples of using goto in actual code. It's easy enough to come up with pseudo code that demonstrates a desire for goto, but it may be the case that every real usecase for goto could be better implemented without it.
I'm still very open minded to this feature, but i think it's time to bring in real examples.
I read some details about this here: http://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables
Looks like the benefits come from two sources: skipping the bounds check on switch, and doing the jump in each case instead of jumping to a centralized dispatch instruction. Both of these optimizations are theoretically possible without computed goto in Zig, but achieving the same performance may require writing an optimization pass for llvm. I haven't done any research to see if this already works or not.
Skipping the bounds check can be enabled by making the default case
Putting the dispatch jump in each case isn't as obvious how to do, but this is equivalent to inlining something about the loop and switch. It's definitely possible that the right kind of compiler optimization could achieve this.
The only use of
I think it's just a labeled break from the for loop though.
I'll throw in 2 use cases for goto:
Here's another idea instead of labeled blocks.
We already have the feature that
Here's my proposal:
Now we don't have this awkward choice for functions, do we use
Ad computed goto - the only use I am aware is in Forth intepreters, where it usually claims large (tens of %) speedups. The speedup is due to better fit for the branch prediction mechamism, as I understand it. I personally never used it.
I use goto for error handling at the end of function, occasionally to jump down to a block. So far I avoided jumping up. I also used gotos hidden in macros to implement finite state machines (this results in ideal syntax).
I never had problems with break and continue. In fact I see the C syntax for control flow as almost perfect and would not recommend to remove anything.
Labeled break, perhaps, if only down. Return is IMO important visual clue. The proposal above (return instead of break) feels strange.
I just want to voice my agreement with @PavelVozenilek - that return syntax feels strange. In terms of readability, we are leveraging some of the fundamental constructs of C to make the language more familiar and accessible to users, it feels strange to remove break and change return so much.
The points about porting are also very legitimate, in order to replace C, we must first replace it =P
Goto is used in visual novels all the time. You rarely need to go back when reading a book, you only go forward. Functions return back, goto doesn't.
You guys are making life harder for yourself for no good reason.
Also, goto is good for error handling. It's used in linux kernel for that quite often. Defer seems to partially replace that usage, but I'm not sure if it can replace goto completely. It's also sometimes used to give a function two different exits.
Another example here, http://ollydbg.de/ , Disasm.zip , assembl.c . I don't quite understand what exactly this code does, but I think it's useful here.
Goto is a good lightweight replacement for exceptions, but using it for that is complicated. Need to make sure you don't have anything important on stack (no destructors), need to store correct stack pointer somewhere (to free a lot of stack space at once). If you goto inside a function, it's much easier, because the difference in stack before and after goto is always constant.
Exceptions are good for avoiding a lot of conditional branches in the program and annoying checks, it must be affecting both program speed and program complexity. It's especially good for file parsing, when something can go wrong at literally any moment. They are pretty much multi-function gotos.
Also read this #578. I think I need exceptions after all. Just don't need to abuse them.