epage
commented
2 years ago 
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).
Please complete the following tasks
Clap Version
v3.0.0-beta.4
Describe your use case
clap_derivehas adefault_value_tattribute that takes a rust data type, instead of a string, and sets it asdefault_valueon theArg.However, there are related functions that are missing similar
_tmagic methodsDescribe 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