numbers as varying radix values, 15 0xF 0o17 1111

[epage]

Discussed in #4563

^{Originally posted by jtmoon79 December 19, 2022}
tl;dr a nice feature for numbers would allow reading passed argument as differing radix among the traditional hexadecimal, decimal, octal, and binary.

I have implemented this here. It's a good bit of work. Would be nice if clap handled this for me. I'm imagining an option like allow_radix_all

    #[clap(
        required = false,
        long,
        default_value_t = 0xFFFF,
        allow_radix_all,
    )]
    number: u64,

And perhaps, further fine-grained options would also be allowed: allow_radix_hexadecimal, allow_radix_octal, allow_radix_binary. So allow_radix_all would just enable all the prior.
And might even want to throw in disallow_radix_decimal for some users that really want such.

Parsing could require a prepended 0 before the radix symbol, e.g. 0xF, 0d15, 0o17, 0b1111 and reject without, e.g. xF, d15, o17, b1111. or could be flexible and accept both. I'm not sure what is best there.

[epage]

There are a couple routes we can go with this

• Create wrapper types for a specific use case and have the derive/builder automatically pick it up, like in Implement convenient helper methods for PathBufValueParser to reduce boilerplate #4074
• Support this on the existing numeric value parsers

I somewhat lean towards supporting 0x, 0o, and 0b prefixes on integer value parsers without any configuration but am still undecided. One concern with this is the slipper slope for digit separators, "human sizes", etc which I wouldn't want to bake all of that in.