Turn the Visibility struct into an enum

[ickk]

Objective

The current implementation of the Visibility struct simply wraps a boolean.. which seems like an odd pattern when rust has such nice enums that allow for more expression using pattern-matching.

Solution

Make Visibility into an enum.

---

Changelog

Changed

Visibility is now an enum

Migration Guide

• Code that checks the visibility.is_visible field should now call it as a method visibility.is_inherited(), use ==, or refactor to use a match.
• Code that used to set or unset the visibility.is_visible field should now directly set the value: *visibility = Visibility::Inherited, or use the .toggle() or .set(bool) methods.
• Any usages of the associated constants Visibility::VISIBLE or Visibility::INVISIBLE should now use the enum variants, Visibility::Inherited or Visibility::Hidden.
• ComputedVisibility::INVISIBLE and SpatialBundle::VISIBLE_IDENTITY have been renamed to ComputedVisibility::HIDDEN and SpatialBundle::INHERITED_IDENTITY respectively.

[ickk]

Since the variants are self descriptive, we could pub use them like std does with Option so that users can avoid the Visibility:: prefix.

[nicopap]

If we are open to a major breaking change, may I suggest a change that improves one of the issues I have with Visibility which is the stuttering. ie: *visibility = Visibility::Invisible (repeats "visible" three times)

What about:

enum Visibility {
  Show,
  Hide
}

Previous way of doing it was visibility.is_visible = false

Also I think here a togglemethod is much needed for an enum-based API, since otherwise it would make it super annoying to swap the value (a bad good idea would be to implement std::ops::Not) (maybe two methods: one that returns a new value and one that mutably updates)

Edit: Adding the Visibility variants to the prelude is just equal part "good" and "bad" for me to be OK with it.

[ickk]

Also I think here a toggle method is much needed for an enum-based API

see #6268 :)

Edit: decided to just include a .toggle() method in this PR since I agree that it is much needed

[mockersf]

I'm not sure I think the is_visible method is really useful here

[sullyj3]

I'm happy to close #6268 in favour of this if there's a consensus that an Enum is a nicer api

[sullyj3]

I agree that is_visible feels redundant:

if vis == Visibility::Show { // ... }
if vis.is_visible() { //... }

The method is slightly terser, which is nice. Unless the variant was exported directly from the prelude:

if vis == Show { //... }

It would also depend on the variant names, eg in

if vis == Visibility::Visible { // ... }
if vis.is_visible() { //... }

the method seems much nicer.

Option has .is_none(), and that seems to be the idiomatic way to do things, despite the fact that you could just check == None there also.
Hmm, I guess to use == with Option<T>, T must be PartialEq, so .is_some() improves ergonomics in the case where it's not? Could that have been the rationale? We don't have that problem here.

I think I'm in favour of the method if the variants aren't exported unqualified, just because it's fewer characters.

[ickk]

I am more than happy to add an implementation for Eq, but I think the is_visible method should stay to provide a more consistent API with ComputedVisibility.

[alice-i-cecile]

I'm in favor of using an enum here. Bikeshedding, I have a pretty strong preference for Visibility::Show and Visibility::Hide. Agree on adding toggle. is_visible can stay for consistency.

[mockersf]

Could you impl the https://doc.rust-lang.org/std/ops/trait.Not.html trait and use it?

[james7132]

Not sure I agree with this decision. While this improves simple assignments and serialized formats, this does make it notably harder to assign visibility state with even simple boolean expressions, instead requiring match/if expressions, which can be a lot less ergonomic.

[sullyj3]

this does make it notably harder to assign visibility state with even simple boolean expressions, instead requiring match/if expressions, which can be a lot less ergonomic.

What if there was a Visibility::from_bool()? Or I guess a From<bool> impl?

[ickk]

I agree could be more terse when modifying an existing instance using the result of a boolean expression.

I wrote out all the scenarios so I could evaluate using From/Into, and I did not really love it.

We could discuss adding something like a set_when method or something maybe?

visibility.set_when(a && b || !c);

[alice-i-cecile]

Why not just visibility.set(visibility.set_when(a && b || !c)); where the set method takes a bool?