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!
