Style Guide Enum Bool Thoughts #21684

In many places we use bool parameters to denote some effect.

I suggest that throughout the codebase, we make an effort to (where feasible/touched) replace these with enum class.

It's a bit more verbose, but it's already a norm to do f(/* confusing bool */ true), and it would be nice if our compiler helped us out.

Further, it makes it easier should later code extend the functionality to add more/different options.

In order to reduce clutter we could make a macro BoolEnum(Argument, EnabledName, DisabledName)

Not high importance, so I don't think we should make a project out of it, but I was looking at some code recently where it would have been nice.

Con: we don't need more structs.

Concept ACK: verbose but clear is preferable over terse but unclear

I think high value targets for this are places where we pass multiple bool params in to a function, or make use of default args.

Concept ACK. We need clarity. I mean, this is Bitcoin.

Another concept is using this paradigm for return bools, which I think could be even better (since return value is otherwise unnamed, at least function parameter names are self documented).

Also using the paradigm:

switch(ret) {
case ReturnType::Yes:
case ReturnType::No:
}
assert(0);

would mean that we can:

• automatically warn about expanded return values (not so with if/else)
• avoid cases where modify code to return something that has a bool-ness that shouldn't be read

E.g., imagine making a function go from returning a bool to a Script and having a bool operator on the Script with a different semantic. This can happen inadvertently and the compiler won't catch it. Worst is going from a bool to an integer where -1, 0, >0 has meaning.

I don't think getting too paranoid about this matters much, but just demonstrates that there are some other niceties in refactoring.

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Specific pull requests with improvements are always welcome.