[Proposal]: Labeled break and continue Statements

[CyrusNajmabadi]

Labeled break and continue Statements

• Specification: https://github.com/dotnet/csharplang/blob/main/proposals/labeled-break-continue.md
• Issue: [Proposal]: Labeled break and continue Statements #9875

Summary

Allow break and continue statements to optionally specify a label that identifies which loop or switch
statement to target, enabling cleaner control flow in nested constructs without requiring goto statements.

For example:

```csharp
outer: for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        if (ShouldSkipRest(x, y))
            continue outer;
        
        if (ShouldExitAll(x, y))
            break outer;
    }
}

Note: the label (outer:) is itself not special or new. It is the existing labeled-statement already present in the language. All that changes is that when these label loops (and switch), then the loop/switch is now able to be the target of a continue x;/break x; statement, instead of those targeting the immediately inner construct.

[jez9999]

The proposal looks good to me. I strongly support it. One could possibly consider an even more flexible mechanism allowing break label to break out of any labeled block but in practice restricting it to loops is probably fine.

@CyrusNajmabadi Your current code examples always have the label on the same line as the for; presumably it could be on a separate line above? Perhaps it's worth adding such an example for clarity.

[CyrusNajmabadi]

Labels don't change with my proposal. They are the same as always. (So they can be on the same line or before). The whitespace doesn't matter.

[LWChris]

As stated in the discussion that was closed:

I want to be able to label loops and switch to allow for "cleaner control flow in nested constructs without requiring goto statements".

But I'm not sure I like that adding a label to allow continue or break also enables goto, and (less importantly) an existing label which coincidentally was right before a loop will now look like I intended to continue or break from an inner loop.

I'd rather have separate syntax so that I can clearly see if a label is for goto or continue and break. Even if all three are "control flow", I still feel "goto" is fundamentally different from at least "continue".

My favorite would be:

restart:
for outer: (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        if (ShouldSkipRest(x, y))
            continue outer;
        
        if (ShouldExitAll(x, y))
            break outer;
            
        if (ShouldStartFromScratch())
            goto restart;
    }
}

where continue restart as well as goto outer are both invalid statements.

But if this is a non-issue to everybody else, I'm happy to swallow my syntax concerns if that means we get the feature, which I strongly support.

[CyrusNajmabadi]

I don't really see a problem where the same label can be used to restart/continue/break the loop. Seems fine, where the jump statement dictates what you want.

This also then just continues(no pun intended) to work for all constructs. Instead of needing a separate syntax for switch/for/foreach/do/while.

[LWChris]

Yeah, I guess... basically one label now identifies three places to jump to:

    M1();
outer:
//  > goto outer;
    for (int x = 0; x < xMax; x++)
    {
        for (int y = 0; y < yMax; y++)
        {
            if (ShouldSkipRest(x, y))
                continue outer;
            
            if (ShouldExitAll(x, y))
                break outer;
                
            if (ShouldStartFromScratch())
                goto outer;
        }
//      > continue outer;
    }
//  > break outer;
    M2();

Still not 100% convinced whether I feel this is good or bad, but I'd rather have a label that allows goto even if I don't want to use that, than have no easy way to control the flow at all.

[huoyaoyuan]

I'm somehow concerned about the position of the label. The syntax is currently valid and the label is placed before the start of the loop. goto label would also be valid, with a different target.

[CyrusNajmabadi]

That's a virtue for me. The label identifies the loop. The control flow construct specifies which behavior you want. All three behaviors are supported.

[SirDragonClaw]

It feels so weird seeing this be proposed again. I was the original proposer of this feature almost a decade ago, wild to think that we still don't have some form of it after all this time.

Anyway I still support this, though would like the ability to break with a number in addition to label, like my original proposition. But I understand the downsides of that particular implementation.

[Rekkonnect]

Yeah not sure why the original discussion #5525 was not mentioned anywhere in this proposal, we have definitely been having this open for a while

[CyrusNajmabadi]

I mentioned it explicitly in the specification

[Rekkonnect]

Oh I see now it's under the Details section; I think we should move it out since it's very easy to miss

[CyrusNajmabadi]

We have many prior issues on this. Like with prior work, we link to it. I'm not sure why more needs to happen. People can get to this discussion from those issues, and the spec can be used if people need to get to those too.

[stevehjohn]

I quite liked the suggestion of:

for (outer: var y = 0; y < 10; y++)
{
    for (inner: var x = 0; x < 10; x++)
    {
        if (condition)
        {
            continue outer;
        }
    }
}

// Or

foreach (outer var item in items)
{
    // ...
}

This makes it distinct from goto labels. For some reason, I just find labels in code aesthetically unappealing.

[Rekkonnect]

I think we could get out of the label: syntax by introducing a new label declaration syntax like $label or `label

• label: - not a fan of because it comes from C which didn't use : in many more places and was relatively unambiguously parsable
• $label - conflicts with other languages' way of declaring variables by using the $ (slightly unimportant), with @label already being a valid identifier declaration, $label would read as the full name of the label could include the $ sigil because it's also visually bulky
• `label - conflicts with the proposal of having `-delimited strings, but otherwise probably one of the best options

So if we picked `label as the alternative label syntax, we could declare them as such:

`outer
for (var y = 0; y < 10; y++)
{
    `inner
    for (var x = 0; x < 10; x++)
    {
    }
}

Getting rid of the un-indentation that the label: syntax is known for can help in this case

Another thing for the alternative label syntax is that we could impose extra rules saying for instance that they are declared on structures (ifs, loops, blocks, etc.), but not on arbitrary statements, and cannot be used with goto, but only on break and continue statements.

[jez9999]

It's hard enough to get new stuff into C# without proposing another label syntax in addition to the labeled loops. There's already a label syntax in C# so this seems like it's adding unnecessary extra stuff to be honest.

[CyrusNajmabadi]

Agreed. We have a label syntax. Why do we need a different one?

[stevehjohn]

Whatever syntax is chosen, I think it's a good feature. I often need to break/continue nested loops (for work code and AoC fun code). Using a bool is boilerplate, and gotos have been hammered into my head as bad.

for (outer: var y = 0; y < 10; y++)
{
    var skip = false;
    
    for (inner: var x = 0; x < 10; x++)
    {
        if (condition)
        {
            skip = true;
        
            break;
        }

        // Whatever processing you are doing
    }
        
    if (skip)
    {
        continue;
    }
    
    // The code you wanted to skip.
}

Becomes:

for (outer: var y = 0; y < 10; y++)
{
    for (inner: var x = 0; x < 10; x++)
    {
        if (condition)
        {
            continue outer;
        }

        // Whatever processing you are doing
    }
    
    // The code you wanted to skip.
}

[jnm2]

Side note: I see "I've been told gotos are bad" stated a few times now with the implication that it will continue to hold weight. The awareness that it's "just something you've been told" is clarity. Isn't that awareness enough to unblock the use of gotos?

[HaloFour]

Stemming from a paper written before most programming languages we know even existed: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

[En3Tho]

I don't really see why C# should have a dedicated feature for a rare specific case that is really no better than goto (which very general and versatile).

And the only motivation is a weird belief based on a 50 years old statement which was made in a drastically different programming environment.

Just do an official statement that "goto is not considered harmful" and it's useful for cases exactly like this (and some other rare clever control flow tricks). Job done.

[Rekkonnect]

in the exactly same way "if" statement is

Not even close. The if statement actually encodes two additional pieces of information:

• A condition that must be met to enter the block, otherwise resulting in a "jump" to the code after the block closes (note that we don't even use labels there)
• A sequence of statements that is grouped so it runs if the condition is met, nicely enclosed without ambiguities or shared code paths

Jumps are a critical feature of programs, much like how functions, exceptions and other features correlate. Most of the time those jumps are conditional (if) or require a sequence of extra steps before/after the jump (function calls). goto in this case is simply a jump, where instead of an arbitrary location in the program's memory, you have a label with some few rules around what locations are legal to jump to. While not 100% similar to a jump, it's the closest any jump-related language feature.

It solves few rare cases (nested loops is one of them) and it is perfectly fine to use.

We shouldn't need to justify goto's existence. The feature of labelled break and continue has naturally occurred as an extension to an existing set of control statements; we're not introducing comefrom or some other absurd replacement/alternative. And I say replacement because goto should really be avoided unless the language doesn't cover your case.

In my opinion, goto not being needed is a net positive for every language that pulls it through. Java can already do without it just right, and in fact they have had labelled break for a long time, thus not having many reasons to need goto, if any. This is not to say that we must copy Java, but that they have succeeded in this way and it proves a point, that goto is replaceable.

Right now, and until labelled control statements reach preview, I will still prefer goto to break outer loops. Relying on those flag variables stopped appealing to me after I decided not to be ultra-idealistic in my style of programming. But nothing would stop me from using break outer; because it really conveys the message "I want to break my outer loop, without caring about the code before or after it". The current way to approach break outer is by putting a label right after the loop ends, which may or may not include extra code (and when it's the end of the block you really have to also place an empty statement just to use a label). If you're breaking out of an outer loop that's the end of the method, you could use return (expr) instead of break outer, but that introduces its own set of maintenability problems that I hope are easy to imagine.

[Rekkonnect]

So that anti-goto zealots won't go like "WHAT IF SOMEBODY JUMPS THERE?"

I could just write an analyzer that emits an error saying "gOtO bAD rEMovE NoW", in the same fashion the Java goto works

[CyrusNajmabadi]

So that anti-goto zealots won't go like "WHAT IF SOMEBODY JUMPS THERE?"

I'm really not interested with designing with that in mind. We think goto is fine. We think continue/break are fine. We think labels are fine. This is just naturally making them work together better in (imo) an intuitive fashion.

If someone doesn't want to use this because it feels too close to goto for them, and they don't like that, that's this own choice.

[LWChris]

For me, the beauty of statements like continue loop_name; and break loop_name; is that they are very expressive.
The keywords continue and break are well-known concepts within loops, and they already do half the work of conveying what's going to happen.

By contrast, the keyword goto in itself is rather unspecific. It's just an instruction to jump to "somewhere". It depends on the label placement whether that jump is equivalent to any well-known flow control concept.

In the best case, the label can carry that meaning, as in goto continue_loop_name; and goto break_loop_name;. But deriving from the label name that goto is used to emulate a continue is just that one tiny step more convoluted than being able to simply use the continue keyword itself.

[jnm2]

Goto can be absolutely harmless, but it always fails to express the "why" it's being used.

@Rekkonnect The amount of "why" that is contained in the existing keywords break or continue is an amount of "why" which can be expressed in a goto label name.

[Zodt]

I have read the specification and the comments in this discussion, and I see several possible ways to implement such a named-loop mechanism.

1. Classic prefix label (label:)

Description

The label is specified as a separate syntactic construct placed before the loop statement, similar to existing labels in C# used with goto.

Example

outer: for (var y = 0; y < 10; y++)
{
    inner: for (var x = 0; x < 10; x++)
    {
        if (condition)
        {
            continue outer;
        }
    }
}

---

2. Label as part of the loop keyword (for outer (...))

Description

The label name is specified immediately after the loop keyword.

Example

for outer (var y = 0; y < 10; y++)
{
    for inner (var x = 0; x < 10; x++)
    {
        if (condition)
        {
            continue outer;
        }
    }
}

---

3. Label inside the loop header parentheses

Description

The label is declared inside the loop’s parentheses, syntactically resembling named arguments or pattern constructs.

Example

for (outer: var y = 0; y < 10; y++)
{
    for (inner: var x = 0; x < 10; x++)
    {
        if (condition)
        {
            continue outer;
        }
    }
}

---

4. Postfix label using as label

Description

The label is specified after the loop header using the as keyword, which can be interpreted logically as “this loop is known as …”. The label becomes part of the loop’s own syntax rather than an external control-flow construct.

Example

for (var y = 0; y < 10; y++) as outer
{
    for (var x = 0; x < 10; x++) as inner
    {
        if (condition)
        {
            continue outer;
        }
    }
}

Similarly for other loops:

foreach (var y in items) as outer { ... }
while (condition) as outer { ... }

For do-while:

do
{
    ...
} while (condition) as outer;

---

Comparative analysis of the approaches

Consistency with the language specification

• label:
  Historically intended for use with goto. Extending its semantics strengthens the association with explicit control-flow jumps, which C# has intentionally moved away from.

• for outer (...)
  Introduces a new syntactic pattern that does not exist elsewhere in the language: an identifier appearing immediately after a statement keyword.

• (outer: ...)
  Conflicts with existing uses of : in the language (named arguments, patterns, switch labels).

• as label
  Naturally extends the existing use of as as a declarative qualifier and does not conflict with current language constructs.

---

Semantic model

Using as label makes the label a property of the loop statement itself, rather than a separate statement. This simplifies:

• scope definition
• name resolution rules
• compile-time diagnostics

---

Grammar changes

To support named loops using the as label syntax, only minimal and localized extensions to the grammar of loop statements are required.

for

for_statement
    : 'for' '(' for_initializer? ';' for_condition? ';' for_iterator? ')'
      loop_label?
      embedded_statement
    ;

foreach

foreach_statement
    : 'foreach' '(' local_variable_type identifier 'in' expression ')'
      loop_label?
      embedded_statement
    ;

while

while_statement
    : 'while' '(' expression ')'
      loop_label?
      embedded_statement
    ;

do-while

do_statement
    : 'do'
      embedded_statement
      'while' '(' expression ')'
      loop_label?
      ';'
    ;

loop_label
    : 'as' identifier
    ;

---

break and continue

break_statement
    : 'break' identifier? ';'
    ;

continue_statement
    : 'continue' identifier? ';'
    ;

---

In conclusion, from the perspective of minimal grammar changes, readability and locality, absence of conflicts with existing constructs, and a clear semantic model, the as label approach appears to be the most natural fit for the language, in my opinion.

[stevehjohn]

I got confused. I stupidly did't realise it referred to switch statements within a loop. Because break is part of switch syntax my brain went wha?

[jnm2]

The second formatting for labeled loops is easier for me to read than the version that pushes the loops further down the line with an arbitrary name starting off the line.

[LWChris]

The only reason I don't quite like it is because ... would be formatted as

That is not the case. You could format this however you want.

Provided Visual Studio will go so far to add this to
Tools → Options... → Text Editor → C# → Formatting → Indentation → Label Indentation

Currently, this has 3 options:

• Place goto labels in leftmost column
• Place goto labels one indent less than current
• Indent labels normally

We would need to be able to differentiate between "goto labels" and "loop/switch labels" and have them behave differently - which might be difficult if "goto labels" and "loop/switch labels" are the same? That's where I was coming from. If you say it can and will be distinguishable for sake of defining different indentation formatting rules, then I'm happy.

[CyrusNajmabadi]

If you say it can and will be distinguishable for sake of defining different indentation formatting rules, then I'm happy.

If there is demand for this different label style, we'll add it. I don't see any problem adding that.

[LWChris]

I don't see any problem adding that.

Okay. I was just worried that if loop and switch labels are essentially nothing but strategically placed goto labels, the formatter might not be able to tell them apart because all are (also) goto labels by definition.

Roslyn must obviously know the difference between a normal label (only goto), a switch label (only goto and break), and a loop label (goto, break and continue); if the formatter has the same information, all is well.

[mattwar]

I like it. Now do it for switch too.

[Rekkonnect]

Allow break and continue statements to optionally specify a label that identifies which loop or switch

Switch is also included in the supported constructs

[sator-imaging]

how about breaking switch case?

using System;

switch (1)
{
    case 0:
        goto case 1;  // valid

    case 1:
        Console.WriteLine("🌄");
        break;

    case 2:
        for(;;)
        {
            do
            {
                while (true)
                {
                    break case 2;  // breaking switch case by break '...';
                }
            }
            while (true);
        }
        break;
}

[CyrusNajmabadi]

this is solved by having a label for the switch, and breaking that label.

[The-Futurist]

@CyrusNajmabadi - One could also consider extending this to if statements. Here's what I mean:

MAINIF:
if (cond1)
{
   // stuff
   if (cond2)
   {
      // stuff
      if (cond3)
         // stuff
      else
         break MAINIF;
   }
}

You get the idea, there are ways to avoid the need for this, but it might be worth considering...

[Rekkonnect]

What different meaning besides the one you mentioned would be carried?

Not breaking a loop, but exiting a construct. In all 4 loops that it's legal to exit now (for, foreach, while, do-while), you're breaking a loop.

Mid-typing the above I realized there is also switch. Which is also semantically equivalent to breaking the current construct, not breaking a loop. So if would not carry much of a different meaning than switch.

That being said, we want to avoid breaking all the existing code and hindering developer experience in every break by effectively mandating the labelling of the construct being broken, because 99% of the time it's not about breaking an if. Allowing breaking a labelled if would cause no usability downsides, we're only considering a possible inconsistency matter. Even if if statements cannot be targets for continue, such is the case with switch. And right now, it's perfectly legal to goto a label that is placed right on the construct, both for if and switch. So enabling labelling if statements to break would be more in line with how switch would behave, barring the ability to break out of an if statement without labelling it.

On the other hand I also thought of the possibility of specifying break block or some equivalent syntax to specify the intent of breaking out of the current block. This would be more largely supported because blocks are very commonly available and would not require specially-treating every other block like if (e.g. lock, using, fixed). That way the user can just break out of a block, and possibly allow labelling a block which can be broken wtih a syntax like break block <label>.

[CyrusNajmabadi]

Besides using goto to jump outside of it?

This is the way. There is already a singular way to do this.

The reason for this proposal is that for the other constructs it unifies 3 jump targets into one label.

That's not the case with if. There is only one jump target. So no need for this. (Which is also why if is not breakable in the first place).

[Rekkonnect]

Which is also why if is not breakable in the first place

Why is switch breakable then?

[CyrusNajmabadi]

Allowing breaking a labelled if would cause no usability downsides, we're only considering a possible inconsistency matter.

Inconsistency is a usability downside.

Why is switch breakable then?

Because there's is no 'restartable switch' that you would use instead. Wheras there is a restartable if (that's just a while loop).

We don't need breakable/continuable ifs because we already have a direct language construct for that. The same isn't true for switch.

C# also opted for explicit control flow for switch to make it clear to people that fallthrough isn't happening (unless you have directly abutting cases). So you need to include a break to satisfy that explicitness. That isn't a concern with if/else as there is no fallthrough expectation/confusion.

[LWChris]

Why is switch breakable then?

Because you need to be able to differentiate between

switch (day)
{
    case DayOfWeek.Saturday:
        break;
    case DayOfWeek.Sunday:
        ...
}

and

switch (day)
{
    case DayOfWeek.Saturday:
    case DayOfWeek.Sunday:
        ...
}

Also it is much clearer if you are forced to declare your intent:

switch (x)
{
    case > 1:
        A();
    case > 0:
        B();
}

Is B() executed for x = 2? Since C# enforces the break for case > 1, there is no doubt what will happen.

[GeeLaw]

What's intended for the following?

   a: b: while (true) break a;
// 1  2  3            4

By the parsing rules, ([..., ...] is interval notation)

• [1, 4] is a labeled_statement, whose identifier is a and whose statement is [2, 4].
• [2, 4] is a labeled_statement, whose identifier is b and whose statement is [3, 4].
• [3, 4] is a while_statement.

The text says

For break statements, the labeled statement must be one of:

The "labeled statement" can be read as the statement of the labeled_statement. Under this interpretation, the code fails to compile.

If the intention is for it to fail compiling, the current text is fine. (Is re-nesting labels done during refactoring? I don't know.)

If the intention is for it to compile, the current text should be edited to clarify the meaning of "labeled statement" to recursively reach for statement until that statement is not a labeled_statement.

[CyrusNajmabadi]

What's intended for the following?

It would not compile as the label doesn't label a switch/loop.

[RikkiGibson]

FWIW, when I encounter this situation today, I don't use a goto or a flag, I just extract the nested statements to local function.

ResultType? result = null;
foreach (var x in coll1)
{
    foreach (var y in coll2)
    {
        result = Find(x, y);
        if (result != null)
        {
            // Want to break out of all of this and use the result.
        }
    }
}

Use(result);

If there's a certain spot after those nested constructs I want to get to, I can simply return to it. Nothing scary.

// Extract a local function:
var result = Search();
Use(result);

ResultType? Search()
{
    foreach (var x in coll1)
    {
        foreach (var y in coll2)
        {
            result = Find(x, y);
            if (result != null)
                return result;
        }
    }

    return null;
}

Since capture in local functions tends to be pretty efficient and seamless, making such a change doesn't usually require refactoring the code very much. It also has a natural tendency to prevent methods from getting too sprawling with nested conditional constructs which we are jumping out of relatively complex ways.

[stevehjohn]

That works perfectly well, but (just my own opionin), I find local functions really jarring. Dunno why, maybe just aesthetics. You could also move it out to a method, but it all seems to be adding boilerplate TBH.

[CyrusNajmabadi]

I too use local functions in cases like this. But primarily as a undesired workaround some of the time. I def agree when things get unwieldy that they're a good option. But for simple two-nested loops, it often feels like overkill.

[LWChris]

I use local and static functions a lot. Sometimes to give complex lambdas a telling name, but sometimes the sole reason is really that return is the break all for a nested loop C# doesn't have (hopefully: yet).

[teo-tsirpanis]

I wonder what do you think about repeating the break keyword:

for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        if (ShouldSkipRest(x, y))
            break continue; // continue continue; would not be accurate because we are breaking from the inner loop and continue the outer.
        
        if (ShouldExitAll(x, y))
            break break;
    }
}

To break or continue a triply nested loop you would write break break break; and break break continue; respectively. One advantage is that you don't have to label the loops.

[stevehjohn]

I think that's the same as the break x concept where x is the number of nesting levels to break out from. I recall that being dismissed as brittle.

[CyrusNajmabadi]

Ldm has approved this feature. I've started on the impl and hope to get it into the upcoming version of c#.

[stevehjohn]

Awesome.