An elegant way to continue/break nested loops.

[stevehjohn]

Hi,

I've been thinking of ways to continue or break nested loops without using a flag or goto.

I was thinking of something like this:

for (var a = 0; a < 10; a++)
{
    for (var b = 0; b < 10; b++)
    {
        if (condition)
        {
            // Breaks out of the entire nested loops
            break a;
        }
        
        if (condition)
        {
            // Starts a new iteration of loop a
            continue a;
        }

        if (condition)
        {
            // Breaks out of loop b
            break b;
        }

        if (condition)
        {
            // Starts a new iteration of loop b
            continue b;
        }

        if (condition)
        {
            // As exists, breaks out of loop b
            break;
        }

        if (condition)
        {
            // As exists, starts a new iteration of loop b
            continue b;
        }

        // Code you want to skip
    }
}

For iterators you could use the enumerated variable name:

foreach (item in items)
{
    foreach (subItem in subItems)
    {
        if (condition)
        {
            break items;
        }
    }
}

I think this is fairly elegant.

Regards,

Steve.

[zms9110750]

if you use var name. then while , for ( ; ; ) for( int a,b ,c ;;) ?

[stevehjohn]

Good point.

I'd say for (;;) unsupported, for (int a, b, c), any of the variable names.

[zms9110750]

If so, I think he is not elegant.
In my opinion, it's better to break 2

[stevehjohn]

I did think of that initially. I think labels are clearer. Maybe both syntaxes? You can use a number if there is nothing named to use.

[The-Futurist]

If so, I think he is not elegant. In my opinion, it's better to break 2

This has come up before, as someone pointed out though, adding an additional loop could render all those break 2 and continue 1 utterly devastating.

[En3Tho]

What about var x, = 0, y = 0 in the loop?
Or foreach var item in foo.Items
Etc?

I think you'd want to label loops explicitly and not rely on patterns like these because they will break right and left.

But labeling loops explicitly isn't really that much different that goto. And it solves only 1 rare case (complex nested loop) which doesn't really make it compelling as a new language feature.

[HaloFour]

If something were to happen here I still much prefer Java's approach of putting a label on the loop which you can then use with break or continue:

outerLoop: for (int x = 0; x < 10; x++) {
    innerLoop: for (int y = 0; y < 10; y++) {

        continue innerLoop;
        break outerLoop;
    }
}

[CyrusNajmabadi]

but it won't fly here.

Why would it not fly here?

[The-Futurist]

but it won't fly here.

Why would it not fly here?

I can't imagine anyone would champion such a change.

[CyrusNajmabadi]

I can't imagine anyone would champion such a change.

I can def imagine that. We already have ways to jump to labels. Updating our other jump constructs to handle labels is something def possible.

[The-Futurist]

I can't imagine anyone would champion such a change.

I can def imagine that. We already have ways to jump to labels. Updating our other jump constructs to handle labels is something def possible.

My remarks pertain to the suggested syntax:

for (row: var y = 0; y < 10; y++)

I cant imagine anyone championing that but if you wan't to, I'm all for it.

[CyrusNajmabadi]

Personally, i think it would make much more sense to just allow:

for (var y = 0; y < 10; row: y++)

Then, you don't even need to do anything special in the body. You just keep using goto row; continue; is just shorthand for having that be an implicit label.

Having the label on the for-statement (or loop) also works, because then continue/break make sense you're continu[ing]/break[ing] from that construct.

Having the label on the declarator is less clear (imo) since you're not really executing that again.

Note: i have no issue with a label on the loop, and then having goto/continue/break all able to refer to it. It has very clear semantics to me. If you have:

label: someLoop { }

Then:

1. goto label takes you to the label (just like always) and starts the loop.
2. continue label is equivalent to continue except that instead of continuing the containing loop, it continues the labeled loop.
3. break label is equivalent to break except that instead of breaking the containing loop, it breaks the labeled loop.

[jnm2]

I think this is really clever. It avoids cluttering code with an additional label, while just lighting up a feature that looks intuitive to me. One downside of the suggested alternative:

someLabel: for (var i = 0; i < 10; i++)
{
    switch (xyz)
    {
        case Xyz:
            break someLabel;
    }
}

...is that goto someLabel; is already valid code today and would have to remain valid, and then there would be an opportunity to be mixed up between either break someLabel; or continue someLabel; and goto someLabel;.

There are of course odd edge cases where the loop declares multiple variables or no variables, but the feature could be simply unavailable in those very rare cases. Less rare might be foreach (var (x, y) in list) and then maybe break (x, y); could work, or again the feature could be unavailable unless you refactor.

[koszeggy]

I've not seen much production code with labels, let alone many in the same method.

What about the .NET Runtime?

[jnm2]

The .NET runtime is under special constraints and practices that aren't likely representative of the majority of C# language use.

[koszeggy]

The .NET runtime is under special constraints and practices that aren't likely representative of the majority of C# language use.

Did I say otherwise?

[jnm2]

Your reply was to a person who was making a higher level point, so it is not clear whether you were also tracking along with the higher level point. The point was that it seems rare enough in production code to name labels the same as identifiers that it would not hamper the suggested feature.

[The-Futurist]

I've not seen much production code with labels, let alone many in the same method.

No doubt because they (non case labels) have very limited (goto and nothing else) application currently, the loop stuff would change all that.

[LWChris]

I'm completely against implicitly naming loops with numbers determined by its loop nesting level, because that's very brittle and I can see it become confusing because the loop level is not related to the nesting level:

foreach (var x in xs)
{
    foreach (var y in ys)
    {
        foreach (var z in zs)
        {
            continue 3;
        }
    }

    if (condition)
    {
        foreach (var z in zs)
        {
            continue 2; // you could easily think this continues "y"
        }
    }
}

So I lean heavily towards explicit names. But since someName: at the start of a line is already the valid syntax for a goto-label, wouldn't "loop labels" and "goto labels" necessarily have to be equivalent if the loop labels were in front of the for etc.?

I can already write this:

startOver:
for (var s = 0; s < sources.Count; ++s)
{
    var source = sources[s];
    for (var e = 0; e < source.Entries.Count; ++e)
    {
        var entry = source.Entries[e];
        if (concurrentModificationWasDetected)
        {
            // Restart from scratch
            goto startOver;
        }
    }
}

This would have to continue to work, so we cannot disallow "goto" for loop labels, and I'm not sure if I like that loop labels would inevitably have to double as goto labels and vice versa.

Therefore I'd prefer a loop label syntax that is distinct from the goto label syntax, so that a goto label cannot be used with continue and a loop label cannot be used with goto.

Something like these (sorted from most to least preferred by me):

for rows: (var r = 0; r < 10; ++r) { } // 1
for (var r = 0; r < 10; ++r) : rows { } // 2
for (var r = 0; r < 10; ++r) as rows { } // 3
for (rows: var r = 0; r < 10; ++r) { } // 4

[CyrusNajmabadi]

This would have to continue to work, so we cannot disallow "goto" for loop labels, and I'm not sure if I like that loop labels would inevitably have to double as goto labels and vice versa.

We can have loop labels, and support continue and break working for them as well. All 3 semantics make sense:

1. goto label literally goes to the label, exactly like it always has.
2. continue label continues the construct identified by that label. and you can think of naked continue; meaning 'continue the immediately outer continuable construct'.
3. break label breaks the construct identified by that label. And you can think of naked break; meaning 'break out of the immediately outer breakable construct'.

[CyrusNajmabadi]

Proposal started here: https://github.com/dotnet/csharplang/blob/main/proposals/labeled-break-continue.md
Championed Issue here: #9875
Discussion here: #9876

Closing this out to move discussion there.