Why do some programming languages have break statements, but not higher-order break statements? [closed]

Question

I may have been exposed to exactly the wrong languages, but though many have loops and break statements, none of the languages I am familiar with have higher-order break statements¹. While a regular break statement terminates the innermost loop inside which it is executed, such a break(n) statement would terminate the n innermost loops.

For example using such a statement, I could write in Python:

for i in range(100):
    for j in range(100):
        if foo(i,j):
            break(2)

As Python lacks such a statement, however, I have to do something like the following:

broken = False
for i in range(100):
    for j in range(100):
        if foo(i,j):
            broken = True
            break
    if broken:
        break

(I am aware that there are other ways to do this, such as raising exceptions. This serves just as an example.)

In another example, this is one of the prominent reasons to use a goto statement in C/C++. While goto allows for a close equivalent of a higher-order break, it introduces a new syntactical element (unless one already uses gotos). Not to forget that goto is frowned upon by many – be it justified or not.

While I see that using a higher-order break statement is not something most people use on a daily basis, this also applies to a lot of other language features. Also, a higher-order break statement does not seem difficult to implement to me and would be rather intuitive to use.

Is there a good reason why programming languages would have a break statement but not a higher-order break statement? I am thinking of things like inherent conceptual problems, broken paradigms or error vulnerability.

---

^{¹ Though, when researching for this question, I learnt that PHP has them.}

Answer 1

Is there a good reason why so few programming languages have higher-order break statements?

Using SO tags as the metric, the seven most popular programming languages in use today are Java, C#, Javascript, PHP, Python, C++, and Objective C. Of these languages,

• Java and Javascript have labeled break

• C++, C#, and Objective C have goto, which is a more general control statement that solves the same problem. They also all have break, naturally, but no multi-level or labeled break

• PHP has both nested (multi-level) break and goto

• and Python is the odd man out with no goto and no labeled break.

So maybe a better question is,

Why doesn't Python have goto or labeled break? ;)

This question has an answer to that question:

Guido rejected it because "code so complicated to require this feature is very rare". The PEP does mention some workarounds, though (such as the exception technique), while Guido feels refactoring to use return will be simpler in most cases.

Personally, I think Python should have one or both, but that is opinionated so don't take it as part of this answer.

Answer 2

Because while and until provide clearer semantics. They provide higher level abstractions for expressing programmer intent. The semantics of break are imperative at the lower level of instructions to the computer. They are closer to that of machine code - like goto, break is thin syntactic sugar over JMP.

McConnell's basic advice:

When to Use a for Loop. If you have a condition under which execution has to jump out of a loop, use a while loop instead....Most complicated looping tasks are better handled by a while loop. -- Code Complete [first edition] pp 329.

This is really just an extension of his more general advice:

Use break and continue only with caution. Use of break eliminates the possibility of treating a loop as a black box. Limiting yourself to only one statement to control a loop's exit condition is a powerful way to simplify your loops. Using break forces the person reading your code to look inside the loop for an understanding of the loop control. This makes the loop more difficult to understand. -- Code Complete [first edition] pp 337-338.

In the end his "key point" is:

Minimize the number of factors that affect the loop. Simplify! Simplify! Simplify! Second treat the inside of the loop as if it were a routine -- keep as much of the control as possible outside the loop. Explicitly state the conditions under which the body of the loop is to be executed. Don't make the reader look inside the loop to understand the loop control. Think of a loop as a black box: The surrounding program knows the control conditions but not the contents.