"Jens Mueller" <jens.k.muel...@gmx.de> wrote in message news:mailman.21.1317824685.28623.digitalmar...@puremagic.com... > >I think we have failed, if a significant number of users rather write >their own command line parsing than using the built-in one.
I suspect that what often happens is what happened to me: The D user has an idea of how they want their cmd line to work, they look at getopt and see it won't work that way, so instead of changing their design to fit getopt they just implement their own solution that actually does what they wanted in the first place. (After all, it's not that hard to make a basic cmdline parser. If it were harder then maybe more people would be succesfully strongarmed into changing their design to match getopt's abilities.) And I'm sure there are cases where a program actually needs to match an existing program's command line for interoperability, in which case changing the design to match getopt would not have even been an option in the first place. Encouraging a "recommended" way is admirable, but doing it by providing a tool that allows the recommended way and then outright doesn't support other ways is very anti-D-philosophy (and at best is going to annoy the very same sorts of people who are attracted to D, and create more work for them). The D-way (and IMO, the *right* way), is to make the "recommended" way the default (and ideally even explain that it's recommended and why), and then allow easy configurability for "heretical"-but-concievable uses. Of course, it's also the D-way to have a one-person veto carved in stone... On a related note, does getopt support the ability to say "allow long options that begin with *either* -- or /"? Since I make stuff that's compiled natively to Windows (as opposed to being a clumbsy mingw-esque "port"), that was important to me way back when, and IIRC may have been one of the reasons I rolled my own cmdline parser a few years ago.
