> Am 10.06.2016 um 07:08 schrieb Xiaodi Wu via swift-evolution > <swift-evolution@swift.org>: > >> On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa....@icloud.com> wrote: >> >>> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution >>> <swift-evolution@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." > >> 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.
So all these people never had contact with SQL? -Thorsten > >> 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. > > 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. > > 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@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@swift.org> wrote: >>>> > >>>> > >>>> >> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <char...@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@swift.org >>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
