> 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.
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.
I rarely write loops where the relationship between the loop control variables has anything meaningful to say about what the iterations did.