[boost] Feature suggestions for Boost's program_options

Subject: [boost] Feature suggestions for Boost's program_options
From: Eyal Rozenberg (eyalroz_at_[hidden])
Date: 2016-08-07 12:58:03

Greetings Boost developers,

[ Disclaimer:
I'm new to this list - I joined by Vladimir Prus' suggestion that I 
raise my feature ideas here on the list. I've read the posting 
guidelines, and I haven't seen any discussion of program_options (at 
least not by Vladimir himself) for at least a year back in the list 
archives, so I think my post is legit. ]

I've been using Boost's program_options library for several months now. 
It mostly does the job (that's a compliment...) - but there are some 
features whose lack is really bugging me. For some of them (especially 
Feature Idea 1) I actually work around by taking some options as 
unparsed remainders, sticking them in a string->string map and parsing 
them myself.

Without further ado, and in decreasing order of importance to me:

--------------------------------
Feature Idea 1:
Support specifying multiple alternative long option names, using
comma-separation. Right now we can specify, for example, 
"include-path,I" - one short form, one long form. Why not allow 
specifying "include-path,include-dir,headers-path,I" ? Only the first 
long option name would be printed as part of the usage information, to 
not complicate things overmuch, and merely tolerate alternative phrasing.

Feature Idea 2:
Have a (new?) parser which supports taking "semi-parsed command-line 
options" as input: A map from string keys to string values, or to 
optional<string> values to represent options without an argument as 
well. This is actually very close to environment parsing, except that 
the environment parser gets its "map" from, well, the environment 
variables. So the implementation might be simply exposing the existing 
functionality with a slightly richer interface.

Feature Idea 3:
A facility for pretty-printing parsed options to an std::ostream, in 
which the option description starts the line, and the option value (not 
the name used for parsing) is printed after it. There is some 
pretty-printing for the usage info to the console, so why not this?

(Argument against this idea: Choosing a default is a very touchy subject.
Counter-argument: ... but that's also somewhat true of printing usage 
information; and nobody has to  use this default, it would be entirely 
optional.)

Feature Idea 4:
Support three rather than just two levels of describing options: name,
for the command line; short description, for listing values (see Feature 
Idea 3; long description for the usage info.

Feature Idea 5:
Create a variant of update_with which doesn't just set the option value, 
but creates a link of sorts between the variable which the app would use 
and the variable_map entry. With this in place, further changes to the 
variable map automagically affect the app variable.
--------------------------------

So,

- What do you think about these suggestions, in principle?
- If you find some of them relevant, can you help estimate the necessary 
development effort and possible negative implications/caveats to consider?
- Assuming a feature idea is both relevant and feasible, is it customary 
to request implementation by the maintainer? Commit yourself to 
implementing it vis-a-vis statement of statement of partiality to 
accepting a patch? Some other practice?

Thank you for getting through the long(ish) email and for your hard work,
Eyal Rozenberg
DB architecture group
CWI Amsterdam