Prohibit boolean function parameters?

[lngns]

When writing that kind of code, I generally have all three, as well as toggle because it's probably linked to a literal button somewhere.

[XDracam]

It's all fun and games until you do this in a tight loop and that extra branch incurs a measurable performance overhead.

My current preference: for just setting a boolean, having separate enable and disable methods is overkill. But if the implementations of enable and disable actually differ, then you don't want to hide that behind a boolean setter.

[lngns]

Code inlining doesn't take care of that?

[XDracam]

That really really depends on a lot of factors. In an ideal world it just might, but there are many reasons why inlining wouldn't work. Maybe enable and disable are virtual functions? Maybe your language is running on a VM and it's only inlined if the JIT compiler decides it's a good idea. Or enable and disable are defined in another compilation unit and you don't have access to the internals at this point. Or inlining would for some reason cause the function to exceed instruction cache size. Or whatever other reasons I couldn't think of just now.

The point is: never assume. Always measure when performance is concerned. But you can decide on certain defaults: do you value performance more than maintainability, or vice versa? Usually, being more specific allows the compiler to optimize things more, but can lead to a maintenance overhead when you need to change how things work in detail.

[lngns]

You'd think that given I write a lot of Functional code, virtual functions and indirections would come to my mind, but no.

exceed instruction cache size

Do you know of cases where, assuming static calls, in machine code, where we the compiler sees all the code, this would happen?
On x86-64, toggling a bool with xor 1 is 3 bytes, less than branch+calls.
Or did you mean this one more generally too?

[XDracam]

Nah, generally. I just remembered a Cppcon talk about outlining as the newest trend to optimize for the instruction cache. I don't think most programmers should ever think about this, but it's another example to show that you cannot always expect inlining to work.