clap_derive: support tuples as shortcut for number_of_values = N, different validators

[CreepySkeleton]

Transferred from: TeXitoi/structopt#349

Sometimes we want to to take a fixed number of values that should always be passed together or not at all. For instance, let's take RGBA: four numbers, first three must be 0 <= N <= 255, the last must be 0 <= N <= 1.0. This can be naturally expressed via tuples:

fn validate_alpha(a: String) -> Result<f32, String> {
    let a = a.parse()?;
    if a > 1 {
        Err(format!("alpha cannot be > 0.1"))
    } else {
        Ok(a)
    }
}

#[derive(Clap)]
struct Args {
    #[clap(
        long,
        // `parse` can be extended to take multiple validators
        // `_` means default `try_from_str = FromStr::from_str`
        parse(_, _, _, try_from_str = validate_alpha)
    )]
    color: (u8, u8, u8, f32), // `number_of_values = 4`, different parsers 
    
    pair: Option<(String, Path)> // they can also be optional 
}

[CreepySkeleton]

Moving it to 3.0 milestone since this would be a breaking change theoretically.

[pksunkara]

Some relevant code from a discussion about key value pairs in here:

    // number_of_values = 1 forces the user to repeat the -D option for each key-value pair:
    // my_program -D a=1 -D b=2
    // Without number_of_values = 1 you can do:
    // my_program -D a=1 b=2
    // but this makes adding an argument after the values impossible:
    // my_program -D a=1 -D b=2 my_input_file
    // becomes invalid.
    #[clap(short = 'D', parse(try_from_str = parse_key_val), multiple_occurrences(true), number_of_values = 1)]
    defines: Vec<(String, i32)>,

[linclelinkpart5]

Chiming in to say I'd love to have this feature. I'm in need of being able to support options of the form:
--source /path/to/dir 7 --source /other/path/to/dir 5. Each of the --source options has a (Path, u8) pair of arguments.

[epage]

The main challenge we'll have with tuple support is the value_parser system assumes that every value is of the same type. So we can easily get #1682 but tuple support is more challenging.

We'll need someone to come up with a proposal for how the value parser system can have disparate types before we are able to get this to move forward.

[ghost]

any news on this? its been 4 years

[epage]

If there isn't word on this issue, then no. The last comment I gave has the main design challenge for this. #1682 would be easier as it bypasses that design challenge but that there is also the issue with dealing with breaking changes. #4626 is exploring that.