Swift replaces it by guard. I’m not a 100% fan of its syntax (1), which is
guard <#condition#> else {
<#statements#>
}
but do like that <#statements#>must return. So, guard… else semantically can be replaced by if !, but is a bit more limited, thus making it easier to recognize the pattern.
“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:
- return
- break
- continue
- throw”
(1) I can’t think of a much better one, but think I would have picked
“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.)”
Comments
If possible, also ditch that if.
Swift replaces it by guard. I’m not a 100% fan of its syntax (1), which is
but do like that <#statements#> must return. So, guard… else semantically can be replaced by if !, but is a bit more limited, thus making it easier to recognize the pattern.https://docs.swift.org/swift-book/documentation/the-swift-pr...:
“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:
- return
- break
- continue
- throw”
(1) I can’t think of a much better one, but think I would have picked
or (getting rid of that weird else): Eiffel’s preconditions (https://www.eiffel.org/doc/eiffelstudio/Precondition) look even nicer: 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. https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28...:“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.)”