[swift-evolution] [Review] Remove C-style for-loops with conditions and incrementers

Stephen Canon scanon at apple.com
Wed Dec 9 20:23:46 CST 2015

What is your evaluation of the proposal?

Mild concern.  I am not opposed to removing C-style for loops, but I do think that it leaves a hole in the language that should be filled by some other means, and I would prefer to figure that out before removing a useful feature.

Is the problem being addressed significant enough to warrant a change to Swift?

Not obviously so.  C-style for loops, while not particularly stylish, are “mostly harmless”.  That said, some of their functionality is duplicated in for … in loops, so there is some overlap that might be cleaned up.  Having a simpler language (if we can do so without compromising usability) is a good thing.

Does this proposal fit well with the feel and direction of Swift?

For … in loops are more Swifty, and we should encourage people to use them where appropriate.  However, they are significantly less versatile than C-style for loops.  My concerns, as a low-level library writer, are that:

- The loss of C-style for makes iterating backwards more complex than iterating forwards.  This asymmetry is unnatural.

- The loss of C-style for makes it significantly more complex to use strides that vary between iteration steps.

In particular, the available replacements for the second issue force one to split the “loop control” over multiple lines in e.g. a while loop:

	var i = initialValue
	// possible intermediate stuff
	while i < terminalValue {
		// some loop contents
		i += update

I have seen some proposals floated involving closures, but I don’t think any of these to pass the smell test.  One of the chief virtues of the C-style loop is that it lets one gather all of the loop control in one place, which makes reading complex code much, much easier (if we keep C-style for, I would strongly support something like "for (let i = blah; … )” where i is immutable within the loop body for exactly this reason).

My biggest concern (the asymmetry of loops with stride -1) could be addressed by having a reasonable range operator for this case ("N >.. 0" or similar).  I haven’t seen a really strong proposal yet for other loop structures, but I’m willing to write them off if we have a good story for -1 stride, which is the 99% case in my experience.

If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Every language I’ve used heavily either has a "c-style-for” structure, or is so utterly foreign to Swift as to offer no practical guidance here.

 How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve read all of the emails carefully, and spent a while looking for cases in my own code where I would really miss the current feature.

Thanks to everyone for taking time to contribute to this!
– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/ba873f79/attachment.html>

More information about the swift-evolution mailing list