Idea: invert() or toggle() function for boolean type?

[Soni]

I’ve wanted this a few times, but ended up using Option<()> and take(), so maybe fn clear(&mut self) -> bool and fn set(&mut self) -> bool would be more useful?

[ExpHP]

I know that I can make my own function ,

I’m not sure if this is your intent, but your use of emphasis here comes across as extremely hostile! I know that you know this. I read the post from top to bottom and back. I was responding to these specific words: (emphasis mine)

While I can create a function like that myself, it’s a bit annoying not to have it in the standard library or implemented directly on the bool type, so I wanted to ask if it would be a good idea to implement this.

to point out that method syntax can be recovered.

---

NLL won’t help with the braces,

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b6fc456e5c45ef9074a5093dad50595b

NLL allows overlapping mutable borrows to coexist as long as old ones are never reused.

---

Which is why I was asking if anyone has objections to putting it in the standard library.

For me, the default answer to “should it be in the standard library” on anything I haven’t previously thought about is always “no.” That is why my first reply focused on specific details in your post to see if any of them changes the landscape of the problem enough for another solution to be workable. And were this not the case, my next response probably would have been something along the lines of:

Well, I suppose there aren’t an awful lot of other things that one might need to do with a bool, so adding a method for this seems harmless. (Modulo the color of the bike shed.)

[earthengine]

You can also do

some_bool ^= true;

although perhaps it’s less readable.

or you can use the explicit form

some_bool.bitxor_assign(true);

[Centril]

or you can use the explicit form

some_bool.bitxor_assign(true);

That seems less readable than

some_bool.toggle();

the intent signaled is quite different. With the former I have to stop and think “ah, this is just flipping the truthiness” and with the latter there’s no thinking.

[tspiteri]

For all integer primitives and for bool, currently bitand, bitor and bitxor have counterparts bitand_assign, bitor_assign and bitxor_assign but not does not have a counterpart. This is probably because there are &=, |= and ^= operators but no operator for bitwise inversion of self.

An invert or toggle function would be a counterpart to not, though there is no operator. I think invert is better than toggle as it can be applied to integers as well as bool, where it can be useful too though not as much as for bool.

[tspiteri]

*x != *x;

I think you mean *x = !*x;

*data != *data;

And *data = !*data;

[scottmcm]

With the former I have to stop and think “ah, this is just flipping the truthiness” and with the latter there’s no thinking.

I find ^= true more readable than .toggle(), personally. I’ve been using that for years in multiple different languages, and don’t see the need to invent a name for it that ends up being longer anyway. (Particularly since there’s no usable chaining that can be involved here.)

[Centril]

That’s fair; I don’t do much bitwise operations so when I see ^= true I still have to wait and think about the true here. I suspect that you do these kind of operations more than me so you are more used to it?

[nikomatsakis]

it seems worthwhile as a standard library addition for the improved readability

I’m not sure about toggling exactly but there are a few similar “convenience methods” I’ve wanted in the past (and some random names):

• reset – equivalent to mem::replace(path, false). I often want to do something like while dirty.reset() {... dirty = true; ...}
• increment – equivalent to fetch_add(1, Ordering::SeqCst) but for ordinary integers, not atomic ones

Similar to the poster here, I’ve never quite felt sufficiently motivated to make a helper library for these.

[nikomatsakis]

For that matter, I would like to have a method not that is equivalent to !x, just because prefix operators are annoying. =)

[Centril]

For that matter, I would like to have a method not that is equivalent to !x , just because prefix operators are annoying. =)

https://doc.rust-lang.org/nightly/std/ops/trait.Not.html#tymethod.not

Long live the post-fix operators!

[drXor]

multiple different languages,

What other languages given you ^ as a first-class thing for bools? I’ve never seen this before (beyond using != for bools as a hacky version thereof).

[CAD97]

Almost every language I know (that I picked out on TIO in a quick pass through) offered boolean xor via ^:

• C (stdbool.h): Try it online!
• C#: Try it online!
• C++: Try it online!
• Haskell: omitted because I don’t know it well enough to bang out a TIO example
• Java: Try it online!
• JavaScript (cooerce to number): Try it online!
• Kotlin: no, Try it online!
• Python: Try it online!
• Rust: Try it online!
• Swift: no, Try it online!

[drXor]

My entire life has been a lie.

[mbrubeck]

increment – equivalent to fetch_add(1, Ordering::SeqCst) but for ordinary integers, not atomic ones

x.add_assign(1) (or x += 1) seem like reasonable approximations in this case.

If we had an increment method then people would want a ++ operator to go with it.

[Centril]

Haskell: omitted because I don’t know it well enough to bang out a TIO example

Haskell does the sane (imo – =P) thing of defining (^) :: (Num a, Integral b) => a -> b -> a as the power function. (this further demonstrates that ^= is not so readable… is it raising the LHS by a power or bitwise…?)

[tspiteri]

increment – equivalent to fetch_add(1, Ordering::SeqCst) but for ordinary integers, not atomic ones

x.add_assign(1) (or x += 1 ) seem like reasonable approximations in this case.

But x.fetch_add(1, ...) returns the value before adding 1, like C’s post-increment x++.

[drXor]

…and post-increment is often forbidden in C++ style guides because of its confusing nature and bizarre copying semantics.

I really don’t want ++ in Rust.

[Soni]

what about <-x++ (for post-increment) and x++-> (for pre-increment)? i.e. the arrow indicates when the output happens. and x++ itself is an ().

[drXor]

<-x++;
x += 1;

You win one character, and lose infinity readability. Symbolic inc/dec operators carry a lot of bad historical baggage for epsilon benefit.