> On Jan 6, 2025, at 9:02 AM, Tiago Freire via Std-Proposals <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]> On Behalf Of Simon Kraemer via Std-Proposals
> Sent: Monday, January 6, 2025 5:34 PM
> To: std-proposals_at_[hidden]
> Cc: Simon Kraemer <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_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals