Feedback

[cakebaker]

As promised some feedback. It's from a user's PoV, from looking at the tests.

Overall, impressive work!

Initial seems to me to be the wrong noun, it means "the first letter of a word or name" according to the dictionary.

Similarly, positional and free are not nouns and so don't fit to option. Plus I don't understand why it's named free as it specifies the parser function for the corresponding option.

With the defaults, why do you introduce #[initial(..)] instead of using std::default::Default?

I assume things like "option x conflicts with option y" are outside the scope of this library?

[tertsdiepraam]

Thanks!

Initial was meant to invoke the idea of "initial state". I made it basically to provide a nicer derive for Default. It can also do things like environment variables, which would be strange for a Default implementation. I generally expect default to be a pure function. However, if you want, I can remove it in favor of using Default. The advantage of that is that the library does become simpler. The disadvantage is that we'd get very verbose implementations for Default when we cannot derive it, just to set a few fields to another default value, because Default does not have something like the #[initial(..)] attribute on fields. Imagine for instance what this looks like without Initial:

https://github.com/tertsdiepraam/uutils-args/blob/87fc2f3d7c0ae87242400e1f89ab10e90fa91d6c/tests/coreutils/ls.rs#L325

positional and free are indeed not great names. Happy to take suggestions for both of these.

Positional is just a positional argument and I didn't want write that all out, but we could. It could also be arg? But that's confusing because I'm already using Arg as both options and positional arguments. bpaf also uses the name "operand"? gumdrop uses "free" for positional arguments.

The "free" that I have here is complicated, because it's essentially a new concept. It's free in the sense of being able to appear everywhere, as long as it fits the predicate. It could also be "custom" or "predicate" or "guarded"?

I have an issue for conflicting arguments: https://github.com/tertsdiepraam/uutils-args/issues/11 The priority is fairly low because you could implement it manually and it's not used much in the coreutils. A manual (but pretty low-effort and bad) implementation would look something like this:

enum Arg {
    #[option("--foo")
    Foo,
    #[option("--bar")
    Bar,
}

struct Settings {
    foobar: Foobar,
    foobar_set: usize,
}

impl Options<Arg> Settings {
    fn apply(&mut self, arg: Arg) {
        match arg {
            Arg::Foo => {
                self.foobar = Foobar::Foo;
                self.foobar_set += 1;
            }
            Arg::Bar => {
                self.foobar = Foobar::Bar;
                self.foobar_set += 1;
            }
        }
    }
}

// then check `foobar_set` afterwards

This could be made easier if apply could return a result. Or we'd have to implement something like I described in the issue. Also if you remember more examples of conflicting options in coreutils, I'd love to know about them. I think I only found cut so far, but I think there's more that I forgot about.

[pacak]

https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap12.html - I took some terminology for bpaf from here

[tertsdiepraam]

Interesting! I'll take a look at that. Thanks!

[tertsdiepraam]

Based on that document, I see the following options (no pun intended):

• option/positional (the current names)
• optional/positional (similar but more consistent)
• option/operand (two nouns)

I like the last option, even though I think that option and operand look a bit too similar.

Another possibility is to merge them and differentiate them based on the given string. Then we don't have to really care about the names at all (except in the documentation, but we can use longer names there):

enum Arg {
    #[arg("-f", "--foo")] // option
    Foo,
    #[arg("FILES")]       // operand
    Bar(OsString),
}

Maybe that makes it nicer too? It's also a bit more similar to clap's approach.

@dho any opinions on this?

[tertsdiepraam]

I think I've resolved everything in here now :)