--- title: break label ; and continue label ; document: P3568R2 date: 2026-05-10 audience: SG22 Compatibility,EWG Evolution reply-to: - "Jan Schultke" paper-type: proposal --- --- ## Revision history ### Since R1 - Added some more motivation in § 3.4 Expansion statements Rebased § 7 Proposed wording on the post-Croydon working draft ### Since R0 The paper was seen by EWGI and then by EWG at Hagenberg 2025, with the following polls: > **P3568R0**: EWG likes syntax `N3355: for (...) { }` > > | SF > F > N > A > SA > > 4 > 16 > 5 > 9 > 5 | F > N > A > SA > > 4 > 16 > 5 > 9 > 5 | N > A > SA > > 4 > 16 > 5 > 9 > 5 | A > SA > > 4 > 16 > 5 > 9 > 5 | SA > > 4 > 16 > 5 > 9 > 5 | 4 > 16 > 5 > 9 > 5 | 16 > 5 > 9 > 5 | 5 > 9 > 5 | 9 > 5 | 5 | > | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | > | 4 > 16 > 5 > 9 > 5 | 16 > 5 > 9 > 5 | 5 > 9 > 5 | 9 > 5 | 5 | | | | | | > > **P3568R0**: EWG likes syntax `for N3377 (...) { }` > > | SF > F > N > A > SA > > 7 > 13 > 5 > 5 > 8 | F > N > A > SA > > 7 > 13 > 5 > 5 > 8 | N > A > SA > > 7 > 13 > 5 > 5 > 8 | A > SA > > 7 > 13 > 5 > 5 > 8 | SA > > 7 > 13 > 5 > 5 > 8 | 7 > 13 > 5 > 5 > 8 | 13 > 5 > 5 > 8 | 5 > 5 > 8 | 5 > 8 | 8 | > | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | > | 7 > 13 > 5 > 5 > 8 | 13 > 5 > 5 > 8 | 5 > 5 > 8 | 5 > 8 | 8 | | | | | | > > **P3568R0**: If C has it, we are interested in this feature too. > > | SF > F > N > A > SA > > 16 > 21 > 5 > 2 > 1 | F > N > A > SA > > 16 > 21 > 5 > 2 > 1 | N > A > SA > > 16 > 21 > 5 > 2 > 1 | A > SA > > 16 > 21 > 5 > 2 > 1 | SA > > 16 > 21 > 5 > 2 > 1 | 16 > 21 > 5 > 2 > 1 | 21 > 5 > 2 > 1 | 5 > 2 > 1 | 2 > 1 | 1 | > | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | > | 16 > 21 > 5 > 2 > 1 | 21 > 5 > 2 > 1 | 5 > 2 > 1 | 2 > 1 | 1 | | | | | | Due to lack of consensus in EWG, syntactical design choices were delegated to WG14. WG14 saw [N3377] at Graz 2025 and voted as follows: > **N3377**: Would WG14 like to see a paper changing loop name syntax at a future meeting? > > | F > N > A > > 6 > 11 > 9 | N > A > > 6 > 11 > 9 | A > > 6 > 11 > 9 | 6 > 11 > 9 | 11 > 9 | 9 | > | --- | --- | --- | --- | --- | --- | > | 6 > 11 > 9 | 11 > 9 | 9 | | | | The authors of [N3377] have expressed that they are no longer pursuing the paper; therefore, R1 of this paper assumes that the debate on label syntax is entirely settled, and C++ follows the [N3355] syntax. Furthermore, the proposed wording has been improved slightly, and a `__cpp_break_label` feature-test macro is now included. ## Introduction While C++ already has a broad selection of control flow constructs, one construct commonly found in other languages is notably absent: the ability to apply `break` or `continue` to a loop or `switch` when this isn’t the innermost enclosing statement. This feature is popular, simple, and quite useful: Specifically, we propose the following functionality: ``` outer: for (auto x : xs) { for (auto y : ys) { if (/* ... */) { continue outer; // OK, continue applies to outer for loop break outer; // OK, break applies to outer for loop } } } switch_label: switch (/* ... */) { default: while (true) { if (/* ...*/) { break switch_label; // OK, break applies to switch, not to while loop } } } break outer; // error: cannot break loop from the outside goto outer; // OK, used to be OK, and is unaffected by this proposal switch_label:; // OK, labels can be reused goto switch_label; // error: jump target is ambiguous ``` The `break label` and `continue label` syntax is identical to that in [N3355] and has been accepted into C2y (see working draft at [N3435]). We bring that syntax into C++ and relax restrictions on labels to make it more powerful, and to address concerns in a follow-up proposal [N3377]. Note that `break` and `continue` with labels have been proposed in [N3879] and rejected at Rapperswil 2014 ([N4327]): > Straw poll, proposal as a whole: > > | SF > F > N > A > SA > > 1 > 1 > 1 > 13 > 10 | F > N > A > SA > > 1 > 1 > 1 > 13 > 10 | N > A > SA > > 1 > 1 > 1 > 13 > 10 | A > SA > > 1 > 1 > 1 > 13 > 10 | SA > > 1 > 1 > 1 > 13 > 10 | 1 > 1 > 1 > 13 > 10 | 1 > 1 > 13 > 10 | 1 > 13 > 10 | 13 > 10 | 10 | > | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | > | 1 > 1 > 1 > 13 > 10 | 1 > 1 > 13 > 10 | 1 > 13 > 10 | 13 > 10 | 10 | | | | | | > > "break label;" + "continue label;" > > | SF > F > N > A > SA > > 3 > 8 > 4 > 9 > 3 | F > N > A > SA > > 3 > 8 > 4 > 9 > 3 | N > A > SA > > 3 > 8 > 4 > 9 > 3 | A > SA > > 3 > 8 > 4 > 9 > 3 | SA > > 3 > 8 > 4 > 9 > 3 | 3 > 8 > 4 > 9 > 3 | 8 > 4 > 9 > 3 | 4 > 9 > 3 | 9 > 3 | 3 | > | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | > | 3 > 8 > 4 > 9 > 3 | 8 > 4 > 9 > 3 | 4 > 9 > 3 | 9 > 3 | 3 | | | | | | I believe that rejecting `break label` was a grave mistake at a time. Regardless, the WG21 sentiment towards the feature is now the opposite, even if just for C compatibility (see § 1.2 Since R0). ## Motivation `break label` and `continue label` are largely motivated by the ability to control nested loops. This is a highly popular feature in other languages, and C++ could use it too, since it has no good alternative. To be fair, a conditional `return` in the loop sometimes bypasses the need to terminate it. However, this is not always allowed; such practice is outlawed by MISRA-C++:2008 Rule 6-6-5 "A function shall have a single point of exit at the end of the function" ([MISRA-C++]). Even if it is permitted, there are many cases where an early `return` does not obsolete `break`, and it generally does not obsolete `continue`. Note: I have been told that more recent revisions of MISRA-C++ no longer include this rule. ### No good alternative Let’s examine a motivating example which uses our new construct: > ``` > void f() { > process_files: for (const File& text_file : files) { > for (std::string_view line : text_file.lines()) { > if (makes_me_angry(line)) { > continue process_files; > } > consume(line); > } > std::println("Processed {}", text_file.path()); > } > std::println("Processed all files"); > } > ``` > > `continue label` is very useful in this scenario, and expresses our intent with unparalleled clarity. We want to continue processing other files, so we `continue process_files`. > > A plain `break` cannot be used here because it would result in executing the following `std::println` statement, but this should only be done upon success. There are alternative ways to write this, but all of them have various issues. #### `goto` ``` for (const File& text_file : files) { for (std::string_view line : text_file.lines()) { if (makes_me_angry(line)) { goto done_with_file; } consume(line); } std::println("Processed {}", text_file.path()); done_with_file: } std::println("Processed all files"); ``` `goto` is similar in complexity and even readability here, however there are some issues: - `goto` cannot cross (non-vacuous) initialization, which would be an issue if some variable was initialized prior to `std::println`. This can be addressed by surrounding the outer loop contents with another set of braces, but this solution isn’t obvious and takes away from the elegance of `goto` here. `goto` cannot be used in constant expressions. For processing text files like in the example, this doesn’t matter, but nested loops are desirable in a `constexpr` context as well. Many style guides ban or discourage the use of `goto`. See [MISRA-C++], [CppCoreGuidelinesES76], etc. This discouragement dates all the way back to 1968 (see [GotoConsideredHarmful]), and 66 years of teaching not to use `goto` won’t be undone. Even in the cases where `goto` isn’t discouraged, those cases are always special, like "only `goto` forwards", "only `goto` to break out of loops", etc.. This issue has been debated for decades, and there is still no consensus on when, actually, `goto` is okay to use. `goto` is innately more difficult to use because to understand its purpose, the user has to know where the jump target is located. A `goto past_the_loop` behaves radically differently compared to a `goto before_the_loop`. Moving the jump target or the `goto` statement relative to each other can also completely change these semantics. By comparison, `break` and `continue` always jump forwards, past a surrounding loop, or to the end of a surrounding loop respectively. This makes them much easier to reason about, and much less error-prone. The "local readability" of `goto` relies heavily on high-quality naming for the label. A `goto end` could mean to the end of a loop, to after the loop, to the end of a function, etc. Since `break` and `continue` are much more limited, they do not require such good label naming. A `break loop` has bad name, but the user *generally* understands its purpose. Note: Previous discussion on the [isocpp-core] reflector has addressed the idea of just adding `constexpr goto`, but doing so is alleged to be more complicated than more limited `constexpr` control flow structures which can only "jump forwards", such as `break` and `continue`. In conclusion, there are too many issues with `goto`, some of which may never be resolved. [std-proposals] discussion prior to the publication of this proposal has shown once again that `goto` is a controversial and divisive. #### Immediately invoked lambda expression (IILE) ``` for (const File& text_file : files) { [&] { for (std::string_view line : text_file.lines()) { if (makes_me_angry(line)) { return; } consume(line); } std::println("Processed {}", text_file.path()); }(); } std::println("Processed all files"); ``` While this solution works in constant expressions, we may be painting ourselves into a corner with this design. We cannot also `break` the surrounding loop from within the IILE, and we cannot return from the surrounding function. If this is needed at some point, we will have to put substantial effort into refactoring. Furthermore, this solution isn’t exactly elegant: - The level of indentation has unnecessarily increased through the extra scope. The call stack will be one level deeper during debugging. This may be relevant to debug build performance. The fact that the lambda is immediately invoked isn’t obvious until reading up to `()`. The word `return` does not express the overall intent well, which is merely to continue the outer loop. This can be considered a teachability downside. It is also possible to use an additional function instead of an IILE in this place. However, this is arguably increasing the degree of complexity even more, and it scatters the code across multiple functions without any substantial benefit. #### Mutable `bool` state ``` for (const File& text_file : files) { bool success = true; for (std::string_view line : text_file.lines()) { if (makes_me_angry(line)) { success = false; break; } consume(line); } if (success) { std::println("Processed {}", text_file.path()); } } std::println("Processed all files"); ``` This solution substantially increases complexity. Instead of introducing extra scope and call stack depth, we add more mutable state to our function. The original intent of "go process the next file" is also lost. Such a solution also needs additional state for *every* nested loop, i.e. N `bool`s are needed to `continue` from N nested loops. ### Constant expressions Use of `constexpr` has become tremendously more common, and `goto` may not be used in constant expressions. Where `goto` is used to break out of nested loops, `break label` makes it easy to migrate code: > Uses of > > goto > > to break out of nested loops can be replaced with > > break label > > as follows: > > ``` > constexpr void f() { > outer: while (/* ... */) { > while (/* ... */) { > if (/* ... */) { > goto after_loop; > break outer; > } > } > } > after_loop:; > } > ``` Due to reasons mentioned above, I do not believe that "`constexpr` `goto`" is a path forward that will find consensus. ### Argumentum ad populum Another reason to have `break label` and `continue label` is simply that it’s a popular construct, available in other languages. When Java, JavaScript, Rust, or Kotlin developers pick up C++, they may expect that C++ can `break` out of nested loops as well, but will find themselves disappointed. [StackOverflow] *"Can I use break to exit multiple nested `for` loops?"* shows that there is interest in this feature (393K views at the time of writing). A draft of the proposal was posted on [Reddit] and received overwhelmingly positive feedback (70K views, 143 upvotes with, 94% upvote rate at the time of writing). #### Poll Another way to measure interest is to simply ask C++ users. The following is a committee-style poll (source: [TCCPP]) from the Discord server [Together C & C++](https://discord.gg/tccpp), which is the largest server in terms of C++-focused message activity: > Should C++ have "break label" and "continue label" statements > to apply break/continue to nested loops or switches? > > | SF > F > N > A > SA > > 21 > 21 > 12 > 6 > 4 | F > N > A > SA > > 21 > 21 > 12 > 6 > 4 | N > A > SA > > 21 > 21 > 12 > 6 > 4 | A > SA > > 21 > 21 > 12 > 6 > 4 | SA > > 21 > 21 > 12 > 6 > 4 | 21 > 21 > 12 > 6 > 4 | 21 > 12 > 6 > 4 | 12 > 6 > 4 | 6 > 4 | 4 | > | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | > | 21 > 21 > 12 > 6 > 4 | 21 > 12 > 6 > 4 | 12 > 6 > 4 | 6 > 4 | 4 | | | | | | Note: 64 users in total voted, and the poll was active for one week. #### How common is `break`/`continue` with labels? To further quantify the popularity, we can use GitHub code search for various languages which already support this feature. The following table counts only control statements with a label, *not* plain `break;`, `continue;`, etc. We also count statements like Perl’s `last label`; it is de-facto `break label`, just with a different spelling. | Language Syntax Labeled `break`s Labeled `continue`s Σ `break` `continue` Java `label: for (...)` `break label;` `continue label;` [424K files](https://github.com/search?q=language%3AJava+%2F%28%3F-i%29break+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) [152K files](https://github.com/search?q=language%3AJava+%2F%28%3F-i%29continue+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) 576K files JavaScript `label: for (...)` `break label;` `continue label;` [53.8K files](https://github.com/search?q=language%3AJavaScript+%2F%28%3F-i%29break+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) [68.7K files](https://github.com/search?q=language%3AJavaScript+%2F%28%3F-i%29continue+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) 122.5K files Perl `label: for (...)` `last label;` `next label;` [34.9K files](https://github.com/search?q=language%3APerl+%2F%28%3F-i%29last+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) [31.7K files](https://github.com/search?q=language%3APerl+%2F%28%3F-i%29next+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) 66.6K files Rust `label: for (...)` `break 'label;` `continue 'label;` [30.6K files](https://github.com/search?q=language%3ARust+%2F%28%3F-i%29break+%3F%27%5Ba-zA-Z0-9%5D%2B%3B%2F&type=code) [29.1K files](https://github.com/search?q=language%3ARust+%2F%28%3F-i%29continue+%3F%27%5Ba-zA-Z0-9%5D%2B%3B%2F&type=code) 59.7K files TypeScript `label: for (...)` `break label;` `continue label;` [11.6K files](https://github.com/search?q=language%3ATypeScript+%2F%28%3F-i%29break+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) [9K files](https://github.com/search?q=language%3ATypeScript+%2F%28%3F-i%29continue+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) 20.6K files Swift `label: for ...` `break label` `continue label` [12.6K files](https://github.com/search?q=language%3ASwift+%2F%28%3F-i%29break+%5B_a-zA-Z0-9%5D%2B%5Cn%2F&type=code) [5.6K files](https://github.com/search?q=language%3ASwift+%2F%28%3F-i%29continue+%5B_a-zA-Z0-9%5D%2B%5Cn%2F&type=code) 18.2K files Kotlin `label@ for (...)` `break@label` `continue@label` [8.7K files](https://github.com/search?q=language%3AKotlin+%2F%28%3F-i%29break%40%5B_a-zA-Z0-9%5D%2B%2F&type=code) [7.6K files](https://github.com/search?q=language%3AKotlin+%2F%28%3F-i%29continue%40%5B_a-zA-Z0-9%5D%2B%2F&type=code) 16.3K files D `label: for (...)` `break label;` `continue label;` [3.5K files](https://github.com/search?q=language%3AD+%2F%28%3F-i%29break+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) [2.6K files](https://github.com/search?q=language%3AD+%2F%28%3F-i%29continue+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) 6.1K files Go `label: for ...` `break label;` `continue label;` [270 files](https://github.com/search?q=language%3AGo+%2F%28%3F-i%29break+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) [252 files](https://github.com/search?q=language%3AGo+%2F%28%3F-i%29continue+%5B_a-zA-Z0-9%5D%2B%3B%2F&type=code) 522 Ada `label: for ...` `exit label;` N/A N/A N/A Dart `label: for ...` `break label;` `continue label;` N/A N/A N/A Cpp2 (cppfront) `label: for ...` `break label;` `continue label;` N/A N/A N/A C `label: for (...)` `break label;` `continue label;` N/A N/A N/A Fortran `label: do ...` `exit label` N/A N/A N/A Groovy `label: for ...` `break label;` `continue label;` N/A N/A N/A Odin `label: for ...` `break label;` N/A N/A N/A PL/I `label: do ...` `exit label;` N/A N/A N/A PostgreSQL `<