<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 31, 2016, at 11:16 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">The motivating example is a compelling illustration of a problem with the current grammar. I don't think anyone would disagree that `if let y = y where x < z` is an abomination.<br class=""><br class="">Now, I see no principled criteria, and none have been proposed here, that would be useful to restrict what can come after `where`. Moreover, I see no contention with the argument that arbitrary Boolean assertions should be possible after a let binding.<br class=""><br class="">Finally, it is a stated goal of the core team that there shouldn't be multiple 'dialects' of Swift, and that where possible there should be one general solution rather than two options.<br class=""><br class="">Given these premises, I have to conclude that *if* the motivating issue is to be fixed, we must get rid of `where`.<br class=""></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">This proposal does affect where clauses in:</div><div class=""><ul class="" style="font-family: Palatino-Roman;"><li class=""><span class="">case conditions (<font face="Menlo" class="">case pattern initializer where-clause?</font>)</span></li><li class=""><span class="">optional binding conditions (<font face="Menlo" class="">optional-binding-head optional-binding-continuation-list? where-clause?</font>)</span></li></ul><div class="">This proposal does not affect where clauses in:</div></div><div class=""><ul class="" style="font-family: Palatino-Roman;"><li class="">for-in statements (<font face="Menlo" class="">for case? pattern in expression where-clause? code-bloc</font>k)</li><li class="">case item lists (<font face="Menlo" class="">case-item-list → pattern where-clause? | pattern where-clause? , case-item-list</font>)</li><li class="">catch clauses (<font face="Menlo" class="">catch pattern? where-clause? code-block</font>)</li><li class="">generic parameter clause's requirement clause</li></ul><div class="">What I'm hearing is that at least some developers would like to retain where clauses in case conditions and optional binding conditions but still allow the more controllable logic introduced by differentiating condition types with semicolons or newlines. Is that a fair summary? </div><div class=""><br class=""></div><div class="">Here is the where clause grammar:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">where_clause = where where_expression</font></div><div class=""><font face="Menlo" class="">where_expression = expression</font></div><div class=""><br class=""></div><div class="">I think technically, by adding the new separators, the `where` need not be disallowed. That leaves the following questions:</div><div class=""><br class=""></div><div class="">* Should `where` clauses be allowed where the contents of the where clause have no connection to the condition that precedes it?</div><div class="">* Is there a technical way to to check for such conformance?</div><div class="">* Should the `where` clause be left unconstrained, as it currently is in switch statements and for loops, etc, which is consistent with the rest of the language but contrary to the spirit of safety in Swift?</div><div class="">* Should `where` clauses be re-evaluated throughout the language?</div><div class=""><br class=""></div><div class="">-- E</div></div><div class=""><br class=""></div></body></html>