Negative value for positional argument with command chaining

[abey79]

Considering this modified command chaining example:

use bpaf::{positional, Bpaf, Parser};

#[derive(Debug, Clone, Bpaf)]
#[bpaf(options)]
pub struct Options {
    #[bpaf(external(cmd), many)]
    pub commands: Vec<Cmd>,
}

#[derive(Debug, Clone, Bpaf)]
pub enum Cmd {
    #[bpaf(command, adjacent)]
    /// Performs drinking action
    Drink {
        #[bpaf(positional("BEVERAGE"))]
        coffee: isize,  // <------------- KEY CHANGE HERE
    },

    #[bpaf(command, adjacent)]
    /// Performs taking a nap action
    Sleep,
}

fn main() {
    println!("{:?}", options().run())
}

I can't find a way to allow passing negative values to the drink command. With positional argument, neither of the documented was seem possible. Using = with positional arg isn't possible, and -- doesn't work either:

$ negative_positional drink -- -1 
Error: expected BEVERAGE, pass --help for usage information

Is there another way to support positional negative values?

[pacak]

Is there another way to support positional negative values?

#347

[abey79]

• Thanks for the note on anywhere, indeed I don't need it to make it work (will update the snippet above for future reference).
• I tend to have different METAVAR everywhere, so I'd indeed need to have support for something like #[bpaf(external(numeric("META")))] (which is still a lot of boilerplate :) )
• It would also be OK for me if -- worked as expected (aka separator between named and positional args for the current command) in chained command context. FWIW, that's how Click addresses that issue.

[abey79]

Side note: the type can be inferred, avoiding repeating it in the any attribute.

[abey79]

positional("META", any) could be nice syntactic sugar for any::<_>("META", Some)?

[pacak]

Side note: the type can be inferred, avoiding repeating it in the any attribute.

any is an escape hatch that lets you parse strange things rather than something you would use normally, type cannot be inferred, at least not with information available in a proc macro. Currently any takes a function and that function can change a type any produces.

I'm trying to keep combinatorial and derive APIs close to each other and positional("META", any) breaks this principle for not that much gain.

It would also be OK for me if -- worked as expected (aka separator between named and positional args for the current command) in chained command context.

This is an interesting thought, I'll see how far I can get it.

[abey79]

type cannot be inferred

I mean, it does work with any::<_>("BEVERAGE", Some), so type is inferred by rustc (but indeed not by the proc macro).