Default display for String is awkward, ie [default: ]

[nathan-at-least]

Please complete the following tasks

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

Rust Version

rustc 1.69.0 (84c898d65 2023-04-16)

Clap Version

4.3.4

Minimal reproducible code

use clap::Parser;

#[derive(Parser)]
struct Opts {
    #[clap(long, default_value_t)]
    text: String,
}

fn main() {
    Opts::parse();
}

Steps to reproduce the bug with the above code

$ cargo run -- --help

Actual Behaviour

Usage: foo [OPTIONS]

Options:
      --text <TEXT>  [default: ]
  -h, --help         Print help

Expected Behaviour

I do not think this "should" happen given the current release, but IMO it would be more ideal:

Usage: foo [OPTIONS]

Options:
      --text <TEXT>  [default: '']
  -h, --help         Print help

In this proposed feature enhancement, all Display values would be disambiguated via single quote ', so some examples:

• field type String displays [default '']
• field type i64 displays [default '0']
• field type bool displays [default 'false']

Additional Context

The display of default_value_t defaults just literally uses Display, which can be confusing for a variety of defaults:

• empty string (like in this example)
• strings containing ']' or other symbols.

unlikely / pathological cases:

• newlines

In my "expected behavior" I'm imagining consistent shell-like escaping. This need not be literal shell syntax (especially because users can vary which shells they use and across platforms), but only "unambiguous to typical commandline users".

Simply surrounding the Display value with single ticks ' handles the empty string case, but introduces an escaping problem with Display values that contain '. So this complication would make this feature improvement a bit more messy.

Perhaps \'-style escapes would be simple enough?

#[clap(long, default_value = "val: 'blah'")]
text: String,

-would produce:

[default: 'val: \'blah\'']

Debug Output

n/a

[nathan-at-least]

I filed this as a bug, because I consider UX issues which may cause confusion to users as bugs. I could also see categorizing this as a feature/enhancement.

[epage]

Currently, we only check for to decide if we should use quoting. When we quote, we are currently using Rust's debug representation of a string.

I think checking for empty string and quoting in that case is reasonable.

We also have the code spread out a bit. We should probably consolidate these before quoting for empty strings.

See

• https://github.com/clap-rs/clap/blob/master/clap_builder/src/output/help_template.rs#LL776C42-L776C42
• https://github.com/clap-rs/clap/blob/master/clap_builder/src/builder/possible_value.rs#L179
• https://github.com/clap-rs/clap/blob/master/clap_builder/src/error/format.rs#L535

[zippy-dice]

Is it ideal to quote for String that is empty or contain spaces?
As a solution, I suggest creating a function to wrap a string by '' or "" and use it in help_template.rs and possible_value.rs.
In that case, I believe there would be no need to change format.rs, as it will always enclose a string by '', regardless of whitespace or empty strings.