[swift-evolution] [Pitch] Retiring `where` from for-in loops

[Thorsten Seitz]

+1

-Thorsten 

> Am 10.06.2016 um 14:49 schrieb Vladimir.S via swift-evolution <swift-evolution at swift.org>:
> 
> +1 to Haravikk's opinion, my thoughts exactly the same.
> 
>> On 10.06.2016 15:18, Haravikk via swift-evolution wrote:
>> 
>>> On 10 Jun 2016, at 07:25, Xiaodi Wu via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> * Swift is explicitly a C-family language. In most or all other C-family
>>> languages, for loop statements allow specification of conditions for
>>> exiting the loop but not for filtering. Therefore, Swift's use of `where`
>>> is unprecedented and needs to be learned anew by every user of Swift.
>> 
>> Swift may have some similarities with C, but the last thing anyone should
>> want is for it to be bound to C as a language. Besides, the purpose of a
>> for in loop is to iterate over elements in a sequence, so filtering is very
>> much a useful thing to do so it’s hardly unprecedented, and it’s also a
>> fairly common thing to want to do.
>> 
>>> * The word "where" does not consistently imply `break` or `continue`. In
>>> current Swift, `where` implies `break` in the context of a `while` loop
>>> and `continue` in the context of a `for` loop. Some users intuitively
>>> guess the correct meaning in each context, while others guess the wrong
>>> meaning. Therefore, the only way to learn for sure what `where` means in
>>> any context is to read the rulebook. That, by definition, means that this
>>> is unintuitive.
>> 
>> This is an argument for renaming the where keyword on for loops to be more
>> clear, or to somehow integrate continue/break to be more explicit about
>> what the developer intends for it to do.
>> 
>>> * There are other ways to break from a loop or continue to the next
>>> iteration without performance penalty. Nearly all of these serve more
>>> general purposes than a `where` clause.
>> 
>> This isn’t really an argument against the where clause; the where clause is
>> useful for common, simple cases, so it’s not surprising if more
>> complex/unusual cases can’t (or can’t easily) be handled by it. This is for
>> the simple cases where this isn’t an issue.
>> 
>>> Some of these (such as `if` or `guard`) would already be familiar to a
>>> new user before they encounter loops, assuming a typical order for
>>> learning a programming language. Many of these (such as filtering methods
>>> on collections, or simply `if`) would be familiar to a user of another
>>> C-family language. Therefore, the `where` clause provides no independent
>>> utility, is not more discoverable than its alternatives, and is not
>>> required for progressive disclosure of an important facility to a learner
>>> (i.e. a simplified syntax for those who may not be ready for the advanced
>>> concepts needed to use a more fully-featured alternative).
>> 
>> Simplification isn’t just for the new users; all you need to know with
>> where is that it’s a shorthand for guard X else { continue }, for many
>> people this is intuitive enough, but if there are enough for whom it isn’t
>> then again that’s an argument to tweak it to be more clear about what it
>> does, rather than remove it entirely.
>> 
>> The independent utility that it offers is being able to avoid if/guard
>> boilerplate at the start of your loop, but instead putting it on the same
>> line; in simple cases this can be nice and neat.
>> 
>>> it has been used incorrectly by at least some users.
>> 
>> Every feature in every language "has been used incorrectly by at least some
>> users", should we just drop all programming languages? It’s not as if users
>> can’t make mistakes while using an inline if/guard condition. Again, this
>> an argument that the meaning isn’t implicit enough, which is just as well
>> served by tweaking the syntax than removing it.
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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