Command line args to set int values can’t easily be used in a bool context. In fact, they will silently do the wrong thing.
For example, setting -checkaddrman will silently disable the checks, instead of enabling them.
Obviously reading the documentation would avoid those mishaps, but it still feels wrong to silently do the opposite thing the user asked for.
Same for: -mempoolexpiry, -par, and pretty much any other int setting that can be mistaken as a bool setting.
Few thoughts:
I think it’s good to only change the way options are interpreted in targeted PRs like #23061, and in general be as careful as possible changing what any existing option does.
Changes in how options are interpreted should be well documented:
-X previously did Y, starting from this release the new behavior is Z.”V. Previously X did Y instead of Z.” The information about previous versions could be removed after those versions are no longer supported.If any options can have a big impact on security or privacy or performance, it would be better to avoid changing their behavior at all, and instead just add new options to replace them. This could be done with errors “Option -X has been removed. Please use option -Y instead” or warnings “Option -X is deprecated, please use option -Y instead”
In #16545, with the ALLOW_INT flag, this problem would not happen. The ambiguous syntax would trigger “Can not set -xxx with no value. It must be set to an integer” errors