Date: Mon, 6 Jan 2025 17:02:46 +0000
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.
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, no existing 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
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.
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, no existing 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
Received on 2025-01-06 17:02:49