I don’t see this as arbitrary, so much as essential, given the current rules we have. It’s the only sensible extension of how scope works, what else could it possibly apply to?
I wouldn’t mind this at all. I’m not convinced it’s essential that this be enforced by the compiler, but it’s a less-strict version of my own style rule, and I don’t expect I could come up with a good counterexample for why this shouldn’t be an error.
That’s exactly why I never use break and continue without labels, if the loop they apply to isn’t clearly visible on the screen when I use it. My heuristic is quite a bit less than a full screen actually, blocks have a way of growing over time and I’d rather get labeling out of the way now than have to remember it while I thinking about something else.
It would be weird to get a compiler error like “while loop longer than 15 lines has a break, must add a label” but the equivalent for nested conditionals, it’s a reasonable suggestion.
I also comment the end of large conditioned blocks if the start isn’t visible:
frobnicating: while (frob.next()) |a_frob| {
// A great deal of code later...
} // end :frobnicating
Or just // end while, with perhaps the condition as well, if there’s no label. I think we’re modestly better off without Ada’s requirement to always label end conditions, but that rule exists for a reason and it’s cheap to take advantage of the clarity it provides.
Zig requires labels to be used, which I get but I sometimes want to be able to label things, both as documentation and to have it available if and when a continue or break enters the picture.
It’s part of the general “only live code” philosophy, and it means when reading code that if you see a label then you know it will be used. I’m on the fence about whether this is a good application of that philosophy though, because it doesn’t work both ways: if there isn’t a label, there could still be breaks and continues, so letting me document the purpose of a loop without imposing that requirement doesn’t seem so bad.