derive: default to parse_os_str for OsString or PathBuf types

[joshtriplett]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Clap Version

3.1.1

Describe your use case

Most CLI applications should handle any path the user provides, not just UTF-8 paths. I'd like to make that easier to do by default when using derive, without having to remember to change the parse function.

Describe the solution you'd like

Currently, according to the documentation, parsing non-UTF-8 paths requires using parse(from_os_str).

I'd love to see this become the default if deriving an argument with a field type of PathBuf or OsString, to automatically do the right thing with paths.

Alternatives, if applicable

No response

Additional Context

No response

[epage]

Huh, I know I had considered this at one point but I can't find an issue for it. I do wonder / hope for #2683 to help with this class of problem in the long term.

I know one odd thing is for us to define how we detect these types since we just get the textual name (iirc). For example, for external subcommands, we only support String and OsString, so users have to do use std::ffi::OsString (ie we don't support ffi::OsString, std::ffi::OsString, ::std::ffi::OsString, or any kind of use defined alias).

As for when to do this, an awkward thing is we haven't fully defined what our compatibility story is because users might set attributes assuming what attributes we set or make direct calls on a generated Command or ArgMatches. I'm leaning towards this being considered a "minor incompatibility" of the level of MSRV change and leaving it to a minor release, as compared to major or patch.

[joshtriplett]

@epage One approach that might be viable on a clap 4 timeframe would be to do all conversions by way of bytes, and then conversions to String can check for UTF-8, while conversions to OsString or PathBuf or similar wouldn't. (On a comparable timeframe, we might manage to make OsString's use of bytes transparent in the standard library.) I'm also hoping such a change would make it easy to handle BString.

Meanwhile, in the short term, it seems vaguely reasonable to have the automatic behavior work the same way you're currently handling Vec.

[epage]

Just realized, changing any of this in the short term might be considered a breaking change since we would be implicitly setting allow_invalid_utf8 which if someone directly accesses the field via ArgMatches, will now panic.

Something we've not fully defined is our expectations for the derive: how much can people expect from the behavior of the derive when they do not use it in a self-contained way (pairing the generated Args with FromArgMatches). At the moment, we do not allow people deriving them independently at least.