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
