std.getopt suggestion

[Jonathan M Davis]

Okay. I have a suggestion for an improvement to std.getopt that I think merits 
a bit of discussion. There's currently a pull request with some improvements 
for getopt which are mostly internal changes rather than API changes ( 
https://github.com/D-Programming-Language/phobos/pull/272 ), but I think that 
there is an API change that we should consider.

Right now, there are three configuration options which are mutable module-level 
variables:

dchar optionChar = '-';
string endOfOptions = "--";
dchar assignChar = '=';

and the aforementioned pull request adds another for an array separator. 
Mutable module/global variables are generally considered to be bad design 
(though they're sometimes necessary), and I'm very much inclined to have those 
variables _not_ be at the module scope like that.

So, my suggestion is that we create a GetOpt struct which contains all of the 
options for getopt, and we make getopt a member function of that struct. That 
way, if you're doing any configuration to getopt, you create a GetOpt object, 
set whatever properties you want to set on it, and call getopt on it - much 
cleaner than setting module-level variables. However, because you generally 
don't care about setting options on getopt, we then have a getopt function 
which is a free function (as we do now) which internally uses GetOpt.init and 
calls its getopt. So, it improves the configuration situation but leaves the 
usage of std.getopt to be pretty much the same if you don't want to mess with 
the default configuration.

Does anyone think that that's a bad idea for any particular reason? 
Personally, I think that it's a significant improvement given that it's getting 
rid of the mutable module-level variables and better encapsulating getopt's 
functionality, but I think that there's some value in discussing the idea 
first.

Also, it gives us a good opportunity to rename getopt to getOpt (so that it's 
properly camelcased per Phobos' naming conventions) as well as change any 
defaults which need changing. For instance, the aforementioned pull request 
adds a noSpaceOnlyForShortNumericOptions option, which it then recommends 
using but doesn't make the default, because it would break code. With this 
change, we could make it the default (with the old getopt function still using 
the current behavior for as long as its around). Personally, I'd also like to 
see bundling be the default, since that's how most command line programs work 
(at least on Posix), but regardless, renaming getopt to getOpt gives us a good 
opportunity to change some of the defaults if appropriate.

In any case, the primary question is whether the basic idea of creating a 
GetOpt struct for configuring getOpt, making getOpt a member function of it, 
and then having a free function getOpt which uses GetOpt.init seems like a 
good idea or whether anyone can come up with a good reason why it _wouldn't_ 
be a good idea.

- Jonathan M Davis