On Sat, Aug 31, 2013 at 07:29:42PM -0700, Jonathan M Davis wrote: > On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote: > > I remember sitting next to Kirk McDonald at the D conference in 2007 > > as he was showing me Python's argparse. I personally found pretty > > much any example we could think of more verbose and uglier than > > std.getopt. > > std.getopt is definitely lacking some nice-to-have features (like > automatically generating --help from the options), but for the most > part, I don't think that it can be improved much without seriously > complicating it. I think that it's about at the limit of what can be > done and still have it be simple, and it works really well for the > most part, so if we haven't hit the sweet spot, we're at least close. > I've toyed with trying to figure out how to improve it, but I think > that doing so cleanly would be very hard.
I've had several people complain to me about std.getopt not understanding / supporting "standard" command-line syntax. Like '-c5' vs. '-c 5'. I've also experienced some quirks in how it handles option parsing, such as being unable to distinguish between '-w' and '--water' where both are distinct options (the use case is that multiple options begin with 'w', but one is more common than the others so '-w' is desirable as a shorthand, but currently std.getopt support for this is sketchy and unreliable). I'm not sure how to address this issue, though; I assume some of the design decisions stemmed from Windows vs. Posix compatibility, which may make supporting this kind of syntax tricky to support. > The main thing that I'd really like to see changed is the exception > types that it throws, because I'd very much like to be able to have > code which can give specific information about how the flags were > incorrectly used and whatnot, and ConvException (which is usually what > you get) doesn't cut it for that. You'd need getopt-specific > exceptions for that. But we can fix that without changing the API. > It's just that doing so would likely break code which was catching > ConvException explicitly, so if we do that, we might be forced to > introduce getOpt to replace getopt or something like that. But even if > we did that, the basic design wouldn't change, just what it's throwing > on failure. [...] Ideally, getopt should catch ConvExceptions (and whatever other exceptions that get thrown when a conversion fails, e.g., from a user-supplied delegate) and rethrow it with a better message. For example, "unable to convert 'abc' to int in option '-a'" instead of "std.exception.convException: illegal digit" or something similarly obscure, which is completely unhelpful to the end user. T -- Meat: euphemism for dead animal. -- Flora
