C-style For Loops

Evolution Discussion
1

This is a nice solution that translates nicely without creating too much concern about changing the nature of an algorithm in a complex system. :+1:

Should at least get a nice "fix it" in Xcode though. On survey, we do have developers using the C style syntax, but we're early in the process of transitioning.

···

On Dec 04, 2015, at 02:52 PM, Johan Jensen <jj@johanjensen.dk> wrote:

With the removal of post/pre-increment/decrement you might as well translate C-style for-loops to something akin to

for var i in 0..<10 {
...
}

If more advanced C-style for-loops are needed, I am sure most developers can use a while-loop (as mentioned by Ray Fix) until they get accustomed to Swift’s syntax.

On Fri, Dec 4, 2015 at 11:37 PM, Joe Groff <jgroff@apple.com> wrote:
You might ease the pain by approximating C-style 'for' by a higher-order function:

func cStyleFor(@autoclosure init initializer: () -> (), @autoclosure test: () -> Bool, @autoclosure inc: () -> (), body: () throws -> ()) rethrows {
// left as an exercise
}

var i = 0
cStyleFor(init: i = 0, test: i < 10, inc: ++i) {
print(i)
}

-Joe

On Dec 4, 2015, at 2:33 PM, Colin Cornaby <colin.cornaby@mac.com> wrote:

I was talking with people in the office about this proposal today, in since there has been such a long discussion already I'll just reply to the top of the tree just to get our take in before the review...

It's understood that Swift has better, more readable ways to do for loops, but C style for loops reduce friction for getting our C or C++ developers on board with Swift. Unless there is a gain elsewhere to be made in their removal, it would be nice to keep them. As we transition to Swift we can educate developers on better ways to iterate, but it would be nice to have one less thing in the way of getting people writing Swift code.

We work on a lot of algorithmic code which would be well suited for Swift. And again, I understand that C style for loops are redundant. But it's just one less speed bump in understanding for some of our developers or for porting pure C or C++ code without having to do as much re-validation of algorithms for accidental changes.

But if it's actively hurting some other part of the language we could probably be talked into it.

On Dec 03, 2015, at 03:32 PM, Erica Sadun <erica@ericasadun.com> wrote:

Does Swift still needs C-style for loops with conditions and incrementers?

<Screen Shot 2015-12-03 at 4.30.15 PM.png>

More Swift-like construction is already available with for-in-statements and stride.
This would naturally starve the most common point for -- and ++ operators as well.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

2

Indeed. Python doesn't have it, and there isn't much concern about the learning curve or the missing functionality there, it seems. I actually didn't even realize it was missing from Python until I stopped and thought about it.

At first I was concerned about losing C style for loops, but I really can imagine a scenario in which they are more succinct while still maintaining clarity of intent. Plus they're a pain to type out.

From time to time when programming in C or JS I will include more than one statement or more complicated logic in the increment part of the for loop (perhaps move 2 indices in a complicated way), but perhaps that would be clearer just to implement as a while loop with the logic at the end.

One thing I will say is that it's nice to have your loop variables scoped to the loop, which is more difficult (impossible?) to accomplish with a while loop.

Perhaps some while loop syntax like:

while (x < someThing) start var x = 0, y = 11 {
  x += someOtherThing
}

Which is decidedly terrible syntax, but that's kind of the idea anyway.

Tyler

···

On Dec 4, 2015, at 3:21 PM, Colin Cornaby <colin.cornaby@mac.com> wrote:

This is a nice solution that translates nicely without creating too much concern about changing the nature of an algorithm in a complex system. :+1:

Should at least get a nice "fix it" in Xcode though. On survey, we do have developers using the C style syntax, but we're early in the process of transitioning.

On Dec 04, 2015, at 02:52 PM, Johan Jensen <jj@johanjensen.dk> wrote:

With the removal of post/pre-increment/decrement you might as well translate C-style for-loops to something akin to

for var i in 0..<10 {
    ...
}

If more advanced C-style for-loops are needed, I am sure most developers can use a while-loop (as mentioned by Ray Fix) until they get accustomed to Swift’s syntax.

On Fri, Dec 4, 2015 at 11:37 PM, Joe Groff <jgroff@apple.com> wrote:
You might ease the pain by approximating C-style 'for' by a higher-order function:

func cStyleFor(@autoclosure init initializer: () -> (), @autoclosure test: () -> Bool, @autoclosure inc: () -> (), body: () throws -> ()) rethrows {
  // left as an exercise
}

var i = 0
cStyleFor(init: i = 0, test: i < 10, inc: ++i) {
  print(i)
}

-Joe

On Dec 4, 2015, at 2:33 PM, Colin Cornaby <colin.cornaby@mac.com> wrote:

I was talking with people in the office about this proposal today, in since there has been such a long discussion already I'll just reply to the top of the tree just to get our take in before the review...

It's understood that Swift has better, more readable ways to do for loops, but C style for loops reduce friction for getting our C or C++ developers on board with Swift. Unless there is a gain elsewhere to be made in their removal, it would be nice to keep them. As we transition to Swift we can educate developers on better ways to iterate, but it would be nice to have one less thing in the way of getting people writing Swift code.

We work on a lot of algorithmic code which would be well suited for Swift. And again, I understand that C style for loops are redundant. But it's just one less speed bump in understanding for some of our developers or for porting pure C or C++ code without having to do as much re-validation of algorithms for accidental changes.

But if it's actively hurting some other part of the language we could probably be talked into it.

On Dec 03, 2015, at 03:32 PM, Erica Sadun <erica@ericasadun.com> wrote:

Does Swift still needs C-style for loops with conditions and incrementers?

<Screen Shot 2015-12-03 at 4.30.15 PM.png>

More Swift-like construction is already available with for-in-statements and stride.
This would naturally starve the most common point for -- and ++ operators as well.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

I must be the only person who still likes C-style for loops on occasion. eg a loop with something floating point

for var floatingThing = start ; floatingThing <= end ; floatingThing += delta
{
  // more than a few lines of code with early escape continues
}

shows intent of the loop very clearly, start, condition and increment all together at the top, and however you loop you always execute the increment part of the statement. Convert that to a while(), if you have a continue in the body, you have a good chance of not incrementing at all, or duplicating the increment code before every continue. So you can’t always nicely turn for into while. I second the point below about the loop variable being local to the for as well, I also like that.

In the float case yes you can use stride

for var floatingThing in start.stride( through : end, by : delta )
{
}

but it’s not terribly pretty and you have to be sure whether you mean stride( through:, end:) or stride( to:, end:)

That’s not a problem with integers where you have the ‘0..<n’ syntax which reads very clearly in a for .. in construct but in other cases the old c-style for can be a clearer read than for .. in with an iterator.

···

On 5 Dec 2015, at 15:14, Tyler Cloutier <cloutiertyler@aol.com> wrote:

Indeed. Python doesn't have it, and there isn't much concern about the learning curve or the missing functionality there, it seems. I actually didn't even realize it was missing from Python until I stopped and thought about it.

At first I was concerned about losing C style for loops, but I really can imagine a scenario in which they are more succinct while still maintaining clarity of intent. Plus they're a pain to type out.

From time to time when programming in C or JS I will include more than one statement or more complicated logic in the increment part of the for loop (perhaps move 2 indices in a complicated way), but perhaps that would be clearer just to implement as a while loop with the logic at the end.

One thing I will say is that it's nice to have your loop variables scoped to the loop, which is more difficult (impossible?) to accomplish with a while loop.

Perhaps some while loop syntax like:

while (x < someThing) start var x = 0, y = 11 {
  x += someOtherThing
}

Which is decidedly terrible syntax, but that's kind of the idea anyway.

Tyler

On Dec 4, 2015, at 3:21 PM, Colin Cornaby <colin.cornaby@mac.com <mailto:colin.cornaby@mac.com>> wrote:

This is a nice solution that translates nicely without creating too much concern about changing the nature of an algorithm in a complex system. :+1:

Should at least get a nice "fix it" in Xcode though. On survey, we do have developers using the C style syntax, but we're early in the process of transitioning.

On Dec 04, 2015, at 02:52 PM, Johan Jensen <jj@johanjensen.dk <mailto:jj@johanjensen.dk>> wrote:

With the removal of post/pre-increment/decrement you might as well translate C-style for-loops to something akin to

for var i in 0..<10 {
    ...
}

If more advanced C-style for-loops are needed, I am sure most developers can use a while-loop (as mentioned by Ray Fix) until they get accustomed to Swift’s syntax.

On Fri, Dec 4, 2015 at 11:37 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
You might ease the pain by approximating C-style 'for' by a higher-order function:

func cStyleFor(@autoclosure init initializer: () -> (), @autoclosure test: () -> Bool, @autoclosure inc: () -> (), body: () throws -> ()) rethrows {
  // left as an exercise
}

var i = 0
cStyleFor(init: i = 0, test: i < 10, inc: ++i) {
  print(i)
}

-Joe

On Dec 4, 2015, at 2:33 PM, Colin Cornaby <colin.cornaby@mac.com <mailto:colin.cornaby@mac.com>> wrote:

I was talking with people in the office about this proposal today, in since there has been such a long discussion already I'll just reply to the top of the tree just to get our take in before the review...

It's understood that Swift has better, more readable ways to do for loops, but C style for loops reduce friction for getting our C or C++ developers on board with Swift. Unless there is a gain elsewhere to be made in their removal, it would be nice to keep them. As we transition to Swift we can educate developers on better ways to iterate, but it would be nice to have one less thing in the way of getting people writing Swift code.

We work on a lot of algorithmic code which would be well suited for Swift. And again, I understand that C style for loops are redundant. But it's just one less speed bump in understanding for some of our developers or for porting pure C or C++ code without having to do as much re-validation of algorithms for accidental changes.

But if it's actively hurting some other part of the language we could probably be talked into it.

On Dec 03, 2015, at 03:32 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

Does Swift still needs C-style for loops with conditions and incrementers?

<Screen Shot 2015-12-03 at 4.30.15 PM.png>

More Swift-like construction is already available with for-in-statements and stride.
This would naturally starve the most common point for -- and ++ operators as well.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

Hmm, yeah, that is definitely a good point. It can be easy enough to throw a continue into a while loop an completely skip the increment step. Of course you could add syntax to a while loop to allow for block/loop scoping of variables and then it might be tempting to add some finally logic to ensure that the incrementing is never skipped. Which, then what you have is a C style for loop with unfamiliar/unprecedented syntax, which would be silly.

Perhaps the question is, is it worth keeping the C style around for loop syntax for these particular types of uses?

On a total side note, I figure while I'm proposing silly things and decidedly terrible syntax, I might as well mention that when I originally began programming I was confused about the need for two different styles of loops. It seemed like "while" was a special case of "for" and was redundant (but made for a nicer looking syntax). An interesting thought experiment is to think about what dropping "while" might look like.

Just like there is for-in

for x in someGenerator {
  // code
}

There could also be for-if-repeat and for-repeat-if

for var x = 0 if x < 7 repeat {
  // code
} then x + 7

for var x = 0 repeat {
  // code
} if x < 7 then x + 7

Certainly an unnecessary change considering the problem at hand and has obvious downsides, but I think fun to think about.

Tyler

···

On Dec 4, 2015, at 11:54 PM, Roland King <rols@rols.org> wrote:

I must be the only person who still likes C-style for loops on occasion. eg a loop with something floating point

for var floatingThing = start ; floatingThing <= end ; floatingThing += delta
{
  // more than a few lines of code with early escape continues
}

shows intent of the loop very clearly, start, condition and increment all together at the top, and however you loop you always execute the increment part of the statement. Convert that to a while(), if you have a continue in the body, you have a good chance of not incrementing at all, or duplicating the increment code before every continue. So you can’t always nicely turn for into while. I second the point below about the loop variable being local to the for as well, I also like that.

In the float case yes you can use stride

for var floatingThing in start.stride( through : end, by : delta )
{
}

but it’s not terribly pretty and you have to be sure whether you mean stride( through:, end:) or stride( to:, end:)

That’s not a problem with integers where you have the ‘0..<n’ syntax which reads very clearly in a for .. in construct but in other cases the old c-style for can be a clearer read than for .. in with an iterator.

On 5 Dec 2015, at 15:14, Tyler Cloutier <cloutiertyler@aol.com> wrote:

Indeed. Python doesn't have it, and there isn't much concern about the learning curve or the missing functionality there, it seems. I actually didn't even realize it was missing from Python until I stopped and thought about it.

At first I was concerned about losing C style for loops, but I really can imagine a scenario in which they are more succinct while still maintaining clarity of intent. Plus they're a pain to type out.

From time to time when programming in C or JS I will include more than one statement or more complicated logic in the increment part of the for loop (perhaps move 2 indices in a complicated way), but perhaps that would be clearer just to implement as a while loop with the logic at the end.

One thing I will say is that it's nice to have your loop variables scoped to the loop, which is more difficult (impossible?) to accomplish with a while loop.

Perhaps some while loop syntax like:

while (x < someThing) start var x = 0, y = 11 {
  x += someOtherThing
}

Which is decidedly terrible syntax, but that's kind of the idea anyway.

Tyler

On Dec 4, 2015, at 3:21 PM, Colin Cornaby <colin.cornaby@mac.com> wrote:

This is a nice solution that translates nicely without creating too much concern about changing the nature of an algorithm in a complex system. :+1:

Should at least get a nice "fix it" in Xcode though. On survey, we do have developers using the C style syntax, but we're early in the process of transitioning.

On Dec 04, 2015, at 02:52 PM, Johan Jensen <jj@johanjensen.dk> wrote:

With the removal of post/pre-increment/decrement you might as well translate C-style for-loops to something akin to

for var i in 0..<10 {
    ...
}

If more advanced C-style for-loops are needed, I am sure most developers can use a while-loop (as mentioned by Ray Fix) until they get accustomed to Swift’s syntax.

On Fri, Dec 4, 2015 at 11:37 PM, Joe Groff <jgroff@apple.com> wrote:
You might ease the pain by approximating C-style 'for' by a higher-order function:

func cStyleFor(@autoclosure init initializer: () -> (), @autoclosure test: () -> Bool, @autoclosure inc: () -> (), body: () throws -> ()) rethrows {
  // left as an exercise
}

var i = 0
cStyleFor(init: i = 0, test: i < 10, inc: ++i) {
  print(i)
}

-Joe

On Dec 4, 2015, at 2:33 PM, Colin Cornaby <colin.cornaby@mac.com> wrote:

I was talking with people in the office about this proposal today, in since there has been such a long discussion already I'll just reply to the top of the tree just to get our take in before the review...

It's understood that Swift has better, more readable ways to do for loops, but C style for loops reduce friction for getting our C or C++ developers on board with Swift. Unless there is a gain elsewhere to be made in their removal, it would be nice to keep them. As we transition to Swift we can educate developers on better ways to iterate, but it would be nice to have one less thing in the way of getting people writing Swift code.

We work on a lot of algorithmic code which would be well suited for Swift. And again, I understand that C style for loops are redundant. But it's just one less speed bump in understanding for some of our developers or for porting pure C or C++ code without having to do as much re-validation of algorithms for accidental changes.

But if it's actively hurting some other part of the language we could probably be talked into it.

On Dec 03, 2015, at 03:32 PM, Erica Sadun <erica@ericasadun.com> wrote:

Does Swift still needs C-style for loops with conditions and incrementers?

<Screen Shot 2015-12-03 at 4.30.15 PM.png>

More Swift-like construction is already available with for-in-statements and stride.
This would naturally starve the most common point for -- and ++ operators as well.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

Well... you can do that:

  var x = 0
  while x < 10 {
    defer { x += 1 } // warning: also increment x if an exception is thrown
    continue
  }

Or maybe the C-style for loop could just be made more readable. You could replace the semicolons with words:

  for var x = 0 while x < 10 defer x += 1 {
  }

But that might be slightly misleading. "defer" would imply that this part is executed when an exception is thrown, which would be unlike a regular for loop.

···

Le 5 déc. 2015 à 2:54, Roland King <rols@rols.org> a écrit :

Convert that to a while(), if you have a continue in the body, you have a good chance of not incrementing at all, or duplicating the increment code before every continue.

--
Michel Fortin
michel.fortin@michelf.ca
https://michelf.ca

6

You’re not the only one, I like them too. :-)

I notice that the SE-0007 proposal only includes positive feedback from the community. I hope that counter arguments will be added too.

The thing that bothers me about this first batch of proposals is that they seem to be about “dumbing down” the language. Personally, I think it would be a mistake to remove “power” features such as the C-style for loop. I like Swift but I don’t want it to hold my hand all the time.

You may think the following is horrible code — I like the expressiveness:

extension LinkedList {
  public func reverse() {
    for var node = head; node != nil; head = node, node = node!.previous {
      // swap next and previous
    }
  }
}

Another example from the same LinkedList class. It finds the right place to insert a new node:

  for next = head; next != nil && index > 0; prev = next, next = next!.next, --index { }

Extreme? Probably, but I like it better than the same thing done in five lines of while loop.

Another benefit of a C-style for loop is that it simply ignores the loop when n <= i, as in the following example,

  for var i = 100; i < n; ++i { ...

while the Swifty version gives an error because it cannot create a range where the end is smaller than the start:

  for i in 100..<n { ...

Of course, you can add an if-statement to catch this but in the C-style loop this is implicit. Hence, it is more expressive.

Personally, I tend to use for-in as much as possible but I dislike it for going backwards. It’s a style thing but I much prefer,

  for var i = 100; i > 0; --i { ...

over:

  for i in 100.stride(to: 0, by: -1) { ...

Ideally I’d write this instead, but Swift doesn’t allow such ranges:

  for i in 100...1 {

In all these examples, I admit that a C-style for loop is harder to learn. So what? People are only beginners for a short time. I only have a little insight into this but from what I can tell, most beginners don’t have a problem learning the language so much as the frameworks.

We shouldn’t “simplify” the language in the belief that this will help beginners, without a clear understanding of what sort of problems beginners actually have. So far all I’ve seen are assumptions, not actual data. (I only have anecdotal evidence myself.)

Just to be clear: I’m not against making the language easier to learn, but that should not get in the way of allowing more advanced programmers to do their jobs.

-Matthijs

···

On 5 dec. 2015, at 08:54, Roland King <rols@rols.org> wrote:

I must be the only person who still likes C-style for loops on occasion. eg a loop with something floating point

7

Maybe a keyword like "oncontinue" would be a little more obvious about its behavior than "defer"?

···

On Dec 5, 2015, at 5:17 AM, Michel Fortin <michel.fortin@michelf.ca> wrote:

Le 5 déc. 2015 à 2:54, Roland King <rols@rols.org> a écrit :

Convert that to a while(), if you have a continue in the body, you have a good chance of not incrementing at all, or duplicating the increment code before every continue.

Well... you can do that:

   var x = 0
   while x < 10 {
       defer { x += 1 } // warning: also increment x if an exception is thrown
       continue
   }

Or maybe the C-style for loop could just be made more readable. You could replace the semicolons with words:

   for var x = 0 while x < 10 defer x += 1 {
   }

But that might be slightly misleading. "defer" would imply that this part is executed when an exception is thrown, which would be unlike a regular for loop.

--
Michel Fortin
michel.fortin@michelf.ca
https://michelf.ca

8

I’m not a big fan of the C-style for loop, mostly because i find the parts of it badly separated by those tiny semicolons which are easily overlooked.

Therefore for me it would be ok if the C-style for loop would be dropped but transforming its syntax into more Swift like syntax like suggested by Tyler might be even better as Roland and Tyler made some good points about advantages of the for loop (especially the guaranteed execution of the increment part). Being able to have the loop variable scoped locally to the loop is another advantage over the while loop.

Moving the incrementation part after the loop body as suggested by Tyler puts too much distance between the parts defining the loop mechanics IMHO (although I have to admit that it makes the order very clear), so I’d rather stay more closely with the original syntax, just eliminating the semicolons.

Therefore I’d like to suggest the following syntax (for-while-loop):

for var x = start while x <= end loop x += delta {
  // more than a few lines of code with early escape continues
}

The initialization part (between „for" and „while“) and the loop part (after „loop“) are allowed to contain more than one statement.
The scope of all variables introduced (in the example „x“) is local to the loop.

Additionally the following form (for-until-loop) could be provided:

for var x = start until x > end loop x += delta {
  // more than a few lines of code with early escape continues
}

Question: should the initialization part be restricted to var declarations or should it allow all statements?

Alternatives to the „loop“ keyword might be: iterate (a bit long), step, advance, next

Thorsten

···

Am 05.12.2015 um 11:27 schrieb Tyler Cloutier <cloutiertyler@aol.com>:

Hmm, yeah, that is definitely a good point. It can be easy enough to throw a continue into a while loop an completely skip the increment step. Of course you could add syntax to a while loop to allow for block/loop scoping of variables and then it might be tempting to add some finally logic to ensure that the incrementing is never skipped. Which, then what you have is a C style for loop with unfamiliar/unprecedented syntax, which would be silly.

Perhaps the question is, is it worth keeping the C style around for loop syntax for these particular types of uses?

On a total side note, I figure while I'm proposing silly things and decidedly terrible syntax, I might as well mention that when I originally began programming I was confused about the need for two different styles of loops. It seemed like "while" was a special case of "for" and was redundant (but made for a nicer looking syntax). An interesting thought experiment is to think about what dropping "while" might look like.

Just like there is for-in

for x in someGenerator {
  // code
}

There could also be for-if-repeat and for-repeat-if

for var x = 0 if x < 7 repeat {
  // code
} then x + 7

for var x = 0 repeat {
  // code
} if x < 7 then x + 7

Certainly an unnecessary change considering the problem at hand and has obvious downsides, but I think fun to think about.

Tyler

On Dec 4, 2015, at 11:54 PM, Roland King <rols@rols.org <mailto:rols@rols.org>> wrote:

I must be the only person who still likes C-style for loops on occasion. eg a loop with something floating point

for var floatingThing = start ; floatingThing <= end ; floatingThing += delta
{
  // more than a few lines of code with early escape continues
}

shows intent of the loop very clearly, start, condition and increment all together at the top, and however you loop you always execute the increment part of the statement. Convert that to a while(), if you have a continue in the body, you have a good chance of not incrementing at all, or duplicating the increment code before every continue. So you can’t always nicely turn for into while. I second the point below about the loop variable being local to the for as well, I also like that.

In the float case yes you can use stride

for var floatingThing in start.stride( through : end, by : delta )
{
}

but it’s not terribly pretty and you have to be sure whether you mean stride( through:, end:) or stride( to:, end:)

That’s not a problem with integers where you have the ‘0..<n’ syntax which reads very clearly in a for .. in construct but in other cases the old c-style for can be a clearer read than for .. in with an iterator.

On 5 Dec 2015, at 15:14, Tyler Cloutier <cloutiertyler@aol.com <mailto:cloutiertyler@aol.com>> wrote:

Indeed. Python doesn't have it, and there isn't much concern about the learning curve or the missing functionality there, it seems. I actually didn't even realize it was missing from Python until I stopped and thought about it.

At first I was concerned about losing C style for loops, but I really can imagine a scenario in which they are more succinct while still maintaining clarity of intent. Plus they're a pain to type out.

From time to time when programming in C or JS I will include more than one statement or more complicated logic in the increment part of the for loop (perhaps move 2 indices in a complicated way), but perhaps that would be clearer just to implement as a while loop with the logic at the end.

One thing I will say is that it's nice to have your loop variables scoped to the loop, which is more difficult (impossible?) to accomplish with a while loop.

Perhaps some while loop syntax like:

while (x < someThing) start var x = 0, y = 11 {
  x += someOtherThing
}

Which is decidedly terrible syntax, but that's kind of the idea anyway.

Tyler

On Dec 4, 2015, at 3:21 PM, Colin Cornaby <colin.cornaby@mac.com <mailto:colin.cornaby@mac.com>> wrote:

This is a nice solution that translates nicely without creating too much concern about changing the nature of an algorithm in a complex system. :+1:

Should at least get a nice "fix it" in Xcode though. On survey, we do have developers using the C style syntax, but we're early in the process of transitioning.

On Dec 04, 2015, at 02:52 PM, Johan Jensen <jj@johanjensen.dk <mailto:jj@johanjensen.dk>> wrote:

With the removal of post/pre-increment/decrement you might as well translate C-style for-loops to something akin to

for var i in 0..<10 {
    ...
}

If more advanced C-style for-loops are needed, I am sure most developers can use a while-loop (as mentioned by Ray Fix) until they get accustomed to Swift’s syntax.

On Fri, Dec 4, 2015 at 11:37 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
You might ease the pain by approximating C-style 'for' by a higher-order function:

func cStyleFor(@autoclosure init initializer: () -> (), @autoclosure test: () -> Bool, @autoclosure inc: () -> (), body: () throws -> ()) rethrows {
  // left as an exercise
}

var i = 0
cStyleFor(init: i = 0, test: i < 10, inc: ++i) {
  print(i)
}

-Joe

On Dec 4, 2015, at 2:33 PM, Colin Cornaby <colin.cornaby@mac.com <mailto:colin.cornaby@mac.com>> wrote:

I was talking with people in the office about this proposal today, in since there has been such a long discussion already I'll just reply to the top of the tree just to get our take in before the review...

It's understood that Swift has better, more readable ways to do for loops, but C style for loops reduce friction for getting our C or C++ developers on board with Swift. Unless there is a gain elsewhere to be made in their removal, it would be nice to keep them. As we transition to Swift we can educate developers on better ways to iterate, but it would be nice to have one less thing in the way of getting people writing Swift code.

We work on a lot of algorithmic code which would be well suited for Swift. And again, I understand that C style for loops are redundant. But it's just one less speed bump in understanding for some of our developers or for porting pure C or C++ code without having to do as much re-validation of algorithms for accidental changes.

But if it's actively hurting some other part of the language we could probably be talked into it.

On Dec 03, 2015, at 03:32 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

Does Swift still needs C-style for loops with conditions and incrementers?

<Screen Shot 2015-12-03 at 4.30.15 PM.png>

More Swift-like construction is already available with for-in-statements and stride.
This would naturally starve the most common point for -- and ++ operators as well.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

Another example from the same LinkedList class. It finds the right place to

insert a new node:

  for next = head; next != nil && index > 0; prev = next, next = next!.
next, --index { }

Extreme? Probably, but I like it better than the same thing done in five
lines of while loop.

next = head; while next != nil && index > 0 { prev = next; next =
next!.next; --index }

A 'for' statement gets away with a single line only because it substitutes
semicolons and commas for line breaks. You can do the same with 'while'.

But as Joe pointed out, you can recreate an almost identical 'for'
with autoclosures
anyway.

···

On Sat, Dec 5, 2015 at 11:10 AM, Matthijs Hollemans <mail@hollance.com> wrote:

10

Yes - I’m still thinking it through. while() is really a special case of the c-style for, just without the initializer and the pre-test increment (which I don’t like calling increment because it’s far more useful than that). The fact it calls the increment code every time before the test, with the notable exception of the first time, makes for a powerful sequence of test-do-increment-test-do-increment-test .. which while() alone doesn’t quite replicate. A continue in a for loop doesn’t translate well into a while() at all, obviously you can do it with nested ifs and other means but I think the power of the sequence for() gives you along with continue and break lets you write simple, understandable loop code.

So I’m not convinced by the argument that where you see a for() you can write a while() with a bit of code shuffling, for() is more powerful than while(), while() is the special case.

So that moves on to for .. in. That looks persuasively like a syntax which you can always change a C-style for into. And of course you can, you can make a generic generator which takes a few closures and does exactly what the c-style for does if you want. It’s easy however to just think in terms of things which have natural generators, 1..<n, an array of things, and when you use those with for .. in you get a very understandable line of code

  for var element in myArray {}

is very clear because Array has a natural generator. Under the hood this is of course sugar for a c-style for loop where the initialisation and increment are predefined.

In other non-natural-generator cases, turning things into generators in order to use them with for .. in makes the code harder to read and understand. I brought up iterating floats, some of Matthijs’ examples from a couple of mails ago really would look a bit nasty shoehorned into an iterator paradigm so for .. in could un-shoehorn them again and turn them into the original for test-do-modify-test-do-modify-test he started with.

I’ve now had my 2c twice - I will be quiet.

···

On 5 Dec 2015, at 18:27, Tyler Cloutier <cloutiertyler@aol.com> wrote:

Hmm, yeah, that is definitely a good point. It can be easy enough to throw a continue into a while loop an completely skip the increment step. Of course you could add syntax to a while loop to allow for block/loop scoping of variables and then it might be tempting to add some finally logic to ensure that the incrementing is never skipped. Which, then what you have is a C style for loop with unfamiliar/unprecedented syntax, which would be silly.

11

I’d be perfectly happy if a semantic equivalent, but syntactically more easily comprehensible, alternative to the c-style for loop was introduced. An extension to while sounds reasonable if there’s a version which is generally agreed to be clearer. I’d like not to throw away what the fullness of what a c-style for loop can express, I don’t mind at all if we throw away the semicolons currently used to express it and replace them with an alternative and more readable syntax. I thought Thorsten’s suggestion for one was fine, I’m sure there are others.

···

On 5 Dec 2015, at 19:35, Thorsten Seitz <thorsten.seitz@web.de> wrote:

I’m not a big fan of the C-style for loop, mostly because i find the parts of it badly separated by those tiny semicolons which are easily overlooked.

Therefore for me it would be ok if the C-style for loop would be dropped but transforming its syntax into more Swift like syntax like suggested by Tyler might be even better as Roland and Tyler made some good points about advantages of the for loop (especially the guaranteed execution of the increment part). Being able to have the loop variable scoped locally to the loop is another advantage over the while loop.

12

It looks like my emails were being classified as spam by Gmail. Below are my earlier thoughts on the C-style For loop.

Hmm, yeah, that is definitely a good point. It can be easy enough to throw a continue into a while loop an completely skip the increment step. Of course you could add syntax to a while loop to allow for block/loop scoping of variables and then it might be tempting to add some finally logic to ensure that the incrementing is never skipped. Which, then what you have is a C style for loop with unfamiliar/unprecedented syntax, which would be silly.

Perhaps the question is, is it worth keeping the C style around for loop syntax for these particular types of uses?

On a total side note, I figure while I'm proposing silly things and decidedly terrible syntax, I might as well mention that when I originally began programming I was confused about the need for two different styles of loops. It seemed like "while" was a special case of "for" and was redundant (but made for a nicer looking syntax). An interesting thought experiment is to think about what dropping "while" might look like.

Just like there is for-in

for x in someGenerator {
  // code
}

There could also be for-if-repeat and for-repeat-if

for var x = 0 if x < 7 repeat {
  // code
} then x + 7

for var x = 0 repeat {
  // code
} if x < 7 then x + 7

or for-while-repeat and for-repeat-while if that syntax is preferred. Maybe not the most practical solution here, but I think fun to think about.

Tyler

···

On Dec 7, 2015, at 1:24 PM, Tyler Cloutier <tcloutier@machinezone.com> wrote:

Hi Johan,

Thanks for the heads up. That probably means a number of the emails I sent went to spam. I’ll try sending from a different address from now on. I wonder though, why Gmail thinks it’s failing the tests. Avoidance of Gmail is the only reason I have an AOL address in the first place.

Thank you,

Tyler

On Dec 7, 2015, at 1:20 PM, Johan Jensen <jj@johanjensen.dk <mailto:jj@johanjensen.dk>> wrote:

(Replying privately)

Hey Tyler,

Just wanted to let you know, that your two recent emails arrived in the spam-folder on my GMail account and thus likely also in others spam-folder.
Google has the following explanation: “Why is this message in Spam? It has a from address in aol.com <http://aol.com/&gt; but has failed aol.com <http://aol.com/&gt;&#39;s required tests for authentication.”

—Johan

On Sat, Dec 5, 2015 at 11:27 AM, Tyler Cloutier <cloutiertyler@aol.com <mailto:cloutiertyler@aol.com>> wrote:
Hmm, yeah, that is definitely a good point. It can be easy enough to throw a continue into a while loop an completely skip the increment step. Of course you could add syntax to a while loop to allow for block/loop scoping of variables and then it might be tempting to add some finally logic to ensure that the incrementing is never skipped. Which, then what you have is a C style for loop with unfamiliar/unprecedented syntax, which would be silly.

Perhaps the question is, is it worth keeping the C style around for loop syntax for these particular types of uses?

On a total side note, I figure while I'm proposing silly things and decidedly terrible syntax, I might as well mention that when I originally began programming I was confused about the need for two different styles of loops. It seemed like "while" was a special case of "for" and was redundant (but made for a nicer looking syntax). An interesting thought experiment is to think about what dropping "while" might look like.

Just like there is for-in

for x in someGenerator {
  // code
}

There could also be for-if-repeat and for-repeat-if

for var x = 0 if x < 7 repeat {
  // code
} then x + 7

for var x = 0 repeat {
  // code
} if x < 7 then x + 7

Certainly an unnecessary change considering the problem at hand and has obvious downsides, but I think fun to think about.

Tyler

On Dec 4, 2015, at 11:54 PM, Roland King <rols@rols.org <>> wrote:

I must be the only person who still likes C-style for loops on occasion. eg a loop with something floating point

for var floatingThing = start ; floatingThing <= end ; floatingThing += delta
{
  // more than a few lines of code with early escape continues
}

shows intent of the loop very clearly, start, condition and increment all together at the top, and however you loop you always execute the increment part of the statement. Convert that to a while(), if you have a continue in the body, you have a good chance of not incrementing at all, or duplicating the increment code before every continue. So you can’t always nicely turn for into while. I second the point below about the loop variable being local to the for as well, I also like that.

In the float case yes you can use stride

for var floatingThing in start.stride( through : end, by : delta )
{
}

but it’s not terribly pretty and you have to be sure whether you mean stride( through:, end:) or stride( to:, end:)

That’s not a problem with integers where you have the ‘0..<n’ syntax which reads very clearly in a for .. in construct but in other cases the old c-style for can be a clearer read than for .. in with an iterator.

On 5 Dec 2015, at 15:14, Tyler Cloutier <cloutiertyler@aol.com <>> wrote:

Indeed. Python doesn't have it, and there isn't much concern about the learning curve or the missing functionality there, it seems. I actually didn't even realize it was missing from Python until I stopped and thought about it.

At first I was concerned about losing C style for loops, but I really can imagine a scenario in which they are more succinct while still maintaining clarity of intent. Plus they're a pain to type out.

From time to time when programming in C or JS I will include more than one statement or more complicated logic in the increment part of the for loop (perhaps move 2 indices in a complicated way), but perhaps that would be clearer just to implement as a while loop with the logic at the end.

One thing I will say is that it's nice to have your loop variables scoped to the loop, which is more difficult (impossible?) to accomplish with a while loop.

Perhaps some while loop syntax like:

while (x < someThing) start var x = 0, y = 11 {
  x += someOtherThing
}

Which is decidedly terrible syntax, but that's kind of the idea anyway.

Tyler

On Dec 4, 2015, at 3:21 PM, Colin Cornaby <colin.cornaby@mac.com <>> wrote:

This is a nice solution that translates nicely without creating too much concern about changing the nature of an algorithm in a complex system.

Should at least get a nice "fix it" in Xcode though. On survey, we do have developers using the C style syntax, but we're early in the process of transitioning.

On Dec 04, 2015, at 02:52 PM, Johan Jensen <jj@johanjensen.dk <>> wrote:

With the removal of post/pre-increment/decrement you might as well translate C-style for-loops to something akin to

for var i in 0..<10 {
    ...
}

If more advanced C-style for-loops are needed, I am sure most developers can use a while-loop (as mentioned by Ray Fix) until they get accustomed to Swift’s syntax.

On Fri, Dec 4, 2015 at 11:37 PM, Joe Groff <jgroff@apple.com <>> wrote:
You might ease the pain by approximating C-style 'for' by a higher-order function:

func cStyleFor(@autoclosure init initializer: () -> (), @autoclosure test: () -> Bool, @autoclosure inc: () -> (), body: () throws -> ()) rethrows {
  // left as an exercise
}

var i = 0
cStyleFor(init: i = 0, test: i < 10, inc: ++i) {
  print(i)
}

-Joe

On Dec 4, 2015, at 2:33 PM, Colin Cornaby <colin.cornaby@mac.com <>> wrote:

I was talking with people in the office about this proposal today, in since there has been such a long discussion already I'll just reply to the top of the tree just to get our take in before the review...

It's understood that Swift has better, more readable ways to do for loops, but C style for loops reduce friction for getting our C or C++ developers on board with Swift. Unless there is a gain elsewhere to be made in their removal, it would be nice to keep them. As we transition to Swift we can educate developers on better ways to iterate, but it would be nice to have one less thing in the way of getting people writing Swift code.

We work on a lot of algorithmic code which would be well suited for Swift. And again, I understand that C style for loops are redundant. But it's just one less speed bump in understanding for some of our developers or for porting pure C or C++ code without having to do as much re-validation of algorithms for accidental changes.

But if it's actively hurting some other part of the language we could probably be talked into it.

On Dec 03, 2015, at 03:32 PM, Erica Sadun <erica@ericasadun.com <>> wrote:

Does Swift still needs C-style for loops with conditions and incrementers?

<Screen Shot 2015-12-03 at 4.30.15 PM.png>

More Swift-like construction is already available with for-in-statements and stride.
This would naturally starve the most common point for -- and ++ operators as well.

-- E

_______________________________________________
swift-evolution mailing list
<>swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<>https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
<>swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<>https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
<>swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<>https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
<>swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<>https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

13

Yeah I just threw that syntax together after a few minutes, but if there's actual interesting in consolidating whiles and C style fors, perhaps it warrants further consideration? If list comprehensions are ever to be added, it might be a good idea to allow it to be compatible with the possibility that fors could be used as a generator expression. I know others are talking about a similar thing for if and switch.

Tyler

···

On Dec 5, 2015, at 9:28 AM, Roland King <rols@rols.org> wrote:

On 5 Dec 2015, at 19:35, Thorsten Seitz <thorsten.seitz@web.de> wrote:

I’m not a big fan of the C-style for loop, mostly because i find the parts of it badly separated by those tiny semicolons which are easily overlooked.

Therefore for me it would be ok if the C-style for loop would be dropped but transforming its syntax into more Swift like syntax like suggested by Tyler might be even better as Roland and Tyler made some good points about advantages of the for loop (especially the guaranteed execution of the increment part). Being able to have the loop variable scoped locally to the loop is another advantage over the while loop.

I’d be perfectly happy if a semantic equivalent, but syntactically more easily comprehensible, alternative to the c-style for loop was introduced. An extension to while sounds reasonable if there’s a version which is generally agreed to be clearer. I’d like not to throw away what the fullness of what a c-style for loop can express, I don’t mind at all if we throw away the semicolons currently used to express it and replace them with an alternative and more readable syntax. I thought Thorsten’s suggestion for one was fine, I’m sure there are others.