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

Conflicting options #11

Open
tertsdiepraam opened this issue Dec 20, 2022 · 3 comments
Open

Conflicting options #11

tertsdiepraam opened this issue Dec 20, 2022 · 3 comments

Comments

@tertsdiepraam
Copy link
Member

tertsdiepraam commented Dec 20, 2022

It doesn't occur often in coreutils, but sometimes options conflict. They might even conflict with themselves. This is tricky to support while also maintaining good error messages.

One design could be to define conflict groups (leaving out some boilerplate in the example):

enum Arg {
    #[arg("--foo", conflict_group="foobar")]
    Foo,
    #[arg("--bar", conflict_group="foobar")]
    Bar,
}

"foobar" is a key into some hashset of options that have been set.

An example of conflicting options are cut's --fields, --bytes and --characters.

@tertsdiepraam
Copy link
Member Author

Interestingly, those options in cut are also required.

@tertsdiepraam
Copy link
Member Author

There's another possible design:

#[arguments(
    conflicts = [
        (Foo, Bar)
    ]
)]
enum Arg {
    #[arg("--foo", conflict_group="foobar")]
    Foo,
    #[arg("--bar", conflict_group="foobar")]
    Bar,
}

@tertsdiepraam
Copy link
Member Author

tertsdiepraam commented Dec 19, 2023

But there are some difficulties:

  • Should arguments conflict with themselves?
  • How do we customize the errors? (GNU checks most manually probably so they have different errors for each util)
  • How do we do conflict groups and more pairwise conflicts nicely?

I wonder if there's some convenience function we can make for the Settings struct that makes this easier?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant