Attaching labels to do/for/while/switch statements and having gotos target
them is already legal in C and C++. If someone needs that construct, they
can already use it whether the would-be masters of C++ style like it or
not. So the argument against using those labels for break/continue seems to
be that programmers would not normally write such gotos, but once they
attach the labels, the temptation will be so overwhelming that they won't
be able to help themselves. Which ... I can't even.

On Mon, Jan 6, 2025 at 3:45 PM Oliver Hunt via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Jan 6, 2025, at 12:15 PM, Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
>
>
> > 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 mean `continue label`, `break label`, are not equivalent to goto label,
> for
>
> ```cpp
> label: statement-header { break/continue label; }
> ```
>
> I think in a prior email we showed that `continue label;` could not be
> replicated with goto without a _lot_ of syntactic nonsense going on.
>
>
> 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).
>
>
> Yeah, like I said it’s the weaker argument, and other languages don’t have
> the same historical constraints as C++, I just feel that if we do diverge
> it sure be for more solid reasons than “labels are like goto"
>
>
> 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.
>
>
> Exactly, I don’t consider this a real problem, we can continue saying
> “labels are unscoped” without allowing the above `break label1` to be valid
> - break/continue already have scoped semantics, and saying
> “(continue|break) label requires label be applied to the containing control
> flow construct”.
>
>
> 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).
>
>
> We could also say “if you use continue/break label” that label becomes
> lexically scoped - it’s not necessarily the nicest, but it would work -
> essentially continue/break label implicitly removes label from the allowed
> goto targets.
>
> The problem there is that while unscoped labels are irksome and bad, I
> think that even removing that constraint runs into problems. A lot of the
> unscoped examples in this thread were things like
>
> ```cpp
> {
> label: for (…) { continue label; }
> }
> {
> label: for (…) { continue label; }
> }
> ```
>
> But even if we discard “unscoped” lookup for labels, and say lets assume
> lexical scoping:
>
> ```cpp
> label: for (…) { continue label; }
> label: for (…) { continue label; }
> ```
> Where `label` is in the same scope, there’s no weird “cross scope”
> behavior, but lexically scoping the label doesn’t resolve the conflict. To
> be clear “correctly” targeting the continue is still entirely doable, but
> only by introducing a weird variation on label behaviour.
>
> Other languages are able to handle this because labels aren’t a standalone
> statements, they’re generally a production along the lines of
>
> ```
> <Ident> ‘:’ <statement>
> ```
>
> e.g. they’re implicitly scoped.
>
>
> > 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.
>
>
> Ah ok, the prior comments made it sound like C had already chosen that, if
> it has not actually finalized such a choice, it’s somewhat moot as an
> argument.
>
> 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.
>
>
> I realize one other problem I have with `for label ( … )` syntax is that
> it is adding yet more tokens into that same section of the grammar, and
> it’s starting to be really noisy, e.g
>
> ```
> for template consteval label ( …. ) { … }
> ```
>
> Starts to intermingle the name of the loop with the actual type of the
> control structure.
>
> I wonder if I’d feel less unhappy with something like:
> ```
> for .. (label: …)
> ```
>
> Except of course that’s ambiguous with `for(:)` because language design is
> miserable :D
>
> —Oliver
>
>
>
>
> *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]> 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]>:
>
> On Mon, Jan 6, 2025 at 10:57 AM Jeremy Rifkin via Std-Proposals <
> 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, no
> *existing* compiler implements `-Wgoto` today.)
>
> –Arthur
> --
> Std-Proposals mailing list
> 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
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>