> On Dec 18, 2024, at 11:18 PM, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I personally agree with N3377, N3355 is simply too ambiguous and would break code.
>
> Let's think about what we are trying to achieve in this case.
> We are just trying to give a name to a for/while/do/switch such that when we use "break/continue", we are able to identify exactly which for/while/do/switch do we mean.
> Calling it a "label" is slightly misleading as it leads to confusion with the "goto label" which names a singular point in the code that can be jumped into regardless of any surrounding code (within certain limitations).
> We are trying to name a control flow statement, not create a jump point.
>
>
> The problem is, if
> `
> name: for()
> {
> }
> `
> names the "for" the loop, so does this:
> `
> name:
>
> for()
> {}
> `
>
> Now, did I mean name the "for" or create a "goto label"?

You created a label. That label can be used to reference the loop for break and continue without a problem. Just as it is in every other language that supports labeled continue and break.

There is no ambiguity: break and continue are not *goto*. There is no such thing as a “goto label” or a “break label” or a “continue label”. There is a label. If the label is a loop or switch header, then continue and break can point to it because they apply to loops. If the label points to a construct for which break or continue are not appropriate it is not valid, this is no different from break or continue being invalid outside of an appropriate control structure.

The *only* question is does:
label1:
label2:
while (..) …

Permit “continue/break label1”. In many languages it is invalid (labels are explicitly part of the grammar of the loop/whatever construct) but others (like JS) consider all labels preceding a construct as valid labels for that construct.

Your example here is no different from saying

int

x = 5;

Did you intend to have a separate variable declaration there? Maybe - who knows, but the compiler certainly does not care.

Nothing stops someone from writing hard to read code. But hard to read does not mean “different semantics”.

Labeled continue and break are not new, they are not novel, and nor is the syntax being proposed. The only argument given for not just using the same syntax is the somewhat dubious reference to label break/continue in macros, but that if that really is a problem that can be trivially handled by saying “labels are scoped for the purpose of break and continue”, and saying "a function cannot simultaneously use cross scope goto and have duplicate labels."

—Oliver