Break also considerably complicates loop semantics. For example you can no longer rely on the loop condition being false on loop termination. Instead you have to do a flow analysis of every loop and conditional leading to the break to determine the established postcondition.

True, but the person I responded to wants multiple exits in tail-recursive functions which introduces the same complications as multiple exits in loops, non-recursive functions, and non-tail-recursive functions.

If you're trying to do control flow analysis on an AST, you're going to have a bad time. The article is a blinking red advertisement to not try to analyze loops at the source level.

I did spend about half the article going "... why are you trying to do analysis based on the AST instead of using a control-flow-graph-based IR?"

But for a programmer break is wonderful. Maybe you have a loop condition for a normal exit and use break if an unusual condition (eg EOF) occurs.

"Well, I'm done with this now" is a very nice, simple, and most importantly obvious addition to a mental model that will translate to things they've been doing since they were toddlers.

It has consequences, but it's first week sort of thing because it's so easy/relatable.

> For example you can no longer rely on the loop condition being false on loop termination. Instead you have to do a flow analysis of every loop and conditional leading to the break to determine the established postcondition.

I rarely write loops where the relationship between the loop control variables has anything meaningful to say about what the iterations did.

Simple example: Get input from the user until the input matches a condition, often "is it a number?".

Even if that’s true (and you may be more often than you realize), you still rely on a great deal of code that does, like searching and sorting.

It is a little disappointing how few programmers know how to construct a nontrivial loop that both always terminates and does what it’s supposed to for all inputs.

Binary search is a classic example. If you think it’s trivial to get right, you probably aren’t. Knuth has some interesting things to say about it in The Art of Computer Programming.

Binary search is a great example of why you can't just look at the loop control variables to understand what body does for the iterations.

You have to look at both. If it turns out that the body's behavior can be easily described in terms of the loop control variables (or the reverse), great, but assuming that it does and trying to fix up things when that gets complicated is a disaster.

Of course, if you dislike break, you can fake it with continue and a flag, as long as your loop control guarantees termination. However, that complicates understanding the loop's behavior in terms of said control.