Date: Tue, 07 Jan 2025 12:17:57 +0000
On 7 January 2025 08:57:18 GMT, Simon Kraemer via Std-Proposals <std-proposals_at_[hidden]> wrote:
>But using labels will cause problems with this:
>
>func1()
>{
> outer: for (…)
> {
> inner: for(…)
> {
> break outer;
> }
> }
>}
>
>func2()
>{
> outer: for (…) // label already defined
> {
> inner: for(…) // label already defined
> {
> break outer;
> }
> }
>}
No, labels are scoped to function bodies, that wouldn't be ill-formed.
>
>Am Di., 7. Jan. 2025 um 09:44 Uhr schrieb Simon Schröder via Std-Proposals <
>std-proposals_at_[hidden]>:
>
>> On 7. Jan 2025, at 07:44, Tiago Freire via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>
>> It's because we don't want things that you don't need from outstaying
>> their welcome. A label is a thing that outstays long after they are no
>> longer welcome.
>> It's probably fine, but do I need to keep constantly looking at my
>> shoulder to see if that label is going to stab me in the back?
>> Let me forget things that I no longer need, and keep things clean.
>>
>>
>> I agree with this. Naming things is hard. Most of the time I would expect
>> to see something like this:
>> outer: for (…)
>> {
>> inner: for(…)
>> {
>> break outer;
>> }
>> }
>> I just know that I want to break the outer loop. If I had a real name for
>> that loop it could most likely be a function. I’m not sure we know how to
>> name loops.
>>
>> Because ‘outer’ and ‘inner’ are the most obvious names it would be nice if
>> I can reuse those names for another loop in the same function (I personally
>> tend to ignore Clean Code when I have an algorithm that I just want to
>> write down top to bottom in a single function). If these are labels I
>> cannot have 2 loops both named ‘outer’ in the same function.
>>
>> Somebody might argue instead that this would be the reason to use labels
>> because they cannot be duplicate. It would avoid confusion if two loops
>> have the same name inside the same function.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>But using labels will cause problems with this:
>
>func1()
>{
> outer: for (…)
> {
> inner: for(…)
> {
> break outer;
> }
> }
>}
>
>func2()
>{
> outer: for (…) // label already defined
> {
> inner: for(…) // label already defined
> {
> break outer;
> }
> }
>}
No, labels are scoped to function bodies, that wouldn't be ill-formed.
>
>Am Di., 7. Jan. 2025 um 09:44 Uhr schrieb Simon Schröder via Std-Proposals <
>std-proposals_at_[hidden]>:
>
>> On 7. Jan 2025, at 07:44, Tiago Freire via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>
>> It's because we don't want things that you don't need from outstaying
>> their welcome. A label is a thing that outstays long after they are no
>> longer welcome.
>> It's probably fine, but do I need to keep constantly looking at my
>> shoulder to see if that label is going to stab me in the back?
>> Let me forget things that I no longer need, and keep things clean.
>>
>>
>> I agree with this. Naming things is hard. Most of the time I would expect
>> to see something like this:
>> outer: for (…)
>> {
>> inner: for(…)
>> {
>> break outer;
>> }
>> }
>> I just know that I want to break the outer loop. If I had a real name for
>> that loop it could most likely be a function. I’m not sure we know how to
>> name loops.
>>
>> Because ‘outer’ and ‘inner’ are the most obvious names it would be nice if
>> I can reuse those names for another loop in the same function (I personally
>> tend to ignore Clean Code when I have an algorithm that I just want to
>> write down top to bottom in a single function). If these are labels I
>> cannot have 2 loops both named ‘outer’ in the same function.
>>
>> Somebody might argue instead that this would be the reason to use labels
>> because they cannot be duplicate. It would avoid confusion if two loops
>> have the same name inside the same function.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
Received on 2025-01-07 12:18:04