C-style For Loops

Evolution Discussion
1

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?

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

2

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

3

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