C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Bringing break/continue with label to C++

From: Tiago Freire <tmiguelf_at_[hidden]>
Date: Thu, 19 Dec 2024 07:51:11 +0000
goto isn't going anywhere, you still need a workable language in which you can properly express what things mean without ambiguity.

I quite strongly disagree that 'The only other remaining "mainstream" use of "goto" at that point is the "goto error" idiom', even though I agree that "goto" use cases are rare, when you need it they are the best tool for the job and for that reason it will never go away.
But most importantly it will not go away when and if this feature is adopted.

So "having a language where you can express what you mean" beats everything else.


-----Original Message-----
From: Jan Schultke <janschultke_at_googlemail.com>
Sent: Thursday, December 19, 2024 8:39 AM
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_lists.isocpp.org
Subject: Re: [std-proposals] Bringing break/continue with label to C++

> I personally agree with N3377, N3355 is simply too ambiguous and would break code.

To my knowledge, no existing code is broken. Even with changes to label semantics, existing uses of goto remain valid and unaffected.

> We are trying to name a control flow statement, not create a jump point.

We are, and why should we not use the same syntax for both? "int x"
can declare a variable, or declare a function parameter. Just because syntax is reused for multiple purposes doesn't imply some fundamental problem, and I'm not seeing any problem which couldn't be addressed by fixing labels up a bit more.

> name:
>
> for()
> {}

We have bigger issues than code like this. This just feels intuitively wrong; a label should be placed where it is applied. It could make sense to diagnose cases like this with clang-tidy or compiler warnings, since it's quite likely that the user forgot to write the semicolon in "name;" or something. Either way, goto name: still "goes to name", and "break name" still breaks the for loop with this label, if the user intended to label the loop. This seems pretty much OK, just poor style.

Overall, I think it's a complete waste of effort to prefer the N3377 syntax to cater to goto users. It is possible to relax changes to label semantics so they behave like Java, JavaScript, Rust, Kotlin etc. labels. Inventing a whole new syntax for labeling loops without any prior art is the much greater evil.

Also keep in mind that many uses of goto are being replaced with labeled break/continue, so it makes even less sense to treat the goto/label constructs with silk gloves. "goto past_the_outer_loop" was perhaps the most mainstream use of goto. The only other remaining "mainstream" use of "goto" at that point is the "goto error" idiom. If this also gets replaced in the future, perhaps through "defer" or some other form of lightweight RAII, it will have been an enormous historical blunder to cater to this dead language construct.

I say replace goto, use the well-established and well-known syntax we've had for 40 years.

Received on 2024-12-19 07:51:14