Date: Mon, 6 Jan 2025 11:20:27 -0500
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_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
Received on 2025-01-06 16:20:44