<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br>I think that Jon has exactly described my view on this proposal. Thanks, Jon.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">-1.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"> -- Greg </div><div><br>On Jun 4, 2016, at 12:17 AM, Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><span class="Apple-tab-span" style="white-space:pre"> </span>The suitability of “where” as the keyword in these clauses is a completely separate issue. Frankly, it just comes down to English not having a good, single word to describe an if-and-only-if relationship. So “where" was chosen (some explanation from the original designers has been sorely missing in this thread). The fact that it doesn’t make sense in all cases of conversational English is largely irrelevant, since pretty much all English words in programming languages have that problem. <div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>As for the actual proposal:</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• What is your evaluation of the proposal?<br class=""></blockquote>-1 </div><div class=""><br class=""></div><div class="">I don’t believe any of the proposed advantages outweigh the rather jarring change in syntax.</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></blockquote><div class=""><br class=""></div>No. There has been enough discussion in this thread to convince me that the issues with “where” are vastly overwrought and “where” is actually quite useful as a condition for binding variables. Some improvement may be possible here, especially with the error messages generated, but I think the current syntax is quite good, from a user’s perspective.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Does this proposal fit well with the feel and direction of Swift?<br class=""></blockquote><br class=""></div><div class="">It feels like a regression in style. Introducing semicolons or newlines as important conditional separators feels like a throwback to C in many ways. Eliminating “where” also feels like the elimination of a unique and useful bit of Swift styling.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></blockquote><br class=""></div><div class="">Swift is unique in this regard among the languages I’ve used, to its benefit.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</blockquote><br class=""></div></div><div class="">Read multiple drafts of the proposal and the entire discussion thread.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 1, 2016, at 1:35 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">It is of course true that all parts of a conditional statement have something in common with each other, namely that they are part of the same conditional statement.<br class=""><br class="">A problem definitely exists with the current syntax, which is that the de minimis semantic relationship you are showing is not the relationship implied by the meaning of the word "where."<br class=""><br class="">It is acceptable to say, "I will buy all the apples that are on sale, where the sale is 5% off or better." It is not acceptable to say, "I will buy all the apples that are on sale, where my bike is large," even if it is true that you would only buy all the apples if you had a large bike to transport them home.<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jun 1, 2016 at 11:50 Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Revisiting this conversation, it seems that most of the design space has been thoroughly explored. I think all suggestions presented so far boil down to these:</div><div class=""><br class=""></div><div class="">Q: How is an arbitrary boolean assertion introduced after `if let`?</div><div class=""><br class=""></div><div class="">Option 1 (present scenario)--using `where`</div><div class="">Advantages: expressive when it means exactly the right thing</div><div class="">Drawbacks: makes obligatory the suggestion of a semantic relationship between what comes before and after even when there is no such relationship</div></div></div></blockquote><div class=""><br class=""></div></div><div dir="auto" class="">Haravikk already demonstrated that a semantic relationship always exists in the sense of "bind this variable for all caes where the following condition holds".<div class=""><br class=""></div><div class="">So, the perceived problem with the `where` clause does not exist.</div></div><div dir="auto" class=""><div class=""><br class=""></div><div class="">-Thorsten </div><div class=""><br class=""></div></div><div dir="auto" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Option 2--using a symbol sometimes encountered in conditional statements (e.g. `&&` or comma)</div><div class="">Advantages: doesn't look out of place</div><div class="">Drawbacks: needs to be disambiguated from existing uses, necessitating other changes in syntax</div><div class=""><br class=""></div><div class="">Option 3--using a symbol never encountered in conditional statements (e.g. semicolon)</div><div class="">Advantages: doesn't need to be disambiguated from any existing uses</div><div class="">Drawbacks: looks out of place</div><div class=""><br class=""></div><div class="">For me, options 1 and 2 have permanent and objective drawbacks. By contrast, familiarity increases with time, and beauty is in the eye of the beholder.</div><div class=""><br class=""></div><div class="">* * *</div><div class=""><br class=""></div><div class="">It does occur to me that there is one more option. I don't know that I like it, but it's an option no one has put forward before: recite the opening keyword when beginning a new boolean expression:</div><div class=""><br class=""></div><div class="">`if let x = x where x < 3 { ... }` becomes</div><div class="">`if let x = x if x < 3 { ... }`</div><div class=""><br class=""></div><div class="">`while let item = sequence.next() where item > 0 { ... }` becomes</div><div class="">`while let item = sequence.next() while item > 0 { ... }`</div><div class=""><br class=""></div><div class="">etc.</div><div class=""><br class=""></div><div class=""><br class=""></div>On Tue, May 31, 2016 at 2:00 PM, Erica Sadun <span dir="ltr" class=""><<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>></span> wrote:<br class=""><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"><span class=""><br class="">
> On May 31, 2016, at 12:52 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:<br class="">
> These lines of reasoning are what have compelled me to conclude that `where` might not be salvageable.<br class="">
<br class="">
</span>To which, I'd add: `where` suggests there's a subordinate and semantic relationship between the primary condition and the clause. There's no way as far as I know this to enforce it in the grammar and the proposal allows both clauses to be stated even without the connecting word. You could make a vague argument, I suppose, for renaming `where` to `when` but all in all, even killing `where` we benefit with better expressive capabilities and a simpler grammar.<br class="">
<span class=""><font color="#888888" class=""><br class="">
-- E<br class="">
<br class="">
</font></span></blockquote></div><br class=""></div></div>
</div></blockquote></div></div><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></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">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>