[swift-evolution] Add a while clause to for loops

Haravikk swift-evolution at haravikk.me
Wed Jun 8 16:44:28 CDT 2016

> On 8 Jun 2016, at 17:11, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> On Wed, Jun 8, 2016 at 3:38 AM, Haravikk <swift-evolution at haravikk.me <mailto:swift-evolution at haravikk.me>> wrote:
>> Yes this could be handled by an if/guard statement with continue, and while as proposed here could be done with the same plus a break, but these things come up so often that it just makes a lot of sense to get it all neatly onto one line.
> As I pointed out above with Tim's example, putting it all on one line is absolutely not 'neat'--it reads like spaghetti. That is one major beef I have with this proposal: that it *encourages* writing on one line too many things that, whether you use `where` or not, are much more clearly written on multiple lines. If writing everything on one line is for you the major advantage of this proposal, we could agree on everything else and I would be very much opposed to this proposal on that basis alone.

I’m not proposing that every single loop have all of its conditions crushed onto one line, just like I wasn’t when discussing where on the condition clause thread. The usefulness of where and the proposed while is in the common, simple cases, for example:

	for eachValue in theValues while eachValue < 100 where eachValue % 2 == 0 { … }

The alternatives would be:

	for eachValue in theValues {
		guard eachValue < 100 else { break }
		guard eachValue % 2 == 0 else { continue }
	for eachValue in theValues.prefix(while: { $0 < 100 }).filter({ $0 % 2 == 0 }) { … } // Could also be on multiple lines

The former wastes vertical space for what it does IMO; it’s fine if the conditions were more complicated, but since they’re not where/while is ideal. The second isn’t terrible, but it’s a pretty noisy way to handle common loop conditions.

The use of where/while isn’t about eliminating either of these alternatives, they’re absolutely useful in cases where their drawbacks become advantages. For example the inline guards are great when the conditions are more complex, and necessary if you want to do more than the simple cases allow. The second form is best when you need more than the two methods, alternate methods, or you have predicates you can pass in directly, although personally when I do this I tend to do the chinning on its own lines outside of the loop, leaving me with a loop of: for eachValue in theFilteredValues { … } or whatever.

> Closures are--I'm sure you'd agree--a far more advanced concept than loops. Concepts like closing over a variable are very, very hard. Many useful things can be written without using closures. Not so many things could do without loops. It very much matters that a learner might feel that he or she cannot understand everything about a loop with the handwavy explanation that it'll "come later”.

Not my point at all; my point was about the shorthand for closures not closure as a whole, you can’t learn the closure shorthands without first learning what a closure is. In exactly the same way where/while are just be shorthands for inline if/guard, you don’t need to learn about these clauses to make a functioning loop if you know how to do it with your if/guard statements. In fact it’s better to learn it in this order as once you know what each clause is a shorthand form of (if/guard continue or break) then you know exactly what it does already.

Ignoring for a moment that you’re opposed to the where clause in general, what would your thoughts be on only permitting one of where/while in a for? i.e- you would be able to do only one of:

	for eachValue in theValues where eachValue % 2 == 0 { … }
	for eachValue in theValues while eachValue < 100 { … }

But not have both a where and a while on the same line. This eliminates the question mark around the order they are applied in, while still giving us the ability to essentially switch the behaviour of the where from continue to break. I’m not decided whether I want both in a single statement or if I just want to be able to choose between them. It also limits how much goes on one line as you have to use an inline condition to achieve both for a single loop.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/06d5447a/attachment.html>

More information about the swift-evolution mailing list