std.getopt suggestion

[Nick Sabalausky]

"Jens Mueller" <jens.k.mueller at gmx.de> wrote in message 
news:mailman.21.1317824685.28623.digitalmars-d at 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.