> On 8 Jun 2016, at 01:54, Xiaodi Wu via swift-evolution
> <[email protected]> wrote:
>
> 1) It is spelled out exactly what happens when a condition is met. I no
> longer have to remember whether the word that describes breaking from a loop
> uses a place analogy ("where") or a time analogy ("while" or "when”).
>
> (You cannot convince me that these words are intuitive when the meaning of
> "where" changes by context in today's Swift. Now, if you want to propose that
> these be named "breakif" and "continueif" instead, then I'd agree with you
> that they're intuitive names, but then they'd also be really ugly.)
I’m not sure I agree that this is confusing, a little extra to learn for new
programmers perhaps but I think it’s fairly intuitive:
while let value = foo.next() where someCondition(value) { … }
This reads to me as “repeat the following block until this fails to be true”,
the conditional binding in this case fails to be true if someCondition(value)
isn’t true, so the loop ends. I think the key thing here is that the where
clause is for the conditional binding and not the loop itself, so in this
respect it behaves exactly like an if or guard statement. Meanwhile:
for eachValue in theValues where someCondition(eachValue) { … }
Reads as “for everything in theValues do the following if
someCondition(eachValue) is also true”, in other words this loop always tries
to visit every element of the sequence (a while loop has no implicit awareness
of the sequence, it’s really just an if statement that runs over and over). In
this case the where clause is part of the loop itself. There may be an argument
that where should be renamed on for loops to better distinguish this, but once
you consider that there’s no pattern or conditional binding here I think it
makes a reasonable amount of sense.
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. Chaining methods can do this, but it’s actually less readable IMO, or
requires multiple lines to keep it clear which defeats the point.
As with where on if/guard statements it’s about keeping the simpler, more
common cases as clean and readable as possible. If the re-use of the keyword
where on the for loop is confusing then that’s an argument for renaming that,
rather than rejecting while or ditching the whole thing IMO. Personally I think
it’s okay, you just have to think what the where clause is actually acting upon.
> 3) I have the flexibility to do something between the first if statement and
> the second if statement, if I want. By placing the break statement at the end
> of my loop, I could effectively choose to have one more iteration than if I
> placed it at the beginning of my loop. There is nothing you can do to mimic
> that choice with your proposed while clause, unless you want to also propose
> a `for...in...repeat { } while` syntax.
So? Like where clauses this is for the simpler cases, if you want to do
something more complex you remain free to use more complex conditionals. A lot
of the time you don’t need this however, so it makes sense to simplify the
common case while leaving the complex one just as useful as it is today.
Nothing about this proposal would stop you from using if/guard conditions
inside the loop.
> 4) This is the perhaps the important point. A beginning programmer--not any
> of us, presumably, but we were all beginners once--can accomplish everything
> that he or she desires without learning this new proposed syntax. Almost all
> texts, I believe, teach if statements before loops, and teach break and
> continue in the same breath as the loops themselves.
In terms of teaching there shouldn’t be a problem with just teaching the basic
building blocks first, then showing off simplifications later. As with any
coding the most important thing is to get the intended behaviour correct,
simplifying or optimising the code can always come later.
You could argue the same thing about the shorthands around closures; I’m not
sure why but I had trouble with those initially until after I’d worked with
them in the more verbose form (with fully named parameters and a return
statement) till I started to get the logic behind it, now I can just right a
quick closure with the dollar sign shorthand.
A good linter could be written to detect the presence of a simple if/guard
right inside the loop and could then suggest the use of where/while as
appropriate._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
