Date: Thu, 19 Dec 2024 08:39:26 +0100
> I personally agree with N3377, N3355 is simply too ambiguous and would break code.
To my knowledge, no existing code is broken. Even with changes to
label semantics, existing uses of goto remain valid and unaffected.
> We are trying to name a control flow statement, not create a jump point.
We are, and why should we not use the same syntax for both? "int x"
can declare a variable, or declare a function parameter. Just because
syntax is reused for multiple purposes doesn't imply some fundamental
problem, and I'm not seeing any problem which couldn't be addressed by
fixing labels up a bit more.
> name:
>
> for()
> {}
We have bigger issues than code like this. This just feels intuitively
wrong; a label should be placed where it is applied. It could make
sense to diagnose cases like this with clang-tidy or compiler
warnings, since it's quite likely that the user forgot to write the
semicolon in "name;" or something. Either way, goto name: still "goes
to name", and "break name" still breaks the for loop with this label,
if the user intended to label the loop. This seems pretty much OK,
just poor style.
Overall, I think it's a complete waste of effort to prefer the N3377
syntax to cater to goto users. It is possible to relax changes to
label semantics so they behave like Java, JavaScript, Rust, Kotlin
etc. labels. Inventing a whole new syntax for labeling loops without
any prior art is the much greater evil.
Also keep in mind that many uses of goto are being replaced with
labeled break/continue, so it makes even less sense to treat the
goto/label constructs with silk gloves. "goto past_the_outer_loop" was
perhaps the most mainstream use of goto. The only other remaining
"mainstream" use of "goto" at that point is the "goto error" idiom. If
this also gets replaced in the future, perhaps through "defer" or some
other form of lightweight RAII, it will have been an enormous
historical blunder to cater to this dead language construct.
I say replace goto, use the well-established and well-known syntax
we've had for 40 years.
To my knowledge, no existing code is broken. Even with changes to
label semantics, existing uses of goto remain valid and unaffected.
> We are trying to name a control flow statement, not create a jump point.
We are, and why should we not use the same syntax for both? "int x"
can declare a variable, or declare a function parameter. Just because
syntax is reused for multiple purposes doesn't imply some fundamental
problem, and I'm not seeing any problem which couldn't be addressed by
fixing labels up a bit more.
> name:
>
> for()
> {}
We have bigger issues than code like this. This just feels intuitively
wrong; a label should be placed where it is applied. It could make
sense to diagnose cases like this with clang-tidy or compiler
warnings, since it's quite likely that the user forgot to write the
semicolon in "name;" or something. Either way, goto name: still "goes
to name", and "break name" still breaks the for loop with this label,
if the user intended to label the loop. This seems pretty much OK,
just poor style.
Overall, I think it's a complete waste of effort to prefer the N3377
syntax to cater to goto users. It is possible to relax changes to
label semantics so they behave like Java, JavaScript, Rust, Kotlin
etc. labels. Inventing a whole new syntax for labeling loops without
any prior art is the much greater evil.
Also keep in mind that many uses of goto are being replaced with
labeled break/continue, so it makes even less sense to treat the
goto/label constructs with silk gloves. "goto past_the_outer_loop" was
perhaps the most mainstream use of goto. The only other remaining
"mainstream" use of "goto" at that point is the "goto error" idiom. If
this also gets replaced in the future, perhaps through "defer" or some
other form of lightweight RAII, it will have been an enormous
historical blunder to cater to this dead language construct.
I say replace goto, use the well-established and well-known syntax
we've had for 40 years.
Received on 2024-12-19 07:39:38