Date: Wed, 18 Dec 2024 20:53:42 -0800
> On Dec 18, 2024, at 5:49 PM, Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On 12/19/24 03:21, Oliver Hunt via Std-Proposals wrote:
>>> On Dec 18, 2024, at 2:56 PM, Richard Hodges via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>> Isn't the solution to allow goto in constant expressions and unban it?
>>
>> Adding goto does nothing to help here.
>>
>> some_label: while(…) {
>> ...
>> goto some_label;
>> }
>>
>> Does not provide break *or* continue semantics which is what this feature is.
>>
>> Constexpr support for goto is not relevant.
>>
>>> It's been useful for 50 years. It seems like a lost cause to try to ban it on questionable ideological grounds.
>>
>> Yes, it has been “useful" because better alternatives - alternatives that exist in other languages - are not available in C and C++.
>
> Is there an objective metric by which those alternatives are better?
Yes. I literally just gave an example, which is the entire motivation of this proposal: goto does not support continue or break semantics.
> 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. The remaining use cases are all handled better as “terminate this scope” (that’s labeled break and continue) or “defer” (cleanup on exit of scope for values that aren’t managed by RAII objects). All of which are better handled directly than hacked up haphazardly on top of goto, which is a model that demonstrably leads to incorrect code.
—Oliver
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> On 12/19/24 03:21, Oliver Hunt via Std-Proposals wrote:
>>> On Dec 18, 2024, at 2:56 PM, Richard Hodges via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>> Isn't the solution to allow goto in constant expressions and unban it?
>>
>> Adding goto does nothing to help here.
>>
>> some_label: while(…) {
>> ...
>> goto some_label;
>> }
>>
>> Does not provide break *or* continue semantics which is what this feature is.
>>
>> Constexpr support for goto is not relevant.
>>
>>> It's been useful for 50 years. It seems like a lost cause to try to ban it on questionable ideological grounds.
>>
>> Yes, it has been “useful" because better alternatives - alternatives that exist in other languages - are not available in C and C++.
>
> Is there an objective metric by which those alternatives are better?
Yes. I literally just gave an example, which is the entire motivation of this proposal: goto does not support continue or break semantics.
> 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. The remaining use cases are all handled better as “terminate this scope” (that’s labeled break and continue) or “defer” (cleanup on exit of scope for values that aren’t managed by RAII objects). All of which are better handled directly than hacked up haphazardly on top of goto, which is a model that demonstrably leads to incorrect code.
—Oliver
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-12-19 04:53:44