[swift-evolution] C-style For Loops
Thorsten Seitz
thorsten.seitz at web.de
Sat Dec 5 05:35:23 CST 2015
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 at 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 at rols.org <mailto:rols at 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 at aol.com <mailto:cloutiertyler at 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 at mac.com <mailto:colin.cornaby at 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 at johanjensen.dk <mailto:jj at 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 at apple.com <mailto:jgroff at 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 at mac.com <mailto:colin.cornaby at 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 at ericasadun.com <mailto:erica at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151205/cc2342e1/attachment-0001.html>
More information about the swift-evolution
mailing list