Need ability to influence formatting of enum argument suggestions

[eiriktsarpalis]

Supposing I added a CLI argument that takes the following enum:

enum Argument { Foo, Bar, Baz }

var argument = new Argument<Argument>("argument", Argument.Baz);

The help text for the particular argument would render as follows:

--option <Foo|Bar|Baz>

I'd like the enum value suggestions to format using camel case, however the only way I can achieve this at the moment is by changing the enum identifiers:

enum Argument { foo, bar, baz }

However this style violates C# coding conventions. Would it be possible to expose a mechanism that controls this? One approach could be using attributes to override the identifiers:

enum Argument { [Description("foo")]Foo, [Description("bar")]Bar, [Description("baz")]Baz }

[jonsequitur]

This would be really useful. A couple of things it would be good to solve along with this example:

• Can I use it for enums whose declarations are not in my own code?
• Can I use it for other types that might have convention-based suggestions?

Regarding the attribute approach, there's been consistent interest in building this sort of declarative API, but the current focus is on building the core APIs that can be used to implement an attribute-driven model, or other types of models (code gen, DSL, etc.)

So currently, the suggestion APIs are additive, but there's no simple way to clear out the existing suggestion sources and set your own:

[eiriktsarpalis]

Another possible approach is to use magic and convert all identifiers to camel case. Json.net exposes such functionality, although I personally find it a bit distasteful.

[sharwell]

This is the specific purpose of DisplayNameAttribute

[jonsequitur]

I realize I opened a can of worms. 😄

@sharwell That's a good suggestion and could work for an eventual attribute-based API, one of which @KathleenDollard has been prototyping. It gets complicated fast, though. Is DisplayNameAttribute intended to be purely for display, or also affect the behavior of the program, e.g. parsing? The help suggestions are not just for display, but also have to round trip correctly back to the parser, so case sensitivity could be a concern in the general case. (Though we parse enums case-insensitively so it should be fine in this specific case.)

More broadly, we've avoided attribute-based models in the core APIs for reasons of clarity and startup performance. It's not straightforward to communicate where the attribute will be meaningful in the programming model. If the lower-case enum value will bind correctly after being parsed, what should happen it we rename it entirely? (That would currently break the binding. The same problem exists in my suggestion above, of course.) If it works on enums, can I also use it on model classes' properties and constructor parameters and expect it to influence binding? If so, is it inherited from base classes or interfaces?

I think that whatever approach is taken here, the attribute and underlying API should signal more clearly that this is a sort of two-way binding, not just for display.

Rather than try to solve that right now, I think @eiriktsarpalis's suggestion puts guardrails on the solution by constraining it to casing changes on enums. For the two questions I raised here, it solves the first one and nicely leaves the second out of scope.

Thoughts?

[eiriktsarpalis]

More broadly, we've avoided attribute-based models in the core APIs for reasons of clarity and startup performance.

I think startup performance is a very valid concern. Many years ago I wrote a heavily attribute-driven cli parsing library and startup performance suffered as a consequence.

[jonsequitur]

This is resolved by #955 and #962.