> 1. It’s a novel syntax, for no particular reason beyond the concern that it might make people think “goto” should be used (labeled break and continue do not have goto semantics). ```label: continuable-breakable-statement``` is a widely used syntax at this point

I have to agree with the statement that you still have to write the goto yourself, it’s an intentional thing if you use it, it’s not like you can just opsie it into the code.
I’m not particularly convinced by the argument “because other languages did it like this, that we have to do it this way”, I can just counter-argue that with a “so what?”. The priority should be to do what’s best for C++, not make C++ to look like all other languages (even though it isn’t).

But the argument is that regardless of how you feel about it, a label is a label, it is something that already exists and is not going away, and it usually understood to have a global scope to the function.
And code like this can be written:

label1: for(…)
{
…
}

label2: while()
{
                break label1; //I know what it is but it’s invalid here
}

While obviously this code should be ill-formed (as it clearly violates the intention of the proposal), the fact that label1 is a thing that is observable when used is bound to lead to confusion and tempts misfortune. While compilers can handle this and correctly deduce it as a mistake just fine, the problem is more for humans.

While new syntax:

for label1 (…)
{
…
}

while label2 ()
{
                break label1; //I don’t know what is label1?
}

Makes the intention clear, it can only be explicitly naming the statement, and you can forget that it exists once you are out of the scope of the while/for loop. We use the “new syntax” to create the convention that we can forget things when no longer needed, it makes it “feel” more local, it “feels” more like complementing the obscured feature of break/continue as opposed to making break/continue just a glorified goto (which it is, not arguing that, but the idea you want to express is different, it’s much more constrained and structured than just a simple goto).

> 2. My understanding (from this thread) is that C is adopting the ```label: continuable-breakable-statement``` syntax

I think that’s a misunderstanding, a proposal is different from it being adopted. It is not adopted. N3355 and N377 are both suggestions to change the C language, not C++, and they are still both open. C++ would then need its own paper to adopt whatever C adopted in this field.
But I agree, it breaks with precedent if we were to do something different to C in this regard.
And whatever they adopt we should do to for sake of consistency.
I believe is what we can do in this regard is to band together and express the feelings that the C++ community has regarding this topic in order to help the decision move one way or the other. I’m pretty sure that there is a lot of work overlap between the two, perhaps the committee should help establish a work group to help both C and C++ come to a consensus on this feature and adopt it together.



From: Oliver Hunt <oliver_at_[hidden]>
Sent: Monday, January 6, 2025 8:38 PM
To: std-proposals_at_[hidden]
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] Bringing break/continue with label to C++




On Jan 6, 2025, at 9:02 AM, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

I think that we can all agree that the feature is useful and that we would like to see it in a future version of C++.
We are just arguing over how we are going to paint the bike shed.

Arguing that “goto should be overlooked because it is bad”…. at the end of the day is a thing that exists and it ain’t going away.

All we are trying to do is to bridge a synthetical gap where break/continue stop working when we nest these things together.
IMHO N3377 provides a better syntax overall because there’s less confusion surrounding it, don’t need to change much about the language, not because “goto’s are evil and we should avoid any confusion like the plague”, but because it’s clear and cannot be confused with a label regardless of where you stand in relation to “goto”.

Can you make N3355 work and still produce readable code by “exercising restraint on how you use it”? Yes.

It’s feels like personal preference at this point, I think the only way to settle this is by majority vote.
I don’t think we can make everyone happy.
Let’s just have a vote on it, have the feature, and move on.


Should goto work in constexpr context? Yes. But that is a separate discussion. If you write that paper I will support it, but it’s separate thing.

Yeah, I think there are many reasons for goto not being supported in constexpr (largely lack of structured control flow creates many avenues for UB, that makes constant evaluation harder, and there’s a large body of evidence that unstructured control flow is much more error prone than structured control flow).

If you really want constexpr goto, it’s a separate feature from labeled continue/break, and should be a different proposal.

That said I don’t really buy the argument people seem to be making that “labels” act as a back door into having goto where we don’t “want” it.

In constexpr, simply allowing label statements does not magically require adding support for goto - it’s completely independent.

Now, I oppose N3377 (or whichever is the ```for <label> …``` proposal, etc) for two main reasons:

1. It’s a novel syntax, for no particular reason beyond the concern that it might make people think “goto” should be used (labeled break and continue do not have goto semantics). ```label: continuable-breakable-statement``` is a widely used syntax at this point
2. My understanding (from this thread) is that C is adopting the ```label: continuable-breakable-statement``` syntax

The first is a weaker argument: “other languages do it this way” is not evidence that the approach is perfect, but if we want to diverge we should have actual strong arguments.

The second is IMO the much stronger argument: If C is adopting ```label: continuable-breakable-statement``` then every major C++ compiler will have to support the syntax (because every major C++ compiler is also a C compiler), *and* every C++ compiler will need to support the syntax when compiling C++, due to the frequent need to include C headers. So adopting N3377 (or whichever it is) does not mean C++ compilers would not support ```label: continuable-breakable-statement```, but would mean they would need to support both, and then you could imagine this nonsense:

```cpp

label1: for (…) {
  continue label1;
  for label1 (....)
    continue label1;
```

Obviously this is silly code, though macros seem to result in the most absurd code, so we would need to specify the behavior in such a case.

Cheers,
—Oliver





From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> On Behalf Of Simon Kraemer via Std-Proposals
Sent: Monday, January 6, 2025 5:34 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Simon Kraemer <sikraemer_at_[hidden]<mailto:sikraemer_at_[hidden]>>
Subject: Re: [std-proposals] Bringing break/continue with label to C++

Hi everyone,

IMHO the labels for break and continue are different from scope (and partially also intend) to the ones used for goto.
Is anyone objecting that the labels used with break and continue should be locally available?
Is anyone actually proposing that you should be able to break/continue a loop outside of the current function scope?

If not then maybe not treat it the same way and make it clear to the user that these two types of labels are actually different.
I would argue that it shouldn't even be called "label" but rather something like "name" or "id".

Apart from that I don't really care about it being either "for name(...){break name;}", "for(...) as name {break name;}" or something else.

BR
 Simon

Am Mo., 6. Jan. 2025 um 17:20 Uhr schrieb Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>:
On Mon, Jan 6, 2025 at 10:57 AM Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
> Trying to eliminate goto from the language is counterproductive.

We can talk about gotos or not but I think it’s a red herring.

C is adding labeled break/continue, C++ will too. As far as proposals go this should be pretty straightforward.

I think the only reason we're talking about labeled break/continue right now this month is that WG14 is still debating the syntax with which to add labeled break/continue.
There's the accepted proposal N3355 "Named loops"<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm>, which is the usual labeled-loop syntax we're all used to; but then there's also a proposal (again targeting C, not C++ yet) N3377 "An Improved Syntax for N3355"<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf>, which proposes a different syntax for the entire feature. The latter syntax doesn't use `FOO:`-style labels; it uses a new kind of thing that can't be targeted by `goto`. Hence the discussion of `goto` in this context.

Relevant blog posts:
https://quuxplusone.github.io/blog/2024/12/20/labeled-loops/
https://quuxplusone.github.io/blog/2024/12/22/labeled-loops-in-uthash/

More background on the `goto` thing: C++ has supported loops, break, continue, and (more to the point) `switch` in constexpr evaluation mode since C++14. C++ has never supported `goto` in constexpr. As Richard Hodges said, this isn't for any deep technical reason; it's because "goto is bad". (See N4472 "constexpr goto"<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4472.html> (2015), this SO answer from Barry Revzin<https://stackoverflow.com/questions/45266577/why-disallow-goto-in-constexpr-functions> (2017), etc.) That's relevant to the labeled-loop-syntax discussion because one of the arguments against the N3355 syntax is: "If we allow people to write FOO: before a loop, then that might be a gateway drug to writing `goto FOO`. Gotos are bad. We need a way to write labels that you can't `goto` to."
So (as I understand it) Richard was challenging the framing assumption there, by saying, hey, goto isn't bad after all — or at least not so bad that we need to be constantly guarding the wall against it.
And (and I understand it) Avi was pointing out that someone who really wants to guard the wall against `goto` could just implement `-Wgoto` in their compiler and then turn it on as an error. Ta-da, no more use of `goto`! (This hypothetical `-Wgoto` would be similar to existing diagnostics like `-Wvla` and my own Quuxplusone/Clang's `-Wctad`. AFAIK, noexisting compiler implements `-Wgoto` today.)

–Arthur
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals