Support flattening Vec<Struct>

[lu-zero]

Sometimes you would like to have a cli in which arguments are grouped so you expect to have all/some of them set multiple times:

--option-applying to_input ... -i my_first_input --option-applying to_input ... -i my_second_input --other_options applying to outpus -o output

would be nice to have something like

#[derive(Args)]
struct GroupedOpts {
  #[clap(short, long)]
  aopt: usize,
  #[clap(short, long)]
  bopt: usize,
  #[clap(short, long)]
  copt: usize,
}

#[derive(Parser)]
struct Opt {
   #[clap(flatten)]
   group: Vec<GroupedOpts>,
}

possibly extended to support setting defaults

#[derive(Args)]
struct GroupedOpts {
  #[clap(short, long, default_value = "42")]
  aopt: usize,
  #[clap(short, long)]
  bopt: Option<usize>,
  #[clap(short, long, group_reset = true)]
  copt: usize,
}

#[derive(Parser)]
struct Opt {
   #[clap(flatten)]
   group: Vec<GroupedOpts>,
}

so that

-a 1 -b 2 -c 0 -c 1 -b 0 -c 2

produces

Opt {
  group: [
    GroupedOpts { aopt: 1, bopt: Some(2), copt: 0 } ,
    GroupedOpts { aopt: 42, bopt: None, copt: 1 } ,
    GroupedOpts { aopt: 42, bopt: Some(0), copt: 2 }
  ]
}

[epage]

Could you expand on the semantics? I'm guessing you are defining group_reset to mean that after that option, a new group starts. Is that correct? Would it error if you have two -as in a row?

At first glance, this feels too specialized to have in clap. Someone might want a group_reset, someone else might want a group_start, and its unclear what all other options people would want.

Not everything has to live in clap though. You can implement the traits yourself. Something like

#[derive(Parser)]
struct Opt {
    ...
    #[clap(flatten)]
    groups: OptGroups,
}

struct OptGroups {
    groups: Vec<OptGroup>,
}

struct OptGroup {
  aopt: usize,
  bopt: Option<usize>,
  copt: usize,
}

impl clap::Args for OptGroups {
    ...
}

impl clap::FromArgMatches for OptGroups {
    ...
}

You can take advantage of ArgMatches::indices_of to organize into the sequence of groups however you want.

[lu-zero]

Could you expand on the semantics? I'm guessing you are defining group_reset to mean that after that option, a new group starts. Is that correct? Would it error if you have two -as in a row?

Yes, it should error. It would be an extension of the current ArgGroup validation.

At first glance, this feels too specialized to have in clap. Someone might want a group_reset, someone else might want a group_start, and its unclear what all other options people would want.

This usage pattern exists in the wild in ffmpeg. I'm not sure if something is using the group_start logic in the wild though.

Not everything has to live in clap though. You can implement the traits yourself. Something like

#[derive(Parser)]
struct Opt {
    ...
    #[clap(flatten)]
    groups: OptGroups,
}

struct OptGroups {
    groups: Vec<OptGroup>,
}

struct OptGroup {
  aopt: usize,
  bopt: Option<usize>,
  copt: usize,
}

impl clap::Args for OptGroups {
    ...
}

impl clap::FromArgMatches for OptGroups {
    ...
}

You can take advantage of ArgMatches::indices_of to organize into the sequence of groups however you want.

I'm expecting to have a value_at_index or the clap-split list of arguments to use the index information with but I cannot find it, am I'm missing something glaringly obvious?

[epage]

This usage pattern exists in the wild in ffmpeg. I'm not sure if something is using the group_start logic in the wild though.

I understand. There are many different usages in the wild and we have to prioritize which are worth making easy vs just making possible.

I'm expecting to have a value_at_index or the clap-split list of arguments to use the index information with but I cannot find it, am I'm missing something glaringly obvious?

Clap is currently not organized around indices but arguments. You can build that up yourself via indices_of.

[realuser]

Also was looking for this. ffmpeg says:

https://manpages.ubuntu.com/manpages/focal/man1/ffmpeg.1.html

As a general rule, options are applied to the next specified file. Therefore, order is important, and you can have the same option on the command line multiple times. Each occurrence is then applied to the next input or output file. Exceptions from this rule are the global options (e.g. verbosity level), which should be specified first.

My case is I want to process a list of files with optional arguments that can have independent values associated with each file, while at the same time having a few global optional arguments