<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><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="">In the <a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" class="">Commonly Rejected Changes</a> page and in <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005534.html" class="">this swift-evolution email</a> to which it refers, I read that first there was “unless", then “require” then finally “guard ... else”.<div class=""><br class=""></div><div class="">I couldn’t find the earlier discussion in which “unless” was replaced for a while by “require”, so I am moved to ask, “Was there ever “require … else”, or was it just “require”? I’ll assume it was just “require”.</div><div class=""><div class=""><br class=""><div class="">There are various problems with the choice of the keyword “guard”. These have bothered me every since I first saw it.</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="AEC8A2A3-AC34-4BE0-95F8-956B654EFF1D" height="55" width="439" apple-width="yes" apple-height="yes" class="" src="cid:A9449DAB-154E-4A98-9AAC-8CF8E89CCB06@d.yost.com"></div><div class=""><br class=""></div><div class="">Problems:</div><div class=""><ul class="MailOutline"><li class="">If we’re reading “guard” as a verb, then we expect the object to come right after it, but it doesn’t; you can’t say you’re guarding the condition-clause. No, what you’re guarding is the code after the entire guard-statement.</li><li class="">The “else” after guard suggests that the else code covers what to do when the guard fails, but the guard doesn’t fail in the “else”; the guarding works correctly on both execution paths.</li><li class="">The “guard” keyword gives no hint really as to whether the condition is required or prohibited; you figure that out only be thinking about why there is an “else” clause. The guard statement is intended to replace typical code in the wild that uses an “if” statement that is written to abort when the condition fails, not when it succeeds.</li></ul></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div class="">Proposed</div><div class=""> require count >= 0 else { return }</div><div class="">Replaces</div><div class=""><div class=""><div class=""> guard count >= 0 else { return }</div></div></div></div></div><div class="">Unambiguously equivalent to</div><div class=""> if count < 0 { return }</div><div class=""><br class=""></div><div class="">Benefits of “require … else”:</div><div class=""><ul class="MailOutline"><li class="">The word “require” states more clearly and strongly than “guard” that it is an ultimatum.</li><li class="">The word “require” conveys clearly that the require-statement can block the following statement from executing.</li><li class="">The condition-clause functions as the object of the verb “require”, so it reads well as natural language.</li><li class="">The sense of the condition-clause is clear; success is <i class="">required</i> before executing the next statement.</li><li class="">The “else” after “require” clearly introduces code to run if the requirement is not met.</li><li class="">With the new comma syntax for conditions, the word “require” fits well with the fact that all conditions in the list are, shall we say, required.</li><li class="">When one of the conditions is a let, “require” conveys the idea that the declaration will be required and thus will have a lifetime beyond the require-statement.</li></ul></div><div class=""><br class=""></div><div class="">It would still be OK to refer to a require-statement as a “guard clause", to invoke the history of guarding. But even here, I think “require clause” is clearer (see last bullet point). Evoking the historical use of the term “guard” for this construct in Swift is not such a great argument because (a) the term is not that well known, and (b) the term has not always been used for clearly the same purpose. <a href="https://en.wikipedia.org/wiki/Guarded_Command_Language#Selection:_if" class="">Dijkstra’s use of the term</a>, for example, was a bit different, allowing for nondeterministic execution.</div><div class=""><br class=""></div><div class="">In summary, “require … else” is a very clean choice and beats “guard ... else” handily.</div><div class=""><br class=""></div></div></div></body></html>