> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution
> <[email protected]>:
>
>> On Fri, Jun 10, 2016 at 6:10 AM, Karl <[email protected]> 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 exactly right, but I’d expand that last bit a bit to:
>> “… picking the one that is most familiar to programmers in the extended C
>> family is a good idea.["]
>> The extended C family of language (which includes C, C++, ObjC, but also C#,
>> Java, Javascript, and more) is
>> an extremely popular and widely used set of languages that have a lot of
>> surface-level similarity. I
>> don’t claim to know the design rationale of all of these languages, but I
>> surmise that this is not an
>> accident: 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 declarator/declaration specifier part of the grammar) there is a
>> lot of goodness in the basic
>> operator set, focus on dot syntax, and more.
>> I do agree that there are some benefits to ditching braces and relying on
>> indentation instead, but there are
>> also downsides. Deviating from the C family in this respect would have to
>> provide *overwhelmingly* large
>> advantages for us to take such 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!
-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
>>> <[email protected]> wrote:
>>>
>>>> On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <[email protected]> wrote:
>>>
>>>>
>>>>
>>>>> On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution
>>>>> <[email protected]> wrote:
>>>>>
>>>>>> On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <[email protected]> wrote:
>>>>>>
>>>>>>> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution
>>>>>>> <[email protected]> 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
>>>>>>>> <[email protected]> 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
>>>>>>>> > <[email protected]> wrote:
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >> On Jun 9, 2016, at 11:11 AM, Charlie Monroe
>>>>>>>> >> <[email protected]> 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
>>>>>>>> > [email protected]
>>>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> [email protected]
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> [email protected]
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
