Please help review my Swift proposal: participating in Swift’s future



I recently submitted the following proposal to the Swift Evolution repository (direct link to the full proposal).

The C-style for-loop appears to be a mechanical carry-over from C rather than a genuinely Swift-specific construct. It is rarely used and not very Swift-like.

More Swift-typical construction is already available with for-in statements and stride. Removing for loops would simplify the language and starve the most common use-points for -- and ++, which are already due to be eliminated from the language.

The value of this construct is limited and I believe its removal should be seriously considered.

If you have feelings one way or the other, please submit a review between December 7-10, 2015, as you can see on the master schedule. You  submit reviews by emailing the Swift Evolution mailing list.

How to Review

To review, you state whether you believe the proposal should or should not be accepted into Swift. Here are the key points for a helpful review, from the official process document:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Thanks everyone in advance for your feedback.

Additional Points

From Alex Chan:

I was a bit surprised that safety wasn’t among the disadvantages of for loops. For loops make it easy to mess up the bounds of an array.  You can miss items at either end, or inadvertently read beyond the end.  For example:

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

There are similar mistakes where you can miss an element of an array at either end.  I’m struggling to imagine how you could make the same mistakes with for-in loops.

Perhaps only a minor benefit, but I still think it adds to the case in favour.

From Ray Fix:

One argument that I don’t see being made in your proposal is that the while statement provides an equivalent, more verbose form of C-style for loops.

var i = 0
while (i < 10) {
    i += 1

I understand that one of the major goals of Swift is to be a language great to learn about computing. Removing C-style loops doesn’t really diminish this goal because the same thing can be taught with while.


  • ‘Rarely used and not very Swift-like’ ?? Come on Erica, give us some numbers … How rarely used ? And how Swift-like ?. My image processing code is full of for-loops, perfectly clear as it is and Swifty-ness was not in the requirements.

  • TBH I never use the “for var i = 0; i < 15; i++ { … }" construct. Still, I think it gives out the best idea about what a for loop does. You see the initialization, the exit condition, and the post-effect in one line. If we are aiming for Swift to be the first taught language in universities, it might as well stay there to show students what a "classical" for loop looks like.

    • I don’t get the advantage over for i in 0..<15 or for i in 0.stride(through: 15, by: 2) or even for i in 0..<15 where i % 2 == 1.

      I don’t see these as any less pedagogical. As for exit conditions, while and repeat have those covered well. I don’t think a modern programming language should retain features just to show students what a “classical” loop looked like before it was designed more effectively.

  • Did you get the idea for this proposal from Chris Latner’s proposal to remove increment and decrement from Swift 3? I think that you could basically rewrite his justification for this case. Specifically, his question: if we didn’t already have X, would we feel the need to add it to Swift 3?

    Chris implies that the answer to that question is “no” for increment and decrement, and I think a strong case could be made that the C-style for loop would have no impetus if it were not already part of Swift as well. It certainly isn’t Swift-like, and I don’t think there’s any defense of the C-style for loop on grounds of clarity. I remember learning C back in the late 80’s, as an immigrant from Pascal and BASIC, and the two things that were the least comprehensible were increment/decrement and the for loop syntax.

  • I’m a bit on the fence with this proposal. On one hand, image processing code is full of classic for-loops, but they can usually be replaced with for-in loops, unless someone manipulates raw pointers. OTOH, keeping for-loop in Swift will allow for this monstrosity to be written:

    for var a = 0, b = 1, c = 2; a+b+c < 99; ++a, ++b, c *= 2 {

    I just looked through my C++ code, since I haven't written anything substantial in Swift yet, and I found a "good" use for such a monstrosity:

      for (int y = 0; y < height; ++y) 
        for (int i = y*width, j = y*(2*width+1), k = j + w; i < (y+1)*width; ++i, ++j, ++k) {
          grid[j] = pixel[i]+pixel[i+1];
          grid[k] = pixel[i]+pixel[i+width];

    It would look strange, if I had to replace the inner loop with a repeat-while loop.

    • As for the first, you can replace it with:

      var (a, b, c) = (0, 1, 2)
      while a + b + c < 99 {
          print(a + b + c)
          (a, b, c) = (a + 1, b + 1, c * 2)

      As for the second “good use”, you can still use for in loops:

      do {
          let (width, height) = (100, 100)
          let bytesPerPixel = 3
          let pixels = malloc(width * height * bytesPerPixel); defer {free(pixels)}
          for row in 0..<height {
              let rowOffset = row * width * bytesPerPixel
              for column in 0..<width {
                  let _ = pixels[rowOffset + column + kRedOffset]
                  // blah blah other stuff
      • Using tuples definitely reduces the pain in converting multivariate for-loops to while-loops. I think I could live without C-style for-loops, but it’s only my second day with Swift.