labeled loops, labeled break, labeled continue

[thejoshwolfe]

EDIT: scroll to current proposal here: #346 (comment)

Proposal:

Remove the current goto and label constructs. Introduce two kinds of labels:

• Labeled loops, like in Java. e.g. label: while (..., label: for (...
  • You can break label and continue label, like in Java.
  • You cannot goto label for this kind of label.
• Labeled blocks. e.g. label: { ... }
  • Control flow must not "fallthrough" into or out of a labeled block.
  • You can goto label to enter the label.
  • We may want to allow label: return foo() or similar without a block, but this may be confusing when labeled loops are a distinct concept. You could always just do label: { return foo(); } anyway, so we probably don't need a blockless form.

I searched the Zig standard library as well as @andrewrk's tetris and clashos projects, and the only 3 uses of goto are effectively continues; one of them would need to be a labeled continue; the other two can be easily converted to status quo continues. I think those 3 pieces of code would be improved by this proposal.

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 goto by using labeled break and continue (see Java), but I think there are cases where it would be an abuse of the syntax to do so.

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 return from its function, which every usecase for labeled blocks I can think of would do.

The real-world usage of goto is pivotal to this proposal. I don't want to act on this proposal without more real-world data.

[andrewrk]

I added the ability for break to give an expression and loops now have an else (See #357). So this steers us in the direction of labeled loops.

[thejoshwolfe]

The proposed break label syntax clashes with the current break expression syntax. To disambiguate, we could do one of these:

1. break :label, break expression, break :label expression
2. break (expression), break label, break (expression) label

[andrewrk]

(1) looks good to me.

[PavelVozenilek]

There are several useful use cases for goto in C:

1. Clean implementation of finite state machines using macros and gotos. This probably doesn't apply to Zig.

2. Error handling for which defer would be not enough or would be clumsy (defers have to repeat their code or use named function). Example:

   ... 
   if (...) goto error1;
   ...
   if (...) goto error2;
   ...
   if (...) goto error1;
   ...
   error1:
    ... lot of code here
   error2:
    ... lot of code
   

   Here all error code
   (a) is put at function's end (one always knows where to look for it),
   (b) stays together (inconsistency is easier to spot) and
   (c) does not clutter the happy path (readability win).

3. Going from one code block to another inside a large function. Example:

    void nontrivial_function(void) { 
   
    phase1: 
    ...
    if (...) goto phase2;
    ...
    if (...) goto phase3;
    ...
   
    phase2:
    ... 
    if (...) goto phase4;
    ...
    if (...) goto phase3;
    ...
   
    phase3:
    ... etc
    }
   

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.

---

IMO goto should stay, probably restricted to "going down only", with style guidelines recommending clean use cases.

---

PS: GCC also has "computed goto" feature, which is used to implement fast interpreters (faster than those having big switch, thanks to better branch prediction).

[thejoshwolfe]

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.

GCC also has "computed goto" feature, which is used to implement fast interpreters

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 unreachable. Then an optimizer can safely let an out-of-bounds value cause undefined behavior, like the computed goto 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.

[andrewrk]

The only use of goto in zig compiler is here: https://github.com/zig-lang/zig/blob/master/src/c_tokenizer.cpp

I think it's just a labeled break from the for loop though.

I'll throw in 2 use cases for goto:

• Leaving goto in makes it easier to port C code to zig
• goto is useful if you're using zig as a target language for a compiler. This is one current use of C - compilers compile to C.

[andrewrk]

Here's another one: mixing inline assembly and zig.

If we had better inline assembly integration, we could have labels declared in assembly that we can use goto to jump into.

[andrewrk]

Here's another idea instead of labeled blocks.

We already have the feature that const foo = this; and now foo refers to a specific block of code.

Here's my proposal:

• Delete break.
• Remove the option to leave off semicolons in block statements.
• return now accepts an optional block argument like this: return :block expr or return :block. So you can return a value from any parent block. If the block argument is left off, it defaults to the block that is the function definition.
• If you want to break out of a loop, you better alias the loop block so you can return from it:

while (true) {
 const while_loop = this;
 return :while_loop;
}

Now we don't have this awkward choice for functions, do we use return or not? Yes, you have to use return to return a value.

[PavelVozenilek]

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.