-
Notifications
You must be signed in to change notification settings - Fork 3
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
Positional arguments redo #70
Comments
I'll post several comments exploring some designs. The simplest alternative is to change the implementation a bit by removing the ranges and instead encoding the number of arguments in the specification: #[derive(Arguments)]
enum Arg {
#[arg("VAL")] // 1
Foo,
#[arg("[VAL]")] // 0 or 1
Bar,
#[arg("VAL...")] // 1 or more
Baz,
#[arg("[VAL]...")] // 0 or more
Qux,
} This brings it more in line with the option arguments in how it is defined. However this only really solves the third problem. |
A second option is to take the positional arguments out of the enum and pass them as #[derive(Arguments)]
#[arguments(positional = "VAL1 [VAL2]...")]
enum Arg {}
struct Settings {
a: PathBuf,
b: Vec<PathBuf>,
}
impl Options<Arg> for Settings {
fn apply(&mut self, arg: Arg) {
...
}
fn apply_positional(&mut sef, args: Vec<PathBuf>) {
...
}
} This "solves" all the problems, but is also verbose. It also makes error handling for positional arguments more difficult. |
A third option is to not try to really integrate the positional arguments at all: #[derive(Arguments)]
enum Arg { ... }
#[derive(Default)]
struct Settings { ... }
impl Options<Arg> for Settings { ... }
fn main() {
// `operands` is a `Vec<OsString>` with the positional arguments:
let (settings, operands) = Settings::default().parse();
} Instead of just having a |
I'm not happy with positional arguments at the moment. They do not fit nicely with the rest of the library and have a weird API. We need to reassess how they should work.
The problems are:
cp
requires).The text was updated successfully, but these errors were encountered: