On Sat, Jun 11, 2016 at 2:42 PM, Thorsten Seitz <tseit...@icloud.com> wrote:
> > > 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? > What do you mean by this comment? Do you expect users of Swift to arrive at the language already knowing 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
