C-style loops can allow for arbitrary increments

This is especially visible when the increment is some non-constant calculation, like when I was trying to implement an optimized prime checker in Kotlin, which doesn’t have C style for loops. As noted in the comments, you can also go back (have a negative increment) using C-style for loops.

The C style doesn't work with parallel programming

Some languages would want to add some built-in support for parallel programming in the basic looping constructs. A C style for doesn't work well in this case. If the language has only C style for, it would surprise the programmer when they want to change something to parallel.

There are cases that a foreach cannot work well, for example in the cases with non-constant increment. But a for loop also doesn't fully replace foreach with parallel programming in consideration.

A foreach loop is an instance of a for loop, and a for loop is an instance of a while loop. Each is less general than the next.
In particular foreach is specially crafted to loop over items in some collections where both for and while give you control over the looping mechanism.

Here are some examples of for loops which may or may not be translatable to an equivalent foreach:

• Looping over a constant range:

  for(int x = start; x ⩽ end; x += n) {} 

• Looping over a variable range:

  int n = initialStride; for(int x = start; x ⩽ end; x += n) { n = f(x); } 

• Looping over an integral's digits:

  for( int x = n, digit = x % radix; x ≠ 0; x = floor(x / radix), digit = x % radix ) {} 

• Following pointers:

  struct S { struct S* next; } for(struct S* p = start; p; p = p->next) {} 

• Iterating over a segmented list:

  struct S { struct S* next; size_t length; int elems[length]; }; assert(start); for( struct S* sp = start, size_t ep = 0; sp && ep < sp->length; (++ep == sp->length) ? (sp = sp->next, ep = 0) : 0 ) {} 

• Iterating over multiple lists at once:

  for( int (*lp)[] = &xs, size_t i = 0, elem = (*lp)[0]; i ≠ END; ++i, lp = (lp == &xs ? &ys : &xs), elem = (*lp)[i] ) {} 

• Looping with initialisation and incrementation clauses being unrelated to the condition:

  S* p; for(xs.prealloc(); p = xs.next(); free(p)) {} 

In fact when writing macros, it is common to use for's incrementation clause as a way to defer code evaluation.
Here are some examples:

• lock:

  #define lock(mutex) _lock_impl(UNIQUE_ID(_lock_id_), mutex) #define _lock_impl(id, mutex) mtx_lock(mutex); for(char id = 1; id--; mtx_unlock(mutex)) 

  Example use:

  void f() { static mtx_t mtx = GLBL_MUTEX_INIT; lock(mtx) { printf("synchronised output\n"); } } 

• with resource:

  #define with(init, deinit) _with_impl(UNIQUE_ID(_with_id_), init, deinit) #define _with_impl(id, init, deinit) char id = 1; for(init; id--; deinit) 

  Example use:

  int main() { with(FILE* f = fopen("./input.txt", "r"), fclose(f)) { fseek(f, 0, SEEK_END); long int length = ftell(f); fseek(f, 0, SEEK_SET); with(char* buf = malloc(length), free(buf)) { fread(buf, 1, length, f); printf("%s", buf); } } } 

both assuming GNU C's __COUNTER__ and

#define UNIQUE_ID(prefix) CONCAT(prefix, __COUNTER__) #define CONCAT(x, y) _CONCAT_IMPL(x, y) #define _CONCAT_IMPL(x, y) x##y 

Avoiding off-by-one errors

If you're not concentrating, it it really easy to get an off-by-one error with a C-style for loop.

For example, if I want to loop 10 times:

for (i=0; i<=10; i++) { // do stuff } 

actually loops 11 times.

But,

for i in range(10): # do stuff 

is a lot harder to get wrong

Flexibility is both a pro and a con of C-style for-loops.

You can have a for-loop with an arbitrary setup, arbitrary condition and arbitrary "increment" expressions.

This also means that

for (A; B; C) { body; } 

is just syntactic sugar for

{ // Block limits scope of variable declarations in A. A; while (B) { body; C; } } 

... and depending on the specifics, having that syntactic sugar may not be worth it.

One major advantage of a foreach loop is that it makes safe bounds check removals a lot easier for the compiler. A C-style loop requires the compiler to prove a relation between the index and the array while the foreach gets bounds check removal for basically free.

For each is much more ergonomic, declarative, and can even make some optimisations possible like removing bounds checking.

However, compared to C style for loops it’s much less obvious how it compiles to efficient machine code, so in most languages for each is slower than an equivalent C style loop.

The exception is languages with zero cost abstraction, specifically ones with lots of static dispatch and inlining which can compile for each down to the same thing as a C style loop.

1. C style loop allows joining multiple arrays by index:

for (size_t i = 0; i < a.size(); i++) { do_something_together(a[i], b[i]); } 

The use cases are the same as for the join statement in SQL:

select a.x, b.y from a join b on (a.p == b.p) 

Here also one may argue, "keep all fields you would ever need together in one table". Unfortunately this does not always work and it may be more important things influencing the clarity of the code. There is often no obvious and easy construct to iterate over multiple arrays, having values at the same position of each array together. See this question for the possible approaches, many of them look complex. This is difficult to add later and should be built into the language, envisioning something like

for (ax: a join bx: b) { do_something_together(ax, bx); } 

Of course, to be efficient this should not work just by copying. It should be an assertion that the arrays have the same dimensions or otherwise just "outer join" (loop terminates after reaching the boundary of the shorter array).

I am mostly using the "for each" style loops, but some need to be reworked into "old style" loops if they use two or more arrays this way in the iteration.

2. There are also cases when adjacent elements are needed:

for (size_t i = 1; i < a.size(); i++) { double difference = a[i] - a[i-1]; ... } 

This needs precautions for the first or last member of the array, anyway you also need another member that is not available in the "modern" ranged loop. Algorithms like filtering, smoothing, differentiating and the like often need access to the values that are spread around the current index. Here is the access as required, for the 2D array, by Crank-Nicolson method, the golden classic of numeric computation (image credit):

3. There may be cases when just the number of the iteration is needed, like printing the numbered list. It is very stupid when you cannot easily get it and need to define and maintain a separate counter. The question has been asked here, and, again, most of solutions are just too complex to be practical.

4. Least, not the last: identifying the first and the last iteration. The most obvious case is when all you need is to produce the comma delimited list of items: it must be no comma after the last item. See this question for all fun the people attempted. Surely the classic C++ look also looks ugly, but still:

 for (int k = 0; k < a.size(); k++) { if (k + 1 == a.size()) { // Last iteration } ... } 

something like

for (int x: a) { ... if (last x) { ... } } 

may look nicer, but how can you take value and return something that depends on the position inside the loop. Due that last and first must likely be the keywords built into the language, or some system functions that are processed in a very specific way with the help of compiler.

Some of these problems are also solvable with C++ iterators but the syntax also looks quite cluttered.

P.S. This answer advocates that it is important to have a loop where the loop variable is just an integer, supporting the usual arithmetic and usable with any array. There is a comment that it does not need to be a typical C loop, a simpler syntax like for int x in a .. b would also suffice. But even if loops providing just a reference to the member of collection being iterated look very simple and clean in most cases, there are other cases where they cannot be easily used.