We're going in circles again. I addressed this with relation to `guard`, and I would reply in the same way about `for case`:
The fact is that there are even experienced users of Swift who see `where` and affirmatively believe it does what it does not do. The same cannot be said for `for case`. That is, a user might say, 'What in the world does for case mean?', but even a totally new user is unlikely to say, 'I can guess what for case means, and it means [something that for case does not in fact mean].' On Tue, Jun 14, 2016 at 12:55 Ryan Lovelett via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Jun 14, 2016, at 01:37 PM, Xiaodi Wu via swift-evolution wrote: > > On Tue, Jun 14, 2016 at 12:16 PM, David Waite < > da...@alkaline-solutions.com> wrote: > > I’m a bit late to this conversation, and I don’t totally understand the > goal. > > There are a *lot* of things you can do in for…in loop with pattern > matching that also would supposedly go against this interpretation of > approachability. Pattern matching in general might be considered to go > against this interpretation. > > Is this pitch saying statements such as: > > for i in 1..<100 where i%2 == 1 {…} > > should be disallowed, while statements like > > for case let view? in views { … } > > are still approachable enough to warrant being supported in the language? > > > Language design has to weigh many factors simultaneously, I think you'd > agree. The argument, essentially, is that `where` is not approachable *for > the functionality that it provides* (namely, as an alternative for a > trivial `guard...continue` statement). Pattern matching is daunting no > doubt, but it offers functionality not conducive to much simpler syntax. > (Or could it be much simpler? If so, then I would support a proposal to > that effect.) > > Put simply, `where` is a less-than-straightforward expression of a very > straightforward concept (filtering an array), whereas pattern matching is > an advanced concept with a commensurately difficult syntax. Others have > brought up generics, for example, but again that's an advanced *concept*; > filtering an array is not. > > > So you do not see that for case syntax as "a less-than-straightforward > expression of a very straightforward concept (filtering an array)"? > > That's strange to me. Seems like that would be the _poster_ child for such > a syntax. > > enum Things { > case One > case Two > case Three > case Four > } > > let things: [Things] = [.One, .Two, .One, .Three, .Four, .One] > for case .One in things { > print("Found a .One") > } > > That code prints "Found a .One" three times. If the `where` syntax is > non-obvious with regard to `continue` or `break` then surely _that_ code is > down right opaque! > > > > > > FWIW, I wouldn’t support removing where based on current arguments without > either the keyword “where" being eliminated completely from the language, > and/or adding equivalent intuitive functionality to Sequence with > same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…). > > > > > I feel bad sending clearly passionate people over to crush another > conversation, but I think you'll find in the Swift repository the > beginnings of some explorations by a certain member of the core team to > rename `.filter()` to `.where()` :D > > As to whether certain methods should be lazy or eager by default, that's a > discussion certainly appropriate for this list. > > > I’ve known about and used the feature since it was first added to Swift > (learned via the language book), and don’t fully understand the confusion > that some developers may have - especially since ‘while’ is already a > keyword and could have been used if that was the actual semantics. > > > One source of confusion was that `while...where` was supported and had > breaking semantics. Now that's gone with SE-0099. Still, the point is that > `where` is favored by some *because* you don't have to write explicitly > what happens when something doesn't pass the filter, whereas the > counterpoint argument is that not writing explicitly what happens when a > rejected element is encountered *is* the very source of confusion. > > > > > -DW > > > > On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > And from the WWDC Platforms SOTU: "Swift is super simple and > approachable.... It's great as a first language. And in fact, we think this > is so important that when we designed Swift this was an explicit design > goal." > > I would be absolutely against adding any more sugar to the for loop. In > that sense, `where` sets a terrible example that certain features of > sequences deserve contextual sugar. (And before someone points it out > again, I've already argued why `for...in` holds its own weight, namely > difficulty of writing a correct `while` replacement and progressive > disclosure to the learner so that the concept of iterators can be learned > afterwards.) > > In short, I would very much be opposed to adding keywords "for fun." > > > > > *_______________________________________________* > > 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