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

[Xiaodi Wu]

On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <bknope at me.com> wrote:

>
>
> On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls at icloud.com> wrote:
>
>>
>> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> a écrit :
>>
>> There have been, in previous threads, several examples given where users
>> of Swift have found the behavior of `where` to be misleading and confusing.
>>
>>
>> Sorry Xiaodi, but beside you (on multiple instances), and recently Erica,
>> I have do not recall hearing that many voices saying that 'where' is
>> confusing.
>>
>
> Shawn Erickson wrote this to the list just yesterday:
>
> "I support your position on the use of where and while/when being
> confusing in the loop statement. I (and I know others) have for example
> used where in a loop statement mistakenly thinking it would terminate the
> loop early but of course learned that it basically filters what causes the
> loop body to be executed. After the fact that made sense to me but it
> didn't click at first."
>
>
> Couldn't we find examples of anyone being confused at any syntax?
> Especially with an unfamiliar construct in a new language.
>
> If people find the new proposed syntax confusing, do we pull that too? At
> what point do we stop?
>

That is why I favored (1) removal of the confusing syntax altogether; and
(2) this proposal, which involves aligning the confusing syntax with an
existing syntax. In short, no new syntax to get confused about.

Yes, there's was maybe even less voices stating that it is not confusing,
>> but which group is more vocal?
>>
>> Maybe I have been recently corrupt by Solid SQL queries:
>> select * from PEOPLE_TABLE where AGE_FIELD = 100
>>
>> Or by my (likely) broken English:
>> The places where I had the most fun
>>
>> But, to me, where can only suggest some filtering (thus tag to a for ..
>>  in .., continue if not matching).
>>
>
> I'm glad that you find it very clear. I do as well. That does not mean it
> is clear to everyone.
>
>
> I still have yet to see widespread confusion of this. A few people
> learning swift here or there, but once they learn the syntax...do they
> still find it confusing?
>

Again, as I said, once you've mastered something, by definition you find it
not confusing. Why should we doom x% of new users to writing a loop
incorrectly at least once when we don't have to?

I expect some concrete data on stuff like this...especially with proposed
> syntax changes.
>
> Without concrete examples, what would stop one from coming in here and
> waving their hands around to push *what they like* through?
>

Here's what's not handwavy:

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

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

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

Conclusion: the `where` clause is unprecedented, unintuitive, provides no
independent utility, is not more discoverable than alternatives, and is not
required for pedagogical reasons; however, it has been used incorrectly by
at least some users. Therefore, it is harmful and ought to be removed or
reformed.

I know there's a linguist on the list, maybe he could comment on whether or
>> not using 'where' as a filter is proper or an abomination.
>>
>> I do not think that because something is confusing to some, or at first,
>> that it warrant removal from the language.
>>
>
> It is a very bad sign if something is confusing at first, especially to a
> significant proportion of users. It's true by definition that once you have
> mastered something you are no longer confused by it.
>
>
> Again, where is this significant proportion of users? I don't mean to
> hound you on this, but I am genuinely curious where this is all coming from.
>

We were talking about the hypothetical something here and what the bar
should be for removal from the language. My response is that being
confusing at first sight *is* a legitimate consideration for removal from
the language. If something turns out to be a confusing way to describe a
straightforward concept, then the more widespread the confusion, the more
urgent its removal.


> The burden of evidence is on the proposers of these ideas.
>
> As has been stated on this list, education is a valid and important
> consideration for Swift. If something is confusing rather than difficult
> (and the *concept* of filtering a list is not at all a difficult concept),
> and if the same underlying concept can already be invoked in alternative
> and equivalent ways that are not confusing, then it's a no-brainer that the
> confusing thing is harmful to the language and should be removed on that
> basis alone.
>
>
> What is clear to one person may be confusing to another. There is no
> perfect syntax that will not make it confusing for some users.
>
> ----
>
> I really think it is important to come armed with more information with
> these proposals. It's easy to say a significant proportion of people are
> confused but it would make me much more comfortable to see this data to
> back it up.
>
> What if we are spinning our wheels for no reason on a feature that *most*
> don't find confusing? What if we make a bigger proportion of those who did
> understand it more confused now?
>

The point here is that this is not a slippery slope. If `where` offered
independent utility, then some confusion alone probably wouldn't be enough
to justify removal, though it may justify some consideration for change.
However, as the extensive discussion has shown, there is nothing `where`
can do that something else can't do better. I know you like it for style,
but that's not sufficient grounds for keeping something confusing, IMO.


> Brandon
>
>
> By analogy, Chinese and Japanese share difficult writing systems. Yet many
> people use those languages daily without difficulty. Does that mean there's
> not a problem? Far from it: in fact, you'll find that many intelligent
> people have devoted their life's work to mitigating the issue. Both Chinese
> and Japanese underwent a round of simplification in the 20th century. Think
> about it: real languages used for daily life by a significant fraction of
> the world's population were revamped for the purpose of increasing
> accessibility to new learners.
>
> The by-value/by-reference is well define, but can be confusing at first.
>> Same goes for eager/lazy processing, or escaping vs non-escaping closure,
>> or even the difference between closure and function. But no one suggest to
>> remove them.
>>
>
> Value types vs. reference types is a concept (and a moderately advanced
> one), eager vs. lazy processing is a concept (and a moderately advanced
> one), and closures are a concept (and definitely an advanced one).
>
> Filtering a collection is a concept as well, and no one is suggesting its
> removal. We are proposing to simplify and rationalize the syntax by which
> filtering is invoked. If there were a way to dramatically simplify the
> syntax surrounding value types and reference types so as to diminish
> confusion, you can absolutely guarantee that there would be proposals to
> change the syntax. If I could think of one tomorrow, you'd see a thread
> tomorrow about it. I don't think I'm that smart though.
>
>
>> Dany
>>
>> In fact, the first of these proposals began with a question: how does one
>> write arbitrary Boolean assertions after a let binding? The answer (use
>> `where`) was found to be misleading and confusing.
>>
>> I think you're being unfair to say that these proposals have no purpose
>> other than an academic consistency.
>> On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>         As time goes on, I’m feeling more and more that these
>>> consistency proposals are sorely misguided. Frankly, unless the syntax is
>>> confusing or misleading, even once the developer has learned the guiding
>>> principles of Swift, consistency is not a good argument for change. This
>>> proposal is the perfect example of this. No one will find the use of
>>> “where” in loops confusing, aside from those who will wonder why it was
>>> removed from if statements. There is no misleading behavior or confusing
>>> syntax here. This is just consistency for consistency’s sake. Once this
>>> proposal is done, then another will be made to remove “where” from another
>>> place in the language. Then another and another until it’s gone completely
>>> and a very useful part of the language is removed in the name of
>>> consistency. Which really just comes down to “where” isn’t used here, so it
>>> can’t be used there anymore. It’s death by a thousand cuts.
>>>
>>>
>>>
>>> Jon Shier
>>>
>>>
>>> > On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> >
>>> >
>>> >> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <
>>> charlie at charliemonroe.net> wrote:
>>> >> See my latest post - included results with -Ofast. But still, using
>>> filter and lazy.filter is 10+% slower, which were the suggested
>>> alternatives to `where`.
>>> >>
>>> >>
>>> >
>>> > I need to correct this misapprehension.
>>> > My suggested alternative to where was and remains `guard`.
>>> >
>>> > -- E
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160610/b2261f2b/attachment.html>