Inferring more meaning from types for derives

[epage]

Right now, we only use types to infer occurrences / values (see #1772) or some limited capabilities when a user sets arg_enum.

What else can we infer from types?

• If its a Path, set ValueHint::AnyPath
• Expand on fix(derive): Follow value_name convention #2611 and set value_name based on the type, like NUM for integers, PATH for Path, etc
• Select an appropriate parser for Path, OsString, etc.
  • feat: Auto-detect FromStr, TryFrom<&OsStr>, etc., in clap_derive #2298 wuld help with this

[epage]

What if we add a trait:

trait ArgHint {
    // Reasonable default value_name for Self
    //
    // By convention, this should be SCREAMING_CASE
    //
    // When `None`, clap will provide a value name based on the argument name
    fn value_name() -> Option<&str> {
        None
    }
    fn value_hint() -> Option<ValueHInt> {
        None
    }
}

impl ArgHint for i32 {
    fn value_name() -> Option<&str> {
        Some("NUM")
    }
}
// ditto for other numbers

impl ArgHint for std::path::PathBuf {
    fn value_name() -> Option<&str> {
        Some("PATH")
    }
    fn value_hint() -> Option<ValueHInt> {
        Some(ValueHint::AnyPath)
    }
}

By being a trait,

• Its easier for users to look into whats happening (since I suspect most casual users don't pop open cargo expand every day, I know I didn't until doing macro development on clap)
• Users can plug in their own types

The downside is everything must implement it. We could probably use the tricks in #2298 or similar to work around this.

[pksunkara]

I agree with inferring more things, but I think the trait idea might be tricky. Anyway, I think this can be done after 3.0 since I don't see any breaking changes needed.

[epage]

I agree things are tricky with a trait. The main hope that direction was to allow it to be user-defined which is relatively low value since a type is usually not so wide spread with some clap knowledge but without an derive(Args)