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;
      }
  }
}

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
>