> Am 11.06.2016 um 21:50 schrieb Xiaodi Wu <[email protected]>: > >> On Sat, Jun 11, 2016 at 2:42 PM, Thorsten Seitz <[email protected]> wrote: >> >> >>> Am 10.06.2016 um 07:08 schrieb Xiaodi Wu via swift-evolution >>> <[email protected]>: >>> >>>> 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." >>> >>>> 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?
Not as a requirement but as a probability. I mean that it is likely that they already had contact with SQL (or C#) where `where` is used without the problems you insist being present in Swift. I don't buy your argument that `where` in for-loops is confusing. It is perfectly aligned with its usage in mathematics or SQL. That it is relatively little known is a deficiency in the documentation which would be easily fixed. I don't agree with your discoverability argument. When I wonder about the meaning of a keyword I'm going to have a look at the documentation. It might be old school to look it up myself instead of getting it presented by clicking on it but it isn't that difficult. When learning a new language I read the languages documentation. How would you know how to write a for-loop in Swift in the first place when you come from Java, say? How would you know to use "in" instead of ":"? Just RTFM and you will discover `where` right in there (if the documentation is fixed). -Thorsten > >> >> -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 >>>>>> <[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
