Nesting: need for #[bpaf(external)]

[kshpytsya]

According to the tutorial and the practical experience, #[bpaf(external)] is required for nesting. Is this a technical limitation (i.e. you cannot find a way to get it working without), or a conceptual one (i.e. you insist that this has to be explicit? Also, it seems awkward to me that the default (implicit) argument for external is derived not from the type name but from the field name. This makes it necessary to name the field as a snake_case version of the type to make use of implicit form #[bpaf(external)]. This also makes it impossible to use the implicit form in case of enum variants containing structs (see example below). I cannot seem to find an answer as to why it is chosen to generate a function instead of a trait implementation. I would argue that having to use a differently cased function instead of just a method of a type is less ergonomic.

Instead of:

#[derive(Debug, Clone, bpaf::Bpaf)]
pub struct A1Options {
    a1: String,
    a1x: bool,
}

#[derive(Debug, Clone, bpaf::Bpaf)]
pub struct A2Options {
    a2: i64,
    a2x: bool,
}

#[derive(Debug, Clone, bpaf::Bpaf)]
pub enum AOptions {
    A1(
        #[bpaf(external(a1_options))]
        A1Options,
    ),
    A2(
        #[bpaf(external(a2_options))]
        A2Options,
    ),
}

#[derive(Debug, Clone, bpaf::Bpaf)]
#[bpaf(options)]
pub struct Options {
    #[bpaf(external)]
    a_options: AOptions,
}

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

I would really like to be able to write:

#[derive(Debug, Clone, bpaf::Bpaf)]
pub struct A1Options {
    a1: String,
    a1x: bool,
}

#[derive(Debug, Clone, bpaf::Bpaf)]
pub struct A2Options {
    a2: i64,
    a2x: bool,
}

#[derive(Debug, Clone, bpaf::Bpaf)]
pub enum AOptions {
    A1(A1Options),
    A2(A2Options),
}

#[derive(Debug, Clone, bpaf::Bpaf)]
pub struct Options {
    a: AOptions,
}

fn main() {
    println!("{:?}", bpaf::run::<Options>())
}

P.S. not related to code but to the end-user experience with this example. Trying to to supply incompatible sets of options leads to confusing error messages, e.g.:

$ cargo r -- --a1x --a2=1
Error: no such flag: `--a1x`, did you mean `--a1`?
$ cargo r -- --a1=1 --a2x
Error: no such flag: `--a2x`, did you mean `--a1x`?

[pacak]

According to the tutorial and the practical experience, #[bpaf(external)] is required for nesting. Is this a technical limitation (i.e. you cannot find a way to get it working without), or a conceptual one (i.e. you insist that this has to be explicit?

You tend to have much more primitive parsers (those that parse using flag or FromStr logic) than nested parsers so I tried to optimize towards more common case scenario. In a proc macro you can't tell if a function targeted by external exists or not. When there's no annotation derive macro makes a few attempts to guess (is it a bool?, an Option<T>, a Vec<T>) before deciding to go with either positional or argument parser with FromStr.

It's a decision I made, but mostly coming from a technical limitation.

Also, it seems awkward to me that the default (implicit) argument for external is derived not from the type name but from the field name. This makes it necessary to name the field as a snake_case version of the type to make use of implicit form #[bpaf(external)].

This again optimizes for more common scenario if you work with existing types:

fn verbosity() -> impl Parser<usize> { .. }
fn starting_ofset() -> impl Parser<usize> { .. }

struct Opts {
...
    #[bpaf(external)]
    pub verbosity: usize,
    #[bpaf(external)]
    pub starting_offset: usize,
...
}

This way you can have several parsers for the same type and the name carries some meaning.

This also makes it impossible to use the implicit form in case of enum variants containing structs (see example below).

I cannot seem to find an answer as to why it is chosen to generate a function instead of a trait implementation. I would argue that having to use a differently cased function instead of just a method of a type is less ergonomic.

For a custom type a trait would be more ergonomic, but the trait won't work if you are working with existing types. Supporting both a trait and a function would require a second variant of external. Mostly decision for simplicity I guess.

I would really like to be able to write:

Unfortunately proc macros are limited like that.

P.S. not related to code but to the end-user experience with this example. Trying to to supply incompatible sets of options leads to confusing error messages, e.g.:

I think I have this fixed in the next major version.

[kshpytsya]

Thank you for your prompt and elaborate reply and for the bpaf itself!