<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body 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">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>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><br></div><div>-Thorsten </div><div><br></div><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 class=""><br>
> On May 31, 2016, at 12:52 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">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 class="HOEnZb"><font color="#888888"><br>
-- E<br>
<br>
</font></span></blockquote></div><br></div></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></div></body></html>