`toggled` or `isFalse` property/method on bool for use with KeyPath APIs

[1-877-547-7272]

I think that a Bool.toggled property would be too similar to the existing ! operator and could cause confusion with new users about which they should use.

Also, the primary motivation of key path expressions being usable as function types is to be able to refer to instance properties in a slightly more convenient way. Key path expressions are not meant to be a replacement for closure expressions. Additionally, I don’t think
string.filter(\.isWholeNumber.toggled)
offers any benefits in terms of clarity or conciseness over
string.filter { !$0.isWholeNumber }
to most Swift programmers — I doubt there are many who know about key paths but don’t know about the ! operator. Even if you find the shorthand $0 argument name confusing, you could name the argument something like character:
string.filter { character in !character.isWholeNumber }

I don’t think we should add an ! operator that’s only for key paths where the value type is Bool like @GreatApe is proposing. However, I am interested in adding support for operators in key path expressions and key path–based @dynamicMemberLookup types. There have been previous discussions on these forums about allowing instance methods to be referenced within key paths:

Why can’t key paths refer to instance methods?

In most parts of Swift, instance methods are treated like properties. However, if you try to reference an instance method using a key path, you get a compiler error. Why is this the case? I assume there is a reason, but I cannot find it. It would be extremely useful in all the same places that other key paths are. Note that I am not asking about calling instance methods inside a key path. I want to know why this works: let instance = 100 let method = instance.isMultiple method(10) // true met…

Allow key paths to reference unapplied instance methods

Allow key paths to reference unapplied instance methods The original key path proposal expressly limited key paths to be able to reference only properties and subscripts: \Person.name // KeyPath<Person, String> \Person.pets[0] // KeyPath<Person, Pet> This proposal adds the ability for key paths to reference instance methods, optionally specifying argument names: \Person.sing // KeyPath<Person, () -> Sound> \Person.sing(melody:lyrics:) // KeyP…

and I think that allowing unary operators in key paths like
string.filter(!\.isWholeNumber)
is something that should be considered as well. Core Team member @Joe_Groff has stated that there’s no fundamental reason key paths can’t support instance methods, and I assume the same thing is true for operators since their implementations are similar. This syntax is intuitive, too:

@toph42

This is exactly what I expected to already work when I was trying to filter based on a KeyPath to a Bool .