On Saturday, March 24, 2018 09:59:44 H. S. Teoh via Digitalmars-d wrote: > And given the defensiveness surrounding std.getopt, my conclusion can > only be: dump std.getopt, roll my own. It's sad, since in general > Phobos design tends to be superior to its C++ counterparts. But we then > have warts like std.getopt that people refuse to acknowledge is a > problem. So be it.
I think that there are at least a couple alternatives to std.getopt on code.dlang.org if you want alternatives. Personally, the only complaints I've had with std.getopt is that bundling isn't the default and that it's not always easy to figure out whether an argument has been set or not. But at least the bundling can be configured, and getopt can probably be improved to work with Nullable so that it'll be easier to figure out whether an argument has been set. As for defensiveness, I'm not quite sure what you're referring to. The main point was that given how often getopt gets called in a program, improving its Big-O complexity isn't worth it, but there have been a number of improvements to getopt over the years, so it's not like we're not allowed to improve it. It's just that improving its Big-O complexity is kind of pointless. In any case, as Andrei said, if a new option can be added to fix your use case, then that shouldn't be a problem, though I have no clue how much of a pain that will be to implement, particularly since std.getopt isn't exactly simple. - Jonathan M Davis
