<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 31 May 2016, at 18:57, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></div></blockquote><br class=""></div><div>Personally I’m not sure that where should need to be constrained, in fact one of the examples given as “incorrect” is arguably not so:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let foo = x where y < z { … }</font></div><div><br class=""></div><div>In this case y < z doesn’t appear strictly related to the optional binding, but it may still be a condition of it, in essence it’s saying “bind foo if this is true”. This is interesting because the compiler is actually free to evaluate y < z first, and only perform the binding afterwards. Actually this is also true in the following case:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let foo = x where foo > 5 { … }</font></div><div><br class=""></div><div>To evaluate foo > 5 the compiler doesn’t actually need to unwrap x, it just needs to know if x is .Some, in which case it can compare the value and only if the comparison succeeds actually copy it into a variable and continue.</div><div><br class=""></div><div>Of course statements separated by semi-colons can be reordered behind the scenes if the compiler wants to do-so, so long as the logic doesn’t change, but I find that where reads better with that implication in mind. It reads visually like “bind this if this test is true” rather than “bind this, then test this”.</div><div><br class=""></div><div>Plus it just looks nicer (to me); sometimes aesthetics are important, and the majority of cases don’t need the complexity of lots of conditionals that need separating, sometimes a pattern and a condition, or a binding and a condition is enough, and the where clause has this covered, and keeps these forms of conditional visually distinct. Much more complex cases will benefit from semi-colons, which in turn will make them visually distinct too, even if a lot of the building blocks are the same.</div><div><br class=""></div><div>Put another way, I tend to think of pattern matching, conditional binding and regular logic as three completely different forms of conditional (I suppose they are in fact at present), the separators as proposed will let you mix and match these cleanly, which has the potential for some overlap sure, but I think developers can be left to resolve that for themselves by choosing whether to group a conditional with where, or separate it.</div><div><br class=""></div><div><br class=""></div><div>Anyway, it doesn’t really matter overall, as the addition of semi-colons/new-lines as separators isn’t dependent upon the removal of where clauses, so they can be removed later if it’s deemed useful. In fact, doing it this way would be a better way to do it as it gives us a period in which both features will be available, and we can just wait and see what people actually use. If where clauses are ignored in favour of semi-colons/new-lines, then at this point it will be trivial to replace them, as you can non-destructively remove the feature by simply swapping the where keyword from these types of conditionals for a semi-colon, or provide a fixit to do this, as functionally they will be identical.</div></body></html>