On Dec 19, 2024, at 2:32 AM, Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

On 12/19/24 07:53, Oliver Hunt wrote:


Yes. I literally just gave an example, which is the entire motivation of
this proposal: goto does not support continue or break semantics.

It does. It's just your example (I'm assuming, it's the one quoted
above) is incorrect wrt. the existing goto semantics.


Please, show me goto supporting the same semantics of labeled continue:

label1: while (cond) {
   for  (….) {
     if (x) continue label1;
   }
}

label1: for (int i = 0;i < n;i++) {
   for  (….) {
     if (x) continue label1;
   }
}

label1: for (auto a: vec) {
   for  (….) {
     if (x) continue label1;
   }
}




Because the motivation I've seen so far is "because people think goto is
bad because... we don't like it" which is subjective. I, for one, do not
see how a labeled break is better than a goto. In fact, I think it's
worse because it breaks the existing label usage. Previously, switch and
goto would jump to a label, now break and continue with a label jump
somewhere else instead of the label.

Honestly, people, just use goto. There's nothing wrong with it.

The semantics of goto are garbage, and all uses of it are coupled with
“but don’t use it in ways X, Y, or Z” , where X, Y, *and* Z are *all*
valid in the language.

Goto is as straightforward as it possibly can be. More straightforward
than break or continue, for instance, since unlike those, goto's target
is clearly marked. The "don't use goto" narrative is garbage and
subjective. Goto is objectively useful in some contexts and there's
nothing wrong with using it there. Same as any other tool.

It is “straight forward” that does not mean it is good. 


Instead you're inventing another tool that is basically the same

(1) Not inventing: this is a common syntax and idiom that is available in more or less every other C-esque syntax language
(2) It is not the same: goto does not support continue
(3) It is completely unstructured which means you have no defense against code motion causing radically different behavior

I get that you believe this is unnecessary, but the entirety of your argument is “I can do this [questionably] with goto”, and that same argument applies to all language provided loop constructs and I don’t see you arguing that while/for loops are unnecessary as we have goto, or that virtual methods are unnecessary as we have function pointers, etc.

—Oliver