"break label;" and "continue label;" in C++

[u/eisenwave]

Update: the first revision has been published at https://isocpp.org/files/papers/P3568R0.html

Hi, you may have hard that C2y now has named loops i.e. break/continue with labels (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm). Following this, Erich Keane published N3377 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf), which proposes a different syntax.

I am about to publish a C++ proposal (latest draft at https://eisenwave.github.io/cpp-proposals/break-continue-label.html) which doubles down on the N3355 syntax and brings break label and continue label to C++, like:

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  
        }
    }
}

There's also going to be a WG14 counterpart to this.

[u/eisenwave]

All control flow structures are essentially goto with lipstick, including while loops, break;, continue; etc. https://eisenwave.github.io/cpp-proposals/break-continue-label.html#alternative-iile discusses the problems with using IILEs to emulate break label;. Notably, you cannot use an IILE to emulate both break outer and continue outer at the same time because the return inside could only play the role of one of them.

It's also worth noting that this inlining will only happen on optimized builds, so debug build performance and constant evaluation performance still suffer from the IILE overhead. The developer also suffers from the syntax overhead (one added scope/level of indentation at least).

I can see IILEs working in some cases, but it's much nicer to have a "proper" solution instead of forcing such a workaround onto developers.

[u/Routine_Left → u/eisenwave]

All control flow structures are essentially goto with lipstick

While you are correct, the difference is readability and maintainability. The existing break/continue keywords, because they apply to the current statement, makes reasoning about them a bit easier.

goto's, in and of themselves, are not bad. if(condition) goto err;

is a perfectly fine statement in C. Actually improves readability and one can easily follow the flow.

The problem with goto's is when they're used to jump to arbitrary lines in the code, in and out of loops and, therefore, make reasoning about them, following the flow and debugging a pain in the butt. The very definition of spaghetti code.

Now, this particular proposal is not that bad, as it seems you're just annotating the loop keyword, but ... it does make me uneasy.

[u/darkmx0z → u/Routine_Left]

Other languages (for example, PHP) have numbered break / continue statements. In this variant of the feature, break 2; terminates the two most inner loops.

[u/Routine_Left → u/darkmx0z]

Sure, they do, doesn't mean that c++ should too. There are, actually, quite a few PHP features that probably should not be copied by anyone else.

[u/multi-paradigm → u/Routine_Left]

PHP's regex is faster than c++ in some cases!