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

**URL:** <https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464>\
**Category:** Discussion\
**Created:** [August 24, 2021, 7:44pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464 "2021-08-24T19:44:28Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ilias\_Karim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ilias_karim/32/2339_2.png) [@Ilias\_Karim](https://forums.swift.org/u/Ilias_Karim)\
**Post date:** [August 24, 2021, 7:44pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/1 "2021-08-24T19:44:28Z")

</div>

Implementation:

```swift
extension Bool {
  var toggled: Bool {
    !self
  }
}

```

Usage:

```swift
let trueBool = true
print(trueBool.toggled) // false

```

Rationale:  
`toggled` provides ease-of-use in functional contexts.

E.g.  
In the status quo, one way to filter whole numbers from a string would be as follows.

```swift
let string = "abc12345" 
let nonDigits = string.filter { !$0.isWholeNumber } // "abc"

```

However, such an approach does not leverage the benefit key paths introduced in Swift 5.  
You can see these in use in the following expressions.

```swift
let string = "abc12345" 
let nonDigits = string.filter(\.isWholeNumber.toggled) // "abc"

```

Besides brevity, a major advantage is that when used in an if-let or guard-let clause, the filter expression will not need to be wrapped in both parentheses as well as curly braces.

Prior art:  
Other Swift types offer similar interfaces that can be drawn on for inspiration. Take the Sequence for instance.  
It offers two methods, one which mutates, `reverse()` and another `reversed()` which does not.

```swift
var collection = ["A", "B", "C"]
print(collection.reverse())
// ["C", "B", "A"]
print(collection)
// ["C", "B", "A"]

```

```swift
let collection = ["A", "B", "C"]
let reversedCollection = collection.reversed()
print(collection)
// ["A", "B", "C"]
print(Array(reversedCollection))
// ["C", "B", "A"]

```

The prior art would imply a corresponding set of methods on the Bool type.  
`.toggle()` already exists on Bool.

```swift
var bool = true
bool.toggle()
print(bool)
// false

```

That makes it plain the obvious omission of`.toggled` on Bool, that would clean up a lot of filtering code.

This approach provides greater utility to developers to the swift ecosystem, who would either

- declare toggled/toggled() in each code base worked on
- use curly braces simply in order to access the '!" not operator.
- as mentioned at the outset of my post, not having to wrap curly braces in parentheses in the context of if-let and guard-let statements where the only reason to do so would be to access with "!" not operator.  
The resulting benefits include:
- code deduplication through declaring such a property in Swift standard library

Previous thread: [[Proposal] Add property for negation to Bool - Evolution / Discussion - Swift Forums](https://forums.swift.org/t/proposal-add-property-for-negation-to-bool/2720/17)

---

<div class="post-metadata">

**Author:** ![JJJ](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jjj/32/12193_2.png) [@JJJ](https://forums.swift.org/u/JJJ)\
**Post date:** [August 24, 2021, 9:18pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/2 "2021-08-24T21:18:21Z")

</div>

I like it because it's not as tempting to "misuse" this for ordinary if conditions as if it was named e.g. "not". And it nicely complements `toggle()` 👍

I'm just fearing stuff like

```swift
if isEven(x).toggled {
  doStuff(x)
}

```

Perhaps we could have a fixit suggesting `isEven(x) == false` instead? 🙂

---

<div class="post-metadata">

**Author:** ![Peter-Schorn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/peter-schorn/32/11183_2.png) [@Peter-Schorn](https://forums.swift.org/u/Peter-Schorn)\
**Post date:** [August 24, 2021, 10:25pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/4 "2021-08-24T22:25:30Z")

</div>

> [@Ilias\_Karim](#):
>
> Prior art:  
> Other Swift types offer similar interfaces that can be drawn on for inspiration. Take the Sequence for instance.  
> It offers two methods, one which mutates, `reverse()` and another `reversed()` which does not.

There is no operator that performs the equivalent operation to the `reversed` method on `Sequence`, whereas there is one that provides the equivalent operation on `Bool.toggled`. Because this operation is already provided by an operator, the extra property is redundant.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [August 24, 2021, 10:30pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/5 "2021-08-24T22:30:54Z")

</div>

I’m not sure anything has changed in the last five years to warrant repeating the conversation again. It’s unlikely to surface any new arguments which haven’t already been discussed at length.

I’ll reiterate my point from before that Swift doesn’t vend alternative spellings for the same API. While prefix operators are more cumbersome to use in certain idioms that involve lots of chaining, so are free functions; if that’s deemed a significant enough usability problem then an appropriate solution is some feature that can be used to solve this problem for all such cases, not a piecemeal duplication of one API at a time.

But to circle back, starting up a new thread doesn’t seem like a very productive use of the community’s time, as nothing fundamentally has changed since the numerous previous discussions. If it has, it’d be worth focusing on that here. Otherwise, everyone can browse the many previous threads at their leisure.

---

<div class="post-metadata">

**Author:** ![David\_Catmull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_catmull/32/1007_2.png) [@David\_Catmull](https://forums.swift.org/u/David_Catmull)\
**Post date:** [August 24, 2021, 10:34pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/6 "2021-08-24T22:34:03Z")

</div>

> [@Peter-Schorn](#):
>
> There is no operator that performs the equivalent operation to the `reversed` method on `Sequence` , whereas there is one that provides the equivalent operation on `Bool.toggled` . Because this operation is already provided by an operator, the extra property is redundant.

As I understand it, the main selling point here is that having a property facilitates accessing the value via a keypath, which is more convenient in some cases.

---

<div class="post-metadata">

**Author:** ![Peter-Schorn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/peter-schorn/32/11183_2.png) [@Peter-Schorn](https://forums.swift.org/u/Peter-Schorn)\
**Post date:** [August 24, 2021, 10:39pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/7 "2021-08-24T22:39:53Z")

</div>

It would only be more convenient for APIs that require a keypath, as opposed to those that accept a closure but which can satisfied by a keypath literal. For this reason, the `string.filter(\.isWholeNumber.toggled)` example is a bad one. `string.filter { !$0.isWholeNumber }` is actually more brief.

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [August 25, 2021, 7:05am UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/8 "2021-08-25T07:05:46Z")

</div>

This properly was also often referred as `isFalse` in the forum.

---

<div class="post-metadata">

**Author:** ![GreatApe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/greatape/32/2640_2.png) [@GreatApe](https://forums.swift.org/u/GreatApe)\
**Post date:** [August 25, 2021, 9:55am UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/9 "2021-08-25T09:55:43Z")

</div>

> [@xwu](#):
>
> While prefix operators are more cumbersome to use in certain idioms that involve lots of chaining, so are free functions

This is not a free function though. I for one agree that there should be a way to use negation in keypath expressions, and ideally in chaining.

---

<div class="post-metadata">

**Author:** ![Ilias\_Karim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ilias_karim/32/2339_2.png) [@Ilias\_Karim](https://forums.swift.org/u/Ilias_Karim)\
**Post date:** [August 25, 2021, 12:04pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/10 "2021-08-25T12:04:13Z")

</div>

Presume for a moment that string is optional.

`if let x = string?.filter(\.isWholeNumber.toggled) { print($0) }`  
is clearer than (and nearly a brief as)  
`if let x = string?.filter({ !$0.isWholeNumber }) { print($0) }`  
and it is more more brief than not using anon. variables for the filter clause,

```swift
if let x = string?.filter({ number in,
  number.isWholeNumber }) { 
 print(x) }
}

```

In short, that this syntax like `toggled` or `isFalse` may introduce an extract character is made up for in terms of readability. One or two characters does not seem a good reason to omit an API that can improve keypath chaining, a first class feature since Swift 5 that requires the utmost support for it's mamy widespread use cases. In other words, the proposal for `toggled` or `isFalse` is decidedly not an issue about "could golf' see how much few character can be used to execute the same correct code.

Further, there are certainly scenarios where a "!" cannot apply. Let's say you map one object to another using keypaths, for instance. There is no place to put a not operator.

---

<div class="post-metadata">

**Author:** ![GreatApe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/greatape/32/2640_2.png) [@GreatApe](https://forums.swift.org/u/GreatApe)\
**Post date:** [August 25, 2021, 12:07pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/11 "2021-08-25T12:07:40Z")

</div>

> [@Ilias\_Karim](#):
>
> Further, there are certainly scenarios where a "!" cannot apply. Let's say you map one object to another using keypaths, for instance. There is no place to put a not operator.

You could put it in front of the keypath, you can probably make a function that transforms keypaths, at least if you create your own private .toggled.

---

<div class="post-metadata">

**Author:** ![Ilias\_Karim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ilias_karim/32/2339_2.png) [@Ilias\_Karim](https://forums.swift.org/u/Ilias_Karim)\
**Post date:** [August 25, 2021, 12:13pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/12 "2021-08-25T12:13:12Z")

</div>

This is what I am suggesting: a .`toggled` or `isFalse` property on Bool. There is precedent with `reversed()` and `reverse()` methods already available in Swift.

Of course, everyone can write their own .toggled property. That would only negate the purpose of having a standard library.

---

<div class="post-metadata">

**Author:** ![GreatApe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/greatape/32/2640_2.png) [@GreatApe](https://forums.swift.org/u/GreatApe)\
**Post date:** [August 25, 2021, 12:38pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/13 "2021-08-25T12:38:12Z")

</div>

And I'm suggesting an operator on KeyPaths. I'm just saying it might need to be powered by a (private) .isFalse property if you want to make something like that yourself.

---

<div class="post-metadata">

**Author:** ![ensan-hcl](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ensan-hcl/32/15186_2.png) [@ensan-hcl](https://forums.swift.org/u/ensan-hcl)\
**Post date:** [August 25, 2021, 12:51pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/14 "2021-08-25T12:51:07Z")

</div>

> [@Ilias\_Karim](#):
>
> ```swift
> print(true.toggled) // or (true.toggled()
> 
> ```

But `.toggled()` cannot be used with key paths, since key paths don't support functions. I think adding `toggled()` doesn't solve the problem you mentioned.

---

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [August 25, 2021, 1:10pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/15 "2021-08-25T13:10:03Z")

</div>

+1. "toggled" matching "toggle()" is what i like. but as i said in another thread that ship has sailed, so just define it in your own codebase and treat it as if it was part of the standard library.

i remember there was a litmus test for proposals' inclusion along the lines that "if we designed swift today would we do it or not". would we use the same symbol "!" for boolean negation and optional unwrapping? i'd say not. do we still follow this litmus test guidline and does it mean we need to deprecate ! for boolean negation? i'm afraid not and no; it's so deep in swift's DNA.

---

<div class="post-metadata">

**Author:** ![Avi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/avi/32/2962_2.png) [@Avi](https://forums.swift.org/u/Avi)\
**Post date:** [August 25, 2021, 1:55pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/16 "2021-08-25T13:55:13Z")

</div>

It seems to me that the property name `toggled` has no semantic meaning. To toggle something is to change the state from current to new. To turn off a switch that's on. To change a boolean from false to true. Without knowing the current state, asking if it's toggled is a meaningless question. By definition, it's not toggled, because toggling requires a change in state and querying the current state is not changing it.

As to the general idea, I see a value in having `isFalse`. Operators are not always convenient to use.

---

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [August 25, 2021, 2:15pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/17 "2021-08-25T14:15:04Z")

</div>

> [@](#):
>
> It seems to me that the property name `toggled` has no semantic meaning. To toggle something is to change the state from current to new. To turn off a switch that's on. To change a boolean from false to true. Without knowing the current state, asking if it's toggled is a meaningless question. By definition, it's not toggled, because toggling requires a change in state and querying the current state is not changing it.

it's fine to me - like getting an "amended bill" in mail or like "returning a clone of a switch with the value toggled compared to the original". i do this all over the place (e.g. in my extensions to CoreGraphics i have "translate()/translated()/translation()", "invert()/inverted", and so on).

> [@](#):
>
> As to the general idea, I see a value in having `isFalse` . Operators are not always convenient to use.

"isFalse" looks strange to me but better than nothing. i also wouldn't mind "not" or another name.

---

<div class="post-metadata">

**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\
**Post date:** [August 25, 2021, 4:20pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/18 "2021-08-25T16:20:21Z")

</div>

I would suggest that the continued growth of `KeyPath` APIs over the last 5 years indicates a direction the rest of the language might want to enable. Whether it justifies this API I don't know, but there is at least one new consideration since `toggle()` was added.

---

<div class="post-metadata">

**Author:** ![Ilias\_Karim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ilias_karim/32/2339_2.png) [@Ilias\_Karim](https://forums.swift.org/u/Ilias_Karim)\
**Post date:** [August 25, 2021, 4:33pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/19 "2021-08-25T16:33:25Z")

</div>

I certainly agree with your rationale against a piecemeal approach to what you call "alternative spellings" for existing APIs.

However, the discussion I propose it not to replace "!" with "not" and "&&" with "and" as was the discussion of the previously discussion you refer to.

This discussion pertains to the use of existing operators in conjuction withe keypaths, in order to simplify functional programming statements such that curly braces and the boilerplate of anonymous parameter names, can be safely omitted. As I have mentioned, these will improve readability and writability.

1. anonymous closure arguments can be cumbersome to read to non-authors
2. in the context of if-let and guard-let statements, curly braces do not suffice and wrapping curly braces in parentheses may be error prone when writing--after all, they can be quite difficult to discussion between even when using a reasonable editor text size.

If you have alternatives to propose that may not only apply to negating boolean properties, all interested parties here will be very interested to hear them. If not, at the very least, `isFalse` or `toggled` may prove a jumping off point for further such discussions.

Thank you @xwu for your interest in the topic at discussion.

---

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [August 25, 2021, 6:36pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/20 "2021-08-25T18:36:11Z")

</div>

I struggled with finding a way to express wanting a logical inversion of a filter based on a `KeyPath` to a `Bool` when I recently learned how `KeyPath`s work and gave up on using a `KeyPath` in that case, so I can empathize with the motivation here. However, perhaps the right thing is to find a way to express an inversion of a `KeyPath` to a `Bool` instead of unnecessarily expanding `Bool`'s API.

---

<div class="post-metadata">

**Author:** ![Ilias\_Karim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ilias_karim/32/2339_2.png) [@Ilias\_Karim](https://forums.swift.org/u/Ilias_Karim)\
**Post date:** [August 25, 2021, 7:02pm UTC](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464/21 "2021-08-25T19:02:00Z")

</div>

> However, perhaps the right thing is to find a way to express an inversion of a `KeyPath` to a `Bool` instead of unnecessarily expanding `Bool` 's API.

I agree with your sentiment, however, such a solution escapes me. It looks like the key path code only deals with downcats.  
swift/KeyPath.swift at main · apple/swift ([github.com](http://github.com))]([https://github.com/apple/swift/blob/main/stdlib/public/core/KeyPath.swift](https://github.com/apple/swift/blob/main/stdlib/public/core/KeyPath.swift)))

So, something like this may not work,

```swift
extension KeyPath where Value == Bool {
  var not: KeyPath<Root, Bool> {
    return <#...#>
  }
}

```

[Next page](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464.md?page=2)