Should use_field_init_shorthand differentiate preserve and false

[mqudsi]

For the use_field_init_shorthand configuration option, currently the (default) "false" option is actually "preserve" while the "true" option is more akin to "force".

Would it be beneficial for this to be changed to match many of the other options that have a default of "preserve" and the option of overriding it in either direction (where possible) via "false" and "true"?

EDIT:

Also, the example for use_field_init_shorthand has a bug where the last SLOC is emitted from the second example. This actually makes it look like there's no difference between the "false" and "true" cases.

[ytmimi]

Thanks for reaching out. I think true and false are appropriate for the option since there isn't really an in between that I can think of. Did you have something in mind? Are you suggesting that Preserve and Force would be clearer options?

As demonstrated by #5488, we can't always use the shorthand even when the value is set to True.

[calebcartwright]

Thanks for reaching out, but no, that's not a change we'd want to make especially not for an already stable option. In strictly boolean cases like this, we feel it's more natural for the option to follow the typical true/false paradigm. The Preserve variant is typically reserved for options that are non-binary in nature, and often connote more of a "use the original formatting to inform output formatting" as opposed to a "no, don't do that".

Also, the example for use_field_init_shorthand has a bug where the last SLOC is emitted from the second example. This actually makes it look like there's no difference between the "false" and "true" cases.

No, not really. There's varying interpretations/perspectives have about the config examples, but it's not intended to be interpreted as there being a relationship between the snippets from different values (there's no input/output relationship). The snippets are meant to be used as independent inputs such that running rustfmt over that snippet with that particular value would result in no code changes.

We've discussed trying to evolve the config documentation to try to include a separate input snippet that would be used and all the option value snippets would show the output of that snippet, but that's a large bucket of work no one has attempted to tackle yet

[mqudsi]

Ok, thanks for taking the time to respond.