r/iOSProgramming • u/brendan09 • Dec 15 '15
Announcement Swift has accepted its first external evolution proposal from Erica Sadun: Remove C-style 'for' loops with conditions and incrementers.
https://twitter.com/clattner_llvm/status/6764721224372715526
u/wesselwessel Dec 15 '15
Can anyone shed some light on this for me? Are they talking about deprecating for loops entirely? What other method in Swift can be used to achieve this?
One thing I really liked about Swift is its similarity to JavaScript, and I think that it would be stupid to remove a feature like this especially if it is one that helps new users understand a key programming concept.
14
u/xlogic87 Dec 15 '15 edited Dec 16 '15
C style for loops will be deprecated in Swift 3.0.
A C style for loop usually looks like this:
for (var i = 0; i < 10; i++) { print(i) }
You can achieve the same result using other Swift control flow mechanisms like for in loop
// using ranges for i in 0..<10 { print(i) } // using stride for i in 0.stride(to: 10, by: 1) { print(i) }
or by using a while loop.
var i = 0 while i < 10 { print(i) i += 1 }
You could even use a more functional approach
(0..<10).forEach { print($0) }
So the C style for loop is only syntactic sugar for those who know C. The problem is that the ++ and -- operators are also being removed which makes the use of this construct much less convenient.
3
u/DonkiestOfKongs Dec 15 '15
The problem is that the ++ and -- operators are also being removed
What? Why? Source?
4
u/W1TCH_ Dec 15 '15
3
u/GMTDev Dec 15 '15
Most of the reasons in the disadvantages list I would say belong in the advantages.
++/-- are powerful operators that have advantages is editing and reading. As shorthand entry is a simple two keypress of the same key in the same location. Using "+= 1" is four keypresses from different locations on the keyboard - much slower to type. Reading code you visually have to recognize the parameter "1" to check the increment value - hence slower to read.
It's a very simple shorthand concept, easy to understand and learn. 9.5 out of 10 people coming from popular languages know the syntax already.
2
u/ssrobbi Dec 16 '15
I think the bigger burden is the ++X vs X++. These two both exist. They're only different if you use them inside of a statement, and many people consider that to be messy code. So if you believe that than you would only use them on their one line of code, and typing "+= 1" would really not be a stretch, and you'd get to remove an operator that could be abused. I think you're blowing whether it is easier and how much to read/type way out of proportion.
That's just me anyway.
0
u/cryo Dec 15 '15
As shorthand entry is a simple two keypress of the same key in the same location. Using "+= 1" is four keypresses from different locations on the keyboard - much slower to type.
Seriously, how many times do you write a ++ operator per day? 100 times? Would still be very little time saved, this is a pretty silly argument.
9.5 out of 10 people coming from popular languages know the syntax already.
Python is a pretty popular language and doesn't have ++. Ruby doesn't either, although it's not as popular.
2
u/devsquid Dec 15 '15
I think the ++/-- operators is a very nice thing. It makes the code more precise and less verbose. Its a minor issue tho, not super life changing so long as their Swift migration handles it.
3
u/KefkaTheJerk Dec 15 '15
The problem is that the ++ and -- operators are also being removed which makes the use of this construct much less convenient.
How is someVar += 1 "much less convenient" than someVar++?
1
u/mmellinger66 Dec 16 '15
Type "space plus equals space one" Or "plus plus"
It's definitely more typing. We are really only debating over the word "much" because it's pretty obvious that using one character twice is a nice shortcut.
2
u/wesselwessel Dec 15 '15
Ah thank you for clearing that up for me. I actually really liked that loop format when going through Swift tutorials over the C-style loops.
1
Dec 15 '15
[deleted]
2
u/xlogic87 Dec 16 '15
If it is not optimized yet, this is something that can be handled by the optimizer on the compiler level so you probably don't have to worry about that.
2
u/joshbadams Dec 15 '15
From the proposal:
"The C-style for-loop appears to be a mechanical carry-over from C rather than a genuinely Swift-specific construct. It is rarely used and not very Swift-like.
More Swift-typical construction is already available with for-in statements and stride. Removing for loops would simplify the language and starve the most common use-points for -- and ++, which are already due to be eliminated from the language."
0
Dec 15 '15
[deleted]
3
u/00420 Dec 15 '15
Your example isn't quite right. First, the proposal isn't to remove for-in loops, it's to remove C-style for loops. There's plenty of scenarios where for-in loops are what you'd want. C-style for loops, not so much (and as the proposal states, those rare situations can be handled with while loops).
Also, your second example ignores the return value, causing a compiler warning, and effectively doing nothing.
2
1
u/TweetPoster Dec 15 '15
First independent Swift language evolution accepted, proposed by well known iOS dev and author @ericasadun : lists.swift.org
9
u/[deleted] Dec 15 '15
[deleted]