Support automatic naming and kebab-casing of fields/subcommands

[williamyaoh]

Description

Have a derive like this:

#[derive(StructOpt)]
struct Opt {
    #[structopt(long)]
    dry_run: bool,
    #[structopt(long)]
    config: Option<String>
}

automatically produce two command-line flags: --dry-run and --config. Currently, a #[structopt(long = "$NAME")] would have to added to both of them to make them usable.

Have a derive like this:

#[derive(StructOpt)]
enum Cmd {
    Loop,
    Lutz,
    Salchow,
    ToeLoop
}

automatically produce the subcommands loop, lutz, salchow, and toe-loop. As of #17, a #[structopt(name = "$NAME")] would be required here, otherwise CamelCase names would have to passed on the command line.

Semantics

Let the result of to-kebab-case(id) be id'. It's implemented in https://crates.io/crates/heck

For any field in a derive(StructOpt)'d type, if it does not have a name attribute, the name attribute will default to to-kebab-case($FIELD_NAME). If it does have a long attribute with no value , the long attribute will default to the same thing.

For any enum variant in a derive(StructOpt)'d enum, if it does not have a name attribute, the name attribute will default to to-kebab-case($VARIANT_NAME).

Purpose

To make structopt more convenient to use by reducing the amount of typing needed for common cases. It should not make structopt less intuitive to use.

Concerns

• While convenient, implementing this can mean that a user of structopt will have to pass names and flags on the command line that they technically never specified in their source code. Does the convenience outweigh the possible confusion from "magic" code?
• The name attribute can be easily overridden by a user. However, as far as I can see, there isn't a way to "unset" a .long() call on a clap::Arg. So optional arguments will end up being usable through long flags, even if the user, say, only wants short flags. How common is this scenario?
• The default mechanism for lowercasing in std::char isn't specialised for any given locale. Should structopt support customised lowercasing based on locale, or should it remain untailored for simplicity of use?

Alternatives

• Only automatically set the name attribute, rather than the long attribute. This avoids the problem with unremovable long flag names mentioned above.
• Don't do anything. Undesirable.

Anything else?

[sp3d]

My thoughts:

• structopt already does some things implicitly, such as creation of a --help option. I think that as long as the library is documented this is sane default behavior, since nearly nobody wants their command-line arguments to follow Rust variable/enum conventions. For users, the help message documents all available flags, and for developers the relation between these and the struct handed to structopt seems obvious.

• can we have #[structopt(long = "")] prevent the "automatic" .long() call? structopt should avoid forcing long options on library users.

• the motivation of this feature is simplifying the common case; if a developer defines a struct/enum with non-ASCII fields/variants, they aren't in the common case of writing a standard unix utility, since command-line flags are generally not internationalized, even though their help text regularly is. This is complicated by the fact that the command-line arguments of a program are not guaranteed to be valid UTF-8. I think the most conservative choice is for structopt should require an explicit specification of option name any time it gets non-ASCII input (and give a compile-time error otherwise); non-ASCII field/variant names are rare already and don't play well with the 1970s approach to text encodings built into POSIX.

[TeXitoi]

No automatic long, but #[structopt(long)] will kebab-casing the name as the long option.

[droundy]

I'd love to see this addition. Is there any work being done on implementing it? Would a pull request be welcome, if I can find time to implement this?

[TeXitoi]

No one is working on it yet to my knowledge, and a PR is very welcome.

Look at https://crates.io/crates/heck for case conversion.

It will be a breaking change.

You can also add support for #[structopt(short)] that convert to short(&name[0..1]) to be consistent with the long option, but not needed for the PR to be accepted.

Thanks for your interest! If you have any question, feel free to ask here.

[droundy]

I decided not to use heck, since field names are already snake_case by convention. So I just switched '_' to '-'. That allows users who violate convention to more easily get capital letters.

[TeXitoi]

But it doesn't work for renaming Enum in subcommand. And with the documentation, that's much better to say "converted to kebab-case" that "change every "_" to "-".

[kbknapp]

My only concern is from the struct definition alone, I wouldn't know if config is supposed to be a flag/option (--config) or a positional argument. I understand the OP is meaning a flag/option, but I can imagine it causing some confusion when someone what they think should be a positional argument and it ends up with a long with no way to unset.

Other than that concern, and if we could find a way to fix that, I'm in favor of this proposal.

[TeXitoi]

@kbknapp I agree with you and try to explain that in #18 (comment)

But clearly, that's not understandable, thus I'll update OP to reflect that.

[Lucretiel]

My only concern is from the struct definition alone, I wouldn't know if config is supposed to be a flag/option (--config) or a positional argument. I understand the OP is meaning a flag/option, but I can imagine it causing some confusion when someone what they think should be a positional argument and it ends up with a long with no way to unset.

I've actually implemented similar logic in a similar python library that does largely the same thing as structopt (structured derivation of CLI arguments). My logic was pretty simple: if it's a bool (or bool-like) or it has a default, make it a --flag, otherwise make it positional. I use autocommand in all my Python CLI work and that logic has never steered me wrong.

[azriel91]

Hiya, sounds like this issue may be stalled. In one of my projects, I'd like to have snake_case subcommands for my enum variants instead of kebab-case — the second part of the description.

Would you take a PR that implements an opt-in case change instead of opt-out? Example:

#[derive(StructOpt)]
#[structopt(command_case = "snake_case")]
enum Cmd {
    Loop,
    #[structopt(name = "other")]
    Lutz,
    Salchow,
    ToeLoop
}

which produces loop, other, salchow, and toe_loop as subcommands

[TeXitoi]

I argee on the feature, with the default being "verbatim". That way, there is no breaking change, and we can change the default value in a breaking change version.

For the name of the attribute, I'd use "rename_all" to be in sync with serde. This way, we can also use the same attribute on struct and enum.

@kbknapp what do you think?