using WHERE in this context had a flair of C# Linq, only not coming even close to what can be done with Linq… I think pulling out WHERE from the places where advanced users might make that connection is a wise decision that will avoid people calling it a really-poor-man’s replacement for Linq. With a bit of luck, a truly smart .WHERE (yes '.’) might one day resurface (even under a different name), but this type with REAL horse power.
just a thought. > On Jun 10, 2016, at 8:25 AM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <[email protected] > <mailto:[email protected]>> wrote: > > > On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <[email protected] >> <mailto:[email protected]>> wrote: >> >> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution >> <[email protected] <mailto:[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? > > 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? > > 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: > > * 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. > > * 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. > > * 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). > > 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? > > 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. > > 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] <mailto:[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] <mailto:[email protected]>> wrote: >>> > >>> > >>> >> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <[email protected] >>> >> <mailto:[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] <mailto:[email protected]> >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
