testing or updating the wrong variable), especially when counting down instead of up.Ĭ’s for loop also works well with a couple of its other ultra-concise features: implied tests for zero/null, and assignments within expressions - features which are neat but error-prone, and don’t scale well to larger programs. For a common fixed-count iteration, you need to specify the loop variable three times, which discourages long and meaningful names the order of clauses doesn’t match the usual thought process (putting the increment after the upper limit) it’s very easy to get the termination condition wrong ( <= vs <) and other mistakes are also surprisingly easy to make and hard to spot (e.g.

However, the price for that flexibility is complexity, verbosity, and difficulty of reading and maintaining. So the author clearly felt there was a need for some special cases, even then…) (However, note that C also has while () and do…while () loops, even though the for () loop can cover those cases too. So C didn’t need separate language constructs for all these different types of loop: the single for () does them all. Its flexibility allowed you to write any type of loop: loops that iterated a fixed number of times loops that iterated until a condition was met loops that increment a counter, or decrement it, or follow pointer chains, or anything, or nothing you could even control multiple loop variables with it. When it was introduced, the old-style for () loop had one major advantage: it was comprehensive.

But is there sufficient reason to do so? Not that I can see. First, a nitpick: Kotlin can’t keep the old-style for () loop, because it never had it in the first place! So this question is really a proposal to add it to the language.

Kotlin for loop with index