Even now, I still find myself using true/false/null on occasions, but I'm usually smart enough to replace it with an enum at that point. The only time I don't is when it's an optional parameter to a function to override some default/existing value, at which point it then makes sense to keep it as an optional bool.
For some vector logic the distinction could matter.
For more common situations where the yes/no bool is not available yet or should not be considered, constructs like Rust’s Option<bool> are a very good fit. Layering the bool inside of an Option creates intentional handling about the presence or lack of value first before you can work with it.
> MsoTrioState is "a tri-state Boolean value". it has five possible values. only two of them are supported.
*) https://learn.microsoft.com/en-au/dotnet/api/microsoft.offic...
Sourced from here https://fedi.lynnesbian.space/@lynnesbian/115969259564305759
So let's remember: some programmer, somewhere, is right now thinking about building a tri-state boolean because they think it fits their current problem perfectly fine. And they are always wrong.
How you get 5 possible values into a tri state Boolean is beyond me though.
I think my favourite part is the fact that '1' isn't even one of the supported values.
It is a specific optimization based on the idea of storing one type inside of another type by finding a "niche" of unused bit pattern(s) inside the second type.
It has far more useful application than a tower of Option 254 deep.
Option<NonZeroU32> seems like a much more reasonable to justify this with. Also, enums can easily have invalid bit patterns that are unused without there being any specific bit that is always available. All you need is a single variant of the enum to have a free bit, and you have a niche to shove None into.
public static void main (String[] args) {
Optional<Boolean> n = Optional.ofNullable(null);
Optional<Boolean> e = Optional.empty();
System.out.println(n.equals(e));
}
true
A null in an Optional is empty. So you've got:
Optional<Boolean> n = null;
Optional<Boolean> e = Optional.empty();
Optional<Boolean> t = Optional.of(Boolean.TRUE);
Optional<Boolean> f = Optional.of(Boolean.FALSE);Ah how many of those options fit into that boolean. Word games!
You can make them smaller using bitfields in C.
sizeof(struct {bool a:1;}) == sizeof(char);If one Boolean must be a byte then 8 must be eight bytes. Which is not true. A boolean can be 1/8th of a byte which is a meaningful distinction.