Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow an argument to be both a positional and an option #4426

Closed
2 tasks done
figsoda opened this issue Oct 27, 2022 · 1 comment
Closed
2 tasks done

Allow an argument to be both a positional and an option #4426

figsoda opened this issue Oct 27, 2022 · 1 comment
Labels
A-builder Area: Builder API C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this

Comments

@figsoda
Copy link

figsoda commented Oct 27, 2022

Please complete the following tasks

Clap Version

4.0.18

Describe your use case

As far as I'm aware, short and long overrides the implicit positionalness and there is no way to have both on

Describe the solution you'd like

for example, if I want to have prog a b c, prog -f a b c, and prog --foo a b c to be equivalent

#[derive(Parser)]
struct Opts {
    #[arg(short, long, position, num_args = ..)]
    foo: Option<Vec<String>>,
}

Alternatives, if applicable

Using replace from unstable-replace, but I have to deal with the quirks of replace and also use an unstable feature

#[derive(Parser)]
#[command(replace("-f", [""; 0]), replace("-foo", [""; 0]))] // not sure how to create explicitly typed slices so I had to create this abomination
struct Opts {
    #[arg(short, long, num_args = ..)]
    foo: Option<Vec<String>>,
}

Or having 2 separated fields and combine them manually, which seems overly complicated

#[derive(Parser)]
struct Opts {
    #[arg(short, long, num_args = ..)]
    foo: Option<Vec<String>>,
    foo2: Option<Vec<String>>,
}

Additional Context

No response

@figsoda figsoda added the C-enhancement Category: Raise on the bar on expectations label Oct 27, 2022
@epage epage added A-builder Area: Builder API S-wont-fix Status: Closed as there is no plan to fix this labels Oct 27, 2022
@epage
Copy link
Member

epage commented Oct 27, 2022

I feel like trying to support both without a very strong motivation will add complexity to clap for a case that should be pretty rare in CLIs. I also feel that this isn't a pattern we should be encouraging by making things easier.

Users have the building blocks they need to implement this themselves by putting the two arguments into a group which will be made easier with #2621.

Without more, I'm going ahead and closing this as unplanned.

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Oct 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-builder Area: Builder API C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this
Projects
None yet
Development

No branches or pull requests

2 participants