Crazy idea: Drop the parsing of option values

[eyalroz]

I realize this would break existing functionality significantly, but here's my idea:

Command-line options either can-take a value or cant-take one; in the former case they're naturally booleans, otherwise naturally strings. Consequently, if we don't parse option values as any other types, we get bools, strings, and vectors of bools/strings when we allow multiple appearances of an option. The parsing of option values can be performed completely separately and independently from initial parsing of a command-line into a map of options to their "natural" values.

I argue that this separation is desirable. Separation of concerns, and of tasks, usually simplifies code, as well as making it more robust and flexible. In our case:

• No more need for arbitrary templates over option value types
• No more need for virtual classes for values: We have either two, three or four types, depending on how you look at it, and we can have a variant for those, or a simpler, custom, distinguished-union type.
• No more need for storing shared pointers to anything - since we don't need to work with subclasses via the value superclass.
• No need to make assumptions regarding how strings are parsed into values.

I'm pretty sure this will shave off hundreds of lines of code, if not more.

And the thing is, users of this library even today have to worry about how their input is parsed exactly, so this would not even add so much to the time they need to spend.

[jarro2783]

I'm considering this, and whether I could provide similar functionality as part of a separate utility that includes other things that people have asked for, like enforcing required options or other constraints.
I always wanted this to have a boost::program_options like interface, but you're right about simplification. Maybe that library was always trying to do too much as well.

This would obviously be a huge change, and would have to be a v4, I'll play around with some ideas first and see where it goes.