Break statements in labelled switches, footgun?

Brainstorming
21

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.

2 Likes
22

I don’t dislike the idea of seeing something like the end comment in my editor, however I dislike manually writing such comments, I think if / when I would like to see something like this, the editor should just show a description there, similar to an inlay hint it could generate “} end :frobnicating”.

Possibly styled in a specific way so that it isn’t confused with inlayhints or code/text that actually exists in the file.

This also reminds me a bit of this “sticky scroll” feature About the Editor Sticky Scroll feature - Visual Studio (Windows) | Microsoft Learn
So far I haven’t used it, but I think I should try it out.

Don’t know whether that feature already exists in lazyvim somewhere.

1 Like
23

An advantage of the comment actually existing is that I can use it to navigate, it shows up in grep, etc.

Not a crazy thing for a language server to do. I think it’s better to actually write the comment out, so I’d at least want the server to be smart enough to check for the comment first.

I’m mildly opposed to this addition actually, for a couple reasons. If the labeled block is only 5-10 lines, the hint would just be noise, and for the larger blocks it really is a good idea for the hint to be an actual part of the source code, and I think this would inhibit that practice.

Similarly, I’m mostly glad that Zig has inferred result types, and inferred error sets, but they’re very easy to overuse. Especially inferred error sets, which have a way of spreading: we call a function and it’s just !T, and it feels like a pain in the butt to deal with the error set because who knows what’s in it, so the temptation is to punt and slap a try on the function call and a ! on the return value and propagate the problem. Or use a catch unreachable which is worse.

I try and make a point of doing proofreading passes, especially on library code, where I fix (as in pin down, rather than repair) the errors sets of error-unioned return types, but this is of course extra work and somewhat unrewarding. Doing it as I go along isn’t ideal either because it inhibits flexibility in changing functions, add a new error value and you have to switch gears and think about errors again instead of whatever you were working on.

This is something I would love to have language server support for, just type a magic sequence on an inferred ! and get the actual error set in the code.

There’s a balance to be struct between explicit and verbose, to reach optimal readability of a given block of code. Always a judgement call involved.

2 Likes