> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution
> <[email protected]> wrote:
>
>
>
>> 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!
Where is not exactly a part of c# it belongs to linq
>
> -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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
