Tracking Issue for `bool::toggle`

[CenTdemeern1]

View all comments

Feature gate: #![feature(bool_toggle)]

This is a tracking issue for bool::toggle, a method that toggles a mutable bool in-place.

Public API

impl bool {
    pub const fn toggle(&mut self);
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: Method to invert/toggle a boolean libs-team#820
• Implementation: Implement bool::toggle #159296
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Should this method be called flip instead? (Method to invert/toggle a boolean libs-team#820 (comment))

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[CenTdemeern1]

I suppose I should probably bring this up now; the question of whether it should be renamed to flip instead, as was brought up during a recent rust-libs meeting. Personally, I’d want to call it toggle, as this matches the precedent set by Swift, which was my personal main inspiration for wanting this method on bool. I can see why flip would also be fitting, but it doesn’t have a similar precedent from what I can find.
Would this be worth a doc alias?

[CenTdemeern1]

Would it be worth it to have a similar method on AtomicBool, equivalent to boolean.fetch_xor(true, ordering);?

[clarfonthey]

I think it would be reasonable to add fetch_toggle(ordering) but it should be consistent with whatever the final name is for this.

[asquared31415]

I wonder if the version on bool should be fn toggle(&mut self) -> bool where it returns the old value too?

[clarfonthey]

The main issue is that it's genuinely unclear whether you would refer to the old or new value for a simple boolean method. For an atomic, this is clearer, because the way atomics work is fairly standard and always return the old value.

[CenTdemeern1]

Clar mentioned on Zulip that the AtomicBool stuff could probably be proposed separately so I'll probably do that. And it also sounds like the naming question doesn't really matter that much from what they said, so unless anyone has anything else to say about that return type, I'll probably try to move forward with stabilization then? Sorry if all of this has been confusing, this is my first time doing this

[clarfonthey]

(Can't ever be a second time if you don't have a first time, and it's great to see someone interested in helping out.)

[CenTdemeern1]

The main issue is that it's genuinely unclear whether you would refer to the old or new value for a simple boolean method. For an atomic, this is clearer, because the way atomics work is fairly standard and always return the old value.

I just had a thought; if it returned &mut bool (or &bool) as opposed to a copy, it would be clear that it's returning the new state. But then again I'm not entirely sure how useful getting a reference to the bool would be.