> On 8 Jun 2016, at 17:11, Xiaodi Wu <[email protected]> wrote:
>> On Wed, Jun 8, 2016 at 3:38 AM, Haravikk <[email protected]
>> <mailto:[email protected]>> 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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
