https://issues.dlang.org/show_bug.cgi?id=16604

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com
           Assignee|nobody@puremagic.com        |edi33416@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=16604

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--

https://issues.dlang.org/show_bug.cgi?id=16604

--- Comment #1 from Eduard Staniloiu <edi33416@gmail.com> ---
There is a more elegant solution.
You can use the passThrough config directive.

>From the docs:
"Passing unrecognized options through:
If an application needs to do its own processing of whichever arguments getopt
did not understand, it can pass the std.getopt.config.passThrough directive to
getopt.

An unrecognized option such as "--baz" will be found untouched in args after getopt returns."

So, you could do something like this:

        auto helpInformation = getopt(
                args,
                std.getopt.config.passThrough,
                /* Your options here */);

        if (helpInformation.helpWanted || (args.length > 1))
        {
            defaultGetoptPrinter("Some information about the program.",
                    helpInformation.options);
        }

Any mistaken/nonexistent option will be in args, starting with index 1 (at args[0] you will have the name of your program)

--

https://issues.dlang.org/show_bug.cgi?id=16604

Witold Baryluk <witold.baryluk+d@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |witold.baryluk+d@gmail.com

--- Comment #2 from Witold Baryluk <witold.baryluk+d@gmail.com> ---
Yeah, I did find the exception throwing a bit problematic, and after some time of scratching, used similar trick to what Eduard proposed here.

But the fact that getopt is a function the immediately operates on the args, and doesn't provide introspection or compostability is a problem.

I think a Python argparse has a bit more interesting design, not because of it OOP-ness, but because it can have sub-parsers, you can compose them compose them easily, i.e. if you have multiple libraries that can be tweaked by some program flags, it is essentially impossible to use getopt. You can grab the unprocessed args, but then there is no easy way to forward it to other consumers implicitly really.

I grow a lot with Google flags ( https://github.com/gflags/gflags ) and golang flags (https://golang.org/pkg/flag/) when I did work at Google, and in fact I like them a lot. Similar solutions exist for Java.


If there is a way to do this things easily with getopt, I think documentation should be updated to show how to do it.

--

https://issues.dlang.org/show_bug.cgi?id=16604

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

--