<div dir="ltr">On Mon, Jun 13, 2016 at 8:49 AM, Brandon Knope <span dir="ltr"><<a href="mailto:bknope@me.com" target="_blank">bknope@me.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="auto"><div><br><br>Sent from my iPad</div><span class=""><div><br>On Jun 13, 2016, at 9:36 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope <span dir="ltr"><<a href="mailto:bknope@me.com" target="_blank">bknope@me.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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 dir="auto"><div>Are you really surprised that some people don't want this taken away?</div></div></blockquote><div><br></div><div>Nope, that's to be expected.</div><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 dir="auto"><div></div><div>The burden should be on those that want it taken out of the language and not those that want it kept. After all something is being removed and it should be a delicate process. </div></div></blockquote><div><br></div><div>Agreed. We who think it's better to take this syntax out have advanced an argument with several prongs. Namely, that the `where` clause serves no independent purpose; </div></div></div></div></div></blockquote><div><br></div></span><div>What does this mean or matter?</div></div></blockquote><div><br></div><div>Again, these are prongs to one argument, not independent grounds for removal. We've discussed at length what this means above.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>that a more general solution has already been added to the language (as well as another in the stdlib);</div></div></div></div></div></blockquote><div><br></div></span><div>We have sugar all over the place to make features more palatable </div></div></blockquote><div><br></div><div>This presumes that `guard` is unpalatable. I don't buy that claim.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> that the `where` clause is not necessary for progressive disclosure to new users before they're ready for the general solution; </div></div></div></div></div></blockquote><div><br></div></span><div>I have no clue what this is suppose to mean</div></div></blockquote><div><br></div><div>For instance, `if let ...` is sugar for `if case let ...?`, itself sugar for `if case let .some(...)`; there have been suggestions to remove it on that basis. However, it has been pointed out that one purpose for that grammar is that it allows a new user to unwrap optionals without learning a more advanced feature, namely pattern matching. Likewise `[Int]` may be shorthand for `Array<Int>`, but it has the bonus of removing generics from the picture, so that a user can learn one thing first (namely arrays) before tackling a more advanced concept.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>that it is, at present, rarely used in practice; </div></div></div></div></div></blockquote><div><br></div></span><div>It was added in the official release less than a year ago and it's not really documented well. And I'm not convinced it's rarely used in practice especially when it's exactly what you want</div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div></div></blockquote></span></div></blockquote><div><br></div><div>I've endeavored to outline why it's rarely exactly what you want. Whether you buy it or not, well, that's another matter.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>that it has no analog in other commonly used general purpose languages in the C family; </div></div></div></div></div></blockquote><div><br></div></span><div>Why is this a good argument for its removal?</div></div></blockquote><div><br></div><div>Again, it's a prong of one argument, not independent grounds for removal. It goes to discoverability and user expectations when they approach the language. For people who switch between languages often, features that are unique, especially unique features that serve non-unique purposes (such as filtering an array), will be more rarely reached for than features that are commonly found among languages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>that it is the remnant of a direction in which the core team later decided not to pursue; </div></div></div></div></div></blockquote></span><div>I don't know anything about this but it sure seemed at one point they really liked where. It had to have gone through their own rigorous review process to be added in the first place?</div></div></blockquote><div><br></div><div>It was meant to be part of a larger, more elaborate push into pattern matching, which IIUC was found internally to be not well accepted; the larger effort was abandoned but the incipient grammar was left behind.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>and that, given its lack of utility, lack of use, and vestigial state, </div></div></div></div></div></blockquote><div><br></div></span><div>Another opinion. This doesn't seem like a definitive argument for its removal</div></div></blockquote><div><br></div><div>This is a summation of the prongs mentioned above.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>being the cause of confusion even among a small number of users (if their number be small) is grounds to conclude that it is harmful to the language and therefore ought to be removed.</div></div></div></div></div></blockquote><div><br></div></span><div>"Harmful to the language" seems a bit extreme. </div><div><br></div><div>I would love to hear more from the core team on this but I know they are just too busy right now</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Brandon </div></font></span><div><div class="h5"><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 dir="auto"><div>Don't be surprised when the defenders say it is more readable to them. That is a *sound* argument in my opinion. <br></div></div></blockquote><div><br></div><div>IMO, it cannot stand on its own as a complete argument for saving a feature in the face of the arguments we've advanced. Couldn't you say the same for `++` or `for;;` loops? I'd say our case is at least as strong as that for `for;;` loops. By comparison, if I recall, the `for;;` loop was argued to be ill-fitting the rest of the language and lacking in usage, but it certainly had utility independent of `for...in` loops and was well precedented in C languages.</div><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 dir="auto"><span><div><br></div><div>Brandon<br><br>Sent from my iPad</div></span><div><div><div><br>On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div style="white-space:pre-wrap">This is not a sound argument. If your filtering can be expressed as a where clause, then you would only have to read one line into the loop to see it in the form of a guard clause.<br><br>Moreover, if what you're arguing is that you shouldn't ever have to *read* inside the loop to know if a sequence is filtered, how do you propose that we do that? Remove the continue keyword?<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 13, 2016 at 6:16 AM Jean-Daniel Dupas via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></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">-1 for the removal.<div><br></div><div>When I read code, I find it far more visible that a loop is over a filter list when the filter clause is on the same line, than when the filter clause is inside the loop.</div><div><br></div><div>Having to read the full content of the loop to determine if the list is filtered or not is not an improvement IMHO.</div><div><br></div><div>Moreover, I find it far cleaner to use the where clause that having to remember than I have to use the lazy accessor to avoid a performance hit.</div></div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:10px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">And to follow-up to myself once again, I went to my "Cool 3rd Party Swift Repos" folder and did the same search. Among the 15 repos in that folder, a joint search returned about 650 hits on for-in (again with some false positives) and not a single for-in-while use.</div><div style="font-family:Helvetica;font-size:10px;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></div><div style="font-family:Helvetica;font-size:10px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">-- E</div></blockquote><div><br></div><div>Not to undermine this fact, but I believe the fact that `where` can be used in a for loop is not widely known. I didn't know about it until about a month ago (haven't really read much docs, but most people don't either).</div><div><br></div><div>But after I found out about it, I started using it and it IMHO improved readability of my code. Not by much, but it's the little things that make you smile, right?</div><div><br></div><div>Many people here argument that `where` is a Swift speciality and needs to be learned by the developer - the alternative is to teach the person what's the proper alternative - that using .filter can have performance impact and that the *correct* way is to use guard within the for loop. And that's IMHO much worse than teaching a person about using `where` within a for loop.</div><br><blockquote type="cite"><div><span style="font-family:Helvetica;font-size:10px;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">_______________________________________________</span><br style="font-family:Helvetica;font-size:10px;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:10px;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">swift-evolution mailing list</span><br style="font-family:Helvetica;font-size:10px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:10px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:Helvetica;font-size:10px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:10px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br></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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div></blockquote></div><br></div></div>