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
