What's the best practice for parsing BitFlags?

[kxxt]

Hi,

I have a bitflags enum using https://docs.rs/enumflags2/latest/enumflags2/ .

I would like to know the best practice of parsing bitflags from clap.

Let's say I have the following enum:

#[bitflags]
#[repr(u8)]
#[derive(Copy, Clone, Debug, PartialEq, ValueEnum)]
enum Test {
    A = 0b0001,
    B = 0b0010,
    C, // unspecified variants pick unused bits automatically
    D = 0b1000,
}

And a command line option --test that takes combinations of the bitflags e.g. --test A,B,C:

  #[clap(
    long,
    value_delimiter = ',',
    num_args = 1..,
    help = "help.",
  )]
  pub test: BitFlags<Test>,

I only want unique values so num_args = 1.. doesn't work correctly here.

I also tried to use custom value_parser function in combination with num_args. But it appears that value_parse only parses one value at a time which means it can't throw an error when a non-unique value appears. And I can't really OR the bitflags together.

I think such use cases should be fairly common in CLI applications so I would like to know the current best practice.

And a stateful value_parser function would be really nice to have, like:

fn parse_value(state: &mut BitFlags<Test>, next_value: &str) -> Result<(), String>;
// or
fn parse_value(state: BitFlags<Test>, next_value: &str) -> Result<BitFlags<Test>, String>;

[kxxt]

For now, I am parsing it this way, which parses the str as a single value.

#[clap(
  long,
  help = "Set the default filter for events.",
  value_parser = tracer_event_filter_parser,
)]
pub filter: BitFlags<TracerEventKind>,

fn tracer_event_filter_parser(filter: &str) -> Result<BitFlags<TracerEventKind>, String> {
  let mut result = BitFlags::empty();
  for f in filter.split(',') {
    let kind = TracerEventKind::from_str(f, false)?;
    if result.contains(kind) {
      return Err(format!(
        "Event kind '{}' is already included in the filter",
        kind
      ));
    }
    result |= kind;
  }
  Ok(result)
}

[epage]

This is what I was going to suggest.

I think such use cases should be fairly common in CLI applications so I would like to know the current best practice.

It looks like this hasn't come up before and I can't think of another parser that has built in support for it. We have #3114 for supporting more containers than Vec and one issue with supporting HashMap is knowing what to do on duplicates (drop or error). We might be able to view this as a custom collection and consider it as part of the design of that issue.