<div style="white-space:pre-wrap">We're going in circles again. I addressed this with relation to `guard`, and I would reply in the same way about `for case`:<br><br>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].'<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 14, 2016 at 12:55 Ryan Lovelett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Tue, Jun 14, 2016, at 01:37 PM, Xiaodi Wu via swift-evolution wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>On Tue, Jun 14, 2016 at 12:16 PM, David Waite <span dir="ltr"><<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>></span> wrote:<br></div>
<div><div><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I’m a bit late to this conversation, and I don’t totally understand the goal.<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div>Is this pitch saying statements such as:<br></div>
<div> </div>
<div><span style="white-space:pre-wrap"></span>for i in 1..<100 where i%2 == 1 {…} <br></div>
<div> </div>
<div>should be disallowed, while statements like<br></div>
<div> </div>
<div><span style="white-space:pre-wrap"></span>for case let view? in views { … }<br></div>
<div> </div>
<div>are still approachable enough to warrant being supported in the language?<br></div>
</div>
</blockquote><div> </div>
<div>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.)<br></div>
<div> </div>
<div>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.<br></div>
</div>
</div>
</div>
</blockquote><div> </div>
</div><div><div>So you do not see that for case syntax as "a less-than-straightforward expression of a very straightforward concept (filtering an array)"?<br></div>
<div> </div>
<div>That's strange to me. Seems like that would be the _poster_ child for such a syntax.<br></div>
<div> </div>
<div>enum Things {<br></div>
<div> case One<br></div>
<div> case Two<br></div>
<div> case Three<br></div>
<div> case Four<br></div>
<div>}<br></div>
<div> </div>
<div>let things: [Things] = [.One, .Two, .One, .Three, .Four, .One]<br></div>
<div>for case .One in things {<br></div>
<div> print("Found a .One")<br></div>
<div>}<br></div>
<div> </div>
<div>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!<br></div>
<div> </div>
<blockquote type="cite"></blockquote></div><div><blockquote type="cite"><div dir="ltr"><div><div><div> <br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div> </div>
<div><div>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(…). <br></div>
<div> </div>
<div> </div>
</div>
</div>
</blockquote><div> </div>
<div>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<br></div>
<div> </div>
<div>As to whether certain methods should be lazy or eager by default, that's a discussion certainly appropriate for this list.<br></div>
<div> <br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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.<br></div>
</div>
</div>
</blockquote><div> </div>
<div>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.<br></div>
<div> <br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div> </div>
<div> </div>
<div><span><span style="color:rgb(136,136,136)">-DW</span></span><br></div>
<div> </div>
<div> </div>
<div><div><div><blockquote type="cite"><div><span>On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</span><br></div>
<div> </div>
<div><span><span style="font-family:Helvetica"><span style="font-size:12px">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."</span></span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica"><span style="font-size:12px">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.)</span></span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica"><span style="font-size:12px">In short, I would very much be opposed to adding keywords "for fun."</span></span></span></div>
</blockquote></div>
<div> </div>
</div>
</div>
<div> </div>
</div>
</blockquote></div>
</div>
</div>
</blockquote></div><div><blockquote type="cite"><div><u>_______________________________________________</u><br></div></blockquote></div><div><blockquote type="cite">
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>