Hidden possible values

[dbrgn]

Please complete the following tasks

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

Clap Version

3.0.0-beta.5

Describe your use case

In tealdeer a user can override the platform / OS by using the --platform=(linux|osx|sunos|windows) flag. This is how we implement the parameter:

/// Override the operating system
#[clap(
    short = 'p',
    long = "platform",
    requires = "command",
    possible_values = ["linux", "osx", "sunos", "windows"],
)]
platform: Option<PlatformType>,

In the next version, we will probably rename osx to macos but keep osx for backwards compatibility. However, this means both options will be listed in the --help docs and in auto-generated completion files. To the end user, this may be confusing.

Describe the solution you'd like

It would be nice if I could specify hidden_possible_values that are accepted, but not listed in docs and completions.

/// Override the operating system
#[clap(
    short = 'p',
    long = "platform",
    requires = "command",
    possible_values = ["linux", "macos", "sunos", "windows"],
    hidden_possible_values = ["osx"],
)]
platform: Option<PlatformType>,

Alternatives, if applicable

Alternatively I could specify .hide_possible_values(true) and include the possible values in the help text, but then the value still shows up in the completion, which might confuse the user ("what's the difference between macos and osx?").

Additional Context

No response

[epage]

You're in luck; we already support this! This is a reported earlier in #2756 which was fixed in #2756 and #2762.

It went through some iteration since then, so for a recent example, see https://docs.rs/clap/3.0.0-beta.5/clap/struct.Arg.html#method.possible_values

[dbrgn]

Oh, I'm sorry to have missed this both in the docs and in the issue tracker 😕 But awesome that it's already supported!

[epage]

btw is there a reason you are using possible_values instead of deriving ArgEnum on an enum and using #[clap(arg_enum)]?

Also, an alias (which shouldn't be visible) should also work in your case.

[dbrgn]

@epage yeah, we have a custom FromStr implementation for this type: https://github.com/dbrgn/tealdeer/blob/4a92bed585ae15c58a348e886910fe8dd575624f/src/types.rs#L67-L84 I don't think deriving would work in this case, right?

[pksunkara]

Hmm.. I think it does. IIRC we tried to allow it work with that trait. But maybe the code changed?

[dbrgn]

Well, the custom FromStr works for me, so that's fine 🙂