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

[Andrei Alexandrescu]

On 03/24/2018 09:36 AM, H. S. Teoh wrote:
> On Sat, Mar 24, 2018 at 08:27:48AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> [...]
>> At a point where a realistic benchmarks shows a need. Without a motivating
>> measurement, making getopt faster would be a waste of time.
> [...]
> 
> Guys, for crying out loud, my original complaint was not *performance*,
> but that the (strange) choice of algorithm for getopt resulted in the
> very counterintuitive behaviour that the order options are processed
> depends on the order of option declarations rather than the order they
> were specified on the command-line.

I'd have a difficult time interpreting the following as not 
performance-related:

> Well, looking at the implementation of std.getopt turned up the
> disturbing fact that the program's argument list is actually scanned
> *multiple times*, one for each possible option(!).  Besides the bogonity
> that whether or not searchPaths will be set prior to finding -l depends
> on the order of arguments passed to getopt(), this also represents an
> O(n*m) complexity in scanning program arguments, where n = number of
> arguments and m = number of possible options.

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.

> This makes it basically impossible
> to implement certain styles of option processing, such as that employed
> in the popular ImageMagick suite of tools, where it matters that options
> are processed in the order they are specified by the user, rather than
> some arbitrary (to a user who doesn't and shouldn't care to know the
> code) predetermined order.

This is an exaggeration. Yes you can't process with lambdas. You can 
always collect options first, process after. This is a well-supported 
use case.

> My complaint about the quadratic algorithm was not in the fact that it's
> quadratic, but that it exhibited this strange (and annoying!) behaviour,
> especially since the saner (IMO) non-quadratic algorithm would have been
> the expected choice in the first place, that would *not* have had this
> problem. It felt almost like we went out of our way just to make things
> counterintuitive, with slowness added as a cherry on top.

I want to be convinced. I think you'd need to build a better case on why 
you consider one behavior intuitive and the other counterintuitive.


Andrei