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

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:

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;
    // ./app --param2 42 command --nested_param yay

Reply via email to