Date: Thu, 19 Dec 2024 13:32:01 +0300
On 12/19/24 07:53, Oliver Hunt wrote:
>
>
>> 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.
It does. It's just your example (I'm assuming, it's the one quoted
above) is incorrect wrt. the existing goto 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.
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.
Instead you're inventing another tool that is basically the same, only
which subverts labels in unexpected and inconvenient way (because in
order to understand where a break jumps you first need to scroll up to
see which loop it associates with and then scroll down to find the
matching closing brace, and I hope you don't pick the wrong brace in the
process), and propose to use that. That doesn't make sense to me.
>
>
>> 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.
It does. It's just your example (I'm assuming, it's the one quoted
above) is incorrect wrt. the existing goto 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.
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.
Instead you're inventing another tool that is basically the same, only
which subverts labels in unexpected and inconvenient way (because in
order to understand where a break jumps you first need to scroll up to
see which loop it associates with and then scroll down to find the
matching closing brace, and I hope you don't pick the wrong brace in the
process), and propose to use that. That doesn't make sense to me.
Received on 2024-12-19 10:32:05