Sometimes a good API isn't the right answer. I like getopt as it is but I wanted a little different control. So I wrote up an article on my work around.

https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n

I have another technique for sub commands I should write about too.

On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips wrote:
> Sometimes a good API isn't the right answer. I like getopt as it is but I wanted a little different control. So I wrote up an article on my work around.
>
> https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n
>
> I have another technique for sub commands I should write about too.

http://code.dlang.org/packages/argsd

On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:
> On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips wrote:
>> Sometimes a good API isn't the right answer. I like getopt as it is but I wanted a little different control. So I wrote up an article on my work around.
>>
>> https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n
>>
>> I have another technique for sub commands I should write about too.
>
> http://code.dlang.org/packages/argsd

http://code.dlang.org/packages/darg

On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:
> On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips wrote:
>> Sometimes a good API isn't the right answer. I like getopt as it is but I wanted a little different control. So I wrote up an article on my work around.
>>
>> https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n
>>
>> I have another technique for sub commands I should write about too.
>
> http://code.dlang.org/packages/argsd

I think we are several having written alternative getopt() systems.
I made one too last year, it allows to write tools very nicely.
Recent example for a device flasher:

---
module app;

import
    iz.options;

struct Handler
{
private:

public:

    /// Handle the "--help" command.
    @Argument("--help", "prints the command line usage", ArgFlags(ArgFlag.allowShort))
    static void getHelp();

    /// Handle the "--info" command.
    @Argument("--info", "prints the list of connected mods", ArgFlags(ArgFlag.allowShort))
    static void getInfo();
    /// Handle the "--readFlash" command.
    @Argument("--readFlash", "read the firmware from the mod and save it to the specified file")
    static void readFlash(string fname);

    /// Handle the "--writeFlash" command.
    @Argument("--writeFlash", "read the firmware from the specified file and send it to the mod")
    static void saveFlash(string fname);

    /// Handle the "--reset" command.
    @Argument("--reset", "reset to factory state", ArgFlags(ArgFlag.allowShort))
    static void reset();
}

void main(string[] args)
{
    if (!handleArguments!(CanThrow, Handler)(args[1..$]) || args.length == 1)
        writeln(help!Handler);
}
---

https://github.com/Basile-z/iz/blob/master/import/iz/options.d#L379

Though I've detected several little flaws since it was written, but I don't care much  anymore about my own stuff these days...

On Wednesday, 26 June 2019 at 14:58:08 UTC, Basile B. wrote:
> I think we are several having written alternative getopt() systems.
> ...

Here's another one to add to the list: https://code.dlang.org/packages/jcli

Similar to you I'm pretty sure there's glaring issues I haven't seen/fixed yet.

Since it'll be *a while* until I get documentation written, features written, and bugs fixed, the points of interests (or detest :) ) over other libraries would be:

* I'm trying to make all the building blocks reusable, so even if the user doesn't like my particular style, they'll still have the tools to easily make their own version.

* Building blocks include: A dodgy pull parser for arguments; A builder class for help text, currently with two built-in content providers (which means the user can also make their own); An ArgBinder helper, which can be used to create user-defined argument binder without any boilerplate outside of simply making the binder; And while there's only a few right now, I'm wanting to add a bunch of utility functions similar to scriptlike.

The ArgBinder is probably the only fully interesting part tbh (more for how it's used, rather than how it's implemented), full documentation is in it's doc comment (binder.d).

On Wednesday, 26 June 2019 at 14:58:08 UTC, Basile B. wrote:
> On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:
>> On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips wrote:
>>> Sometimes a good API isn't the right answer. I like getopt as it is but I wanted a little different control. So I wrote up an article on my work around.
>>>
>>> https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n
>>>
>>> I have another technique for sub commands I should write about too.
>>
>> http://code.dlang.org/packages/argsd
>
> I think we are several having written alternative getopt() systems.
> I made one too last year, it allows to write tools very nicely.
> Recent example for a device flasher:

The thing is, I didn't write an alternative, mine utilizes getopt which was the point of the article. I could build out new functionality onto a standard API which didn't support it. It isn't as robust as it could be.

On Wednesday, 26 June 2019 at 23:35:59 UTC, Jesse Phillips wrote:
> On Wednesday, 26 June 2019 at 14:58:08 UTC, Basile B. wrote:
>> On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:
>>> On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips wrote:
>>>> Sometimes a good API isn't the right answer. I like getopt as it is but I wanted a little different control. So I wrote up an article on my work around.
>>>>
>>>> https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n
>>>>
>>>> I have another technique for sub commands I should write about too.
>>>
>>> http://code.dlang.org/packages/argsd
>>
>> I think we are several having written alternative getopt() systems.
>> I made one too last year, it allows to write tools very nicely.
>> Recent example for a device flasher:
>
> The thing is, I didn't write an alternative, mine utilizes getopt which was the point of the article. I could build out new functionality onto a standard API which didn't support it. It isn't as robust as it could be.

Sorry budy, I didn't want to ruin your announce.
Hold on ;)