C-style For Loops


(Colin Cornaby) #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鈥檚 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


Joining Old Orphaned Posts to the Main Threads
(Tyler Cloutier) #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鈥檚 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


(Roland King) #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鈥檛 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鈥檚 not terribly pretty and you have to be sure whether you mean stride( through:, end:) or stride( to:, end:)

That鈥檚 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鈥檚 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


(Tyler Cloutier) #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鈥檛 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鈥檚 not terribly pretty and you have to be sure whether you mean stride( through:, end:) or stride( to:, end:)

That鈥檚 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鈥檚 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


(Michel Fortin) #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


(Matthijs Hollemans) #6

You鈥檙e not the only one, I like them too. :slight_smile:

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 鈥渄umbing down鈥 the language. Personally, I think it would be a mistake to remove 鈥減ower鈥 features such as the C-style for loop. I like Swift but I don鈥檛 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鈥檚 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鈥檇 write this instead, but Swift doesn鈥檛 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鈥檛 have a problem learning the language so much as the frameworks.

We shouldn鈥檛 鈥渟implify鈥 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鈥檝e seen are assumptions, not actual data. (I only have anecdotal evidence myself.)

Just to be clear: I鈥檓 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


(Tyler Cloutier) #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


(Thorsten Seitz) #8

I鈥檓 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鈥檇 rather stay more closely with the original syntax, just eliminating the semicolons.

Therefore I鈥檇 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 鈥瀎or" and 鈥瀢hile鈥) and the loop part (after 鈥瀕oop鈥) are allowed to contain more than one statement.
The scope of all variables introduced (in the example 鈥瀤鈥) 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 鈥瀕oop鈥 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鈥檛 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鈥檚 not terribly pretty and you have to be sure whether you mean stride( through:, end:) or stride( to:, end:)

That鈥檚 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鈥檚 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


(Per Melin) #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:


(Roland King) #10

Yes - I鈥檓 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鈥檛 like calling increment because it鈥檚 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鈥檛 quite replicate. A continue in a for loop doesn鈥檛 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鈥檓 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鈥檚 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鈥檝e 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.


(Roland King) #11

I鈥檇 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鈥檚 a version which is generally agreed to be clearer. I鈥檇 like not to throw away what the fullness of what a c-style for loop can express, I don鈥檛 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鈥檚 suggestion for one was fine, I鈥檓 sure there are others.

路路路

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

I鈥檓 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.


(Tyler Cloutier) #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鈥檒l try sending from a different address from now on. I wonder though, why Gmail thinks it鈥檚 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: 鈥淲hy is this message in Spam? It has a from address in aol.com <http://aol.com/> but has failed aol.com <http://aol.com/>'s required tests for authentication.鈥

鈥擩ohan

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鈥檛 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鈥檚 not terribly pretty and you have to be sure whether you mean stride( through:, end:) or stride( to:, end:)

That鈥檚 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鈥檚 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


(Tyler Cloutier) #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鈥檓 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鈥檇 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鈥檚 a version which is generally agreed to be clearer. I鈥檇 like not to throw away what the fullness of what a c-style for loop can express, I don鈥檛 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鈥檚 suggestion for one was fine, I鈥檓 sure there are others.