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

Sat Jun 11 14:59:05 CDT 2016

On Sat, Jun 11, 2016 at 2:53 PM, Thorsten Seitz <tseitz42 at icloud.com> wrote:

>
>
> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org>:
>
> On Fri, Jun 10, 2016 at 6:10 AM, Karl <razielim at gmail.com> wrote:
>
>> -1
>>
>> * 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.
>>
>>
>> When was this decided? I distinctly remember some bloke under Craig
>> Federighi’s hair saying that it was time to “move beyond” C and essentially
>> ditch legacy conventions which no longer make sense.
>>
>
> I think you misunderstood my argument here. I don't mean that we should
> yoke ourselves to C conventions, and we should absolutely ditch C
> convention when it doesn't make sense. The big-picture argument here is
> that `where` doesn't pass the bar of correcting a C convention that no
> longer makes sense.
>
> FWIW, on the topic of syntax choices, here is what Chris Lattner had to
> say on this list:
>
> Kevin got it exa*c*tly right, but I’d expand that last bit a bit to:
>> “… pi*c*king the one that is most familiar to programmers in the
>> extended *C* *family* is a good idea.["]
>> The extended *C* *family* of language (whi*c*h in*c*ludes *C*, *C*++, Obj
>> *C*, but also *C*#, Java, Javas*c*ript, and more) is
>> an extremely popular and widely used set of languages that have a lot of
>> surfa*c*e-level similarity. I
>> don’t *c*laim to know the design rationale of all of these languages,
>> but I surmise that this is not an
>> a*c**c*ident: programmers move around and work in different languages,
>> and this allows a non-expert in the
>> language to understand what is going on. While there are things about *C*
>> that are really unfortunate IMO
>> (e.g. the de*c*larator/de*c*laration spe*c*ifier part of the grammar)
>> there is a lot of goodness in the basi
>> *c*operator set, fo*c*us on dot syntax, and more.
>> I do agree that there are some benefits to dit*c*hing bra*c*es and
>> relying on indentation instead, but there are
>> also downsides. Deviating from the *C* *family* in this respe*c*t would
>> have to provide **overwhelmingly** large
>> advantages for us to take su*c*h a plunge, and they simply don’t exist.
>
>
>
>> As I understand it, Swift is a new language with new conventions. It is
>> desirable to align as many of those as possible with existing conventions
>> so as to be easily learned, but if you limit Swift to other languages
>> conventions you deny it any identity. Did Python ask anybody’s opinion
>> before dropping curly-braces? Did people learn whatever Perl is supposed to
>> be? Look at C’s hieroglyphic for loops!
>>
>
> I don't think we disagree here.
>
>
>>
>> Realistically, “for … in … while” is not going to cause incredible
>> confusion. Removing it would cause a lot of frustration. You can’t on the
>> one hand say our users are comfortable with the axioms of C’s hieroglyphic
>> loops, and on the other hand say “for x in y while" is 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?
>>
>>
>> Ah, but if you’re not “doomed” to failing once, how will you ever master
>> anything? Nobody knew how to write a C for-loop until someone showed them
>> (and even then…). Nobody is going to just open a REPL and start writing
>> code, with zero prior understanding of what Swift syntax looks like.
>>
>
> The thought here is along the lines of what Chris said, quoted above, and
> repeated here: "The extended C family of language [...] is an extremely
> popular and widely used set[;] programmers move around and work in
> different languages, and [aligning to expectations arising from other C
> family languages] allows a non-expert in the language to understand what is
> going on." By contrast, the `where` clause violates that expectation and I
> do not see "overwhelmingly large advantages" for doing so.
>
>
> What about C#'s `where` then? As C# is a member of the C family languages
> `where` is not violating expectations!
>

C# does not have a where keyword for its foreach loop, afaik.

>
> -Thorsten
>
>
>
>
>>
>> * 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.
>>
>>
>> I didn’t even know while loops supported “where”. I can’t even imagine
>> what that would look like, or how I would reason about one if I saw one. I
>> Googled around a little bit and couldn’t find any examples. If they exist,
>> sure, go ahead, get rid of them. Nobody will miss them.
>>
>
> Actually, we had a *huge* chain where there were definitely people who
> said they would miss them, even though as you said it appears scarcely used
> and not very well known. The pernicious problem with it was that it forced
> even unrelated boolean assertions to be chained with `where`, as in:
>
> ```
> while let x = iterator.next() where y < z { ... }
> ```
>
>
>> It definitely makes sense on ‘for’, though. Lots and lots of people will
>> miss that; it’s a pretty well-known feature.
>>
>
> (See Erica's statistics below.)
>
> Also, after everything you said, it’s still not unintuitive. That is not
>> how languages work at all. Languages spoken by human beings are always
>> ambiguous to some extent, and we use context to determine which meaning is
>> correct:
>>
>> (Quote from
>> https://research.googleblog.com/2016/05/announcing-syntaxnet-worlds-most.html
>> )
>>
>> One of the main problems that makes parsing so challenging is that human
>> languages show remarkable levels of ambiguity. It is not uncommon for
>> moderate length sentences - say 20 or 30 words in length - to have
>> hundreds, thousands, or even tens of thousands of possible
>> syntactic structures. A natural language parser must somehow search through
>> all of these alternatives, and find the most plausible structure given
>> the context. As a very simple example, the sentence "Alice drove down the
>> street in her car" has at least two possible dependency parses:
>>
>> The first corresponds to the (correct) interpretation where Alice is
>> driving in her car; the second corresponds to the (absurd, but
>> possible) interpretation where the street is located in her car. The
>> ambiguity arises because the preposition “in" can either
>> modify drove or street; this example is an instance of what is
>> called prepositional phrase attachment ambiguity.
>>
>>
>> Even algebra is not completely unambiguous - you need to use BODMAS rules
>> to disambiguate potential meanings.
>> It’s this context which I think you’re missing when zooming in at the
>> word “where”:
>>
>> - The context that this is a variation of a ‘for x in y’ loop. We know
>> that it loops through every item in ‘y' and assigns it ‘x’. It is literally
>> Section 2 of the 'Swift Tour' - you learn how to assign a variable, and
>> then you learn about the “for x in y” loop. Everybody should recognise it.
>> - The context that ‘x’ is the subject, so ‘where’ is clearly a condition
>> for x to fulfill
>> - The context that ‘where’ occurs after ‘in’, so it follows the order in
>> which its written: ‘for every x in y, where such-and-such is true, do …”
>> - The “for x in y” loop is a data-driven loop. It doesn’t even have a
>> loop index. It is not like a C for loop and you shouldn’t expect to reason
>> about it that way.
>>
>> * 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).
>>
>>
>> You say the points in favour of removal are not handwavey, but I’m still
>> not convinced. “There are other ways to go to where this shortcut goes” is
>> not reasoning. And I’d definitely argue that it is more discoverable than
>> the ‘guard’ statement. The guard statement is stone-dead last at the end of
>> a massive “Control-Flow” page. I would guess that most first-time readers
>> skip those topics for later.
>>
>
> You cannot say the same about `if`.
>
>
>>
>> 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.
>>
>>
>> It’s more readable. It does that better.
>>
>
> Earlier in this thread and others, I gave my reasoning where I disagree
> with this assertion about being more readable.
>
>
>> The tests also seem to show that (bizarrely) it’s also slightly faster
>> than the alternatives.
>>
>
> I don't believe there has been any demonstration that it's faster than
> `guard` or `if`. I would be shocked if that were the case.
>
>
>>
>> Karl
>>
>> On 10 Jun 2016, at 08:25, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> 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?
>>>
>>
>>
>> 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:
>>
>>
>>
>>
>> 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?
>>>
>>
>>
>>
>>
>>> 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
>>>
>>>
>> _______________________________________________
>> 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/20160611/7341646b/attachment.html>