Skip to content
This repository has been archived by the owner on Jan 1, 2022. It is now read-only.

Support default_missing_value_t, default_value_if_t, etc #211

Open
2 tasks done
epage opened this issue Dec 6, 2021 · 4 comments
Open
2 tasks done

Support default_missing_value_t, default_value_if_t, etc #211

epage opened this issue Dec 6, 2021 · 4 comments

Comments

@epage
Copy link
Owner

epage commented Dec 6, 2021

Issue by epage
Tuesday Oct 05, 2021 at 14:20 GMT
Originally opened as clap-rs/clap#2813


Please complete the following tasks

  • I have searched the discussions
  • I have searched the existing issues

Clap Version

v3.0.0-beta.4

Describe your use case

clap_derive has a default_value_t attribute that takes a rust data type, instead of a string, and sets it as default_value on the Arg.

However, there are related functions that are missing similar _t magic methods

Describe the solution you'd like

Add magic methods for other raw methods that accept a value corresponding to the field the attribute is applied to

Alternatives, if applicable

No response

Additional Context

No response

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by marjakm
Thursday Nov 04, 2021 at 16:00 GMT


As I see it, those methods are all special cases of a pattern that uses a type to generate some code, but why allow only a few special cases not all such patterns?

default_value_t basically generates a call to

pub struct Arg {
    pub fn default_value(self, val: &'help str) -> Self;
}

as something like this:

arg = Arg::default_value(arg, generate_default_from_type!{T});

generate_default_from_type is a special macro in generator, adding default_missing_value_t support would mean creating a similar macro that also takes the type T. Why only allow this pattern for macros defined in the code generator, why not allow the user of the library to provide the macro (or maybe function) and generate code that provides the type to the user-defined macro (or function).

It could be implemented by allowing the user to annotate like such:

    struct Opt {
        #[clap(modify_t(my_mod))]
        arg: i32,
    }
    
    fn my_mod<T: Default + serde::Serialize>(a: Arg) -> Arg {
        let val: &'static str = todo!("serialize default T with serde_json, and leak boxed string");
        a.default_value(val)
         .default_value_if(todo!(), todo!(), todo!())
    }

Derive crate could generate something like this:

arg = my_mod::<T>(arg);

It would still be useful to have attributes such as default_value_t and default_missing_value_t, but they could be implemented via having the macros defined as functions somewhere and converting default_missing_value_t to modify_t(generate_default_from_type).

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by marjakm
Thursday Nov 04, 2021 at 16:06 GMT


I actually would like to generate Arg::about calls in just this way - the arg parses Option<ComplexStruct> via json, the default value should be the empty string, but I'd like to generate an example json in the about.

If you like the above-described solution, I could actually try implementing it and making a pull request

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by epage
Thursday Nov 04, 2021 at 16:10 GMT


Let's split that out into its own issue to talk about. This is specifically about providing natively typed magic methods that map to regular methods.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by epage
Thursday Nov 04, 2021 at 16:10 GMT


Also of note: we might want to see how clap-rs/clap#2683 impacts this issue.

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

No branches or pull requests

1 participant