On Monday, 16 June 2014 at 21:21:47 UTC, Robert Schadek via Digitalmars-d-announce wrote:
On 06/16/2014 11:11 PM, Dicebot via Digitalmars-d-announce wrote:
On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote:
Pretty cool idea. Are you aware of that in D you can, at compile time, parse the doc string and generate a command line parser for
that particular documentation.

I don't think it gives any advantage here :)

docopt looks cool, though my I'd prefer something that works other way
around - automatically generates argument parsing code and help
messages from aggregate that represents configuration and/or CLI API
(with help of few UDA).
+1 I could use reviews for this PR
https://github.com/D-Programming-Language/phobos/pull/2072

Sure, will have a look.

Though I don't see how what I propose can fit into Phobos as std.getopt, it is something for an alternative module. The way I see it, getopt will be more suitable for small simple CLI implementations and that imaginary module - for programs with huge amount of options and complicated nested commands.

Something like this:

@help("
Header used to describe this configuration option block
")
struct CLI
{
    @descr("Some optional parameter")
    Optional!int param1;

    @descr("Mandatory parameter")
    int          param2;

    struct Command
    {
        string nested_param;

        void opCall(ref A outer)
        {
// called after parsing relevant args into this instance
        }
    }

    Command command;
}

void main(string[] args)
{
    Config config;
    parseCLI!config(args);
    // ./app --param2 42 command --nested_param yay
}

Reply via email to