+1 -Thorsten
> Am 10.06.2016 um 07:48 schrieb Brandon Knope via swift-evolution > <[email protected]>: > > > >> 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? > >> >>> 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? > >>> 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. > > 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
