Discussion: C# Break nested loop

[jcouv]

@Danthekilla commented on Thu Aug 31 2017

In C# it would be fanstastic to have a language feature (probably syntactic sugar) that lets you break nested loops.

Currently these are the 2 ways you can break out of nested loops:

var foundValue;
for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        foundValue = GetValue(x, y);
        if (foundValue == valueToCompare)
            goto ENDOFLOOPS;
    }
}
ENDOFLOOPS:

var foundValue;
bool shouldBreak;
for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        foundValue = GetValue(x, y);
        if (foundValue == valueToCompare)
        {
            shouldBreak = true;
            break;
        }
    }
    if (shouldBreak)
        break;
}

I would like to propose the ability for a break to have a value for how many loops to break out of. Like so:

var foundValue;
for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        foundValue = GetValue(x, y);
        if (foundValue == valueToCompare)
            break 2;
    }
}

Not only is it slightly smaller, but I think easier to read.

Anyone have any thoughts on the matter?

[DavidArno]

@Danthekilla,

You forgot the existing third way:

(bool found, ValueType value) Foo()
{
    for (int x = 0; x < xMax; x++)
    {
        for (int y = 0; y < yMax; y++)
        {
            var foundValue = GetValue(x, y);
            if (foundValue == valueToCompare) return (true, foundValue);
        }
    }
    return (false, default);
}

Small focused functions are your friend. But if you want long functions, as you say, there is already two ways of achieving this goal. So I'd see yet another way of achieving it as really bringing nothing to the language.

[jnm2]

Sometimes it's a loop and a switch and coming up with a name for it is super arbitrary and counter-intuitive.

[iam3yal]

I'm not in favour of this but I think the following is better goto ENDOFLOOPS when foundValue == valueToCompare; I know, no one "likes" the goto statement but anyway, we might get a goto and continue expressions so the following would be possible:

var foundValue;
for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        foundValue = GetValue(x, y);
	foundValue == valueToCompare ? goto ENDOFLOOPS : continue;
    }
}
ENDOFLOOPS:

[Logerfo]

I'd prefer to see something like Java Branching Statements, as once pointed out by @HaloFour at #176 (comment)

[jnm2]

goto is perfectly reasonable if you only go to points that can already be jumped to by another kind of branching statement like break. Same with goto case.

[iam3yal]

@Logerfo, Indeed, it makes things clear than having something like break <number>.

[benaadams]

Inline returns slow down loops until .NET Core 2.1 dotnet/coreclr#13314 and functions with a loop generally won't inline (without forcing); so wouldn't be so great for very hot loops; though ok for general loops.

[bondsbw]

break <number> doesn't refactor as well. Adding another loop or removing a loop requires carefully reading back through the code and reworking such statements. Otherwise, it can result in jumping to an unintended point.

[jnm2]

@bondsbw Not to mention copy/paste.

[JarrydSemmens]

This is simple, short and elegant. Goto's require maintenance and their excessive use results in spaghetti code. Extra temp variables hanging around is just junk code that can go wrong.

Break = n; in an n deep loop would create short, concise code that cannot be confused for anything else.

[erik-kallen]

I see absolutely no way in which a goto ENDOFLOOP results in spaghetti code. It is equivalent to the proposed break <n> or Java's break loopName

[jez9999]

It's less intuitive to "go to continue the loop" or "go to break the loop" than to "continue the loop / break the loop", and the labels for the goto have to be placed unintuitively at the end instead of just before the loop. Simple as that.

[CyrusNajmabadi]

It's definitely more intuitive for me. knowing exactly where i'm jumping and exactly what runs next is much nicer. I actually find the label-form more confusing as it appears as if you're jumping before hte loop... but you're actually jumping right before the end such that incrementing and checking happens again, but initialization does not.

[jez9999]

Well, I don't know why. I think to most people it wouldn't be too hard to figure that you're labelling a loop, and breaking or continueing a loop are already well-defined behaviours.

[HaloFour]

I agree with some of the other posters, I don't like the use of an integer indicating the number of levels. If any enhancements to break or continue are considered for nested loop scenarios I'd prefer the labeled loop syntax used by Java.

String foundValue = null;
OUTERLOOP:
for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        foundValue = GetValue(x, y);
        if (foundValue == valueToCompare)
            break OUTERLOOP;
    }
}

This makes it much clearer exactly where the break/continue statement will continue execution.

[Korporal]

I agree with some of the other posters, I don't like the use of an integer indicating the number of levels. If any enhancements to break or continue are considered for nested loop scenarios I'd prefer the labeled loop syntax used by Java.

String foundValue = null;
OUTERLOOP:
for (int x = 0; x < xMax; x++)
{
    for (int y = 0; y < yMax; y++)
    {
        foundValue = GetValue(x, y);
        if (foundValue == valueToCompare)
            break OUTERLOOP;
    }
}

This makes it much clearer exactly where the break/continue statement will continue execution.

It seems to me that allowing an optional identifier to follow the break keyword where that identifier is a label and the label's statement is a loop construct that directly or indirectly contains the break, is an obvious choice, this has been discussed here for five years and has lots of upvotes.

[orthoxerox]

I agree that breaking from a named loop is the best option. I think there was a proposal of mine asking for that. Or was it left in the roslyn repo?

[iam3yal]

@jnm2 It's better to have an "arbitrary" label and know what it is than having a number and starting to wonder what it means, sometimes.

[jnm2]

@eyalsk Exactly my point. 😄

[jnm2]

@eyalsk I don't remember preferring numbers but I'm happy to update my opinion if I did write that somewhere. I'm not seeing it.

[marcussacana]

That's also because you consider that every programmer works for a company without its own code of conduct,
In that are against whoever is managing the project can just create a specification forbidding the feature.
If the programmer used a forbidden coding style, they must review his own code and check again the code of condut, not the opposite.
Of course, that's supossing the feature is depreciated for the programmers, what we can't say.

[CyrusNajmabadi]

GOTO and its use is very frowned upon

Why is it frowned upon?

[Korporal]

GOTO and its use is very frowned upon

Why is it frowned upon?

Because Ed Dijksra wrote a paper that was highly critical of it.

[SirDragonClaw]

GOTO and its use is very frowned upon

Why is it frowned upon?

https://www.l3harrisgeospatial.com/Learn/Blogs/Blog-Details/ArtMID/10198/ArticleID/15289/Why-should-GOTO-be-avoided

This was the first result in Google, there are 1000's more. Personally I think it has its uses and banning it from codebases is going to far, but many disagree.

[HaloFour]

GOTO in older languages could be very dangerous. It effectively let you jump anywhere, into and out of functions and other protected areas. The version of GOTO in C# has much stricter guardrails, but that stigma from decades ago remains, likely continuing to be drilled into the minds of students by their professors. You can thank Dijkstra for that.

[CyrusNajmabadi]

This was the first result in Google,

That is 'goto' in idl. I'm asking why it's frowned upon in c#.

[jnm2]

I recommend the use of goto over introducing loops and flags, for the sake of clarity.

goto case is another example of goto being safe and understandable.

[jez9999]

Boy do I with MS would introduce labeled loops. It's literally the one totally valid use-case for goto. And yet they always tell people not to use goto.

Apparently new C# feautres need a 'champion'. Well, I'm not sure why nobody seems to be willing to champion this considering I've seen comments from hundreds of developers who want it.

I'll also just mark here that a related discussion is going on at #5525

[333fred]

Is that really likely to have something else break it?

Yes. We've discussed using break as a keyword for how to get a value out of a block expression, for instance, and this would conflict.

[jez9999]

Why would you overload break for that functionality instead of using a new keyword? At least this proposal suggests using break for something very similar to what it already does. It'd be using all over again.

[HaloFour]

break is already a keyword, which makes it easier to repurpose. Adding a new keyword would require additional work to disambiguate from other expressions, which is why yield requires being followed by return or break and why await can only be used within an async member.

Plenty of C# keywords and operators mean more than one thing, and using having more than one purpose dates back to C# 1.0.

[333fred]

Why would you overload break for that functionality instead of using a new keyword? At least this proposal suggests using break for something very similar to what it already does. It'd be using all over again.

I don't know that we will use break. I also don't know that we won't use break. The point is that there is no proposal that is a simple slam dunk requiring no thought and design time.

[NN---]

Rust introduces names blocks.

let result = 'block: {
    do_thing();
    if condition_not_met() {
        break 'block 1;
    }
    do_next_thing();
    if condition_not_met() {
        break 'block 2;
    }
    do_last_thing();
    3
};

https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html

[HaloFour]

And yet they always tell people not to use goto.

Because it's not the C# language team telling people to not use goto, they still feel that it's completely appropriate to use that in these cases. The goto keyword in C# is pretty constrained and mitigates most of the issues that led to that paper being written over 50 years ago. Even Djiksta didn't think the advice should be followed dogmatically.

[Korporal]

This is puzzling, the utility of an enhanced break and continue seems to be well established after discussing this for five years. Use of goto to influence loop behavior is potentially less clear because goto could target any reachable label, even one before any of the loops were entered.

The break and continue keywords used within a loop are well established too, their intent is understood to be associated with the execution of the loop and not a general unconstrained change of next execution point.

I would always favor any change too, that reduced the need to use goto it has it uses, but if the number of use cases for goto can be reduced by small improvements to existing idioms, then surely that goes in favor of making this change.

I wouldn't be surprised either to find that most of the uses of goto in C# are for this very reason, loop control.

[CyrusNajmabadi]

In practice when you're using goto in this way you just create a block as a statement placeholder.

I've never seen anyone do that in 25 years :-)

[jez9999]

loop {
  loop {
    goto continue_outerblock;
  }
  continue_outerblock: {}
}

Wrt properties, the benefit it's a tremendous amount of repetition and code that just be kept in sync. That case doesn't exist here.

Yes it does. What skin is it off your nose if this were to get introduced anyway? Why are there always a chorus of wet blankets opposing a feature that won't cause them any problems?

[Korporal]

I wouldn't be surprised either to find that most of the uses of goto in C# are for this very reason, loop control.

Then it sounds like the right tool for the job. The fact that it can also do more doesn't make it wrong. C#'s goto is on pretty tight guardrails, there is no goal to reduce how it can be used.

By definition @HaloFour it is not the "right tool for the job" at all, else the language would never have had a break or continue keyword for use within loops, we'd all be using goto wouldn't we...

[CyrusNajmabadi]

@Korporal i address that point here: #6634 (reply in thread)

Had C had labeled breaks/continues, we likely would have adopted them for comfort level for that audience. But it didn't, so we didn't. Had C not had break/continue at all, we very well may not have had them either.

Thee issue here is that you're using decisions we made around familiarity as part of discussions around features that don't have such surrounding context.

[CyrusNajmabadi]

a feature that won't cause them any problems?

As per another post above that you participated in #6634 (reply in thread)

Yes. We've discussed using break as a keyword for how to get a value out of a block expression, for instance, and this would conflict.

We have to be careful and conscientious about changes. That includes deeply understanding the impact on the language, how it affects other work we may want to do (and may feel is MUCH more important), and determining if the value is there.

The design and discussion process is to ensure this is done in a careful and considered fashion. We do not want to rush features. We have done that in the past, and we're still feeling the pain of doing that. As such, we are careful, considerate, and will deeply discuss the topic in depth (including the negatives) to give us hte highest confidence our decisions are good and that we won't regret them in the future when we're locked into the mistakes for decades.

[Korporal]

I don't think anyone can make a better case, offer better justifications or motivations for a change like this, beyond what has already been presented in this discussion over the past five years, but I'll give it a shot, perhaps, just perhaps it will strike a chord with someone on the language team.

There are important distinctions between leveraging a goto to terminate or resume a loop and using break PRIMARY or continue PRIMARY for example.

The break or continue is and will still be, specifically referring to exiting or resuming the loop. The goto might be referring to loop termination or resumption or it might not, it might just be a blunt goto.

A goto inside a loop might be controlling loop termination or resumption or might be just a blunt goto in which the exiting or resumption of any loops is merely incidental, a consequence rather than a specific intent.

Understanding intent in someone's code is extremely important when trying to reason about code, this presumption that goto is good enough for all such cases is technically true if we disregard the question of intent but why should we do that?

RESUME:

if (expression)
   {
   // stuff
   goto RESUME;
   }

Is to all intents and purposes a while loop, would anyone seriously contend that the if a language had no while then it would never benefit from having one added because goto is "already there", good enough, no need to change anything? I would not reason that way and neither did any language designer who ever included while in a language as many have.

If editing some complex set of nested loops within loops and I want to resume some intermediate loop or terminate some intermediate loop then what is easier than just putting a label at the start of the loop and then inserting a break LOOP or continue LOOP in the code?

With goto as my only linguistic tool I must think carefully about where to position said label, I can't just add it to the loop's opening statement, oh no, I've got to scrutinize the code, because I'm no longer thinking about the loop, but rather where to be, where to go once I exit the loop.

Then what about cases where code gets inadvertently added before or after some label that's used to end or resume a loop? That could easily happen and have subtle effects,

while (X)
   {
   // stuff
   for (blah-blah-blah)
       {
        // stuff
       if (Y)
          goto EXIT_LOOP; // note this label has no syntactic 'attachment' to the loop were exiting!
       }

   // Oh dear, I expected this to always execute after I exited the for loop, but that's not true despite the fact it's the next statement right after the loop!
   stuff_that_wont_get_done_if_Y_was_true(); // do this right after we leave the loop

EXIT_LOOP:  // We get to here when the loop ends, well sometimes we do, but we can get here from many places where a goto gets written.
    // stuff

   }

Can you see? stuff_that_wont_get_done_if_Y_was_true will get done if the loop ends normally but won't get done if it exits via the goto.

A break unconditionally always continues execution at the statement following the loop's closing brace, we can safely rely on that as we reason about code but goto used as the hammer for every nail, does not ensure that, it might or it might not...

[CyrusNajmabadi]

if we took C# code and replaced break and continue with goto as an excercise, we'd see that we lose the ability to assess the intent, we must scrutinize the code to discern the intent.

This point has been stated above. However, multiple people (in this discussion and in others on this topic over the years) have stated that this is not the case in practice. Indeed, the argument would feel more possible were this year 1, where we might not have much confidence in the suitability of goto. But we're literally in year 25 (or 20+ years publicly) that people have been using the language, and the direct lived experience of people working in this space makes me feel vastly different.

You feel like you lose this ability. But others feel like no such ability is lost. Note: of the arguments presented, this certainly is one i can accept as a personal belief in clarity. So the question on our end then becomes how much benefit that brings. Currently, it feels extremely small. But we'll certainly continue to watch this space and see how the community and ecosystem evolve here.

And, like i mentioned a few times, i could easily see someone being swayed that this is important enough, especially if packaged up with other improvements in this space to form a good holistic set of features that overall brings around enough value.

[TahirAhmadov]

I have absolutely no comments on its priority.

Perhaps you should think about it, because even if this is accepted, and is done in 20 years, what benefit is it for you or anybody else participating in this discussion? Trust me, there are tens of large and medium sized language changes that are way more important.

If goto was sufficient then we never really "needed" break or continue yet there were arguments in their favor else we'd never have had them.

There is a big difference - continuing/breaking outer loops is much less often needed than doing the same to the "current" loop. Even forgetting the C/C++ "baggage", there is still an argument that special break and continue make sense for the current loop, but not for the outer loop scenario.

[CyrusNajmabadi]

there is still an argument that special break and continue make sense for the current loop, but not for the outer loop scenario.

Agreed. In my life it's likely around 2-3 orders of magnitude less common (possibly more if i actually go and do the math). Feels very niche.

[macias]

So from our perspective, this doesn't really feel like a substantive improvement

Pity, but fair enough.

But recognize that no matter what we do, there will be many users with that sentiment every release :)

Yes, this is predictable :-) Maybe I clarify what I meant -- improving control over logic, making code less prone to human errors I think in objective scale should be higher than aesthetics factors. Those are important of course, but what good is a program with less whitespaces, or with nicer syntax if it crashes every day and it is hard to find a bug.

The burden of ensuring the code is sound should be left to computer/compiler, not humans (on every day basis).

But maybe this objective scale is subjective thing of mine :-).

[CyrusNajmabadi]

making code less prone to human errors

I'm generally not at all convinced that this feature makes code less prone to human errors. :)

should be higher than aesthetics factors

Strong disagreement. Programming is heavily influenced by aesthetics and ergonomics. Take a look at some terrible examples in the past of programming languages that eschewed these aspects to focus on the other things. Aesthetics also plays heavily into clarity, which is a prime way to prevent human errors.

The burden of ensuring the code is sound should be left to computer/compiler,

I don't see this feature really helping with that at all.

[spydacarnage]

Outside of the current discussion, aimed at people who want this feature, would this be legal code in your proposed view?

loop_1:
for (int i = 0; i < 100; i++)
{
    loop_2:
    for (int j = i; j < 100; j++)
    {
        for (int k = j; k < 100; k++)
        {
            // do stuff
            continue loop_1;
        }
    }
}
if (something)
{
    goto loop_1;
}

i.e. is a "loop label" the same as a "goto label"?

[CyrusNajmabadi]

it's def a bit of an odd duck in that in the continue case it actually refers to a different location (same with 'break' as well). For 'goto' it would be the start-point of that statement. For 'continue' it would be the end-point of the embedded statement of the loop. For 'break' it would be the end-point of the loop itself. Certainly worth discussing more if we decide to go through with this. Thanks! :)

[Korporal]

That's what I expected - I've been trying to fathom out a scenario where this feature might cause an issue. The best I've come up with so far is the fact that by giving labels a second purpose, it might confuse people into thinking that the goto statement in the example could be changed to goto loop_2;, which is illegal.

Or maybe the fact (and this might not be an issue because my knowledge of the deep-level stuff isn't ideal) that loop_1 is actually now doing two things - it's identifying a statement that a goto can explicitly move to, but now it's also denoting (especially in the case of a for or foreach loop) a place in code that denotes the beginning of a statement of which you want to continue into the middle of. Not sure if that makes sense to anyone..?

That's a very interesting point, it does suggest that supporting break LABEL and continue LABEL should include some constraint on the label's location.

while (X > Y)
LOOP1:
{
   if (J)
      continue LOOP1:
   do_stuff();
}

In essence preventing any use of goto LOOP1 from outside the loop, making LOOP1 useable only as a target for a break or continue or goto (inside the loop).

[CyrusNajmabadi]

Generally speaking, i have no issue with all just being legal. If someone doesn't like that, it would be trivial to have a linter rule state that you shouldn't goto to a label which is the target of a break/continue. Seems like it would be a non-issue in practice, and that there would be totally suitable reasons to have such patterns.

[jez9999]

That's a very interesting point, it does suggest that supporting break LABEL and continue LABEL should include some constraint on the label's location.

while (X > Y)
LOOP1:
{
   if (J)
      continue LOOP1:
   do_stuff();
}

In essence preventing any use of goto LOOP1 from outside the loop, making LOOP1 useable only as a target for a break or continue or goto (inside the loop).

I always assumed that continue loop and break loop would have to refer to labels that were 1) directly before a while or for or foreach and 2) in a parent loop of the continue/break statement.

As for whether these labels could still be used as goto targets - sure, why not? That double duty seems quite natural.

[CyrusNajmabadi]

Agreed with @jez9999 on this. We'd likely use the label-location used by several other languages for this concept (like Java). We wouldn't place inside. And break/continue/goto all make sense with that and would be sensible to keep.

break/continue already mean different things for that label, so i don't really have a problem with goto meaning something different as well.

[Korporal]

One could consider not using labels too. One could ponder this for example:

while (X)
{
   do_this();

   while (Y)
   {
      do_that();

      if (J)
         break(1); // breaks out of the loop 'while (X)'
   }
}

Then break(0) would have the same meaning as today's break. I don't know how that would "feel" if I used it though, it avoid labels altogether and refers only to nesting depth, so that's a clean way to express it but then one has to look at the code to see what the numeric value refers too, perhaps not much effort but not as simple visually as a label...

[spydacarnage]

I would see this is as a less-useful version - it's a lot more ambiguous as to what the intention of the code is. Especially if you have large/complicated loops - with a label, you could use your editor's Find function if it came down to it :)

[Korporal]

Perhaps its better the other way around:

while (X)
{
   do_this();

   while (Y)
   {
      do_that();

      if (J)
         break(0); // breaks out of the loop 'while (X)'
   }
}

The outermost loop being always 0 and that nesting number increasing as we enter contained loops...

[CyrusNajmabadi]

Goto seems clearer in both cases as the destination is apparent. No need to do math. The indexed form also seems a bit odd as no other lang features really work that way. So it's an odd duck here :-)

We use math when it comes to contiguous memory segments. But that's not what is going on here...

[spydacarnage]

That looks even more confusing, tbh. I think that if this feature has a chance to fly, it needs to stick to the labelled version.

[leoshusar]

If you added one more loop, you would need to renumber everything. You would also need to remember where you are, from where you are breaking.
Labels would be tied to specific loop.

[Korporal]

Yes, all of these are good points, very good points, I agree here, it's not a great way to express this.

[amenre]

Edit: This is a suggestion/example that allows you to break out to any level in a nested loop. I updated the sample code to be a little more clean & precise.

First, you have an enum:

  public enum BreakType : byte {
    None = 0,
    Minute = 1,
    Hour = 2 | BreakType.Minute,
    Day = 4 | BreakType.Hour,
    Week = 8 | BreakType.Day,
    All = 16 | BreakType.Week
  }

Then you can control where/when it breaks out:

BreakType @break = BreakType.None;
int[] minutes = new int[60]
    , hours = new int[60]
    , days = new int[30]
    , week = new int[52];

for (int i = 0; i < week.Length && (BreakType.Week & @break) != BreakType.Week; i++) {
  @break = BreakType.None;

  // Purposely stop everything after 5th "week"
  if (i > 4)
    @break = BreakType.Week;

  for (int j = 0; j < days.Length && (BreakType.Day & @break) != BreakType.Day; j++) {
    @break = BreakType.None;

    for (int k = 0; k < hours.Length && (BreakType.Hour & @break) != BreakType.Hour; k++) {
      @break = BreakType.None;

      for (int l = 0; l < minutes.Length && (BreakType.Minute & @break) != BreakType.Minute; l++) {
        // Purposely stop after 10 "minutes"
        if (l > 9)
          @break = BreakType.Day; // will break out of "day" to the next "week"
      }
    }
  }
}

[jez9999]

The "use a variable to control the break" is a common suggestion in response to this. As your code above demonstrates clearly, it's ugly, verbose, awkward, unmaintainable, and error-prone (forget to put the check on @break in any of the loop statements and your break variable stops working).

[mattwar]

I like not needing to invent a label, but break 2 feels awkward because there is no other place in C# where a number exists that is not meant as a literal expression. Clearly, we should invent some dedicated syntax that looks more C# like but means the same thing.

I propose we use additional C# specific keywords.

Instead of just break 2 you should type break break to break two levels, and break break break for three and so on.

However, if you are thinking that this is getting ridiculous, it probably is after three breaks. If you have to pump the breaks that many times and still haven't stopped you need to try something else, and all that is left is to swerve into a tree on the side of the road, which is technically a crash.

So, we add the crash keyword as a failsafe.

if (x > y)
    break break break crash;

That should be enough for any scenario.

[macias]

Bad idea, add one loop somewhere in the middle, and then you need to carefully update all breaks/continues. We already have labels, we already have breaks/continues, the only missing ingredient is using them together.

[DavidArno]

Bad idea...

Whoosh...

Apologies, @macias. I am making fun of you, which is a little unkind. But the joke of Matt's comment really did go straight over your head, I feel. 😊