However, I strongly disagree about your second statement. foreach is one looping pattern, but generally, you loop until a condition is satisfied and then you break out of the loop. With a set of items, the condition is running out of items. But it is a mistake to shoe-horn all looping into the “iteration over some set of items” pattern. That is replacing simplicity with unneccessary complexity, and that always leads to less readable code and more bugs.

1. While it provides more freedom to the programmer to construct their loop, it imposes no semantic meaning (other than iteration) which is likely to lead to greater inter-programmer variability and hence less readable code. Further, the existing for, while etc. constructs have lead to idiom with which programmers are familiar; loop will have to grow its own idioms.

2. Looping is just iteration over some set of items. These items may be entirely abstract (e.g. in the case of an infinite loop and other constructs). I think it is much better to use an iterator pattern where one simply iterates by getting the next item, or exists the loop if no next item exists. For me at least, this approach leads to more readable code and fewer bugs.

I don’t like to advocate conformity, but I do advocate consistency, where it makes sense. For better or worse, the C-style languages benefit to some degree by a consistent set of control structures.
Most programmers know how to use if(), for(), while() and do. They can apply the knowledge from other languages to Slick-C. The rare programmer who learns Slick-C before another C-style language can apply
what he learns in Slick-C to those other languages.

Of course, I don’t advocate dropping “parse with”, or other Slick-C peculiarities that are actually useful. But this new loop construct, what is it really useful for?
What’s so terrible about for(;;)???

Regards

John Hurst