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

[H. S. Teoh]

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. 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.

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.


T

-- 
"You are a very disagreeable person." "NO."