Date: Thu, 19 Dec 2024 18:07:20 +0100
On Thu, 19 Dec 2024 at 17:42, Oliver Hunt via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Dec 19, 2024, at 2:32 AM, Andrey Semashev via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> On 12/19/24 07:53, Oliver Hunt wrote:
>
>
>
> Yes. I literally just gave an example, which is the entire motivation of
> this proposal: goto does not support continue or break semantics.
>
>
> It does. It's just your example (I'm assuming, it's the one quoted
> above) is incorrect wrt. the existing goto semantics.
>
>
>
> Please, show me goto supporting the same semantics of labeled continue:
>
> label1: while (cond) {
> for (….) {
> if (x) continue label1;
> }
> }
>
extern bool cond();
extern void something(int);
void test()
{
while (cond())
{
for (int i = 0 ; i < 100 ; ++i) {
if (i == 50) goto continueat1;
something(i);
}
continueat1: ;
}
}
https://godbolt.org/z/7bzo3W75z
No such thing as can't in C++
>
> label1: for (int i = 0;i < n;i++) {
> for (….) {
> if (x) continue label1;
> }
> }
>
> label1: for (auto a: vec) {
> for (….) {
> if (x) continue label1;
> }
> }
>
>
>
>
> Because the motivation I've seen so far is "because people think goto is
> bad because... we don't like it" which is subjective. I, for one, do not
> see how a labeled break is better than a goto. In fact, I think it's
> worse because it breaks the existing label usage. Previously, switch and
> goto would jump to a label, now break and continue with a label jump
> somewhere else instead of the label.
>
> Honestly, people, just use goto. There's nothing wrong with it.
>
>
> The semantics of goto are garbage, and all uses of it are coupled with
> “but don’t use it in ways X, Y, or Z” , where X, Y, *and* Z are *all*
> valid in the language.
>
>
> Goto is as straightforward as it possibly can be. More straightforward
> than break or continue, for instance, since unlike those, goto's target
> is clearly marked. The "don't use goto" narrative is garbage and
> subjective. Goto is objectively useful in some contexts and there's
> nothing wrong with using it there. Same as any other tool.
>
>
> It is “straight forward” that does not mean it is good.
>
>
> Instead you're inventing another tool that is basically the same
>
>
> (1) Not inventing: this is a common syntax and idiom that is available in
> more or less every other C-esque syntax language
> (2) It is not the same: goto does not support continue
> (3) It is completely unstructured which means you have no defense against
> code motion causing radically different behavior
>
> I get that you believe this is unnecessary, but the entirety of your
> argument is “I can do this [questionably] with goto”, and that same
> argument applies to all language provided loop constructs and I don’t see
> you arguing that while/for loops are unnecessary as we have goto, or that
> virtual methods are unnecessary as we have function pointers, etc.
>
> —Oliver
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
>
>
> On Dec 19, 2024, at 2:32 AM, Andrey Semashev via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> On 12/19/24 07:53, Oliver Hunt wrote:
>
>
>
> Yes. I literally just gave an example, which is the entire motivation of
> this proposal: goto does not support continue or break semantics.
>
>
> It does. It's just your example (I'm assuming, it's the one quoted
> above) is incorrect wrt. the existing goto semantics.
>
>
>
> Please, show me goto supporting the same semantics of labeled continue:
>
> label1: while (cond) {
> for (….) {
> if (x) continue label1;
> }
> }
>
extern bool cond();
extern void something(int);
void test()
{
while (cond())
{
for (int i = 0 ; i < 100 ; ++i) {
if (i == 50) goto continueat1;
something(i);
}
continueat1: ;
}
}
https://godbolt.org/z/7bzo3W75z
No such thing as can't in C++
>
> label1: for (int i = 0;i < n;i++) {
> for (….) {
> if (x) continue label1;
> }
> }
>
> label1: for (auto a: vec) {
> for (….) {
> if (x) continue label1;
> }
> }
>
>
>
>
> Because the motivation I've seen so far is "because people think goto is
> bad because... we don't like it" which is subjective. I, for one, do not
> see how a labeled break is better than a goto. In fact, I think it's
> worse because it breaks the existing label usage. Previously, switch and
> goto would jump to a label, now break and continue with a label jump
> somewhere else instead of the label.
>
> Honestly, people, just use goto. There's nothing wrong with it.
>
>
> The semantics of goto are garbage, and all uses of it are coupled with
> “but don’t use it in ways X, Y, or Z” , where X, Y, *and* Z are *all*
> valid in the language.
>
>
> Goto is as straightforward as it possibly can be. More straightforward
> than break or continue, for instance, since unlike those, goto's target
> is clearly marked. The "don't use goto" narrative is garbage and
> subjective. Goto is objectively useful in some contexts and there's
> nothing wrong with using it there. Same as any other tool.
>
>
> It is “straight forward” that does not mean it is good.
>
>
> Instead you're inventing another tool that is basically the same
>
>
> (1) Not inventing: this is a common syntax and idiom that is available in
> more or less every other C-esque syntax language
> (2) It is not the same: goto does not support continue
> (3) It is completely unstructured which means you have no defense against
> code motion causing radically different behavior
>
> I get that you believe this is unnecessary, but the entirety of your
> argument is “I can do this [questionably] with goto”, and that same
> argument applies to all language provided loop constructs and I don’t see
> you arguing that while/for loops are unnecessary as we have goto, or that
> virtual methods are unnecessary as we have function pointers, etc.
>
> —Oliver
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-12-19 17:07:36