<div dir="ltr">+1 <div>I think that it is an improvement overall and the work for consistency is appreciated.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 4, 2016 at 10:03 PM, Greg Titus via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br>I think that Jon has exactly described my view on this proposal. Thanks, Jon.</div><div><br></div><div>-1.</div><div><br></div><div> -- Greg </div><div><div class="h5"><div><br>On Jun 4, 2016, at 12:17 AM, Jon Shier 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><span style="white-space:pre-wrap"> </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><span style="white-space:pre-wrap"> </span>As for the actual proposal:</div><div><br></div><div><div><blockquote type="cite"><span style="white-space:pre-wrap"> </span>• What is your evaluation of the proposal?<br></blockquote>-1 </div><div><br></div><div>I don’t believe any of the proposed advantages outweigh the rather jarring change in syntax.</div><div><br></div><div></div><blockquote type="cite"><div><span style="white-space:pre-wrap"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br></div></blockquote><div><br></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><br><div><blockquote type="cite"><span style="white-space:pre-wrap"> </span>• Does this proposal fit well with the feel and direction of Swift?<br></blockquote><br></div><div>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><br></div><div><blockquote type="cite"><span style="white-space:pre-wrap"> </span>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></blockquote><br></div><div>Swift is unique in this regard among the languages I’ve used, to its benefit.</div><div><br></div><div><blockquote type="cite"><span style="white-space:pre-wrap"> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</blockquote><br></div></div><div>Read multiple drafts of the proposal and the entire discussion thread.</div><div><br><div><blockquote type="cite"><div>On Jun 1, 2016, at 1:35 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="white-space:pre-wrap">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><br>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><br>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></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 11:50 Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" target="_blank">tseitz42@icloud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div><br></div><div><br>Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>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><br></div><div>Q: How is an arbitrary boolean assertion introduced after `if let`?</div><div><br></div><div>Option 1 (present scenario)--using `where`</div><div>Advantages: expressive when it means exactly the right thing</div><div>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><br></div></div><div dir="auto">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><br></div><div>So, the perceived problem with the `where` clause does not exist.</div></div><div dir="auto"><div><br></div><div>-Thorsten </div><div><br></div></div><div dir="auto"><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Option 2--using a symbol sometimes encountered in conditional statements (e.g. `&&` or comma)</div><div>Advantages: doesn't look out of place</div><div>Drawbacks: needs to be disambiguated from existing uses, necessitating other changes in syntax</div><div><br></div><div>Option 3--using a symbol never encountered in conditional statements (e.g. semicolon)</div><div>Advantages: doesn't need to be disambiguated from any existing uses</div><div>Drawbacks: looks out of place</div><div><br></div><div>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><br></div><div>* * *</div><div><br></div><div>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><br></div><div>`if let x = x where x < 3 { ... }` becomes</div><div>`if let x = x if x < 3 { ... }`</div><div><br></div><div>`while let item = sequence.next() where item > 0 { ... }` becomes</div><div>`while let item = sequence.next() while item > 0 { ... }`</div><div><br></div><div>etc.</div><div><br></div><div><br></div>On Tue, May 31, 2016 at 2:00 PM, Erica Sadun <span dir="ltr"><<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.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"><span><br>
> On May 31, 2016, at 12:52 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
> These lines of reasoning are what have compelled me to conclude that `where` might not be salvageable.<br>
<br>
</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>
<span><font color="#888888"><br>
-- E<br>
<br>
</font></span></blockquote></div><br></div></div>
</div></blockquote></div></div><div dir="auto"><div><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></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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></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><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
<br></blockquote></div><br></div>