If possible, also ditch that <i>if</i>.<p>Swift replaces it by <i>guard</i>. I’m not a 100% fan of its syntax (1), which is<p><pre><code> guard <#condition#> else {
<#statements#>
}
</code></pre>
but do like that <i><#statements#></i> <i>must</i> return. So, <i>guard… else</i> semantically can be replaced by <i>if !</i>, but is a bit more limited, thus making it easier to recognize the pattern.<p><a href="https://docs.swift.org/swift-book/documentation/the-swift-programming-language/statements/" rel="nofollow noreferrer">https://docs.swift.org/swift-book/documentation/the-swift-pr...</a>:<p><i>“The else clause of a guard statement is required, and must either call a function with the Never return type or transfer program control outside the guard statement’s enclosing scope using one of the following statements:<p>- return<p>- break<p>- continue<p>- throw”</i><p>(1) I can’t think of a much better one, but think I would have picked<p><pre><code> requires <#condition#> else {
<#statements#>
}
</code></pre>
or (getting rid of that weird <i>else</i>):<p><pre><code> ifnot <#condition#> {
<#statements#>
}
</code></pre>
Eiffel’s preconditions (<a href="https://www.eiffel.org/doc/eiffelstudio/Precondition" rel="nofollow noreferrer">https://www.eiffel.org/doc/eiffelstudio/Precondition</a>) look even nicer:<p><pre><code> require <#condition#>
</code></pre>
but do not allow specifications of what to do when the condition isn’t met, and aren’t supposed to be checked in procession code. <a href="https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions" rel="nofollow noreferrer">https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28...</a>:<p><i>“It is in fact part of the Eiffel method that a routine body should never test for the precondition, since it is the client's responsibility to ensure it. (An apparent paradox of Design by Contract™, which is reflected in the bottom-right entries of the preceding and following contract tables, and should not be a paradox any more at the end of this discussion, is that one can get more reliable software by having fewer explicit checks in the software text.)”</i>