Am I reading this wrong, or is std.getopt *really* this stupid?

[Johannes Pfau]

Am Sat, 24 Mar 2018 17:24:28 -0400 schrieb Andrei Alexandrescu:

> On 3/24/18 12:59 PM, H. S. Teoh wrote:
>> On Sat, Mar 24, 2018 at 12:11:18PM -0400, Andrei Alexandrescu via
>> Digitalmars-d wrote:
>> [...]
>>> Anyhow. Right now the order of processing is the same as the lexical
>>> order in which flags are passed to getopt. There may be use cases for
>>> which that's the more desirable way to go about things, so if you
>>> author a PR to change the order you'd need to build an argument on why
>>> command-line order is better. FWIW the traditional POSIX doctrine
>>> makes behavior of flags independent of their order, which would imply
>>> the current choice is more natural.
>> 
>> So what about making this configurable?
> 
> That'd be great. I'm thinking something like an option
> std.getopt.config.commandLineOrder. Must be first option specified right
> after arguments. Sounds good?

I don't really understand why you want to this keep lexical order 
functionality. There's a well defined use case for command line order: 
Allowing users to write commands in a natural, left-to-right style, where 
options on the right are more specific: systemctl status -l ...

I've never heard of any use case where the lexical order of the arguments 
passed to getopt matters for parsing user supplied command arguments. Is 
there any use case for this?

I thought the only reason we have this lexical order parsing is because 
it's simpler to implement. But if we'll get the non-quadratic command-line 
order implementation there's no reason to keep and maintain the quadratic 
implementation.

-- 
Johannes