<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 class=""><blockquote type="cite" class=""><div class="">On 29 May 2016, at 20:39, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On May 29, 2016, at 3:55 AM, Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On May 27, 2016, at 12:11 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hello Swift community,<br class=""><br class="">The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md</a></div></div></blockquote></div><br class=""><div class="">Thanks everyone. FYI, Erica and I discussed it offlist and agreed to amend the proposal: now you can use semicolons or a newline to separate clauses of different types.</div></div></div></blockquote></div><br class=""><div class="">While I like the improvements made to the proposal, I’m still not in favour of removing the where clause; the introduction of semi-colons and new-lines as separators eliminates the need to use it if you don’t want to, so developers will be free to drop it if they wish, but I don’t see any real reason to remove it from the syntax, as it feels inconsistent if I can use it elsewhere, and I prefer to do so, particularly on if/guard.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I can definitely respect the position that “where” feels more readable than a semicolon, it certainly provides a more “fluent” style.</div><div class=""><br class=""></div><div class="">That said, the existing Swift 2 syntax was inconsistent about this too: if you started a condition with an availability check, you comma separate it from a boolean with a comma:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>if #available(iOS 52, *), x == y {} </div><div class=""><br class=""></div>While we could have used “where” here, it was counterproductive because it didn’t increase clarity of code.</div></div></div></blockquote><div><br class=""></div><div>See I never write statements like these. In fact, I almost never write conditionals that aren’t something like the following:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if foo && (bar == “bar”) { … }</font></div><span class="Apple-tab-span" style="font-family: Monaco; white-space: pre;"> </span><span style="font-family: Monaco;" class="">if let value = foo { … }</span><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let value = foo where value > 5 { … }</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if #available(iOS 52, *) { … }</font></div><div class=""><br class=""></div><div class="">I’m starting to use pattern matching more, but I only found out about the existence of that feature relatively recently as a result of subscribing to this list ;)</div><div class=""><br class=""></div><div class="">Point being that the third case is the only one where I ever do any real mixing and matching. Of course I can’t guarantee that I’ll never need something more complex some day, but I’ve managed pretty well so far without running into problems.</div></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On 29 May 2016, at 15:15, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="white-space: pre-wrap;">Haravikk, this *is* the proposal for removing where clauses; changing the rules about commas was the later addition to the discussion.</div></div></blockquote><br class=""></div><div class="">Still, I feel like these are two different issues, as I’m generally in favour of the switch to semi-colon separators (though I do prefer how commas look, but that’s minor as I almost never use them, and mostly for binding multiple values which looks like it will still be able to use commas anyway), but I’m very fond of using where for the mixing and matching.</div><div class=""><br class=""></div><div class="">I understand that the need for semi-colon separators probably arose as a requirement of removing where, but I think it makes more sense to cover semi-colons first as a result, and come back to removing where clauses afterwards.</div></body></html>