July 04, 2008
Nick Sabalausky wrote:
...
> 
> The getopt version forces you to list each variable three times. Once for
> the variable itself, once more to tell getopt what it's called, and a
> third time to tell getopt where it is. That's highly redundant. They're
> only
> listed once for the C# version.  (The getopt version could probably be
> changed to extract the name from the variable using templates and traits
> though, and it could probably eliminate the rest of that redundancy by
> sticking the vars into a class or stuct, but then it would lose the
> ability to let you specify options for each var. Attributes would bring
> that ability back without creating reduncancy).

I don't understand why attributes are needed to achieve this. You can indeed use traits (with a mixin) to eliminate the redunancy of getopt, this takes about 20 lines of code at most. With mixin+templates, it should not be too difficult to also let the user specify options per variable. C# attributes as I understand it make use of runtime reflection, D and especially D2 has enough compile time reflection power to make this design work and do so in a less verbose manner.
July 04, 2008
"superdan" <super@dan.org> wrote in message news:g4k9tr$34r$1@digitalmars.com...
> Bill Baxter Wrote:
>
>> Jarrett Billingsley wrote:
>> > "Matt" <no-one@none.nowhere.com> wrote in message news:g4jqum$269v$1@digitalmars.com...
>> >> Is there an established library in D for handling command-line arguments?
>> >>
>> >> In particular:
>> >> - handling differences between Windows and UNIX shells (i.e. wildcard
>> >> expansion)
>> >> - handling equivalent options such as "-n 10" === --count=10
>> >> - handling combination of multiple flags, e.g. "-lcf" == "-l -f -c"
>> >>
>> >> Thanks
>> >>
>> >> Matt
>> >
>> > I don't believe there is an argument parser in either Phobos 1 or
>> > Phobos 2.
>> > However, there is one in Tango.
>> >
>> >
>>
>> doost has one that works with Phobos. (http://dsource.org/projects/doost)
>>
>> D2/Phobos2 has std.getopt.
>>
>> There's a port std.getopt to D1 in the std2 project: http://www.dsource.org/projects/std2
>>
>> There's a simple port of BSD's getopt in OpenMesh/D: http://www.dsource.org/projects/openmeshd/browser/trunk/OpenMeshD/OpenMesh/Tools/Utils/getopt.d
>>
>> --bb
>
> there's one in tango too but it takes 20 lines to do anything, as most others do. create a freakin' "command line object". give me a lunch break. std.getopt in phobos is best in the world for my money. and across all languages for that matter. could never imagine do so much shit in one call.

There is a new one in Tango as of the latest release called Arguments.  It's very simple to use:

auto args = new Arguments(argv[1..$]);

if(args.contains("c")) {} // test for -c
auto filename = args["f"]; // get parameter for -f filename

Of course, you can also configure it to be more strict, or to change every detail, down to the switch character (instead of '-'), but it is easy to use to get something up and running quickly.

http://www.dsource.org/projects/tango/docs/current/tango.util.Arguments.html

-Steve


July 04, 2008
Nick Sabalausky Wrote:

> "superdan" <super@dan.org> wrote in message news:g4kit6$nuq$1@digitalmars.com...
> > Nick Sabalausky Wrote:
> >
> >> "Nick Sabalausky" <a@a.a> wrote in message news:g4k93l$1mh$1@digitalmars.com...
> >> > "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:g4ju5s$2dh0$1@digitalmars.com...
> >> >> "Matt" <no-one@none.nowhere.com> wrote in message news:g4jqum$269v$1@digitalmars.com...
> >> >>> Is there an established library in D for handling command-line arguments?
> >> >>>
> >> >>> In particular:
> >> >>> - handling differences between Windows and UNIX shells (i.e. wildcard
> >> >>> expansion)
> >> >>> - handling equivalent options such as "-n 10" === --count=10
> >> >>> - handling combination of multiple flags, e.g. "-lcf" == "-l -f -c"
> >> >>>
> >> >>> Thanks
> >> >>>
> >> >>> Matt
> >> >>
> >> >> I don't believe there is an argument parser in either Phobos 1 or
> >> >> Phobos
> >> >> 2.
> >> >> However, there is one in Tango.
> >> >>
> >> >
> >> > Command-line parsing is one of the big reasons I really wish D had
> >> > C#/Java
> >> > style attributes. I came across this one particular C# command-line
> >> > parser
> >> > (written by a Peter Hallam) a few years ago and absolutely fell in love
> >> > with it, and by extention, attributes. (I'd link to it, but it was on
> >> > GotDotNet, which MS replaced with something else and didn't move this
> >> > particular program over. So I'm attaching the lastest version I have
> >> > (only
> >> > about 11k), even though there are newer versions...somewhere.)
> >> >
> >> > Just check out how awesomely simple it makes this sample case:
> >> >
> >> > BEGIN CODE
> >> > class WCArguments
> >> > {
> >> >    public bool lines;
> >> >    public bool words;
> >> >    public bool chars;
> >> >
> >> > [Utilities.DefaultCommandLineArgument(Utilities.CommandLineArgumentType.MultipleUnique)]
> >> >    public string[] files;
> >> >
> >> >
> >> > [Utilities.CommandLineArgument(Utilities.CommandLineArgumentType.AtMostOnce,
> >> > ShortName = "num")]
> >> >    public int number;
> >> >    public string[] junk;
> >> > }
> >> >
> >> > class WC
> >> > {
> >> >    static void Main(string[] args)
> >> >    {
> >> >        WCArguments parsedArgs = new WCArguments();
> >> >        if (!Utilities.Utility.ParseCommandLineArguments(args,
> >> > parsedArgs))
> >> >        {
> >> >            // error encountered in arguments. Display usage message
> >> >
> >> > System.Console.Write(Utilities.Utility.CommandLineArgumentsUsage(typeof(WCArguments)));
> >> >        }
> >> >        else
> >> >        {
> >> >            // insert application code here
> >> >        }
> >> >    }
> >> > }
> >> > END CODE
> >> >
> >> > The WCArguments class is itself the very definition of the program's
> >> > command-line arguments. And attributes can be used to specify things
> >> > like
> >> > "DefaultCommandLineArgument", "MultipleUnique", "AtMostOnce",
> >> > "ShortName",
> >> > "Required", etc. Later versions include automatically-generated help
> >> > screens. And the command-line syntax is the same
> >> > ultra-clean-consistent-and-unambiguous commandline syntax that MS's
> >> > command-line .NET tools use.
> >> >
> >> > D2 could probably come close to this with its compile-time reflection,
> >> > but
> >> > I don't think there'd be a comparably simple way to specify the things
> >> > that this uses attributes for.
> >> >
> >>
> >> I just took a look at Phobos2's getopt. It's impressively code to this in functionality. But I still think this is much cleaner and more DRY ("drier"?)
> >>
> >>
> >
> > in the words of the annoying chick in friends: oh....... my....... god! how could that dung be better than this?
> >
> > void main(string[] args)
> > {
> >    bool lines = true, words = true, chars = true;
> >    string[] files;
> >    int number;
> >
> >    getopt(args,
> >        "lines", &lines,
> >        "words", &words,
> >        "lines", &lines,
> >        "files", &files,
> >        "num", &number);
> >    ........
> > }
> >
> > this does everything that does /without/ adding a new class and redundant shit in square brackets. the fact that there could be multiple files is inferred from the type string[]. no new class, no attributes, no mess. shit man that c# stuff really blows. awesomely blows if you wish. how can anyone like that shit. to say nothing about the no-good generated help string that always is too short and uninformative to help shit.
> >
> > p.s. look! i wrote an entire post and no fuck! fuck me but this is weird. oops i fucked up again. :)
> 
> The getopt version forces you to list each variable three times. Once for the variable itself, once more to tell getopt what it's called, and a third time to tell getopt where it is. That's highly redundant. They're only listed once for the C# version.

narp. getopt is better for 2 reasons. first, if i want to have an option with a dash in it, with getopt you say;

bool showControlChars;
getopt(args, "show-control-chars", &showControlChars);

i and you and anyone who's used getopt once knows how to do that. but i have no idea how to do that in c#. there may be some shitty attribute to do so but i have to go check the manual. who wins?

second, yarp i do define the var and then specify it in the getopt thing. but that's a good thing, gives me freedom. i can put it locally, or at module level, or in another object. but in c# it's always a member of a new type. shit. i have to define a freakin' *type*. that's useless baggage. why do i have to define a type to parse my command line shit. thanks but i'll use getopt.

>  (The getopt version could probably be
> changed to extract the name from the variable using templates and traits
> though, and it could probably eliminate the rest of that redundancy by
> sticking the vars into a class or stuct, but then it would lose the ability
> to let you specify options for each var. Attributes would bring that ability
> back without creating reduncancy).

run ls --help. you'll see there are 18 options with dashes in'em and 23 without. that's like 40/60.

but then maybe some-option-x could be converted automatically to someOptionX by a template. heh we have an enhancement idea right there.

> Regarding the C# version:
> - Sticking the variable declarations inside a class is trivial.

yarp but i have to have a class in the first place.

> - All of the stuff in square brackets (attributes) are optional.
> (If you do specify any attributes, then the AttributeType is required,
> however I was able to remove that restriction in about two minutes by adding
> two trivial constructors.)

two minutes for command line shit is two minutes too many. that's the problem. command line is easy shit. should be a !brainer. everybody doing command line shit asks me to waste time with their crappy api. getopt in phobos is the first ever to ask me to be done with it in seconds and move on. i think it makes it look so simple people don't see what a work of art it is.

> - You can specify a custom help string for each element.

guess this could be improved in getopt:

uint shits;
getopt(args,
    "shits number of shits given for this run", &shits);

so then the space separates the option from the help string.

> - The fact that there could be multiple files *IS* inferred by using an array of strings. (At least if you don't use any attributes, that is. But that can be fixed fairly easily too.)

hum. so then why would the attributes be needed in the first place.

> If anyone's interested, I found a link: http://www.codeplex.com/CommandLineArguments

sorry won't read. :)

July 04, 2008
== Quote from Jarrett Billingsley (kb3ctd2@yahoo.com)'s article
> "Matt" <no-one@none.nowhere.com> wrote in message news:g4jqum$269v$1@digitalmars.com...
> > Is there an established library in D for handling command-line arguments?
> >
> > In particular:
> > - handling differences between Windows and UNIX shells (i.e. wildcard
> > expansion)
> > - handling equivalent options such as "-n 10" === --count=10
> > - handling combination of multiple flags, e.g. "-lcf" == "-l -f -c"
> >
> > Thanks
> >
> > Matt
> I don't believe there is an argument parser in either Phobos 1 or Phobos 2. However, there is one in Tango.

Tango actually has two right now.  tango.util.ArgParser is the original one, which uses callbacks to process arguments.  There's also a newer one at tango.util.Arguments which is a bit simple to use.  It basically just exposes the arguments via opIndex, much like an AA.


Sean
July 04, 2008
Steven Schveighoffer Wrote:

> "superdan" <super@dan.org> wrote in message news:g4k9tr$34r$1@digitalmars.com...
> > Bill Baxter Wrote:
> >
> >> Jarrett Billingsley wrote:
> >> > "Matt" <no-one@none.nowhere.com> wrote in message news:g4jqum$269v$1@digitalmars.com...
> >> >> Is there an established library in D for handling command-line arguments?
> >> >>
> >> >> In particular:
> >> >> - handling differences between Windows and UNIX shells (i.e. wildcard
> >> >> expansion)
> >> >> - handling equivalent options such as "-n 10" === --count=10
> >> >> - handling combination of multiple flags, e.g. "-lcf" == "-l -f -c"
> >> >>
> >> >> Thanks
> >> >>
> >> >> Matt
> >> >
> >> > I don't believe there is an argument parser in either Phobos 1 or
> >> > Phobos 2.
> >> > However, there is one in Tango.
> >> >
> >> >
> >>
> >> doost has one that works with Phobos. (http://dsource.org/projects/doost)
> >>
> >> D2/Phobos2 has std.getopt.
> >>
> >> There's a port std.getopt to D1 in the std2 project: http://www.dsource.org/projects/std2
> >>
> >> There's a simple port of BSD's getopt in OpenMesh/D: http://www.dsource.org/projects/openmeshd/browser/trunk/OpenMeshD/OpenMesh/Tools/Utils/getopt.d
> >>
> >> --bb
> >
> > there's one in tango too but it takes 20 lines to do anything, as most others do. create a freakin' "command line object". give me a lunch break. std.getopt in phobos is best in the world for my money. and across all languages for that matter. could never imagine do so much shit in one call.
> 
> There is a new one in Tango as of the latest release called Arguments.  It's very simple to use:
> 
> auto args = new Arguments(argv[1..$]);
> 
> if(args.contains("c")) {} // test for -c
> auto filename = args["f"]; // get parameter for -f filename
> 
> Of course, you can also configure it to be more strict, or to change every detail, down to the switch character (instead of '-'), but it is easy to use to get something up and running quickly.
> 
> http://www.dsource.org/projects/tango/docs/current/tango.util.Arguments.html

yarp looked over it. with all due respect, what a piece of crap that is. with that i can't even hope to parse the command line of ssh or rdmd. it loses the original order. it doesn't understand -- which in unix means that options stop here. generally does not obey new unix conventions. defines all sort of useless shit like conflicts that i could care less about. i could write one test expression after parsing thank you very much. but it cannot force the types of its arguments so i must make sure i validate /all/ that shit which is much more voluminous. geez. finally it defines so many types and functions anyone will need a fucking graduate course to use it. no thanks. std.getopt mops the floor with it.
July 04, 2008
"superdan"  wrote
> Steven Schveighoffer Wrote:
>
>> "superdan" wrote
>> > Bill Baxter Wrote:
>> >
>> >> Jarrett Billingsley wrote:
>> >> > "Matt" <no-one@none.nowhere.com> wrote in message news:g4jqum$269v$1@digitalmars.com...
>> >> >> Is there an established library in D for handling command-line arguments?
>> >> >>
>> >> >> In particular:
>> >> >> - handling differences between Windows and UNIX shells (i.e.
>> >> >> wildcard
>> >> >> expansion)
>> >> >> - handling equivalent options such as "-n 10" === --count=10
>> >> >> - handling combination of multiple flags, e.g. "-lcf" == "-l -f -c"
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> Matt
>> >> >
>> >> > I don't believe there is an argument parser in either Phobos 1 or
>> >> > Phobos 2.
>> >> > However, there is one in Tango.
>> >> >
>> >> >
>> >>
>> >> doost has one that works with Phobos. (http://dsource.org/projects/doost)
>> >>
>> >> D2/Phobos2 has std.getopt.
>> >>
>> >> There's a port std.getopt to D1 in the std2 project: http://www.dsource.org/projects/std2
>> >>
>> >> There's a simple port of BSD's getopt in OpenMesh/D: http://www.dsource.org/projects/openmeshd/browser/trunk/OpenMeshD/OpenMesh/Tools/Utils/getopt.d
>> >>
>> >> --bb
>> >
>> > there's one in tango too but it takes 20 lines to do anything, as most
>> > others do. create a freakin' "command line object". give me a lunch
>> > break.
>> > std.getopt in phobos is best in the world for my money. and across all
>> > languages for that matter. could never imagine do so much shit in one
>> > call.
>>
>> There is a new one in Tango as of the latest release called Arguments.
>> It's
>> very simple to use:
>>
>> auto args = new Arguments(argv[1..$]);
>>
>> if(args.contains("c")) {} // test for -c
>> auto filename = args["f"]; // get parameter for -f filename
>>
>> Of course, you can also configure it to be more strict, or to change
>> every
>> detail, down to the switch character (instead of '-'), but it is easy to
>> use
>> to get something up and running quickly.
>>
>> http://www.dsource.org/projects/tango/docs/current/tango.util.Arguments.html
>
> yarp looked over it. with all due respect, what a piece of crap that is. with that i can't even hope to parse the command line of ssh or rdmd. it loses the original order. it doesn't understand -- which in unix means that options stop here. generally does not obey new unix conventions. defines all sort of useless shit like conflicts that i could care less about. i could write one test expression after parsing thank you very much. but it cannot force the types of its arguments so i must make sure i validate /all/ that shit which is much more voluminous. geez. finally it defines so many types and functions anyone will need a fucking graduate course to use it. no thanks. std.getopt mops the floor with it.

Piece of crap is a little harsh :)  It can do some things that std.getopt cannot, and the interface is loads better than the original ArgParser that Tango had.  The issue I have with getopt is that it forces you into a specific option style.  This can be unacceptable if you are required to use another style (by your employer for instance).  Plus, with all the arguments contained in one object, and all the validation being configurable on the object instead of writing some piece of code after parsing, the arguments can be very modularized, and reduced to simple functions.

BTW, does getopt preserve order?  It doesn't look like it from the docs.

That being said, you have some valid points.  For instance, if you are parsing an integer argument, it is tedious to always have to deal with a string that might not be an integer.  And the speicifcation of long/short options together + aliases is very attractive.  However, I think these concepts could be incorporated into Arguments with not a lot of effort. I'll file a ticket about it with Tango.

-Steve


July 04, 2008
Steven Schveighoffer Wrote:

> "superdan"  wrote
> > Steven Schveighoffer Wrote:
> >
> >> "superdan" wrote
> >> > Bill Baxter Wrote:
> >> >
> >> >> Jarrett Billingsley wrote:
> >> >> > "Matt" <no-one@none.nowhere.com> wrote in message news:g4jqum$269v$1@digitalmars.com...
> >> >> >> Is there an established library in D for handling command-line arguments?
> >> >> >>
> >> >> >> In particular:
> >> >> >> - handling differences between Windows and UNIX shells (i.e.
> >> >> >> wildcard
> >> >> >> expansion)
> >> >> >> - handling equivalent options such as "-n 10" === --count=10
> >> >> >> - handling combination of multiple flags, e.g. "-lcf" == "-l -f -c"
> >> >> >>
> >> >> >> Thanks
> >> >> >>
> >> >> >> Matt
> >> >> >
> >> >> > I don't believe there is an argument parser in either Phobos 1 or
> >> >> > Phobos 2.
> >> >> > However, there is one in Tango.
> >> >> >
> >> >> >
> >> >>
> >> >> doost has one that works with Phobos. (http://dsource.org/projects/doost)
> >> >>
> >> >> D2/Phobos2 has std.getopt.
> >> >>
> >> >> There's a port std.getopt to D1 in the std2 project: http://www.dsource.org/projects/std2
> >> >>
> >> >> There's a simple port of BSD's getopt in OpenMesh/D: http://www.dsource.org/projects/openmeshd/browser/trunk/OpenMeshD/OpenMesh/Tools/Utils/getopt.d
> >> >>
> >> >> --bb
> >> >
> >> > there's one in tango too but it takes 20 lines to do anything, as most
> >> > others do. create a freakin' "command line object". give me a lunch
> >> > break.
> >> > std.getopt in phobos is best in the world for my money. and across all
> >> > languages for that matter. could never imagine do so much shit in one
> >> > call.
> >>
> >> There is a new one in Tango as of the latest release called Arguments.
> >> It's
> >> very simple to use:
> >>
> >> auto args = new Arguments(argv[1..$]);
> >>
> >> if(args.contains("c")) {} // test for -c
> >> auto filename = args["f"]; // get parameter for -f filename
> >>
> >> Of course, you can also configure it to be more strict, or to change
> >> every
> >> detail, down to the switch character (instead of '-'), but it is easy to
> >> use
> >> to get something up and running quickly.
> >>
> >> http://www.dsource.org/projects/tango/docs/current/tango.util.Arguments.html
> >
> > yarp looked over it. with all due respect, what a piece of crap that is. with that i can't even hope to parse the command line of ssh or rdmd. it loses the original order. it doesn't understand -- which in unix means that options stop here. generally does not obey new unix conventions. defines all sort of useless shit like conflicts that i could care less about. i could write one test expression after parsing thank you very much. but it cannot force the types of its arguments so i must make sure i validate /all/ that shit which is much more voluminous. geez. finally it defines so many types and functions anyone will need a fucking graduate course to use it. no thanks. std.getopt mops the floor with it.
> 
> Piece of crap is a little harsh :)

i agree it is harsh but i am dead serious. the problem is, tango people should not allow people who can't design add stuff to tango. i look at both option parsing stuff in tango and i get thinkin' of american sedans. you look at an american sedan and you clearly can say it looks like a vicious piece of shit. but it's hard to tell why. maybe if they raised the trunk a little? the headlights should be placed differently? no idea. it just sucks ass because it's designed by someone who can't design. the design is so messed up you can't pinpoint a couple of flaws. the right solution is to throw the whole thing and bring in someone who can design.

>  It can do some things that std.getopt
> cannot, and the interface is loads better than the original ArgParser that
> Tango had.

to be 100% honest the original stuff that ArgParser had set the bar real real low. and again. maybe an american sedan could do something that others can't. maybe it has a neat ac control or a cool steering wheel or shit. would i drive such a piece of shit for that? hell no.

>  The issue I have with getopt is that it forces you into a
> specific option style.  This can be unacceptable if you are required to use
> another style (by your employer for instance).

if your employer wants to override tried and true de facto standards then it's their problem. that comes with custom code for handling args, steeper learning curve for use, and more user annoyance. i fail to see how that's a problem with std.getopt.

> Plus, with all the arguments contained in one object, and all the validation being configurable on the object instead of writing some piece of code after parsing, the arguments can be very modularized, and reduced to simple functions.

"modularized"? there is one command line per app. there is no need to modularize anything. you modularlize if you use several instances in several places. with command parsing all i want is to parse my args and move on. in fact i *want* to put my validation right there in clear instead of modularizing it away.

> BTW, does getopt preserve order?  It doesn't look like it from the docs.

no but it understands -- and also has stopOnFirstNonOption. that's all that's needed.

> That being said, you have some valid points.  For instance, if you are parsing an integer argument, it is tedious to always have to deal with a string that might not be an integer.  And the speicifcation of long/short options together + aliases is very attractive.  However, I think these concepts could be incorporated into Arguments with not a lot of effort. I'll file a ticket about it with Tango.

yeah tell them to make that trunk a little higher while they're at it. ;)
July 04, 2008
== Quote from superdan (super@dan.org)'s article
> Steven Schveighoffer Wrote:
> >
> > Piece of crap is a little harsh :)
> i agree it is harsh but i am dead serious. the problem is, tango people should not allow people who can't design add stuff
to tango. i look at both option parsing stuff in tango and i get thinkin' of american sedans. you look at an american sedan and
you clearly can say it looks like a vicious piece of shit. but it's hard to tell why. maybe if they raised the trunk a little? the
headlights should be placed differently? no idea. it just sucks ass because it's designed by someone who can't design. the
design is so messed up you can't pinpoint a couple of flaws. the right solution is to throw the whole thing and bring in
someone who can design.

I think it would help if Tango had a few more core folks available to review contributions, or
simply more contributors in general.  As it is we're spread pretty thin, and I think our desire
for perfection is somewhat mitigated by a desire to encourage contributions, not alienate
users, and simply to have needed stuff in the library.  It's a difficult line to walk, and perhaps
a more formal review process might help somewhat.

> >  It can do some things that std.getopt
> > cannot, and the interface is loads better than the original ArgParser that
> > Tango had.
> to be 100% honest the original stuff that ArgParser had set the bar real real low. and again. maybe an american sedan could
do something that others can't. maybe it has a neat ac control or a cool steering wheel or shit. would i drive such a piece of
shit for that? hell no.

As always, any contributions to Tango are very much appreciated.  If you've got a better design, please submit it.

> yeah tell them to make that trunk a little higher while they're at it. ;)

tango.group helps here a bit by aggregating commonly used modules, but as far as I know, no one actually uses it :-)


Sean
July 04, 2008
Sean Kelly wrote:

> tango.group helps here a bit by aggregating commonly used modules, but as far as I know, no one actually uses it :-)

And therefore slated for removal.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
July 04, 2008
Sean Kelly Wrote:

> == Quote from superdan (super@dan.org)'s article
> > Steven Schveighoffer Wrote:
> > >
> > > Piece of crap is a little harsh :)
> > i agree it is harsh but i am dead serious. the problem is, tango people should not allow people who can't design add stuff
> to tango. i look at both option parsing stuff in tango and i get thinkin' of american sedans. you look at an american sedan and
> you clearly can say it looks like a vicious piece of shit. but it's hard to tell why. maybe if they raised the trunk a little? the
> headlights should be placed differently? no idea. it just sucks ass because it's designed by someone who can't design. the
> design is so messed up you can't pinpoint a couple of flaws. the right solution is to throw the whole thing and bring in
> someone who can design.
> 
> I think it would help if Tango had a few more core folks available to review contributions, or
> simply more contributors in general.  As it is we're spread pretty thin, and I think our desire
> for perfection is somewhat mitigated by a desire to encourage contributions, not alienate
> users, and simply to have needed stuff in the library.  It's a difficult line to walk, and perhaps
> a more formal review process might help somewhat.
> 
> > >  It can do some things that std.getopt
> > > cannot, and the interface is loads better than the original ArgParser that
> > > Tango had.
> > to be 100% honest the original stuff that ArgParser had set the bar real real low. and again. maybe an american sedan could
> do something that others can't. maybe it has a neat ac control or a cool steering wheel or shit. would i drive such a piece of
> shit for that? hell no.
> 
> As always, any contributions to Tango are very much appreciated.  If you've got a better design, please submit it.

yarp i've got one. just copy std.getopt. i know zilch about copyright and shit but as i read it it looks like they're cool if you just give them credit.