Seriously?

yep - i am not saying there are no cases for using it, but use of it is always worth looking at.

Same whenever I see a do...while loop.

Nothing wrong with a do...while loop, but I've learned to look twice when crossing that particular street. Most loops that don't have bugs tend to support zero iterations seamlessly and inherently.

If you squint, aren't those the same case?

um, a do...while always does something at least once - a for-loop not.

I was trying to say that the difference between a for loop with < and a for loop with <= is roughly the same as the difference between a while loop and a do-while loop, and to whatever degree that's true they might be due suspicion for the same reason.

I agree with parent. do-while communicates that a thing will always execute once, and maybe more, and a while or for loop (even in the higher level for-each/for-in case) may never execute at all.

Being able to choose the right control structure (and data structures) can provide additional information to the correctness of the code than arbitrary choices which may perform the same function. Choosing the Most expressive options may or may not conflict with performance, in which case, comments are helpful to describe why more obvious approaches weren’t taken.

zabzonk is obviously correct about the behavior of the control structures - that's not something I ever meant to disagree about.

The thread had had one poster state they find <= suspicious in a for loop, and another about any do-while loop. I don't think these are literally the same thing (hence "if you squint") but I think they share a meaningful similarity of adding an extra pass through the loop compared to the other form and I thought that was interesting.

x <= y isn't two tests.

In a low-level sense, branch-if-greater-or-equal is one instruction even on RISC machines — and not one any more "complex" than branch-if-greater.

In an abstract boolean-algebra sense, x <= y is the same as !(x > y).

> x <= y is the same as !(x > y)

i.e. two tests, or perhaps i should say logical operations. i'm not saying don't use '<=', but do check that it is doing what you think it should.

Let me put it another way: the following are the same code:

if: x <= y, do: foo(), else: nothing()

if: y < x, do: nothing(), else: foo()

Shouldn't the last statement be:

if: y > x, do: nothing(), else: foo()

Nope, order of evaluation might matter with impure code.

How exactly? Well there is an extreme case where x and y are volatile but even then the order is implementation defined so I can't see a world where it matters.