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
>