Five years later there is still a need for such a negation property on bool particulaly in functional programming use cases.
Current solutions involve writing an extension on bool. E.g.
extension Bool {
var negated: Bool { !self }
}
let string = "abc12345"
let nonDigits = string.filter(\.isWholeNumber.negated) // "abc"
The alternative would be to write let nonDigits = string.filter { !$0.isWholeNumber } // "abc" today.
There are clear drawbacks to this approach in light of the introduction of key paths in more recent Swift versions published since the start of this thread.
- Using key paths removes the need to adopt anonymous closure arguments, which impair readability. Named closure arguments on the other hand would be a detriment to brevity. Neither is a great solution when possibilities exist that cleanly avoid both drawbacks.
- Requiring curly braces means that when used in an if-let or guard-let statement, the filter argument would need to further be wrapped in parentheses. This impairs reading and writing the code.
Declaring an extension on Bool such as isFalse or negated would be trivial. As it is something that could widely benefit the Swift developer community, personally, I see no reason for it not to be adopted into the standard library.
What other alternatives that have not been discussed here, if any?