Revisit use of BoolEnum

[jlapeyre]

We use BoolEnum here

openqasm3_parser/crates/semantics/src/types.rs

Lines 22 to 28 in 3f74976

	use boolenum::BoolEnum;
	#[derive(BoolEnum, Clone, Debug, PartialEq, Eq, Hash)]
	pub enum IsConst {
	True,
	False,
	}

We do this so we see things like Duration(IsConst) rather than Duration(bool).

@jakelishman suggested doing

enum Type {
  Bit { is_const: bool },
  ...
}

At the moment, the reason for choosing BoolEnum. But it's worth revisiting. If there is no advantage in using the external crate, better to get rid of the dependency.

[jakelishman]

The other concern is that when consuming these by enum variant destructuring, you don't see the type name, only the variable you pattern-match it with, which can be anything. Then using the variable is inconvenient, because you have to call .into() to get a bool, so you end up with code like

match expr.type() {
  Type::Bool(can_be_anything) => {
    if can_be_anything.into() {
      ...
    }
    ...
  }
}

(actually at the moment IsConst doesn't derive Copy, so can't automatically deref and needs to be (*can_be_anything).into(), but that's easy to change) whereas struct variants would require construction and destructuring to be

let t = Type::Bool { is_const: true };
match t {
    Type::Bool { is_const } => (),
}

where the name is required to match (or you have to do is_const: can_be_anything).

[jakelishman]

I think the BoolEnum is maybe intended more for use when the magic booleans are function arguments rather than enum variant components - I can certainly see more call-site benefits there.