[swift-evolution] Review: SE-0007 (Remove C-style for-loops with conditions and incrementers)

[Alex Chan]

1. I strongly support this change.

2. It’s not a problem, but an antipattern. Just as it’s important to add new features, it’s also important to consider what should be removed. The for-loops feel like a piece of legacy baggage; I can’t imagine them being added (at least in this form) if they weren’t already in Swift. I can’t imagine a scenario in which I’d recommend using the C-style for-loop instead of a more expressive Swift construct (and was unable to find a counterexample in my Swift or Python code).

3. This proposal fits nicely with Swift, for a few reasons:

   * Readability. The alternatives tend to more expressive and explicit, and feel more Swift-like.

   * Safety. For-loops are often used to iterate over arrays, but it’s easy to make off-by-one errors that mean you miss elements or try to read off the end of an array. For example:

        for var i = 0; i <= bar.count; i++ {
            print("The \(i)th element in bar is \(bar[i]).")
        }

     It would be harder to make this sort of mistake with for-in loops or similar replacement constructs.

  * Simplicity. In my experience, using explicit iterables results in much simpler code in most cases.

4. My primary programming language is Python (for now). Python has neither ++/-- operators nor C-style for-loops. I’ve never had a problem doing complex iterations or loops – indeed, I find Python to be a very powerful language for iteration. I feel the same will hold true for Swift.

   Python and Swift have similar aims for readability and safety. I don’t recall any suggestions to add these constructs to Python; I believe the same would hold true if these constructs weren’t already in Swift.

5. I read the proposal carefully, looked over the responses in the mailing list, and spent several hours reading through my collection of Swift and Python code to look for any cases where lack of a C-style for-loop was a serious impediment. (I didn’t find any.)

— Alex