search

clap-rs / clap

A full featured, fast Command Line Argument Parser for Rust
docs.rs/clap
Apache License 2.0
13.65k stars 1.02k forks source link

Check for group of repeated arguments #5488

Closed Velnbur closed 3 weeks ago

Velnbur commented 1 month ago

Please complete the following tasks

Clap Version

4.3.23

Describe your use case

Currently trying to implement a CLI that accepts different repeated arguments. The problem is that we need to add checks that the lengths of a subset of repeated parameters should be the same.

  1. So for example CLI sends different messages to different recipients:
# is okay
cli send --recipient ALICE --content "hi!" --recipient BOB --content "goodbye"
# results in error as no second recipient is presented
cli send --recipient ALICE --content "hi!" --content "goodbye"
  1. But recipients.len() < contents.len() is okay:
cli send --recipient ALICE --recipient BOB --content "hi!"

Just the same content will be sent to different recipients. So contents became vec!["hi!"; recipients.len()] in this case.

Describe the solution you'd like

Developing additional functionality to ArgGroup could fix that, but I have no context about its current implementation.

Alternatives, if applicable

I believe that #1704 will fix the first case of the requested feature. Which, with some additional tweaks, can fulfill my needs with second case too

Additional Context

No response

epage commented 3 weeks ago

To confirm, the way --recipient and --content are interleaved doesn't matter, only their lengths?

So you can do

$ cli send --recipient ALICE --content "hi!" --recipient BOB --content "goodbye"
$ cli send --recipient ALICE --recipient BOB --content "hi!" --content "goodbye"

and the meaning would be the same?

For myself, I feel like that would be confusing and don't see us adding native support for something thing like this without a stronger case for why this isn't confusing and is more broadly applicable, particularly in light of our work to keep the API, build times, and binary size small.

I think it would be better to focus our efforts on #1704 and #3476. As such, I'm closing this. If there is a reason for us to re-evaluate the status of this, let us know!