Am I reading this wrong, or is std.getopt *really* this stupid?

[Seb]

On Sunday, 25 March 2018 at 04:30:31 UTC, Jonathan M Davis wrote:
> On Saturday, March 24, 2018 09:59:44 H. S. Teoh via 
> Digitalmars-d wrote:
>> And given the defensiveness surrounding std.getopt, my 
>> conclusion can only be: dump std.getopt, roll my own.  It's 
>> sad, since in general Phobos design tends to be superior to

Yeah I have "dumb XYZ, roll my own" experience often too.
As there are already many big libraries like `arsd` or `ae` out 
there, I don't think I'm the only one with these feeling.
I wonder if someone ever tries to fork/reboot Phobos with all the 
goodies, but without the legacy cruft like auto-decoding and 
similar friends whose breaking changes can't be made.

>> its C++ counterparts.  But we then have warts like std.getopt 
>> that people refuse to acknowledge is a problem.  So be it.
>
> I think that there are at least a couple alternatives to 
> std.getopt on code.dlang.org if you want alternatives.

Yes, two good ones are:

https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt
http://code.dlang.org/packages/darg

> Personally, the only complaints I've had with std.getopt is

Hehe I like many things about std.getopt, but it's not perfect 
either.
A few examples:

- I often just want to map CLI arguments to a config object where 
using UDAs would more natural and less boilerplate

     struct Config {
        @option("c|compiler")
        string compiler;
     }

Now with the rejected/postponeed __traits(documentation) the ddoc 
help text could be automatically read and put into the 
auto-generated CLI help.

- I don't like to manually check for .helpWanted

Imho I constantly find myself doing this:

     if (helpInformation.helpWanted)
     {
`DDoc wrapper
All unknown options are passed to the compiler.
./ddoc <file>...
`.defaultGetoptPrinter(helpInformation.options);
         return 1;
     }

I would have preferred this being the default behavior or at 
least the default behavior if a help text string is explicitly 
provided e.g. like:

     getopt(`My program
./program ...`, args, ...);

or maybe with sth. like `.withHelp("")`

- setting shared configs doesn't work

I know, I could use a TLS config or use an atomicOp or 
synchronized assignment to set it, but often casting is easier 
and that's rather ugly:

https://github.com/dlang/dlang.org/blob/master/dspec_tester.d#L101

- in theory getopt should be @safe and use ref

It just does a bit of string manipulation, but it looks like we 
have to wait until DIP1000 for this:

https://github.com/dlang/phobos/pull/6281

Also similarly to std.stdio.read or std.format.formattedRead 
there's no need to use pointers, D's @safe ref would have worked 
too. Now, it looks like this change can't be made anymore as it 
would be a breaking one due to ambiguities.

- it would be really cool to support generating zsh/bash 
completions files

This is the last point on my list as it's not really a limitation 
of std.getopt and GetoptResult should be enough for this, but it 
looks like no one bothered enough to write a zshGetoptPrinter so 
far.

> getopt can probably be improved to work with Nullable so that 
> it'll be easier to figure out whether an argument has been set.

Yes, supporting Nullable would really cool!