Description
The current way to catch any extra args at the end of the command line is to use an IEnumerable<string>
property (with the Value
attribute and an index higher than any other Value
attributes), which will end up catching all the extra args passed on the command line. I suggest that catching extra args is such a common scenario that the extra args should always be available to the library user, whether or not they have defined a final IEnumerable<string>
property in their option type. So I propose the following:
- ParserResult class, or perhaps just its Parsed subclass, gains an ExtraArgs property of type
IEnumerable<string>
. - The
WithParsed<T>
methods in ParserResultExtensions gain another overload that takes anAction<T, IEnumerable<string>>
. This will receive the parsed option instance as its first parameter, and the extra args, if any, as a second parameter. (If all args were parsed into the option instance, the extra args will be an emptyIEnumerable<string>
, but it is guaranteed to never be null.) - Likewise, the
WithParsed<T>
methods in ParserResultExtensionsAsync will also gain an overload that takes aFunc<T, IEnumerable<string>, Task>
, and the second parameter is guaranteed to never be null.
Given the existence of issues like #63, it seems clear that the current design of CommandLineParser where you don't have access to any "extra" args unless you put an IEnumerable<string>
into your options is not intuitive to everyone, and many people expect the library to hand them any extra args and let them decide what to do with them.
This would NOT be a breaking change, so it could go into a 2.x release, but I don't suggest holding up the 2.9 release to get this feature in.