Fixing valid options for std.getopt

[Jens Mueller]

Jonathan M Davis wrote:
> Personally, I'll all for requiring that multi-character flags use -- and not -, 
> and I _do_ think that it's problematic to allow multi-character flags to use -. 
> However, I'm not entirely against having a way to tell getopt to accept multi-
> character flags with a single - if people want that and it can work reasonably 
> without causing problems as long as people are careful about the flags that 
> their program accepts. It definitely shouldn't be the default behavior though.

If I add support for it, it won't be default.
I'm thinking about adding a configuration option
multiCharDoubleDashOnly (default), multiCharSingleDoubleDash (allow
additionally a single dash), and multiCharSingleDashOnly (only allows
single dash for long options).
multiCharSingleDoubleDash or multiCharSingleDashOnly imply that bundling
is turned off.

> However, given that getopt is a single function call with a variadic argument, 
> the only way that I can think of that you'd be able to tell it whether to 
> accept multi-character flags with a single - would be a template argument, and 
> I'd be very concerned that accepting multi-character flags with a single - 
> would make getopt overly complicated. I'd have to examine the implementation 
> though to see how much worse it would make it.

Using getopt's config enum should make it possible as I outlined above.
I hope this change keeps the code simple.

> It would probably have to change so that there is no difference
> between - and -- (both are treated like --), except that --ofbar.bin
> isn't accepted with your changes (you need either --of bar.bin or
> --of=bar.bin). So, treating - like -- isn't really going to do what
> the people who want multi-character flags with - would want anyway
> (and I do think that disallowing --ofbar.bin is the correct decision,
> so I'm not advising changing that).

Yeah. Long options (with whatever many dashes) and no space or equal sign
as separator is confusing. I'm only going to add this if there is a
strong case for it.

> So, I don't know. I'm generally against programs having multi-character flags 
> which work with -, and I'm definitely afraid that allowing such things with a 
> separate setting for getopt is going to overcomplicate getopt. Regardless, I 
> would be _completely_ against the default allowing it. So, I'd prefer that 
> getopt just have the one set of behaviors and disallow multi-character flags 
> with -, but I don't want to just reject it out of hand if others want it and 
> it's reasonably feasible without overcomplicating things.

So far we only have seen some examples of tools that are using single
dash multi-character options. Nobody so far has argued that this is a
good way of doing it which is kind of interesting.

> The real question is how the C getopt works, since that's what our getopt is 
> at least supposed to be modeled after (and given that it has the same name, 
> it's not unreasonable to expect essentially the same behavior). However, a 
> quick glance at getopt's man page makes it seem far more complicated than our 
> getopt, which I would consider to be undesirable. So, we may not want to quite 
> follow the C getopt. However, we should definitely look at how it handles the 
> flags and what it allows and try for something similar.

D's getopt is actually modeled after Perl's Getopt::Long
(http://perldoc.perl.org/Getopt/Long.html). Linux's getopt is actually
different in the details but I believe D's getopt is easy to use in
comparison.

Next I will add support for -tv where v can be of arbitrary type to
support -ofile.bin. This behavior is configurable via
noSpaceForShortOption. If set it implies no bundling. The other behavior
is noSpaceForShortOptionNumeric. I'm not sure yet whether defaulting to
noSpaceForShortOptionNumeric is good as it breaks code.

Many thanks to all for sharing your opinions.

Jens