<div dir="ltr">On Tue, Jun 14, 2016 at 12:37 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">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></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 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">I’m a bit late to this conversation, and I don’t totally understand the goal.<div><br></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.</div><div><br></div><div>Is this pitch saying statements such as:</div><div><br></div><div><span style="white-space:pre-wrap"> </span>for i in 1..<100 where i%2 == 1 {…} </div><div><br></div><div>should be disallowed, while statements like</div><div><br></div><div><span style="white-space:pre-wrap"> </span>for case let view? in views { … }</div><div><br></div><div>are still approachable enough to warrant being supported in the language?</div></div></blockquote><div><br></div></span><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.)</div><div><br></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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 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><br></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</div></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>I should add, if this proposal is adopted along with the enclosed suggestion to replace `where` with `if` in `case` and `catch`, the `where` keyword would be completely eliminated except in the context of generics. If the enclosed suggestion is not adopted here, alternatives will follow on shortly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 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>and/or adding equivalent intuitive functionality to Sequence with same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…). </div><div><br></div><div></div></div></div></blockquote><div><br></div></span><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</div><div><br></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><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 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.</div></div></div></blockquote><div><br></div></span><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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 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"><span><font color="#888888"><div><br></div><div>-DW</div></font></span><span><div><br></div><div><div><div><blockquote type="cite"><div>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:</div><br><div><span 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;float:none;display:inline!important">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><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;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;float:none;display:inline!important">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><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;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;float:none;display:inline!important">In short, I would very much be opposed to adding keywords "for fun."</span></div></blockquote></div><br></div></div></span></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>