<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=""><div class=""><br class=""><br class=""><br class=""><b class="">Impact on existing code<br class=""></b><br class="">There is no impact on existing code. This only makes formerly invalid code start being accepted.</div><div class=""><br class=""></div><div class=""><br class=""><b class="">Alternatives considered<br class=""></b><br class="">There are three primary alternatives: do nothing, expand the scope of ‘if' and ‘while’ conditions as well, and significantly change the syntax of guard.</div><div class=""><br class=""></div><div class=""><b class="">Do nothing</b>: It can be argued that this change would make guard inconsistent with the restrictions of ‘if’ and ‘while’ and that inconsistency would be confusing. On the other hand, I am arguing that this is an arbitrary restriction.</div><div class=""><br class=""></div><div class=""><b class="">Expand the scope of “if” and “while” statements:</b> Through enough heroics and lookahead we could consider relaxing the trailing closure requirements on `if` and `while` statements as well. While this could be interesting, it raises several ambiguity questions. For example, we need significant lookahead to realize that “a” here is not a trailing closure, since we have a closure expression being fully applied after it:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if foo { …a... } { …b… }()</div><div class=""><br class=""></div><div class="">this could be addressed with whitespace rules or other approaches, but since any such direction would be compatible with this proposal, I see it as a separable potential extension on top of this basic proposal.</div><div class=""><br class=""></div><div class=""><b class="">Change the syntax of guard: </b>I only list this for completeness, but we could eliminate the `else` keyword, making guard more similar to `if` and `while`. I personally think that this is a really bad idea though: the guard statement is not a general `unless` statement, and its current syntax was very very carefully evaluated, iterated on, discussed, and re-evaluated in the Swift 2 timeframe. I feel that it has stood the test of time well since then.</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>