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

[Xiaodi Wu]

On Fri, Jun 10, 2016 at 7:18 AM, Haravikk <swift-evolution at haravikk.me>
wrote:

>
> On 10 Jun 2016, at 07:25, Xiaodi Wu via swift-evolution <
> 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.
>

That's not my argument at all. There are elements of syntax that are
commonly seen in languages that take inspiration from C. We can rightly say
that those are 'familiar' or 'precedented,' by which I mean that a
significant proportion of people who come to Swift will be familiar with
how they work. This is a consideration, though by no means determinative of
what features we should have.

By contrast, there are elements of syntax in Swift which are
'unprecedented.' Some of those support features unique to Swift, or
features that Swift deliberately makes more prominent--take, for example,
sugar for unwrapping optionals or a greatly expanded type system.

We have heard from the core team that the `where` clause was put into the
language in order to align with greatly expanded pattern matching
facilities, but this was abandoned. Thus it now falls into a second
category of 'unprecedented' syntax: a syntax with no parallels in other
languages that take inspiration from C, but which does not serve a purpose
that is unique to or uniquely emphasized in Swift.

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.
>

That's not what I mean by precedent--see above.


>
> * 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.
>

Sure: I conclude that the keyword should be *either* removed *or* reformed;
both outcomes could address the issue.


>
> * 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.
>

That is not at all 'utility.' It is tautologically true that if you have
two alternatives A and B, using A has the 'utility' that you don't have to
use B. And since the whole point here is that the word `break` or
`continue` is not implied by `where`, I argue that writing it out within a
`guard` statement isn't boilerplate but absolutely essential. By contrast,
I have argued that the `where` syntax is not 'nice' or '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?
>

Not every feature serves no independent purpose *and* is used incorrectly
by at least some users.


> It’s not as if users can’t make mistakes while using an inline if/guard
> condition.
>

One that's not caught at compile time? Show me.


> Again, this an argument that the meaning isn’t implicit enough, which is
> just as well served by tweaking the syntax than removing it.
>

Again, I'd be happy tweaking the syntax to make it clear, if possible. If
not, I'd remove it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160610/1b17aee8/attachment.html>